From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 1 04:14:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21258 for ; Wed, 1 Nov 2000 04:14:30 -0500 (EST) Received: from standards (47.234.32.16:4441) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE0C1@standards.nortelnetworks.com>; Wed, 1 Nov 2000 3:57:01 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 65831 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Nov 2000 03:57:01 -0500 Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE0C0@standards.nortelnetworks.com>; Wed, 1 Nov 2000 3:57:00 -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 EAA23214 for ; Wed, 1 Nov 2000 04:12:52 -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 EAA23198 for ; Wed, 1 Nov 2000 04:12:51 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA03422; Wed, 1 Nov 2000 10:12:50 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA03411; Wed, 1 Nov 2000 10:12:48 +0100 (MET) X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Original-CC: MEGACO@standards.nortelnetworks.com References: <28560036253BD41191A10000F8BCBD110250C686@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39FFDE47.C8589131@lucent.com> Date: Wed, 1 Nov 2000 10:11:35 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Differences between ABNF and ASN.1 specifications X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Tom, I added the TerminationIDList construct _in my capacity as editor_. The original request came from other parties, with an eye towards future extensions. The construct is used in at least one place in the ASN.1, in AuditResult. The corresponding ABNF rule uses a list of terminationIDs as well. Finally, I fail to see how ABNF is more flexibile than ASN.1 for this particular issue. If there ever is a need to allow multiple TerminationIDs on a command (e.g. Add = T1, T2, T3 { ... }), then the ASN.1 syntax is in place, the ABNF has to be modified, right? Cheers, John Tom-PT Taylor wrote: > > John Segers added the terminationIdList construct with an eye to the > possible future, simply because ASN.1 is less flexible than ABNF. > > > -----Original Message----- > > From: Troy Cauble [mailto:troy@LUCENT.COM] > > Sent: Tuesday, October 31, 2000 1:52 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Differences between ABNF and ASN.1 specifications > > > > > > Terry L Anderson wrote: > > > > > > I notice two differences between the ABNF and ASN.1 > > specifications and I > > > am wondering if these are intentional or errors. > > > > > > 1. In ASN.1 > > > AmmRequest { > > > terminationID TerminationIDList, > > > etc. > > > while in ABNF > > > ammRequest contains TerminationID rather than TerminationIDList > > > > > > TerminationID in both cases can contain wildcards and so be > > effectively > > > a list, but the ASN.1 would allow a list of specific ids > > while the ABNF > > > would not. Is this intentional? > > > > > > > See the second "NOTE" at the beginning of > > section A.2. Most of the TerminationIDLists > > in the ASN.1 encoding are lists of one. > > > > (Why is that?) > > > > -troy > > -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 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 Nov 1 04:34:25 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA29664 for ; Wed, 1 Nov 2000 04:34:25 -0500 (EST) Received: from standards (47.234.32.16:4441) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE0FC@standards.nortelnetworks.com>; Wed, 1 Nov 2000 4:16:59 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 65909 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Nov 2000 04:16:59 -0500 Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE0FB@standards.nortelnetworks.com>; Wed, 1 Nov 2000 4:16:58 -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 EAA03113 for ; Wed, 1 Nov 2000 04:32:50 -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 EAA03101 for ; Wed, 1 Nov 2000 04:32:49 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA07373; Wed, 1 Nov 2000 10:32:48 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA07353; Wed, 1 Nov 2000 10:32:47 +0100 (MET) X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <39FF1250.E35C9067@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39FFE2F6.1B5CCC2B@lucent.com> Date: Wed, 1 Nov 2000 10:31:34 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Differences between ABNF and ASN.1 in ActionReply To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Terry, Having already responded to your first question, I only comment on the second point that you raised in this message. The difference between the ASN.1 and ABNF was not intentional. It is indeed the intention that the SEQUENCE of CommandReply be left empty if there is an error at the action level (section 8.2.2 has some text on what error codes to include at which level in a reply if malformed requests are received). As far as I can tell, the ABNF also allows an action reply to contain contextProperties AND commandReply: actionReply = CtxToken EQUAL ContextID LBRKT ( errorDescriptor / commandReply ) RBRKT commandReply = (( contextProperties [COMMA commandReplyList] ) / commandReplyList ) allows an action reply to contain contextProperties plus, optionally a list of command replies. Cheers, John Terry L Anderson wrote: [snip] > 2. earlier today Sankar Raman asked about ActionReply. In the ASN.1 > ActionReply contains > commandReply SEQUENCE OF CommandReply > which is required and a > contextReply which is optional > while in the ABNF > an ActionReply that contained an errorDescriptor cannot contain either a > contextProperties or a commandReplyList > > Is this intentional? Perhaps since SEQUENCE OF can be of zero length so > not really contain a CommandReply, but there is still the minor > difference that the ASN.1 permits a contextProperties and a commandReply > while the ASN.1 does not. > > -- > ------------------------------------------------------------ > Terry L Anderson mailto:tla@lucent.com > Tel:908.582.7013 Fax:908.582.6729 > Pager:800.759.8352 pin 1704572 1704572@skytel.com > Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 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 Nov 1 05:42:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28766 for ; Wed, 1 Nov 2000 05:42:40 -0500 (EST) Received: from standards (47.234.32.16:4613) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE118@standards.nortelnetworks.com>; Wed, 1 Nov 2000 5:25:13 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 65946 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Nov 2000 05:25:13 -0500 Received: from mars.hss.co.in (202.54.26.197:39659) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE117@standards.nortelnetworks.com>; Wed, 1 Nov 2000 5:25:11 -0500 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id eA1AfWC24695 for ; Wed, 1 Nov 2000 16:11:33 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525698A.0039AE14 ; Wed, 1 Nov 2000 16:00:01 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525698A.0039ADF5.00@sandesh.hss.hns.com> Date: Wed, 1 Nov 2000 16:05:36 +0530 Reply-To: samittal@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sachin Mittal Subject: Stopping a signal of type on/off To: MEGACO@STANDARDS.NORTELNETWORKS.COM Section E.10.3 defines ct/rsp as type on/off and the procedure of section E.10.5 says "When the MGC wants the MG to respond to a continuity test it sends a command to MG containing a signals descriptor with ct/rsp ......" and for stopping it says "The MGC determines when to remove the rsp signal...." But how to remove a signal of type on/off: 1. By sending a signal descriptor NOT containing the signal. 2. By sending a signal descriptor containing the signal. Moreover, if an on/off type signal is active and an event occurs, is the signal stopped (Keepactive not specified)? From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 1 07:47:45 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11842 for ; Wed, 1 Nov 2000 07:47:44 -0500 (EST) Received: from standards (47.234.32.16:3537) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE1D9@standards.nortelnetworks.com>; Wed, 1 Nov 2000 7:30:26 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 66184 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Nov 2000 07:30:26 -0500 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE1D8@standards.nortelnetworks.com>; Wed, 1 Nov 2000 7:30:26 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA04768; Wed, 1 Nov 2000 07:46:16 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA06335; Wed, 1 Nov 2000 07:46:19 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 1 Nov 2000 07:45:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E93D@whq-msgusr-02.pit.comms.marconi.com> Date: Wed, 1 Nov 2000 07:46:09 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Stopping a signal of type on/off X-To: "samittal@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM > But how to remove a signal of type on/off: > 1. By sending a signal descriptor NOT containing the signal. > 2. By sending a signal descriptor containing the signal. Choice 1 "A new SignalsDescriptor replaces any existing SignalsDescriptor. Any signals applied to the Termination not in the replacement descriptor shall be stopped, and new signals are applied, except as follows." > > Moreover, if an on/off type signal is active and an event occurs, > is the signal stopped (Keepactive not specified)? Yes Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 1 08:05:21 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16951 for ; Wed, 1 Nov 2000 08:05:20 -0500 (EST) Received: from standards (47.234.32.16:3537) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE1F6@standards.nortelnetworks.com>; Wed, 1 Nov 2000 7:47:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 66225 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Nov 2000 07:47:55 -0500 Received: from mars.hss.co.in (202.54.26.197:41544) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE1F4@standards.nortelnetworks.com>; Wed, 1 Nov 2000 7:47:54 -0500 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id eA1D4KC28414 for ; Wed, 1 Nov 2000 18:34:21 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525698A.0046C017 ; Wed, 1 Nov 2000 18:22:46 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525698A.0046BE87.00@sandesh.hss.hns.com> Date: Wed, 1 Nov 2000 18:33:45 +0530 Reply-To: sgautam@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sandeep Gautam Subject: Use of generic package event Cause To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, What happens when generic package event Cause ( g/cause) is present in the Events Descriptor. ( see section E.1.2).? How and when is this event detected and what do failure and general cause parameters sent in observed events descriptor refer to? Do they refer to the termination failure cause ? Does termination failure imply bringing the termination to OOS state? Thanx and regards, Sandeep Gautam From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 1 09:38:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12692 for ; Wed, 1 Nov 2000 09:38:01 -0500 (EST) Received: from standards (47.234.32.16:4316) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE24F@standards.nortelnetworks.com>; Wed, 1 Nov 2000 9:20:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 66345 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Nov 2000 09:20:21 -0500 Received: from drawbridge.ascend.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE24E@standards.nortelnetworks.com>; Wed, 1 Nov 2000 9:20:21 -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 GAA26416; Wed, 1 Nov 2000 06:28:15 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 1 Nov 2000 14:36:10 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id GAA13186; Wed, 1 Nov 2000 06:36:09 -0800 (PST) Received: from mastif.eng.ascend.com (mastif.eng.ascend.com [135.92.55.18]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id GAA25078; Wed, 1 Nov 2000 06:36:09 -0800 (PST) Received: from sramannt-pc ([135.92.55.142]) by mastif.eng.ascend.com (8.8.8+Sun/8.8.8) with SMTP id JAA16680; Wed, 1 Nov 2000 09:36:08 -0500 (EST) X-Sender: sraman@mastif.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <200011011436.JAA16680@mastif.eng.ascend.com> Date: Wed, 1 Nov 2000 09:37:22 -0500 Reply-To: Sankar Raman Sender: "Media Gateway Control (megaco)" From: Sankar Raman Subject: Re: Action Reply X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <28560036253BD41191A10000F8BCBD110250C684@zcard00g.ca.norte l.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA12692 At 12:02 PM 10/31/00 -0600, Tom-PT Taylor wrote: > > Commands are executed until the first one fails.  It may therefore be quite > typical to get a series of command results terminated by an errorDescriptor. This would work, however I disagree with this approach as it would be inconsistenet with the implied hierarchy of transaction->action->command. (just like an error in an action is indicated at the action level and not at the transaction level). I would think 1) ErrorDesc in ActionReply pertains to the action level ONLY independent of underlying commands. For e.g. if a contextID is invalid, the MG does not have to bother to look at the commands. It should be able to send an ActionReply with the error desc and no seq of command replies as they do not make sense. (Similar to transaction Reply that has a Choice of error desc or SEQ of action replies). 2) If the action is good but an individual command within the action fails (the case you have mentioned), then the error should be indicated in the command reply level and not the action level. (again, just like an error in an action is indicated at the action level and not at the transaction level) .For e.g. that action reply would have no error desc instead contain (x+1) command replies - the first x replies for the succesful ones and the (x+1) th reply for the failed one with the appropriate error desc. I feel, in the ActionReply, it should be a CHOICE between ErrorDesc and SEQ of Command Replies. If not, atleast make the rules between transactionreply(trans->action) and action reply (action->command) consistent. > > > -----Original Message----- > > From: Sankar Raman > [mailto:Sankar.Raman@ASCEND.COM] > > Sent: Tuesday, October 31, 2000 11:19 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Action Reply > > > > > > Referring to the standard: > > > > ActionReply ::= SEQUENCE > > { > >  contextId ContextID, > >  errorDescriptor ErrorDescriptor OPTIONAL, > >  contextReply ContextRequest OPTIONAL, > >  commandReply SEQUENCE OF CommandReply > > } > > > > Under what circumstances we could have both ErrorDescriptor > > and SEQ of CommandReply? Why is not ErrorDescriptor Vs > > SEQ of CommandReply a CHOICE ? > > > > Thanks > > > > Sankar Raman > > Lucent Technologies > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 1 10:12:21 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22805 for ; Wed, 1 Nov 2000 10:12:21 -0500 (EST) Received: from standards (47.234.32.16:4316) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE283@standards.nortelnetworks.com>; Wed, 1 Nov 2000 9:54:49 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 66420 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Nov 2000 09:54:49 -0500 Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE282@standards.nortelnetworks.com>; Wed, 1 Nov 2000 9:54:49 -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 KAA26120 for ; Wed, 1 Nov 2000 10:10:41 -0500 (EST) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA26116 for ; Wed, 1 Nov 2000 10:10:41 -0500 (EST) Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id KAA15605; Wed, 1 Nov 2000 10:08:53 -0500 (EST) X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD110250C686@zcard00g.ca.nortel.com> <39FFDE47.C8589131@lucent.com> Content-Type: multipart/mixed; boundary="------------E064CC084C06374B3B54E6F5" Message-ID: <3A003201.B4890C7@lucent.com> Date: Wed, 1 Nov 2000 10:08:52 -0500 Reply-To: Terry L Anderson Sender: "Media Gateway Control (megaco)" From: Terry L Anderson Organization: Lucent Technologies Subject: Re: Differences between ABNF and ASN.1 specifications X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------E064CC084C06374B3B54E6F5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Segers wrote: > Tom, > > I added the TerminationIDList construct _in my capacity as editor_. The > original request came from other parties, with an eye towards future > extensions. > > The construct is used in at least one place in the ASN.1, in > AuditResult. The corresponding ABNF rule uses a list of terminationIDs > as well. Yes, both ASN.1 and ABNF has the construct terminationIDList but my point was that the construct AmmRequest in ASN.1 uses this as the type of terminationID while ABNF ammRequest uses only TerminationID (NOT terminationIDList). Of course as pointed out the NOTE at the beginning of A.2 makes the two essentially equivalent except for details of encoding. > > > Finally, I fail to see how ABNF is more flexibile than ASN.1 for this > particular issue. If there ever is a need to allow multiple > TerminationIDs on a command (e.g. Add = T1, T2, T3 { ... }), then the > ASN.1 syntax is in place, the ABNF has to be modified, right? > > Cheers, > > John > > Tom-PT Taylor wrote: > > > > John Segers added the terminationIdList construct with an eye to the > > possible future, simply because ASN.1 is less flexible than ABNF. > > > > > -----Original Message----- > > > From: Troy Cauble [mailto:troy@LUCENT.COM] > > > Sent: Tuesday, October 31, 2000 1:52 PM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Differences between ABNF and ASN.1 specifications > > > > > > > > > Terry L Anderson wrote: > > > > > > > > I notice two differences between the ABNF and ASN.1 > > > specifications and I > > > > am wondering if these are intentional or errors. > > > > > > > > 1. In ASN.1 > > > > AmmRequest { > > > > terminationID TerminationIDList, > > > > etc. > > > > while in ABNF > > > > ammRequest contains TerminationID rather than TerminationIDList > > > > > > > > TerminationID in both cases can contain wildcards and so be > > > effectively > > > > a list, but the ASN.1 would allow a list of specific ids > > > while the ABNF > > > > would not. Is this intentional? > > > > > > > > > > See the second "NOTE" at the beginning of > > > section A.2. Most of the TerminationIDLists > > > in the ASN.1 encoding are lists of one. > > > > > > (Why is that?) > > > > > > -troy > > > > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 303 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572@skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------E064CC084C06374B3B54E6F5 Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;pager:800.759.8352 pin 1704572 tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks / Applications Group version:2.1 email;internet:tla@lucent.com title:DMTS adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA note;quoted-printable:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal)=0D=0A18E343126 / 10034134 x-mozilla-cpt:;-23792 fn:Terry L Anderson end:vcard --------------E064CC084C06374B3B54E6F5-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 1 10:17:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24378 for ; Wed, 1 Nov 2000 10:17:14 -0500 (EST) Received: from standards (47.234.32.16:4316) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE299@standards.nortelnetworks.com>; Wed, 1 Nov 2000 9:59:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 66451 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Nov 2000 09:59:43 -0500 Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE298@standards.nortelnetworks.com>; Wed, 1 Nov 2000 9:59:42 -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 KAA01664 for ; Wed, 1 Nov 2000 10:15:35 -0500 (EST) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA01660 for ; Wed, 1 Nov 2000 10:15:34 -0500 (EST) Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id KAA15732; Wed, 1 Nov 2000 10:13:54 -0500 (EST) X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <39FF1250.E35C9067@lucent.com> <39FFE2F6.1B5CCC2B@lucent.com> Content-Type: multipart/mixed; boundary="------------18618752D3FAA3A01D24A31D" Message-ID: <3A003330.33896C3C@lucent.com> Date: Wed, 1 Nov 2000 10:13:52 -0500 Reply-To: Terry L Anderson Sender: "Media Gateway Control (megaco)" From: Terry L Anderson Organization: Lucent Technologies Subject: Re: Differences between ABNF and ASN.1 in ActionReply X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------18618752D3FAA3A01D24A31D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Segers wrote: > Terry, > > Having already responded to your first question, I only comment on the > second point that you raised in this message. > > The difference between the ASN.1 and ABNF was not intentional. It is > indeed the intention that the SEQUENCE of CommandReply be left empty if > there is an error at the action level (section 8.2.2 has some text on > what error codes to include at which level in a reply if malformed > requests are received). > > As far as I can tell, the ABNF also allows an action reply to contain > contextProperties AND commandReply: > > actionReply = CtxToken EQUAL ContextID LBRKT > ( errorDescriptor / commandReply ) RBRKT > > commandReply = (( contextProperties [COMMA commandReplyList] ) / > commandReplyList ) > > allows an action reply to contain contextProperties plus, optionally a > list of command replies. My point was that ASN.1 permits an actionReply to contain an errorDescriptor as well as a commandReply or an errorDescriptor as well as a contextReply, while the ABNF does not - perhaps only an unuseful difference. Writing the ASN.1 to disallow the combination would have made it more complex. > > > Cheers, > > John > > Terry L Anderson wrote: > [snip] > > 2. earlier today Sankar Raman asked about ActionReply. In the ASN.1 > > ActionReply contains > > commandReply SEQUENCE OF CommandReply > > which is required and a > > contextReply which is optional > > while in the ABNF > > an ActionReply that contained an errorDescriptor cannot contain either a > > contextProperties or a commandReplyList > > > > Is this intentional? Perhaps since SEQUENCE OF can be of zero length so > > not really contain a CommandReply, but there is still the minor > > difference that the ASN.1 permits a contextProperties and a commandReply > > while the ASN.1 does not. > > > > -- > > ------------------------------------------------------------ > > Terry L Anderson mailto:tla@lucent.com > > Tel:908.582.7013 Fax:908.582.6729 > > Pager:800.759.8352 pin 1704572 1704572@skytel.com > > Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 303 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572@skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------18618752D3FAA3A01D24A31D Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;pager:800.759.8352 pin 1704572 tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks / Applications Group version:2.1 email;internet:tla@lucent.com title:DMTS adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA note;quoted-printable:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal)=0D=0A18E343126 / 10034134 x-mozilla-cpt:;-23792 fn:Terry L Anderson end:vcard --------------18618752D3FAA3A01D24A31D-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 1 10:58:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05846 for ; Wed, 1 Nov 2000 10:58:27 -0500 (EST) Received: from standards (47.234.32.16:4684) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE2C9@standards.nortelnetworks.com>; Wed, 1 Nov 2000 10:40:59 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 66520 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Nov 2000 10:40:59 -0500 Received: from cvis29.marconicomms.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE2C8@standards.nortelnetworks.com>; Wed, 1 Nov 2000 10:30:58 -0500 Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 1 Nov 2000 14:28:19 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-28) id OAA24124; Wed, 1 Nov 2000 14:28:17 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 8025698A.004F7C8C ; Wed, 1 Nov 2000 14:28:12 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <8025698A.004F7B3A.00@marconicomms.com> Date: Wed, 1 Nov 2000 14:28:06 +0000 Reply-To: Wayne Cutler Sender: "Media Gateway Control (megaco)" From: Wayne Cutler Subject: Re: Implementors' Guide v4 X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM In addition to the changes in section 9.1 of the implementors guide, can we add to 7.2.5 Audit Value table, the following information that can be obtained with the Audit Command: ContextID Termination Id Information Obtained All Specific (Non-null) Context Id in which the Termination currently exists Regards, Wayne. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 1 11:24:09 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14213 for ; Wed, 1 Nov 2000 11:24:08 -0500 (EST) Received: from standards (47.234.32.16:4684) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE304@standards.nortelnetworks.com>; Wed, 1 Nov 2000 11:06:38 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 66606 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Nov 2000 11:06:38 -0500 Received: from standards (47.234.32.16:4684) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE303@standards.nortelnetworks.com>; Wed, 1 Nov 2000 11:06:38 -0500 Message-ID: Date: Wed, 1 Nov 2000 11:06:38 -0500 Reply-To: Alan Whitton Sender: "Media Gateway Control (megaco)" From: Alan Whitton Subject: Loop around mailing list problems? To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, Can't seem to post anything this morning, keep getting a looparound error problem, what gives? Cheers, Alan From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 1 11:24:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14231 for ; Wed, 1 Nov 2000 11:24:09 -0500 (EST) Received: from standards (47.234.32.16:4684) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE30E@standards.nortelnetworks.com>; Wed, 1 Nov 2000 11:08:06 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 66620 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Nov 2000 11:08:06 -0500 Received: from standards (47.234.32.16:4684) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE30D@standards.nortelnetworks.com>; Wed, 1 Nov 2000 11:08:06 -0500 Message-ID: Date: Wed, 1 Nov 2000 11:08:06 -0500 Reply-To: Alan Whitton Sender: "Media Gateway Control (megaco)" From: Alan Whitton Subject: Last Call On NAS Package (Revisited for November) To: MEGACO@STANDARDS.NORTELNETWORKS.COM Folks, OK, so after looking things over the AUTHRES (or AUTHEX) event looks like it needs a little more information returned in it other than success or failure. Once a "call" is UP, the Modems have trained and now the End User's PC is connected to the ISP's Radius Server more than simply "authorization failure" can occur. Port limiting can occur (not enough virtual modems available to that customer's domain), or there can be a RADIUS server failure (and thus the user cannot log in). What I'd like to propose is either adding a reason code for the AUTHRES (or AUTHEX), or expand the reason codes for AUTHRES (or AUTHEX). The following reasons, come to mind: 1 other, unspecified 2 CLID was unacceptable (rejected by CLID filter) 3 CLID was blocked (rejected because blocked CLIDs not allowed) 4 dialed number is not acceptable 5 port limit or overflow port limit reached 6 no IP address available 7 all home gateways at capacity or admin state locked 8 port guarantee prevented call from being taken proxied to 9 RADIUS server rejected the request Cheers, Alan Whitton Holistic Metaservices Architect CVX SS7 Gateway Nortel Networks, From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 1 15:07:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13415 for ; Wed, 1 Nov 2000 15:07:39 -0500 (EST) Received: from standards (47.234.32.16:4892) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE3B3@standards.nortelnetworks.com>; Wed, 1 Nov 2000 14:50:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 66853 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Nov 2000 14:50:05 -0500 Received: from standards (47.234.32.16:4892) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE3B2@standards.nortelnetworks.com>; Wed, 1 Nov 2000 14:50:05 -0500 Message-ID: Date: Wed, 1 Nov 2000 14:50:05 -0500 Reply-To: Alan Whitton Sender: "Media Gateway Control (megaco)" From: Alan Whitton Subject: Re: Stopping a signal of type on/off X-To: Brian.Rosen@MARCONI.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Greetings, I am keenly interested in this one. How exactly would the message flow look like? Let me have a hack first, and we'll do this as part of an ADD (just to be different): From Controller TO Gateway ---> Transation = TransactionID1 { Context= $ { Add = TDMTermID { Termstate { TDMC/ec = off } }, EVENTS = eventID1 { CT/CMP }, SIGNALS = {CT/CT} } } From Gateway to Controller <--- Reply = TransactionID1 { Context = ContextID { Add=TDMTermID } } Thus our happy loopback COT test is now in place, and running on TDM connection TDMTermID, correct? Now the gateway wants to tell the controller that the test was passed correctly, so we have: From Gateway to Controller <--- Transaction = TransactionID5 { Context = ContextID { Notify = TDMTermID { ObservedEvents = eventID1 { CT/CMP {RES = 1} } } } } From Controller to Gateway ---> Reply = TransationID5{ Context = ContextID { Notify = TDMTermID }} Correct? Thus the Controller "knows" that the test has completed correctly. If the controller is simply now either doing a MODIFY to this context to "continue" the call, or a SUBTRACT to end the call, does it need to do anything to STOP the toning? I don't think so. Comments? Cheers, Alan Whitton From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 1 15:15:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15083 for ; Wed, 1 Nov 2000 15:15:07 -0500 (EST) Received: from standards (47.234.32.16:4892) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE3C7@standards.nortelnetworks.com>; Wed, 1 Nov 2000 14:57:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 66882 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Nov 2000 14:57:43 -0500 Received: from standards (47.234.32.16:4892) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE3C6@standards.nortelnetworks.com>; Wed, 1 Nov 2000 14:57:42 -0500 Message-ID: Date: Wed, 1 Nov 2000 14:57:42 -0500 Reply-To: Alan Whitton Sender: "Media Gateway Control (megaco)" From: Alan Whitton Subject: ServiceChange from a Dead Controller? To: MEGACO@STANDARDS.NORTELNETWORKS.COM {Apologies if this gets reposted, I never saw it appear} OK, I'd like to discuss what happens when a controller dies. Can the "new" (i.e. partner of old controller) send a message to the Gateway "I am the new controller, LISTEN TO ME NOW" ? (i.e. a servicechange message with that capability). In our model the partner controller has a different IP address, and it is important for the Gateway to know it has a NEW controller at a different IP address. Cheers, Alan Holistic Metaservices Architect CVX SS7 Gateway Nortel Networks, From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 1 15:19:56 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16440 for ; Wed, 1 Nov 2000 15:19:55 -0500 (EST) Received: from standards (47.234.32.16:4892) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE3DD@standards.nortelnetworks.com>; Wed, 1 Nov 2000 15:02:25 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 66913 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Nov 2000 15:02:25 -0500 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE3DC@standards.nortelnetworks.com>; Wed, 1 Nov 2000 15:02:25 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA17182; Wed, 1 Nov 2000 15:18:10 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA07140; Wed, 1 Nov 2000 15:18:13 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 1 Nov 2000 15:17:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E960@whq-msgusr-02.pit.comms.marconi.com> Date: Wed, 1 Nov 2000 15:18:01 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: ServiceChange from a Dead Controller? X-To: Alan Whitton To: MEGACO@STANDARDS.NORTELNETWORKS.COM Two answers depending on how "dead" the old controller is: If it's alive enough to send a message, the old one sends a ServiceChange to the MG. If it's dead, the MG will notice and then go through it's list of MGs to find the new one. The security issues associated with an unsolicted "I'm your new boss" were thought to be too great, and we decided NOT to allow such a message. Brian > -----Original Message----- > From: Alan Whitton [mailto:awhitton@NORTELNETWORKS.COM] > Sent: Wednesday, November 01, 2000 2:58 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: ServiceChange from a Dead Controller? > > > {Apologies if this gets reposted, I never saw it appear} > OK, > > I'd like to discuss what happens when a controller dies. Can the "new" > (i.e. partner of old controller) send a message to the > Gateway "I am the > new controller, LISTEN TO ME NOW" ? (i.e. a servicechange > message with that > capability). > > In our model the partner controller has a different IP > address, and it is > important for the Gateway to know it has a NEW controller at > a different IP > address. > > Cheers, > Alan > > Holistic Metaservices Architect > CVX SS7 Gateway > Nortel Networks, > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 1 18:48:46 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05567 for ; Wed, 1 Nov 2000 18:48:45 -0500 (EST) Received: from standards (47.234.32.16:1991) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE45A@standards.nortelnetworks.com>; Wed, 1 Nov 2000 18:31:24 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 67074 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Nov 2000 18:31:24 -0500 Received: from standards (47.234.32.16:1991) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE459@standards.nortelnetworks.com>; Wed, 1 Nov 2000 18:31:24 -0500 Message-ID: Date: Wed, 1 Nov 2000 18:31:24 -0500 Reply-To: Alan Whitton Sender: "Media Gateway Control (megaco)" From: Alan Whitton Subject: Re: ServiceChange from a Dead Controller? To: MEGACO@STANDARDS.NORTELNETWORKS.COM All right, Security is good, but if it's a message from a machine on the Gateway's list, wouldn't that be the same? The concern I have is that if the gateway "ignores" messages from a new controller, until it figures out that it's OLD controller is dead, you'll have a fair number of calls "fall on the floor". Is there any way around losing those calls? Cheers, Alan On Wed, 1 Nov 2000 15:18:01 -0500, Rosen, Brian wrote: >Two answers depending on how "dead" the old controller is: > >If it's alive enough to send a message, the old one sends a >ServiceChange to the MG. > >If it's dead, the MG will notice and then go through it's list of MGs >to find the new one. > >The security issues associated with an unsolicted "I'm your new boss" were >thought to be too great, and we decided NOT to allow such a message. > >Brian > >> -----Original Message----- >> From: Alan Whitton [mailto:awhitton@NORTELNETWORKS.COM] >> Sent: Wednesday, November 01, 2000 2:58 PM >> To: MEGACO@STANDARDS.NORTELNETWORKS.COM >> Subject: ServiceChange from a Dead Controller? >> >> >> {Apologies if this gets reposted, I never saw it appear} >> OK, >> >> I'd like to discuss what happens when a controller dies. Can the "new" >> (i.e. partner of old controller) send a message to the >> Gateway "I am the >> new controller, LISTEN TO ME NOW" ? (i.e. a servicechange >> message with that >> capability). >> >> In our model the partner controller has a different IP >> address, and it is >> important for the Gateway to know it has a NEW controller at >> a different IP >> address. >> >> Cheers, >> Alan >> >> Holistic Metaservices Architect >> CVX SS7 Gateway >> Nortel Networks, >> From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 1 23:09:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06927 for ; Wed, 1 Nov 2000 23:09:14 -0500 (EST) Received: from standards (47.234.32.16:4042) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE533@standards.nortelnetworks.com>; Wed, 1 Nov 2000 22:51:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 67360 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Nov 2000 22:51:54 -0500 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE52E@standards.nortelnetworks.com>; Wed, 1 Nov 2000 22:41:53 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eA23vjZ20128; Thu, 2 Nov 2000 04:57:45 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA16360; Thu, 2 Nov 2000 04:57:44 +0100 (MET) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA22635; Thu, 2 Nov 2000 04:57:42 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <8025698A.004F7B3A.00@marconicomms.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A00B30E.F9C17AE3@ericsson.com> Date: Thu, 2 Nov 2000 11:19:26 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Implementors' Guide v4 X-To: Wayne Cutler To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Wayne, Yes this certainly seems to be a valid case. Tom - can you add this to the extra IETF issues TD that you bring into the meeting? Cheers, Christian Wayne Cutler wrote: > > In addition to the changes in section 9.1 of the implementors guide, can we add > to 7.2.5 Audit Value table, the following information that can be obtained with > the Audit Command: > > ContextID Termination Id Information Obtained > > All Specific (Non-null) Context Id in which the > Termination currently exists > > Regards, > Wayne. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 1 23:47:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15938 for ; Wed, 1 Nov 2000 23:47:52 -0500 (EST) Received: from standards (47.234.32.16:1702) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE550@standards.nortelnetworks.com>; Wed, 1 Nov 2000 23:30:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 67406 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Nov 2000 23:30:39 -0500 Received: from menyapa.cc.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE54F@standards.nortelnetworks.com>; Wed, 1 Nov 2000 23:20:38 -0500 Received: from columbia.edu (tw120bsc.cpmc.columbia.edu [156.111.237.67]) by menyapa.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id XAA03145 for ; Wed, 1 Nov 2000 23:36:32 -0500 (EST) X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 References: <5713E3714F03D4118AB9009027D5B3A23D0ACF@NT-RMNA-EXCH> <39F9BD3A.2343BEAD@americasm10.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A00EFD0.863DFC1D@columbia.edu> Date: Wed, 1 Nov 2000 23:38:40 -0500 Reply-To: Xiaotao Wu Sender: "Media Gateway Control (megaco)" From: Xiaotao Wu Subject: Re: Implementors' Guide v4 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit It's not there now. Does any one know where I can find it? Thanks! -Xiaotao Michael Brown wrote: > The .zip suffix was left off of the link. Access up to the Incoming directory > and grab the file from there. > > Bob Lukas wrote: > > > I'm having trouble accessing it: > > > > Internet Explorer reports FTP error: > > 550/avc-site/Incoming/H248_Implementors_Guide_v4/:No such file or directory > > > > -----Original Message----- > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > > Sent: Friday, October 27, 2000 12:40 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Implementors' Guide v4 > > > > G'Day all, > > > > The H.248 Implementors' Guide Version 4 can now be found at: > > > > ftp://standard.pictel.com/avc-site/Incoming/H248_Implementors_Guide_v4 > > > > A summary of changes can be found at the front. > > > > Please provide your comments on the changes in the guide ASAP. I will be > > submitting it on Monday. Additional clarifications/corrections will need > > to come in seperately to the SG16 meeting. > > > > It would be good if some can also provide some text on clarifying case > > sensitivity. > > > > Tom: can you please compile a list of corrections/clarifications from > > Monday onwards as I won't be in regular contact with email? > > > > Cheers, Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 2 01:42:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA01066 for ; Thu, 2 Nov 2000 01:42:52 -0500 (EST) Received: from standards (47.234.32.16:3416) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE60D@standards.nortelnetworks.com>; Thu, 2 Nov 2000 1:21:53 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 67597 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 01:21:53 -0500 Received: from mailcity.com (fes-qout.whowhere.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE5E1@standards.nortelnetworks.com>; Thu, 2 Nov 2000 1:11:52 -0500 Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Wed Nov 1 22:27:23 2000 Mime-Version: 1.0 X-Sent-Mail: off X-Mailer: MailCity Service X-Sender-Ip: 216.6.89.98 Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Message-ID: Date: Wed, 1 Nov 2000 22:27:23 -0800 Reply-To: kris_albert@lycos.com Sender: "Media Gateway Control (megaco)" From: Kris Albert Organization: Lycos Communications (http://comm.lycos.com:80) Subject: Re: Signal lists X-To: Christian.Groves@ERICSSON.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Christian, I have few questions on your explanation. > [CHG] I guess you can view this is several ways. The KeepActive on ALL > signals certainly makes sense when you don't want any interruption. But > is it erroneous to specify Keepactive on different signals? Certainly > weird behaviour but you may want the initial part of a message to play > irrespective of what event happens and you don't care about the rest of > the signal. I would say that the Keepactive pertains to a moment in time > in the playback of a message. > ie. Signal list = (s1ka, s2, s3, s4ka) > If you receive an event when S1KA is playing the whole list plays. > If you receive an event when S2 is playing the whole list stops. I am not able to understand your example here. It is specified in MEGACO that " Normally, recognition of an event shall cause any active signals to stop. When KeepActive is specified in the event, the MG shall not interrupt any signals active on the Termination on which the event is detected." how does the 'KeepActive' status of signals matter here. Only KeepActive Flag associated with Event Defination should be considered. Otherwise Event Defination should have a embedded Signal Descriptor. I will appriciate if you please further explain your example w.r.t. the arrival of new signal descriptor with the same Signal list. Always, Kris Get FREE Email/Voicemail with 15MB at Lycos Communications at http://comm.lycos.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 2 07:48:26 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04602 for ; Thu, 2 Nov 2000 07:48:26 -0500 (EST) Received: from standards (47.234.32.16:4913) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE7AA@standards.nortelnetworks.com>; Thu, 2 Nov 2000 7:30:53 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 68186 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 07:30:53 -0500 Received: from zrchh190 (47.158.65.22:45867) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE7A9@standards.nortelnetworks.com>; Thu, 2 Nov 2000 7:20:52 -0500 Received: from zrtps06s.us.nortel.com by zrchh190; Thu, 2 Nov 2000 06:36:01 -0600 Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Thu, 2 Nov 2000 07:35:11 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 2 Nov 2000 07:35:11 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD110250C6B2@zcard00g.ca.nortel.com> Date: Thu, 2 Nov 2000 07:35:07 -0500 Reply-To: "Taylor, Tom-PT" Sender: "Media Gateway Control (megaco)" From: "Taylor, Tom-PT" Subject: Re: Signal lists X-To: "kris_albert@lycos.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Signals can also have a KeepActive flag. > -----Original Message----- > From: Kris Albert [mailto:kris_albert@LYCOS.COM] > Sent: Thursday, November 02, 2000 1:27 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Signal lists > > > Hi Christian, > I have few questions on your explanation. > > > [CHG] I guess you can view this is several ways. The > KeepActive on ALL > > signals certainly makes sense when you don't want any > interruption. But > > is it erroneous to specify Keepactive on different signals? > Certainly > > weird behaviour but you may want the initial part of a > message to play > > irrespective of what event happens and you don't care about > the rest of > > the signal. I would say that the Keepactive pertains to a > moment in time > > in the playback of a message. > > ie. Signal list = (s1ka, s2, s3, s4ka) > > If you receive an event when S1KA is playing the whole list plays. > > If you receive an event when S2 is playing the whole list stops. > > I am not able to understand your example here. > It is specified in MEGACO that " Normally, recognition of an > event shall cause any active signals to stop. When KeepActive > is specified in the event, the MG shall not interrupt any > signals active on the Termination on which the event is detected." > > how does the 'KeepActive' status of signals matter here. Only > KeepActive Flag associated with Event Defination should be > considered. Otherwise Event Defination should have a embedded > Signal Descriptor. > > I will appriciate if you please further explain your example > w.r.t. the arrival of new signal descriptor with the same > Signal list. > > > Always, > Kris > > > > Get FREE Email/Voicemail with 15MB at Lycos Communications at http://comm.lycos.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 2 07:58:51 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07055 for ; Thu, 2 Nov 2000 07:58:51 -0500 (EST) Received: from standards (47.234.32.16:4913) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE7C5@standards.nortelnetworks.com>; Thu, 2 Nov 2000 7:41:26 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 68223 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 07:41:26 -0500 Received: from mailcity.com (fes-qout.whowhere.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE7C4@standards.nortelnetworks.com>; Thu, 2 Nov 2000 7:41:26 -0500 Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Thu Nov 2 04:57:08 2000 Mime-Version: 1.0 X-Sent-Mail: off X-Mailer: MailCity Service X-Sender-Ip: 216.6.89.98 Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Message-ID: Date: Thu, 2 Nov 2000 04:57:08 -0800 Reply-To: kris_albert@lycos.com Sender: "Media Gateway Control (megaco)" From: Kris Albert Organization: Lycos Communications (http://comm.lycos.com:80) Subject: Re: Signal lists X-To: taylor@AMERICASM01.NT.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit ----- > Signals can also have a KeepActive flag. That's true, but my question is different, I want to ask whether on the detection of event, do we process only the KeepActive flag associated with Events, or do we also consider the KeepActive flag associated with the active Signals. thanks Kris > > > -----Original Message----- > > From: Kris Albert [mailto:kris_albert@LYCOS.COM] > > Sent: Thursday, November 02, 2000 1:27 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Signal lists > > > > > > Hi Christian, > > I have few questions on your explanation. > > > > > [CHG] I guess you can view this is several ways. The > > KeepActive on ALL > > > signals certainly makes sense when you don't want any > > interruption. But > > > is it erroneous to specify Keepactive on different signals? > > Certainly > > > weird behaviour but you may want the initial part of a > > message to play > > > irrespective of what event happens and you don't care about > > the rest of > > > the signal. I would say that the Keepactive pertains to a > > moment in time > > > in the playback of a message. > > > ie. Signal list = (s1ka, s2, s3, s4ka) > > > If you receive an event when S1KA is playing the whole list plays. > > > If you receive an event when S2 is playing the whole list stops. > > > > I am not able to understand your example here. > > It is specified in MEGACO that " Normally, recognition of an > > event shall cause any active signals to stop. When KeepActive > > is specified in the event, the MG shall not interrupt any > > signals active on the Termination on which the event is detected." > > > > how does the 'KeepActive' status of signals matter here. Only > > KeepActive Flag associated with Event Defination should be > > considered. Otherwise Event Defination should have a embedded > > Signal Descriptor. > > > > I will appriciate if you please further explain your example > > w.r.t. the arrival of new signal descriptor with the same > > Signal list. > > > > > > Always, > > Kris > > > > > > > > Get FREE Email/Voicemail with 15MB at Lycos Communications at > http://comm.lycos.com > > Get FREE Email/Voicemail with 15MB at Lycos Communications at http://comm.lycos.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 2 08:18:13 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11651 for ; Thu, 2 Nov 2000 08:18:13 -0500 (EST) Received: from standards (47.234.32.16:4913) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE805@standards.nortelnetworks.com>; Thu, 2 Nov 2000 7:58:52 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 68258 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 07:58:51 -0500 Received: from zrchh190 (47.158.65.22:47995) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE7DF@standards.nortelnetworks.com>; Thu, 2 Nov 2000 7:48:51 -0500 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by zrchh190; Thu, 2 Nov 2000 07:05:05 -0600 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Thu, 2 Nov 2000 08:04:08 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 2 Nov 2000 08:04:06 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD110250C6B3@zcard00g.ca.nortel.com> Date: Thu, 2 Nov 2000 08:04:04 -0500 Reply-To: "Taylor, Tom-PT" Sender: "Media Gateway Control (megaco)" From: "Taylor, Tom-PT" Subject: Re: Implementors' Guide v4 X-To: Xiaotao Wu To: MEGACO@STANDARDS.NORTELNETWORKS.COM You can get it at ftp://standard.pictel.com/avc-site/0011_Gen/APC-1997.zip Other documents of interest in the same directory are: APC-1950: Liaison To SG 12, SG 13 And SG 16 Asking For Guidance On Quality Of Services to be Supported with the BICC Protocol Source: ITU-T SG 11 There are implications for us because of Study Group 11 proposals to restructure H.248 to separate bearer-related information from media-related information and put the former in LocalControl. In concrete terms, this would take the c= line and maybe other information and place it there. It would mean a completely different approach to ATM from the one in draft-ietf-mmusic-sdp-atm-02.txt. APC-1952: Support of directionality in "H.248 Annex K - Announcement Package" Source: ITU-T SG 11 APC-1954: H.324 Annex C multimedia call package for H.248 Source: Lucent Technologies, NTT DoCoMo APC-1960: Proposal to create an SDL representation of H.248 Source: Lucent Technologies APC-1995: Issues for H.248 implementors' guide Source: Lucent Technologies APC-1998: Draft H.248 Annex K - Generic Announcement Package Source: Editor (Christian Groves) APC-1999: Draft H.248 Annex L - Error Code and Service Change Reason Description Source: Editor (Christian Groves) This provides documentation required before we can register our error codes and service change reasons with IANA. However, note some proposed changes to the meanings of some of the codes in the base text. APC-2000: H.248 Annex x - Load Control Package Source: Ericsson APC-2001: Direction in H.248 Annex K Source: Ericsson APC-2002: Signal on Root for H.248v2 Source: Ericsson APC-2007: Editorial changes to Annex H to H.248 Source: Editor (Alf Heidermark) APC-2008: Editorial changes to Annex I to H.248 Source: Editor (Alf Heidermark) > -----Original Message----- > From: Xiaotao Wu [mailto:xw71@COLUMBIA.EDU] > Sent: Wednesday, November 01, 2000 11:39 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Implementors' Guide v4 > > > It's not there now. > Does any one know where I can find it? Thanks! > > -Xiaotao > > Michael Brown wrote: > > > The .zip suffix was left off of the link. Access up to the > Incoming directory > > and grab the file from there. > > > > Bob Lukas wrote: > > > > > I'm having trouble accessing it: > > > > > > Internet Explorer reports FTP error: > > > 550/avc-site/Incoming/H248_Implementors_Guide_v4/:No such > file or directory > > > > > > -----Original Message----- > > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > > > Sent: Friday, October 27, 2000 12:40 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Implementors' Guide v4 > > > > > > G'Day all, > > > > > > The H.248 Implementors' Guide Version 4 can now be found at: > > > > > > ftp://standard.pictel.com/avc-site/Incoming/H248_Implementors_Guide_v4 > > > > A summary of changes can be found at the front. > > > > Please provide your comments on the changes in the guide ASAP. I will be > > submitting it on Monday. Additional clarifications/corrections will need > > to come in seperately to the SG16 meeting. > > > > It would be good if some can also provide some text on clarifying case > > sensitivity. > > > > Tom: can you please compile a list of corrections/clarifications from > > Monday onwards as I won't be in regular contact with email? > > > > Cheers, Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 2 08:18:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11662 for ; Thu, 2 Nov 2000 08:18:14 -0500 (EST) Received: from standards (47.234.32.16:4913) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE813@standards.nortelnetworks.com>; Thu, 2 Nov 2000 8:00:42 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 68259 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 08:00:41 -0500 Received: from zrchh190 (47.158.65.22:48217) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE7E0@standards.nortelnetworks.com>; Thu, 2 Nov 2000 7:50:41 -0500 Received: from zrtps06s.us.nortel.com by zrchh190; Thu, 2 Nov 2000 07:07:01 -0600 Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Thu, 2 Nov 2000 08:06:15 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 2 Nov 2000 08:06:15 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD110250C6B4@zcard00g.ca.nortel.com> Date: Thu, 2 Nov 2000 08:06:13 -0500 Reply-To: "Taylor, Tom-PT" Sender: "Media Gateway Control (megaco)" From: "Taylor, Tom-PT" Subject: Re: Signal lists X-To: "kris_albert@lycos.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM You process both. The obvious algorithm is: 1) Check for event flag. If there is one, leave signals playing. 2) Otherwise check flag for each signal and keep playing or terminate as indicated. > -----Original Message----- > From: Kris Albert [mailto:kris_albert@lycos.com] > Sent: Thursday, November 02, 2000 7:57 AM > To: Taylor, Tom-PT [NORSE:B901:EXCH] > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Signal lists > > > > ----- > > Signals can also have a KeepActive flag. > > That's true, but my question is different, I want to ask > whether on the detection of event, do we process only the > KeepActive flag associated with Events, or do we also > consider the KeepActive flag associated with the active Signals. > > thanks > Kris > > > > > > -----Original Message----- > > > From: Kris Albert [mailto:kris_albert@LYCOS.COM] > > > Sent: Thursday, November 02, 2000 1:27 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Signal lists > > > > > > > > > Hi Christian, > > > I have few questions on your explanation. > > > > > > > [CHG] I guess you can view this is several ways. The > > > KeepActive on ALL > > > > signals certainly makes sense when you don't want any > > > interruption. But > > > > is it erroneous to specify Keepactive on different signals? > > > Certainly > > > > weird behaviour but you may want the initial part of a > > > message to play > > > > irrespective of what event happens and you don't care about > > > the rest of > > > > the signal. I would say that the Keepactive pertains to a > > > moment in time > > > > in the playback of a message. > > > > ie. Signal list = (s1ka, s2, s3, s4ka) > > > > If you receive an event when S1KA is playing the whole > list plays. > > > > If you receive an event when S2 is playing the whole list stops. > > > > > > I am not able to understand your example here. > > > It is specified in MEGACO that " Normally, recognition of an > > > event shall cause any active signals to stop. When KeepActive > > > is specified in the event, the MG shall not interrupt any > > > signals active on the Termination on which the event is detected." > > > > > > how does the 'KeepActive' status of signals matter here. Only > > > KeepActive Flag associated with Event Defination should be > > > considered. Otherwise Event Defination should have a embedded > > > Signal Descriptor. > > > > > > I will appriciate if you please further explain your example > > > w.r.t. the arrival of new signal descriptor with the same > > > Signal list. > > > > > > > > > Always, > > > Kris > > > > > > > > > > > > Get FREE Email/Voicemail with 15MB at Lycos Communications at > > http://comm.lycos.com > > > > > > > Get FREE Email/Voicemail with 15MB at Lycos Communications at http://comm.lycos.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 2 08:30:17 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14648 for ; Thu, 2 Nov 2000 08:30:16 -0500 (EST) Received: from standards (47.234.32.16:4913) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE859@standards.nortelnetworks.com>; Thu, 2 Nov 2000 8:12:46 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 68351 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 08:12:45 -0500 Received: from central.ishidataiseisha.co.jp (210.233.47.146:3944) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE827@standards.nortelnetworks.com>; Thu, 2 Nov 2000 8:02:44 -0500 Received: from internetpro ([206.125.87.24]) by central.ishidataiseisha.co.jp (Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997)) with SMTP id 4925698B.0032F7BD; Mon, 2 Nov 1970 18:17:31 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Message-ID: Date: Thu, 2 Nov 2000 08:12:45 -0500 Reply-To: pooperbulker@HOTMAIL.COM Sender: "Media Gateway Control (megaco)" From: pooperbulker@HOTMAIL.COM Subject: Strong Buy Recommendation (CPHX) X-To: poopeybulker@hotmail.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM OTC Spotlight's previous BUY ALERTS have gained over 367 % !!! Congratulations to those that participated in our previous alerts: CNXX from $ 1.94 to $4.84, ACEN from $ .18 to $ .85, and SRGL from $5.63 to $10.75! STRONG BUY: Clements Golden Phoenix Enterprises, Inc. OTCBB: CPHX BUY AT $1.88 SELL TARGET $6.50 SPECIAL ALERT... CPHX AWARDED EXCLUSIVE DISTRIBUTION RIGHTS TO SUPPLY CITRUS PRODUCTS TO MILLIONS OF CHINESE CONSUMERS ! CPHX DOMINATES THE $10 BILLION CITRUS PRODUCTS MARKET IN CHINA'S NEW GROWING ECONOMY !!! Clements Golden Phoenix Enterprises (CPHX) is capitalizing on China's recent acceptance into the World Trade Organization (WTO) coupled with the lifting of a 20-year ban on importing American citrus, thus creating perhaps the most financially explosive opportunity ever in that nation. These perfectly timed political maneuvers have vaulted CPHX into the position of becoming the "Minute Maid" or "Tropicana" of China to the country's 1.2 BILLION people. A key element in the purchase of CPHX shares is that the stock is extremely undiscovered and undervalued. During the 2 months that shares have been trading, market conditions have limited the exposure of CPHX to new investors. Even a 2 for 1 (forward) split that took place earlier this month went practically unnoticed. This enhances the opportunity for profit with CPHX trading near its low while revenues soar! Armed with major U.S. and Chinese political backing, CPHX has partnered with the largest dairy and consumer foods distributors throughout China. The exclusive licensing and distribution awarded to CPHX follows the Government of China's program to make citrus products and juices more readily available and affordable while promoting the awareness of health and nutrition. As China makes rapid leaps to catch up to worldwide standards, China has addressed the fact that it's citrus production is less than one-fourth of what the U.S. produces while having 5 times the population. Market research performed by Tropicana Juices owned by PepesiCo (NYSE: PEP) and Minute Maid owned by Coca Cola (NYSE: KO) have forecast annual sales of citrus products to be in the $BILLIONS for a nation in a frenzy for the fresh fruits and juices they have gone so long without. The vast, "wide open" citrus market will eventually lead to joint ventures, partnerships, or perhaps much more in the future between the major players in this arena now that ground has been broken. OTCBB: CPHX Recent Price: $1.88 52 Week High/Low: $4.19 - $1.88 Shares Outstanding: 28.5 Million Float: 1.5 Million Target Price: $6.50 The expectation of astronomical sales is bolstered by China's friendly attitude and environment towards CPHX to capture significant market share. As a new WTO member, the eyes of many nations are tracking China's handling and progress of citrus importation. This includes the drastic lowering of tariffs on citrus, juices, and frozen concentrate to keep in line with the standard trade practices of other WTO member nations. Our research on CPHX clearly reveals that its exponential growth has not yet been noticed by investors. Increased attention with expanding volume is expected as strong company news is released. We anticipate many other well known newsletters will also be exposing CPHX to their subscribers in the near term. With its low float and undervalued stock price, CPHX has the potential to outperform even our best recommendations in the past few months! DISCLAIMER: OTC Spotlight Newsletter cautions that small and micro-cap stocks are high-risk investments and that some or all investment dollars can be lost. We suggest you consult a professional investment advisor before purchasing any stock. All opinions expressed on the featured company are the opinions of OTC Spotlight. All information concerning the companies is received directly from the companies profiled and/or outside interviews conducted by OTC Spotlight. OTC Spotlight recommends you use the information found here as an initial starting point for conducting your own research and conduct your own due diligence on the featured company in order to determine your own personal opinion of the company before investing. OTC Spotlight assumes all information to be truthful and reliable; however, we cannot and do not warrant or guarantee the accuracy of this information. All statements contained herein are deemed to be factual as of the date of this report and as such are subject to change without notice. OTC Spotlight is not an Investment Advisor, Financial Planning Service or a Stock Brokerage Firm and in accordance with such OTC Spotlight is not offering investment advice or promoting any investment strategies. OTC Spotlight is not offering securities for sale or solicitation of any offer to buy or sell securities. An offer to buy or sell can be made only with accompanying disclosure documents and only in the states and provinces for which they are approved. Any reference in the newsletter to past performance(s) of companies previously profiled in the newsletter are specially selected to be referenced based on the favorable performance of said companies and the companies referenced may not be representative of all past profiles as not all past profiles have performed as well. Please remember that past performance does not predict future results which is why it's called "past performance". On occasion OTC Spotlight receives compensation from a third party in relation to the company being profiled in its newsletter sent to our subscribers. In such a case OTC Spotlight directly mentions this in its newsletter sent to our subscribers along with the exact form and amount of compensation. OTC Spotlight has received fi ve thousand free trading shares from a third party for the dissemination of this company profile. OTC Spotlight, its affiliates, associates, relatives and anyone associated with OTC Spotlight in any manner reserves the right to either buy or sell shares in the profiled company's stock, either before the date of the profile, during the date of the profile or at any time after the date of the profile. We have an inherent conflict of interest by sending the newsletter at the same time we may own stock in the same company or even have been paid compensation at the time of the profile/promotion. We reserve the right to sell shares at anytime, even during the time period in which we are profiling a company. OTC Spotlight may profile companies trading in fast moving, highly volatile markets, and any reader of this newsletter should observe the trading behavior of any profiled company prior to investing. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 2 08:48:33 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19668 for ; Thu, 2 Nov 2000 08:48:32 -0500 (EST) Received: from standards (47.234.32.16:4913) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE887@standards.nortelnetworks.com>; Thu, 2 Nov 2000 8:30:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 68479 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 08:30:34 -0500 Received: from mars.hss.co.in (202.54.26.197:56134) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE886@standards.nortelnetworks.com>; Thu, 2 Nov 2000 8:30:29 -0500 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id eA2DkqC22382 for ; Thu, 2 Nov 2000 19:16:53 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525698B.004AA514 ; Thu, 2 Nov 2000 19:05:19 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525698B.004AA312.00@sandesh.hss.hns.com> Date: Thu, 2 Nov 2000 19:10:14 +0530 Reply-To: sgautam@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sandeep Gautam Subject: Re: Signal lists To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, The keepactive flag that comes in the signals descriptor is not remebered. The fact whether the currently playing signal arrived with a keepcative flag or not is immaterial for subsequent processing. According to text Signals present in the replacement descriptor and containing the KeepActive flagshall be continued if they are currently playing and have not already completed. If a replacement signal descriptor contains a signal that is not currently playing and contains the KeepActive flag, that signal SHALL be ignored Thus the scope of keepactive flag is limited to the signal descriptor processing of the descriptor in which it arrived. When subsequently an event is detected the stopping of the signal( which may have arrived with a keepactive flag) is solely governed by the keepactive flag associated with the event that is detected. Thus point no. 2 is invalid. If the KA of event detected is not set then the MG should stop application of all active signals. Is this understanding correct? Regards, Sandy G 1) Check for event flag. If there is one, leave signals playing. 2) Otherwise check flag for each signal and keep playing or terminate as indicated. > -----Original Message----- > From: Kris Albert [mailto:kris_albert@lycos.com] > Sent: Thursday, November 02, 2000 7:57 AM > To: Taylor, Tom-PT [NORSE:B901:EXCH] > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Signal lists > > > > ----- > > Signals can also have a KeepActive flag. > > That's true, but my question is different, I want to ask > whether on the detection of event, do we process only the > KeepActive flag associated with Events, or do we also > consider the KeepActive flag associated with the active Signals. > > thanks > Kris > > > > > > -----Original Message----- > > > From: Kris Albert [mailto:kris_albert@LYCOS.COM] > > > Sent: Thursday, November 02, 2000 1:27 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Signal lists > > > > > > > > > Hi Christian, > > > I have few questions on your explanation. > > > > > > > [CHG] I guess you can view this is several ways. The > > > KeepActive on ALL > > > > signals certainly makes sense when you don't want any > > > interruption. But > > > > is it erroneous to specify Keepactive on different signals? > > > Certainly > > > > weird behaviour but you may want the initial part of a > > > message to play > > > > irrespective of what event happens and you don't care about > > > the rest of > > > > the signal. I would say that the Keepactive pertains to a > > > moment in time > > > > in the playback of a message. > > > > ie. Signal list = (s1ka, s2, s3, s4ka) > > > > If you receive an event when S1KA is playing the whole > list plays. > > > > If you receive an event when S2 is playing the whole list stops. > > > > > > I am not able to understand your example here. > > > It is specified in MEGACO that " Normally, recognition of an > > > event shall cause any active signals to stop. When KeepActive > > > is specified in the event, the MG shall not interrupt any > > > signals active on the Termination on which the event is detected." > > > > > > how does the 'KeepActive' status of signals matter here. Only > > > KeepActive Flag associated with Event Defination should be > > > considered. Otherwise Event Defination should have a embedded > > > Signal Descriptor. > > > > > > I will appriciate if you please further explain your example > > > w.r.t. the arrival of new signal descriptor with the same > > > Signal list. > > > > > > > > > Always, > > > Kris > > > > > > > > > > > > Get FREE Email/Voicemail with 15MB at Lycos Communications at > > http://comm.lycos.com > > > > > > > Get FREE Email/Voicemail with 15MB at Lycos Communications at http://comm.lycos.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 2 08:55:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22245 for ; Thu, 2 Nov 2000 08:55:42 -0500 (EST) Received: from standards (47.234.32.16:4913) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE898@standards.nortelnetworks.com>; Thu, 2 Nov 2000 8:34:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 68478 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 08:34:39 -0500 Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE885@standards.nortelnetworks.com>; Thu, 2 Nov 2000 8:24:38 -0500 Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Nov 2000 14:39:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <98388C05D464D111B61800805F150416012AFADD@p-ibis.issy.cnet.fr> Date: Thu, 2 Nov 2000 14:39:27 +0100 Reply-To: CHATRAS Bruno FTRD/DAC/ISS Sender: "Media Gateway Control (megaco)" From: CHATRAS Bruno FTRD/DAC/ISS Subject: Re: Announcement Package X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA22245 I agree, one call always extend the package. The danger is that each vendor extends this package with its own definitions. I have noticed that there is a similar situation with the "Tone Detection Package". However, in this case, Annex E also defines a "standard" extended package (Call Progress Tones Detection package") to ensure that the most commonly used tones are coded the same way. I think we should do the same for the announcements (i.e. add a "standard" extended package in Annex K). > -----Message d'origine----- > De : Christian Groves [mailto:Christian.Groves@ericsson.com] > Envoyé : mercredi 1 novembre 2000 00:22 > Ŕ : CHATRAS Bruno FTRD/DAC/ISS > Cc : MEGACO@STANDARDS.NORTELNETWORKS.COM > Objet : Re: Announcement Package > > > G'Day Bruno, > > As defacto editor for this (the 2 that started with it have moved on > from their companies) I think the reason for the loose > specification was > to allow for a very Generic / Flexible announcement server > functionality. ie, we didn't want to specify in a package that price, > date etc is included when all the announcement server does in your > implementation is to say "busy". > > You can always extend the package definition to include values for the > parameters. > ie. IN_Generic_Announcement_Server Package > extends Generic Announcement_Server > Additional values: data, telephone number > > Cheers, Christian > > CHATRAS Bruno FTRD/DAC/ISS wrote: > > > > Hi, > > > > I have a question about the use of specific parameters in > announcements > > (Generic Announcement Package). The "Specific parameters > intepretation" > > parameter is currently defined a an enumerated type. > However the possible > > values for this enumaration are specified as "any". Hence, > there is no > > standard solution for the encoding of the most commonly > used types of > > variables (date, telephone number, ...). Does it mean that > this capability > > (variable announcements) will always require additional > specifications > > before being used between MGs and MGCs from different vendors ? > > > > One possible approach to ease interoperability would have > been to define a > > coding for the most commonly used types of parameters. For example: > > Specific parameters interpretation > > ParameterID: spi (0x0005) > > Type: enumeration > > Possible values are: "telephone" (0x00), "date" > (0x01),"time" > > (0x02),"price" (0x03), others > > "telephone" represents a > telephone number as > > a string of hexadecimal digits. > > "date" represents a date as > a string of > > hexadecimal digits in the format YYMMDD > > "time" represents a time as > a string of > > hexadecimal digits in the format HHMMSS > > > > "price" represents a price in > 1/100 of currency > > units. > > > > Is there any reason why this was not specified like that ? > > > > Note: There is no reference to the "price" variable in the > list of examples > > provided in the "procedures" section. However thist type of > variable has > > become widely used with prepaid services. > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 2 09:40:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06354 for ; Thu, 2 Nov 2000 09:40:23 -0500 (EST) Received: from standards (47.234.32.16:3444) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE8E1@standards.nortelnetworks.com>; Thu, 2 Nov 2000 9:20:36 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 68596 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 09:20:35 -0500 Received: from qnsgs000.nortel.com (47.255.64.31:46247) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE8E0@standards.nortelnetworks.com>; Thu, 2 Nov 2000 9:20:35 -0500 Received: from zhard00m.europe.nortel.com (actually zhard00m) by qnsgs000.nortel.com; Thu, 2 Nov 2000 14:32:17 +0000 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 2 Nov 2000 14:32:16 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C044D9.AD0AEBE0" Message-ID: <59E4473E8CD8D111B1180000F8312251055E09F5@bmdhd6.europe.nortel.com> Date: Thu, 2 Nov 2000 14:32:06 -0000 Reply-To: Julian Mitchell Sender: "Media Gateway Control (megaco)" From: Julian Mitchell Subject: Re: Last Call On NAS Package (Revisited for November) X-cc: Alan Whitton 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_01C044D9.AD0AEBE0 Content-Type: text/plain Hi, I think that we should keep the AUTHRES (or AUTHEX) event simple so that it indicates just service denied, callback service authorized and outgoing service authorized. If the service is denied, then we would expect a NASREL event to be triggered. I would therefore suggest adding this list of reasons to the list of possible reason values for the NASREL event, and maybe noting this behaviour in the procedures for the NAS INCOMING PACKAGE. This has the advantage of keeping all the NAS release reasons in one event. Thanks Julian > -----Original Message----- > From: Whitton, Alan [SMTP:awhitton@americasm01.nt.com] > Sent: Wednesday, November 01, 2000 4:08 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Last Call On NAS Package (Revisited for November) > > Folks, > > OK, so after looking things over the AUTHRES (or AUTHEX) event looks like > it needs a little more information returned in it other than success or > failure. > > Once a "call" is UP, the Modems have trained and now the End User's PC is > connected to the ISP's Radius Server more than simply "authorization > failure" can occur. Port limiting can occur (not enough virtual modems > available to that customer's domain), or there can be a RADIUS server > failure (and thus the user cannot log in). > > What I'd like to propose is either adding a reason code for the AUTHRES > (or > AUTHEX), or expand the reason codes for AUTHRES (or AUTHEX). The following > reasons, come to mind: > 1 other, unspecified > 2 CLID was unacceptable (rejected by CLID filter) > 3 CLID was blocked (rejected because blocked CLIDs not allowed) > 4 dialed number is not acceptable > 5 port limit or overflow port limit reached > 6 no IP address available > 7 all home gateways at capacity or admin state locked > 8 port guarantee prevented call from being taken proxied to > 9 RADIUS server rejected the request > > > Cheers, > Alan Whitton > > Holistic Metaservices Architect > CVX SS7 Gateway > Nortel Networks, ------_=_NextPart_001_01C044D9.AD0AEBE0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Last Call On NAS Package (Revisited for November)

Hi,

I think that we = should keep the AUTHRES (or AUTHEX) event simple so that it indicates = just service denied, callback service authorized and outgoing service = authorized.

If the service is = denied, then we would expect a NASREL event to be triggered. I would = therefore suggest adding this list of reasons to the list of possible = reason values for the NASREL event, and maybe noting this behaviour in = the procedures for the NAS INCOMING PACKAGE. This has the advantage of = keeping all the NAS release reasons in one event.

Thanks

Julian

    -----Original Message-----
    From:   Whitton, Alan  = [SMTP:awhitton@americasm01.nt.com]
    Sent:   Wednesday, November 01, 2000 4:08 PM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Last Call On NAS Package (Revisited = for November)

    Folks,

    OK, so after looking things over the = AUTHRES (or AUTHEX) event looks like
    it needs a little more information = returned in it other than success or
    failure.

    Once a  "call" is UP, = the Modems have trained and now the End User's PC is
    connected to the ISP's Radius Server = more than simply "authorization
    failure" can occur. Port = limiting can occur (not enough virtual modems
    available to that customer's domain), = or there can be a RADIUS server
    failure (and thus the user cannot log = in).

    What I'd like to propose is either = adding a reason code for the AUTHRES (or
    AUTHEX), or expand the reason codes = for AUTHRES (or AUTHEX). The following
    reasons, come to mind:
      1 other, unspecified
      2 CLID was unacceptable = (rejected by CLID filter)
      3 CLID was blocked (rejected = because blocked CLIDs not allowed)
      4 dialed number is not = acceptable
      5 port limit or overflow port = limit reached
      6  no IP address = available
      7 all home gateways at = capacity or admin state locked
      8 port guarantee prevented = call from being taken proxied to
      9     = RADIUS server rejected the request


    Cheers,
    Alan Whitton

    Holistic Metaservices Architect
    CVX SS7 Gateway
    Nortel Networks,

------_=_NextPart_001_01C044D9.AD0AEBE0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 2 09:50:26 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09928 for ; Thu, 2 Nov 2000 09:50:23 -0500 (EST) Received: from standards (47.234.32.16:3444) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE8FD@standards.nortelnetworks.com>; Thu, 2 Nov 2000 9:32:02 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 68634 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 09:32:02 -0500 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE8FC@standards.nortelnetworks.com>; Thu, 2 Nov 2000 9:31:48 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA08944; Thu, 2 Nov 2000 09:47:40 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA14917; Thu, 2 Nov 2000 09:47:43 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Nov 2000 09:47: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: <4FBEA8857476D311A03300204840E1CF01A6E97C@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 2 Nov 2000 09:47:32 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: ServiceChange from a Dead Controller? X-To: Alan Whitton To: MEGACO@STANDARDS.NORTELNETWORKS.COM I'm not sure that it's good enough to be on the list. You get into problems like, more than one redundant MGC telling you he's your new leader. Usually it's best if the public makes the choice on the leader, and not the other way around :) The issue of time to discover dead controllers is complex. There are those parameters that give you information on how long to expect a reply to take. On well-engineered networks, that time should be short. I don't think you would be dropping calls unless it's taking seconds to declare MGCs dead. On the Big-I internet, it might take that long, but on a well-engineered net, it should be okay. We spent a while talking about these issues when these decisions were made. We may not have the ideal solution for everyone, but we tried to come up with one we believed would work. If real-life testing shows it doesn't, we will have to change, but I can assure you that we did not treat this issue lightly, and there was quite a lot of discussion on how to do this. The result is, by every measure, a compromise. At the moment, I'd like to try to make what we have got work, rather than changing the mechanism. Brian > -----Original Message----- > From: Alan Whitton [mailto:awhitton@NORTELNETWORKS.COM] > Sent: Wednesday, November 01, 2000 6:26 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM; Rosen, Brian > Cc: Alan Whitton > Subject: Re: ServiceChange from a Dead Controller? > > > OK, > > Security is good, but if it's a message from a machine on the > Gateway's > list, wouldn't that be the same? > > The concern I have is that if the gateway "ignores" messages > from a new > controller, until it figures out that it's OLD controller is > dead, you'll > have a fair number of calls "fall on the floor". Is there any > way around > losing those calls? > > Cheers, > Alan > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 2 10:31:06 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24299 for ; Thu, 2 Nov 2000 10:31:05 -0500 (EST) Received: from standards (47.234.32.16:2408) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE920@standards.nortelnetworks.com>; Thu, 2 Nov 2000 10:13:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 68683 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 10:13:34 -0500 Received: from ertpg14e1.nortelnetworks.com (47.125.208.110:48125) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE91F@standards.nortelnetworks.com>; Thu, 2 Nov 2000 10:13:34 -0500 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Thu, 2 Nov 2000 10:24:29 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 2 Nov 2000 10:24:23 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD110250C6B9@zcard00g.ca.nortel.com> Date: Thu, 2 Nov 2000 10:23:39 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Signal lists X-To: "sgautam@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM I stand corrected and apologize for my carelessness. You're right. So the only thing that determines whether the signal list keeps playing is the keepActive setting (or embedded SignalsDescriptor) in the event itself. > -----Original Message----- > From: Sandeep Gautam [mailto:sgautam@HSS.HNS.COM] > Sent: Thursday, November 02, 2000 8:40 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Signal lists > > > Hi, > The keepactive flag that comes in the signals descriptor is > not remebered. The > fact whether the currently playing signal arrived with a > keepcative flag or not > is immaterial for subsequent processing. > > According to text > > Signals present in the replacement descriptor and > containing the KeepActive > flagshall be continued if they are currently playing and > have not already > completed. If a replacement signal descriptor contains a > signal that is not > currently playing and contains the KeepActive flag, that > signal SHALL be > ignored > > Thus the scope of keepactive flag is limited to the signal > descriptor processing > of the descriptor in which it arrived. > > When subsequently an event is detected the stopping of the > signal( which may > have arrived with a keepactive flag) is solely governed by > the keepactive flag > associated with the event that is detected. Thus point no. 2 > is invalid. If the > KA of event detected is not set then the MG should stop > application of all > active signals. > > > Is this understanding correct? > Regards, > Sandy G > > 1) Check for event flag. If there is one, leave signals playing. > 2) Otherwise check flag for each signal and keep playing or > terminate as > indicated. > > > -----Original Message----- > > From: Kris Albert [mailto:kris_albert@lycos.com] > > Sent: Thursday, November 02, 2000 7:57 AM > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Signal lists > > > > > > > > ----- > > > Signals can also have a KeepActive flag. > > > > That's true, but my question is different, I want to ask > > whether on the detection of event, do we process only the > > KeepActive flag associated with Events, or do we also > > consider the KeepActive flag associated with the active Signals. > > > > thanks > > Kris > > > > > > > > > -----Original Message----- > > > > From: Kris Albert [mailto:kris_albert@LYCOS.COM] > > > > Sent: Thursday, November 02, 2000 1:27 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: Signal lists > > > > > > > > > > > > Hi Christian, > > > > I have few questions on your explanation. > > > > > > > > > [CHG] I guess you can view this is several ways. The > > > > KeepActive on ALL > > > > > signals certainly makes sense when you don't want any > > > > interruption. But > > > > > is it erroneous to specify Keepactive on different signals? > > > > Certainly > > > > > weird behaviour but you may want the initial part of a > > > > message to play > > > > > irrespective of what event happens and you don't care about > > > > the rest of > > > > > the signal. I would say that the Keepactive pertains to a > > > > moment in time > > > > > in the playback of a message. > > > > > ie. Signal list = (s1ka, s2, s3, s4ka) > > > > > If you receive an event when S1KA is playing the whole > > list plays. > > > > > If you receive an event when S2 is playing the whole > list stops. > > > > > > > > I am not able to understand your example here. > > > > It is specified in MEGACO that " Normally, recognition of an > > > > event shall cause any active signals to stop. When KeepActive > > > > is specified in the event, the MG shall not interrupt any > > > > signals active on the Termination on which the event is > detected." > > > > > > > > how does the 'KeepActive' status of signals matter here. Only > > > > KeepActive Flag associated with Event Defination should be > > > > considered. Otherwise Event Defination should have a embedded > > > > Signal Descriptor. > > > > > > > > I will appriciate if you please further explain your example > > > > w.r.t. the arrival of new signal descriptor with the same > > > > Signal list. > > > > > > > > > > > > Always, > > > > Kris > > > > > > > > > > > > > > > > Get FREE Email/Voicemail with 15MB at Lycos Communications at > > > http://comm.lycos.com > > > > > > > > > > > > Get FREE Email/Voicemail with 15MB at Lycos Communications at > http://comm.lycos.com > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 2 10:36:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25638 for ; Thu, 2 Nov 2000 10:36:39 -0500 (EST) Received: from standards (47.234.32.16:2408) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE936@standards.nortelnetworks.com>; Thu, 2 Nov 2000 10:19:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 68713 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 10:19:10 -0500 Received: from smtprch1.nortel.com (47.113.64.103:36959) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE935@standards.nortelnetworks.com>; Thu, 2 Nov 2000 10:19:09 -0500 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Thu, 2 Nov 2000 09:26:09 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 2 Nov 2000 09:25:49 -0600 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD110250C6BA@zcard00g.ca.nortel.com> Date: Thu, 2 Nov 2000 09:25:43 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: IANA Registration To: MEGACO@STANDARDS.NORTELNETWORKS.COM You can see the initial package list at http://www.isi.edu/in-notes/iana/assignments/megaco-h248 I would like to clear up one open question, regarding the assignment of error codes. Do we tell IANA to assign them sequentially starting at 1 but respecting the initial assignments in section 7.3, or what? From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 2 10:44:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27465 for ; Thu, 2 Nov 2000 10:44:00 -0500 (EST) Received: from standards (47.234.32.16:2408) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE94C@standards.nortelnetworks.com>; Thu, 2 Nov 2000 10:26:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 68744 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 10:26:42 -0500 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE94B@standards.nortelnetworks.com>; Thu, 2 Nov 2000 10:26:42 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14294; Thu, 2 Nov 2000 10:42:31 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA05598; Thu, 2 Nov 2000 10:42:33 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Nov 2000 10:41: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: <4FBEA8857476D311A03300204840E1CF01A6E980@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 2 Nov 2000 10:42:22 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: IANA Registration X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM There was some logic to the assignments. If I was writing instructions, I would say that the requestor (of a new error code assignment) should specify the first two digits, and IANA assigns the last sequentially. Brian > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > Sent: Thursday, November 02, 2000 10:26 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: IANA Registration > > > You can see the initial package list at > http://www.isi.edu/in-notes/iana/assignments/megaco-h248 > > I would like to clear up one open question, regarding the > assignment of > error codes. Do we tell IANA to assign them sequentially > starting at 1 but > respecting the initial assignments in section 7.3, or what? > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 2 10:50:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29487 for ; Thu, 2 Nov 2000 10:50:29 -0500 (EST) Received: from standards (47.234.32.16:2408) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE981@standards.nortelnetworks.com>; Thu, 2 Nov 2000 10:33:02 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 68819 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 10:33:02 -0500 Received: from mars.hss.co.in (202.54.26.197:58535) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAE977@standards.nortelnetworks.com>; Thu, 2 Nov 2000 10:32:55 -0500 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id eA2FmrC27504; Thu, 2 Nov 2000 21:18:56 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525698B.0055CE5F ; Thu, 2 Nov 2000 21:07:13 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=B5eeUN7G3A0Rx1e5oVOgzWmBAmRN6KtP9KjZWZlpMOhXW0c6o1nmr9jv" Content-Disposition: inline Message-ID: <6525698B.0055CE29.00@sandesh.hss.hns.com> Date: Thu, 2 Nov 2000 21:18:16 +0530 Reply-To: sgautam@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sandeep Gautam Subject: Re: Signal lists X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM --0__=B5eeUN7G3A0Rx1e5oVOgzWmBAmRN6KtP9KjZWZlpMOhXW0c6o1nmr9jv Content-type: text/plain; charset=us-ascii Content-Disposition: inline I think the question on which there can be confusion is what happens when the embedded signals descriptor( invoked by event detection) contains the currently active signal with the KA flag set? If the processing of embedded descriptor is supposed to happen after the action for event detection has been taken ; then If the event 's KA is not set we should stop the signal. But if the processing of embedded signals descriptor is done simultaneously( or lets say before event detection processing) , then if the KA for any of the active signal is set in the embedded signals descriptor ( i.e. embedded signal descriptor carries an active signal with KA set), then we should also take this in account . In other words stop signals using signals descriptor invocation logic rather than event detection logic. Any views? Regards, Sandy G I stand corrected and apologize for my carelessness. You're right. So the only thing that determines whether the signal list keeps playing is the keepActive setting (or embedded SignalsDescriptor) in the event itself. > -----Original Message----- > From: Sandeep Gautam [mailto:sgautam@HSS.HNS.COM] > Sent: Thursday, November 02, 2000 8:40 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Signal lists > > > Hi, > The keepactive flag that comes in the signals descriptor is > not remebered. The > fact whether the currently playing signal arrived with a > keepcative flag or not > is immaterial for subsequent processing. > > According to text > > Signals present in the replacement descriptor and > containing the KeepActive > flagshall be continued if they are currently playing and > have not already > completed. If a replacement signal descriptor contains a > signal that is not > currently playing and contains the KeepActive flag, that > signal SHALL be > ignored > > Thus the scope of keepactive flag is limited to the signal > descriptor processing > of the descriptor in which it arrived. > > When subsequently an event is detected the stopping of the > signal( which may > have arrived with a keepactive flag) is solely governed by > the keepactive flag > associated with the event that is detected. Thus point no. 2 > is invalid. If the > KA of event detected is not set then the MG should stop > application of all > active signals. > > > Is this understanding correct? > Regards, > Sandy G > > 1) Check for event flag. If there is one, leave signals playing. > 2) Otherwise check flag for each signal and keep playing or > terminate as > indicated. > > > -----Original Message----- > > From: Kris Albert [mailto:kris_albert@lycos.com] > > Sent: Thursday, November 02, 2000 7:57 AM > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Signal lists > > > > > > > > ----- > > > Signals can also have a KeepActive flag. > > > > That's true, but my question is different, I want to ask > > whether on the detection of event, do we process only the > > KeepActive flag associated with Events, or do we also > > consider the KeepActive flag associated with the active Signals. > > > > thanks > > Kris > > > > > > > > > -----Original Message----- > > > > From: Kris Albert [mailto:kris_albert@LYCOS.COM] > > > > Sent: Thursday, November 02, 2000 1:27 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: Signal lists > > > > > > > > > > > > Hi Christian, > > > > I have few questions on your explanation. > > > > > > > > > [CHG] I guess you can view this is several ways. The > > > > KeepActive on ALL > > > > > signals certainly makes sense when you don't want any > > > > interruption. But > > > > > is it erroneous to specify Keepactive on different signals? > > > > Certainly > > > > > weird behaviour but you may want the initial part of a > > > > message to play > > > > > irrespective of what event happens and you don't care about > > > > the rest of > > > > > the signal. I would say that the Keepactive pertains to a > > > > moment in time > > > > > in the playback of a message. > > > > > ie. Signal list = (s1ka, s2, s3, s4ka) > > > > > If you receive an event when S1KA is playing the whole > > list plays. > > > > > If you receive an event when S2 is playing the whole > list stops. > > > > > > > > I am not able to understand your example here. > > > > It is specified in MEGACO that " Normally, recognition of an > > > > event shall cause any active signals to stop. When KeepActive > > > > is specified in the event, the MG shall not interrupt any > > > > signals active on the Termination on which the event is > detected." > > > > > > > > how does the 'KeepActive' status of signals matter here. Only > > > > KeepActive Flag associated with Event Defination should be > > > > considered. Otherwise Event Defination should have a embedded > > > > Signal Descriptor. > > > > > > > > I will appriciate if you please further explain your example > > > > w.r.t. the arrival of new signal descriptor with the same > > > > Signal list. > > > > > > > > > > > > Always, > > > > Kris > > > > > > > > > > > > > > > > Get FREE Email/Voicemail with 15MB at Lycos Communications at > > > http://comm.lycos.com > > > > > > > > > > > > Get FREE Email/Voicemail with 15MB at Lycos Communications at > http://comm.lycos.com > --0__=B5eeUN7G3A0Rx1e5oVOgzWmBAmRN6KtP9KjZWZlpMOhXW0c6o1nmr9jv Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1Mi4zNSI+DQo8VElUTEU+UkU6IFNp Z25hbCBsaXN0czwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCg0KPFA+PEZPTlQgU0laRT0yPkkg c3RhbmQgY29ycmVjdGVkIGFuZCBhcG9sb2dpemUgZm9yIG15IGNhcmVsZXNzbmVzcy4mbmJzcDsg WW91J3JlIHJpZ2h0LiZuYnNwOyBTbyB0aGUgb25seSB0aGluZyB0aGF0IGRldGVybWluZXMgd2hl dGhlciB0aGUgc2lnbmFsIGxpc3Qga2VlcHMgcGxheWluZyBpcyB0aGUga2VlcEFjdGl2ZSBzZXR0 aW5nIChvciBlbWJlZGRlZCBTaWduYWxzRGVzY3JpcHRvcikgaW4gdGhlIGV2ZW50IGl0c2VsZi48 L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBGcm9tOiBTYW5kZWVwIEdhdXRhbSBb PEEgSFJFRj0ibWFpbHRvOnNnYXV0YW1ASFNTLkhOUy5DT00iPm1haWx0bzpzZ2F1dGFtQEhTUy5I TlMuQ09NPC9BPl08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgU2VudDogVGh1cnNkYXks IE5vdmVtYmVyIDAyLCAyMDAwIDg6NDAgQU08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg VG86IE1FR0FDT0BTVEFOREFSRFMuTk9SVEVMTkVUV09SS1MuQ09NPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mZ3Q7IFN1YmplY3Q6IFJlOiBTaWduYWwgbGlzdHM8L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+Jmd0OyBIaSw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgVGhlIGtl ZXBhY3RpdmUgZmxhZyB0aGF0IGNvbWVzIGluIHRoZSBzaWduYWxzIGRlc2NyaXB0b3IgaXMgPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IG5vdCByZW1lYmVyZWQuIFRoZTwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Jmd0OyBmYWN0IHdoZXRoZXIgdGhlIGN1cnJlbnRseSBwbGF5aW5nIHNp Z25hbCBhcnJpdmVkIHdpdGggYSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsga2VlcGNh dGl2ZSBmbGFnIG9yIG5vdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBpcyBpbW1hdGVy aWFsIGZvciBzdWJzZXF1ZW50IHByb2Nlc3NpbmcuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m Z3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBBY2NvcmRpbmcgdG8gdGV4dDwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg U2lnbmFscyBwcmVzZW50IGluIHRoZSByZXBsYWNlbWVudCBkZXNjcmlwdG9yIGFuZCZuYnNwOyZu YnNwOyZuYnNwOyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgY29udGFpbmluZyB0aGUg S2VlcEFjdGl2ZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBmbGFnc2hhbGwgYmUgY29u dGludWVkIGlmIHRoZXkgYXJlJm5ic3A7Jm5ic3A7Jm5ic3A7IGN1cnJlbnRseSBwbGF5aW5nIGFu ZCA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgaGF2ZSBub3QgYWxyZWFkeTwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBjb21wbGV0ZWQuJm5ic3A7IElmIGEgcmVwbGFjZW1lbnQm bmJzcDsmbmJzcDsmbmJzcDsgc2lnbmFsIGRlc2NyaXB0b3IgY29udGFpbnMgYSA8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPiZndDsgc2lnbmFsIHRoYXQgaXMgbm90PC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mZ3Q7IGN1cnJlbnRseSBwbGF5aW5nJm5ic3A7Jm5ic3A7Jm5ic3A7IGFuZCBjb250 YWlucyB0aGUgS2VlcEFjdGl2ZSBmbGFnLCB0aGF0IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jmd0OyBzaWduYWwgU0hBTEwgYmU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgaWdub3Jl ZDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PiZndDsgVGh1cyB0aGUgc2NvcGUgb2Yga2VlcGFjdGl2ZSBmbGFnIGlzIGxpbWl0ZWQgdG8gdGhl IHNpZ25hbCA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgZGVzY3JpcHRvciBwcm9jZXNz aW5nPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IG9mIHRoZSBkZXNjcmlwdG9yIGluIHdo aWNoIGl0IGFycml2ZWQuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Jmd0OyBXaGVuIHN1YnNlcXVlbnRseSBhbiBldmVudCBpcyBkZXRlY3Rl ZCB0aGUgc3RvcHBpbmcgb2YgdGhlIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBzaWdu YWwoIHdoaWNoIG1heTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBoYXZlIGFycml2ZWQg d2l0aCBhIGtlZXBhY3RpdmUgZmxhZykgaXMgc29sZWx5IGdvdmVybmVkIGJ5IDwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Jmd0OyB0aGUga2VlcGFjdGl2ZSBmbGFnPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mZ3Q7IGFzc29jaWF0ZWQgd2l0aCB0aGUgZXZlbnQgdGhhdCBpcyBkZXRlY3RlZC4g VGh1cyBwb2ludCBuby4gMiA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgaXMgaW52YWxp ZC4gSWYgdGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IEtBIG9mIGV2ZW50IGRldGVj dGVkIGlzIG5vdCBzZXQgdGhlbiB0aGUgTUcgc2hvdWxkIHN0b3AgPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mZ3Q7IGFwcGxpY2F0aW9uIG9mIGFsbDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jmd0OyBhY3RpdmUgc2lnbmFscy48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBJ cyB0aGlzIHVuZGVyc3RhbmRpbmcgY29ycmVjdD88L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn dDsgUmVnYXJkcyw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgU2FuZHkgRzwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJz cDsgMSkgQ2hlY2sgZm9yIGV2ZW50IGZsYWcuJm5ic3A7IElmIHRoZXJlIGlzIG9uZSwgbGVhdmUg c2lnbmFscyBwbGF5aW5nLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyAyKSBP dGhlcndpc2UgY2hlY2sgZmxhZyBmb3IgZWFjaCBzaWduYWwgYW5kIGtlZXAgcGxheWluZyBvciA8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgdGVybWluYXRlIGFzPC9GT05UPg0KPEJSPjxG T05UIFNJWkU9Mj4mZ3Q7IGluZGljYXRlZC48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBGcm9tOiBLcmlzIEFsYmVy dCBbPEEgSFJFRj0ibWFpbHRvOmtyaXNfYWxiZXJ0QGx5Y29zLmNvbSI+bWFpbHRvOmtyaXNfYWxi ZXJ0QGx5Y29zLmNvbTwvQT5dPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgU2Vu dDogVGh1cnNkYXksIE5vdmVtYmVyIDAyLCAyMDAwIDc6NTcgQU08L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPiZndDsgJmd0OyBUbzogVGF5bG9yLCBUb20tUFQgW05PUlNFOkI5MDE6RVhDSF08L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBDYzogTUVHQUNPQFNUQU5EQVJEUy5OT1JU RUxORVRXT1JLUy5DT008L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBTdWJqZWN0 OiBSZTogU2lnbmFsIGxpc3RzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jmd0OyAmZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgLS0tLS08L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7IFNpZ25hbHMgY2FuIGFsc28gaGF2ZSBh IEtlZXBBY3RpdmUgZmxhZy48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OzwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IFRoYXQncyB0cnVlLCBidXQgbXkgcXVlc3Rp b24gaXMgZGlmZmVyZW50LCBJIHdhbnQgdG8gYXNrPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m Z3Q7ICZndDsgd2hldGhlciBvbiB0aGUgZGV0ZWN0aW9uIG9mIGV2ZW50LCBkbyB3ZSBwcm9jZXNz Jm5ic3A7IG9ubHkgdGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgS2VlcEFj dGl2ZSBmbGFnIGFzc29jaWF0ZWQgd2l0aCBFdmVudHMsIG9yIGRvIHdlIGFsc288L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBjb25zaWRlciB0aGUgS2VlcEFjdGl2ZSBmbGFnIGFz c29jaWF0ZWQgd2l0aCB0aGUgYWN0aXZlIFNpZ25hbHMuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyB0aGFua3M8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBLcmlzPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7PC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 IEZyb206IEtyaXMgQWxiZXJ0IFs8QSBIUkVGPSJtYWlsdG86a3Jpc19hbGJlcnRATFlDT1MuQ09N Ij5tYWlsdG86a3Jpc19hbGJlcnRATFlDT1MuQ09NPC9BPl08L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPiZndDsgJmd0OyAmZ3Q7ICZndDsgU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDAyLCAyMDAw IDE6MjcgQU08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7ICZndDsgVG86 IE1FR0FDT0BTVEFOREFSRFMuTk9SVEVMTkVUV09SS1MuQ09NPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBTaWduYWwgbGlzdHM8L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPiZndDsgJmd0OyAmZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg Jmd0OyAmZ3Q7ICZndDsgSGkgQ2hyaXN0aWFuLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJIGhhdmUgZmV3 IHF1ZXN0aW9ucyBvbiB5b3VyIGV4cGxhbmF0aW9uLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7IFtDSEddIEkgZ3Vlc3MgeW91IGNhbiB2aWV3IHRoaXMgaXMgc2V2ZXJhbCB3 YXlzLiBUaGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7ICZndDsgS2Vl cEFjdGl2ZSBvbiBBTEw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyBzaWduYWxzIGNlcnRhaW5seSBtYWtlcyBzZW5zZSB3aGVuIHlvdSBkb24ndCB3YW50 IGFueTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBpbnRlcnJ1 cHRpb24uIEJ1dDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7IGlzIGl0IGVycm9uZW91cyB0byBzcGVjaWZ5IEtlZXBhY3RpdmUgb24gZGlmZmVyZW50IHNp Z25hbHM/PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IENlcnRh aW5seTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHdl aXJkIGJlaGF2aW91ciBidXQgeW91IG1heSB3YW50IHRoZSBpbml0aWFsIHBhcnQgb2YgYTwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBtZXNzYWdlIHRvIHBsYXk8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBpcnJlc3Bl Y3RpdmUgb2Ygd2hhdCBldmVudCBoYXBwZW5zIGFuZCB5b3UgZG9uJ3QgY2FyZSBhYm91dDwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUgcmVzdCBvZjwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoZSBzaWduYWwu IEkgd291bGQgc2F5IHRoYXQgdGhlIEtlZXBhY3RpdmUgcGVydGFpbnMgdG8gYTwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBtb21lbnQgaW4gdGltZTwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGluIHRoZSBwbGF5YmFj ayBvZiBhIG1lc3NhZ2UuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsgaWUuIFNpZ25hbCBsaXN0Jm5ic3A7ID0gKHMxa2EsIHMyLCBzMywgczRrYSk8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBJZiB5b3UgcmVj ZWl2ZSBhbiBldmVudCB3aGVuIFMxS0EgaXMgcGxheWluZyB0aGUgd2hvbGU8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPiZndDsgJmd0OyBsaXN0IHBsYXlzLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF PTI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IElmIHlvdSByZWNlaXZlIGFuIGV2ZW50IHdoZW4g UzIgaXMgcGxheWluZyB0aGUgd2hvbGUgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGxp c3Qgc3RvcHMuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IEkgYW0gbm90IGFibGUg dG8gdW5kZXJzdGFuZCB5b3VyIGV4YW1wbGUgaGVyZS48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PiZndDsgJmd0OyAmZ3Q7ICZndDsgSXQgaXMgc3BlY2lmaWVkIGluIE1FR0FDTyB0aGF0ICZxdW90 OyBOb3JtYWxseSwgcmVjb2duaXRpb24gb2YgYW48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn dDsgJmd0OyAmZ3Q7ICZndDsgZXZlbnQgc2hhbGwgY2F1c2UgYW55IGFjdGl2ZSBzaWduYWxzIHRv IHN0b3AuIFdoZW4gS2VlcEFjdGl2ZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyBpcyBzcGVjaWZpZWQgaW4gdGhlIGV2ZW50LCB0aGUgTUcgc2hhbGwgbm90IGlu dGVycnVwdCBhbnk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7ICZndDsg c2lnbmFscyBhY3RpdmUgb24gdGhlIFRlcm1pbmF0aW9uIG9uIHdoaWNoIHRoZSBldmVudCBpcyA8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgZGV0ZWN0ZWQuJnF1b3Q7PC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGhvdyBkb2VzIHRoZSAnS2VlcEFjdGl2ZScgc3RhdHVzIG9m IHNpZ25hbHMgbWF0dGVyIGhlcmUuIE9ubHk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg Jmd0OyAmZ3Q7ICZndDsgS2VlcEFjdGl2ZSBGbGFnIGFzc29jaWF0ZWQgd2l0aCBFdmVudCBEZWZp bmF0aW9uIHNob3VsZCBiZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsg Jmd0OyBjb25zaWRlcmVkLiBPdGhlcndpc2UgRXZlbnQgRGVmaW5hdGlvbiBzaG91bGQgaGF2ZSBh IGVtYmVkZGVkPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFNp Z25hbCBEZXNjcmlwdG9yLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsg Jmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBJIHdpbGwg YXBwcmljaWF0ZSBpZiB5b3UgcGxlYXNlIGZ1cnRoZXIgZXhwbGFpbiB5b3VyIGV4YW1wbGU8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7ICZndDsgdy5yLnQuJm5ic3A7IHRo ZSBhcnJpdmFsIG9mIG5ldyBzaWduYWwgZGVzY3JpcHRvciB3aXRoIHRoZSBzYW1lPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFNpZ25hbCBsaXN0LjwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZndDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jmd0OyAmZ3Q7ICZndDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyBBbHdheXMsPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7IEtyaXM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7ICZn dDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7ICZndDs8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPiZndDsgJmd0OyAmZ3Q7ICZndDsgR2V0IEZSRUUgRW1haWwvVm9pY2VtYWlsIHdpdGggMTVN QiBhdCBMeWNvcyBDb21tdW5pY2F0aW9ucyBhdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0 OyAmZ3Q7ICZndDsgPEEgSFJFRj0iaHR0cDovL2NvbW0ubHljb3MuY29tIiBUQVJHRVQ9Il9ibGFu ayI+aHR0cDovL2NvbW0ubHljb3MuY29tPC9BPjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0 OyAmZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmZ3Q7PC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn dDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IEdldCBGUkVFIEVtYWls L1ZvaWNlbWFpbCB3aXRoIDE1TUIgYXQgTHljb3MgQ29tbXVuaWNhdGlvbnMgYXQ8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPiZndDsgPEEgSFJFRj0iaHR0cDovL2NvbW0ubHljb3MuY29tIiBUQVJH RVQ9Il9ibGFuayI+aHR0cDovL2NvbW0ubHljb3MuY29tPC9BPjwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4NCg== --0__=B5eeUN7G3A0Rx1e5oVOgzWmBAmRN6KtP9KjZWZlpMOhXW0c6o1nmr9jv-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 2 11:13:12 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05988 for ; Thu, 2 Nov 2000 11:13:11 -0500 (EST) Received: from standards (47.234.32.16:2408) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAEA29@standards.nortelnetworks.com>; Thu, 2 Nov 2000 10:54:14 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 69059 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 10:54:14 -0500 Received: from smtprch2.nortel.com (47.113.64.104:50356) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAEA28@standards.nortelnetworks.com>; Thu, 2 Nov 2000 10:54:13 -0500 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Thu, 2 Nov 2000 10:04:54 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 2 Nov 2000 10:08:58 -0600 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD110250C6C1@zcard00g.ca.nortel.com> Date: Thu, 2 Nov 2000 10:08:47 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Signal lists X-To: "sgautam@hss.hns.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM I would favour the second interpretation -- that the fate of active signals depends on what is in the embedded SignalsDescriptor. Not sure this is a real argument, but syntactically the embedded SD is an alternative to the event KeepActive flag. > -----Original Message----- > From: sgautam@hss.hns.com [mailto:sgautam@hss.hns.com] > Sent: Thursday, November 02, 2000 10:48 AM > To: Taylor, Tom-PT [NORSE:B901:EXCH] > Cc: megaco@standards.nortelnetworks.com > Subject: RE: Signal lists > > > > > I think the question on which there can be confusion is what > happens when the > embedded signals descriptor( invoked by event detection) > contains the currently > active signal with the KA flag set? > If the processing of embedded descriptor is supposed to > happen after the action > for event detection has been taken ; then If the event 's KA > is not set we > should stop the signal. > But if the processing of embedded signals descriptor is done > simultaneously( or > lets say before event detection processing) , then if the KA > for any of the > active signal is set in the embedded signals descriptor ( > i.e. embedded signal > descriptor carries an active signal with KA set), then we > should also take this > in account . In other words stop signals using signals > descriptor invocation > logic rather than event detection logic. > > Any views? > > Regards, > Sandy G > > > > > > > I stand corrected and apologize for my carelessness. You're > right. So the > only thing that determines whether the signal list keeps > playing is the > keepActive setting (or embedded SignalsDescriptor) in the > event itself. > > > -----Original Message----- > > From: Sandeep Gautam [mailto:sgautam@HSS.HNS.COM] > > Sent: Thursday, November 02, 2000 8:40 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Signal lists > > > > > > Hi, > > The keepactive flag that comes in the signals descriptor is > > not remebered. The > > fact whether the currently playing signal arrived with a > > keepcative flag or not > > is immaterial for subsequent processing. > > > > According to text > > > > Signals present in the replacement descriptor and > > containing the KeepActive > > flagshall be continued if they are currently playing and > > have not already > > completed. If a replacement signal descriptor contains a > > signal that is not > > currently playing and contains the KeepActive flag, that > > signal SHALL be > > ignored > > > > Thus the scope of keepactive flag is limited to the signal > > descriptor processing > > of the descriptor in which it arrived. > > > > When subsequently an event is detected the stopping of the > > signal( which may > > have arrived with a keepactive flag) is solely governed by > > the keepactive flag > > associated with the event that is detected. Thus point no. 2 > > is invalid. If the > > KA of event detected is not set then the MG should stop > > application of all > > active signals. > > > > > > Is this understanding correct? > > Regards, > > Sandy G > > > > 1) Check for event flag. If there is one, leave signals playing. > > 2) Otherwise check flag for each signal and keep playing or > > terminate as > > indicated. > > > > > -----Original Message----- > > > From: Kris Albert [mailto:kris_albert@lycos.com] > > > Sent: Thursday, November 02, 2000 7:57 AM > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Signal lists > > > > > > > > > > > > ----- > > > > Signals can also have a KeepActive flag. > > > > > > That's true, but my question is different, I want to ask > > > whether on the detection of event, do we process only the > > > KeepActive flag associated with Events, or do we also > > > consider the KeepActive flag associated with the active Signals. > > > > > > thanks > > > Kris > > > > > > > > > > > > -----Original Message----- > > > > > From: Kris Albert [mailto:kris_albert@LYCOS.COM] > > > > > Sent: Thursday, November 02, 2000 1:27 AM > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: Signal lists > > > > > > > > > > > > > > > Hi Christian, > > > > > I have few questions on your explanation. > > > > > > > > > > > [CHG] I guess you can view this is several ways. The > > > > > KeepActive on ALL > > > > > > signals certainly makes sense when you don't want any > > > > > interruption. But > > > > > > is it erroneous to specify Keepactive on different signals? > > > > > Certainly > > > > > > weird behaviour but you may want the initial part of a > > > > > message to play > > > > > > irrespective of what event happens and you don't care about > > > > > the rest of > > > > > > the signal. I would say that the Keepactive pertains to a > > > > > moment in time > > > > > > in the playback of a message. > > > > > > ie. Signal list = (s1ka, s2, s3, s4ka) > > > > > > If you receive an event when S1KA is playing the whole > > > list plays. > > > > > > If you receive an event when S2 is playing the whole > > list stops. > > > > > > > > > > I am not able to understand your example here. > > > > > It is specified in MEGACO that " Normally, recognition of an > > > > > event shall cause any active signals to stop. When KeepActive > > > > > is specified in the event, the MG shall not interrupt any > > > > > signals active on the Termination on which the event is > > detected." > > > > > > > > > > how does the 'KeepActive' status of signals matter here. Only > > > > > KeepActive Flag associated with Event Defination should be > > > > > considered. Otherwise Event Defination should have a embedded > > > > > Signal Descriptor. > > > > > > > > > > I will appriciate if you please further explain your example > > > > > w.r.t. the arrival of new signal descriptor with the same > > > > > Signal list. > > > > > > > > > > > > > > > Always, > > > > > Kris > > > > > > > > > > > > > > > > > > > > Get FREE Email/Voicemail with 15MB at Lycos Communications at > > > > http://comm.lycos.com > > > > > > > > > > > > > > > > > Get FREE Email/Voicemail with 15MB at Lycos Communications at > > http://comm.lycos.com > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 2 11:35:21 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11493 for ; Thu, 2 Nov 2000 11:35:20 -0500 (EST) Received: from standards (47.234.32.16:3941) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAEA5F@standards.nortelnetworks.com>; Thu, 2 Nov 2000 11:17:50 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 69130 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 11:17:50 -0500 Received: from mars.hss.co.in (202.54.26.197:58765) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAEA5E@standards.nortelnetworks.com>; Thu, 2 Nov 2000 11:17:48 -0500 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id eA2GYHC27866 for ; Thu, 2 Nov 2000 22:04:18 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525698B.0059F797 ; Thu, 2 Nov 2000 21:52:40 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525698B.0059F69B.00@sandesh.hss.hns.com> Date: Thu, 2 Nov 2000 22:03:43 +0530 Reply-To: sgautam@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sandeep Gautam Subject: Re: Signal lists To: MEGACO@STANDARDS.NORTELNETWORKS.COM Actually this makes sense because there is no need( and use) to have KA flags set in an embedded signals descriptor if the event does not have KA set. So is there consensus that an embedded signals descriptor means KA of detcted event should be assumed to be set. and thus KAs in embedded signals descriptor honored? ( In case none of the active signals are in the embedded signals descriptor with KA set then the stopping/starting of signals will be equivalent to stopping all the signals due to event detection( with Ka not set) and then processing the embedded descriptor) I would favour the second interpretation -- that the fate of active signals depends on what is in the embedded SignalsDescriptor. Not sure this is a real argument, but syntactically the embedded SD is an alternative to the event KeepActive flag. > -----Original Message----- > From: sgautam@hss.hns.com [mailto:sgautam@hss.hns.com] > Sent: Thursday, November 02, 2000 10:48 AM > To: Taylor, Tom-PT [NORSE:B901:EXCH] > Cc: megaco@standards.nortelnetworks.com > Subject: RE: Signal lists > > > > > I think the question on which there can be confusion is what > happens when the > embedded signals descriptor( invoked by event detection) > contains the currently > active signal with the KA flag set? > If the processing of embedded descriptor is supposed to > happen after the action > for event detection has been taken ; then If the event 's KA > is not set we > should stop the signal. > But if the processing of embedded signals descriptor is done > simultaneously( or > lets say before event detection processing) , then if the KA > for any of the > active signal is set in the embedded signals descriptor ( > i.e. embedded signal > descriptor carries an active signal with KA set), then we > should also take this > in account . In other words stop signals using signals > descriptor invocation > logic rather than event detection logic. > > Any views? > > Regards, > Sandy G > > > > > > > I stand corrected and apologize for my carelessness. You're > right. So the > only thing that determines whether the signal list keeps > playing is the > keepActive setting (or embedded SignalsDescriptor) in the > event itself. > > > -----Original Message----- > > From: Sandeep Gautam [mailto:sgautam@HSS.HNS.COM] > > Sent: Thursday, November 02, 2000 8:40 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Signal lists > > > > > > Hi, > > The keepactive flag that comes in the signals descriptor is > > not remebered. The > > fact whether the currently playing signal arrived with a > > keepcative flag or not > > is immaterial for subsequent processing. > > > > According to text > > > > Signals present in the replacement descriptor and > > containing the KeepActive > > flagshall be continued if they are currently playing and > > have not already > > completed. If a replacement signal descriptor contains a > > signal that is not > > currently playing and contains the KeepActive flag, that > > signal SHALL be > > ignored > > > > Thus the scope of keepactive flag is limited to the signal > > descriptor processing > > of the descriptor in which it arrived. > > > > When subsequently an event is detected the stopping of the > > signal( which may > > have arrived with a keepactive flag) is solely governed by > > the keepactive flag > > associated with the event that is detected. Thus point no. 2 > > is invalid. If the > > KA of event detected is not set then the MG should stop > > application of all > > active signals. > > > > > > Is this understanding correct? > > Regards, > > Sandy G > > > > 1) Check for event flag. If there is one, leave signals playing. > > 2) Otherwise check flag for each signal and keep playing or > > terminate as > > indicated. > > > > > -----Original Message----- > > > From: Kris Albert [mailto:kris_albert@lycos.com] > > > Sent: Thursday, November 02, 2000 7:57 AM > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Signal lists > > > > > > > > > > > > ----- > > > > Signals can also have a KeepActive flag. > > > > > > That's true, but my question is different, I want to ask > > > whether on the detection of event, do we process only the > > > KeepActive flag associated with Events, or do we also > > > consider the KeepActive flag associated with the active Signals. > > > > > > thanks > > > Kris > > > > > > > > > > > > -----Original Message----- > > > > > From: Kris Albert [mailto:kris_albert@LYCOS.COM] > > > > > Sent: Thursday, November 02, 2000 1:27 AM > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: Signal lists > > > > > > > > > > > > > > > Hi Christian, > > > > > I have few questions on your explanation. > > > > > > > > > > > [CHG] I guess you can view this is several ways. The > > > > > KeepActive on ALL > > > > > > signals certainly makes sense when you don't want any > > > > > interruption. But > > > > > > is it erroneous to specify Keepactive on different signals? > > > > > Certainly > > > > > > weird behaviour but you may want the initial part of a > > > > > message to play > > > > > > irrespective of what event happens and you don't care about > > > > > the rest of > > > > > > the signal. I would say that the Keepactive pertains to a > > > > > moment in time > > > > > > in the playback of a message. > > > > > > ie. Signal list = (s1ka, s2, s3, s4ka) > > > > > > If you receive an event when S1KA is playing the whole > > > list plays. > > > > > > If you receive an event when S2 is playing the whole > > list stops. > > > > > > > > > > I am not able to understand your example here. > > > > > It is specified in MEGACO that " Normally, recognition of an > > > > > event shall cause any active signals to stop. When KeepActive > > > > > is specified in the event, the MG shall not interrupt any > > > > > signals active on the Termination on which the event is > > detected." > > > > > > > > > > how does the 'KeepActive' status of signals matter here. Only > > > > > KeepActive Flag associated with Event Defination should be > > > > > considered. Otherwise Event Defination should have a embedded > > > > > Signal Descriptor. > > > > > > > > > > I will appriciate if you please further explain your example > > > > > w.r.t. the arrival of new signal descriptor with the same > > > > > Signal list. > > > > > > > > > > > > > > > Always, > > > > > Kris > > > > > > > > > > > > > > > > > > > > Get FREE Email/Voicemail with 15MB at Lycos Communications at > > > > http://comm.lycos.com > > > > > > > > > > > > > > > > > Get FREE Email/Voicemail with 15MB at Lycos Communications at > > http://comm.lycos.com > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 2 11:51:09 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15445 for ; Thu, 2 Nov 2000 11:51:08 -0500 (EST) Received: from standards (47.234.32.16:1368) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAEA75@standards.nortelnetworks.com>; Thu, 2 Nov 2000 11:33:52 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 69161 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 11:33:52 -0500 Received: from hvmta03-stg.us.psimail.psi.net (hvmta03-ext.us.psimail.psi.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAEA74@standards.nortelnetworks.com>; Thu, 2 Nov 2000 11:33:52 -0500 Received: from dev_4 ([38.150.216.6]) by hvmta03-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20001102164944.EJZG24415.hvmta03-stg@dev_4> for ; Thu, 2 Nov 2000 11:49:44 -0500 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 V4.72.3110.3 Message-ID: <002801c044ec$f16bac30$70d8a8c0@dev_4.us.radvision.com> Date: Thu, 2 Nov 2000 11:50:01 -0500 Reply-To: delbert@radvision.com Sender: "Media Gateway Control (megaco)" From: Dan Elbert Subject: Audit Capabilities To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit In the call flows example, the MGC programs an ephemeral termination with a list of preferred codecs encoded in the Local Descriptor. Let's say that the MGC needs to get beforehand the information about what codecs will be supported in an ephemeral termination in the MG. The MGC can use Audit Capabilities to audit the MG. The question is does the MGC needs to create an ephemeral termination before the audit so it can be addresssed in the Audit ? Or can it use the CHOOSE wildcard ? Or there is some other way to do this ? Thanks, Dan Elbert RADVISION From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 2 12:44:20 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29623 for ; Thu, 2 Nov 2000 12:44:19 -0500 (EST) Received: from standards (47.234.32.16:2765) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAEAB5@standards.nortelnetworks.com>; Thu, 2 Nov 2000 12:26:47 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 69245 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 12:26:47 -0500 Received: from smtprch1.nortel.com (47.113.64.103:56286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAEAB4@standards.nortelnetworks.com>; Thu, 2 Nov 2000 12:26:47 -0500 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Thu, 2 Nov 2000 11:26:37 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 2 Nov 2000 11:26:34 -0600 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD110250C6C2@zcard00g.ca.nortel.com> Date: Thu, 2 Nov 2000 11:26:30 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Signal lists X-To: "sgautam@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Sorry, that's not what I meant to imply. > -----Original Message----- > From: Sandeep Gautam [mailto:sgautam@HSS.HNS.COM] > Sent: Thursday, November 02, 2000 11:34 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Signal lists > > > Actually this makes sense because there is no need( and use) > to have KA flags > set in an embedded signals descriptor if the event does not > have KA set. [PTT] I would expect the opposite: that you need to specify the intent of the individual terms of the embedded signals descriptor when it is present. > > So is there consensus that an embedded signals descriptor > means KA of detcted > event should be assumed to be set. and thus KAs in embedded > signals descriptor > honored? ( In case none of the active signals are in the > embedded signals > descriptor with KA set then the stopping/starting of signals > will be equivalent > to stopping all the signals due to event detection( with Ka > not set) and then > processing the embedded descriptor) > > > > > > I would favour the second interpretation -- that the fate of > active signals > depends on what is in the embedded SignalsDescriptor. Not > sure this is a > real argument, but syntactically the embedded SD is an > alternative to the > event KeepActive flag. > > > -----Original Message----- > > From: sgautam@hss.hns.com [mailto:sgautam@hss.hns.com] > > Sent: Thursday, November 02, 2000 10:48 AM > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > Cc: megaco@standards.nortelnetworks.com > > Subject: RE: Signal lists > > > > > > > > > > I think the question on which there can be confusion is what > > happens when the > > embedded signals descriptor( invoked by event detection) > > contains the currently > > active signal with the KA flag set? > > If the processing of embedded descriptor is supposed to > > happen after the action > > for event detection has been taken ; then If the event 's KA > > is not set we > > should stop the signal. > > But if the processing of embedded signals descriptor is done > > simultaneously( or > > lets say before event detection processing) , then if the KA > > for any of the > > active signal is set in the embedded signals descriptor ( > > i.e. embedded signal > > descriptor carries an active signal with KA set), then we > > should also take this > > in account . In other words stop signals using signals > > descriptor invocation > > logic rather than event detection logic. > > > > Any views? > > > > Regards, > > Sandy G From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 2 15:02:35 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04991 for ; Thu, 2 Nov 2000 15:02:35 -0500 (EST) Received: from standards (47.234.32.16:1187) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAEB72@standards.nortelnetworks.com>; Thu, 2 Nov 2000 14:45:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 69495 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 14:45:03 -0500 Received: from smtprch1.nortel.com (47.113.64.103:42191) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAEB70@standards.nortelnetworks.com>; Thu, 2 Nov 2000 14:45:03 -0500 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Thu, 2 Nov 2000 13:21:32 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 2 Nov 2000 13:21:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04502.13C3BCE0" Message-ID: Date: Thu, 2 Nov 2000 13:21:19 -0600 Reply-To: Amy Pendleton Sender: "Media Gateway Control (megaco)" From: Amy Pendleton Subject: Re: ServiceChange from a Dead Controller? 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_01C04502.13C3BCE0 Content-Type: text/plain I hate to keep revisiting decisions made but the fact is, Nortel has more than one MGC in the market today using protocols which support the equivalent of a ServiceChange message from the MGC directing its gateway during a failover. This mechanism is used both for real failure (dead MGC) and for software upgrade. In both cases, the newly activated MGC instance (as we call it) is the only network element which can reliably determine who should be in control (back to the issue of more than one MGC announcing it is the leader -- the protocol used between the MGC instances should take this case into account). I question how the gateway can determine that the MGC is failing at all. There is no "heartbeating" mechanism in H.248, which could be a good option for determining failure for either side of the association, and the backoff algorithm described in H.248 will likely not determine the failure in a timely manner especially on gateways which are not doing the bulk of messaging (in an ISUP or PRI network, the MG mainly responds to commands from the MGC). I think to simply throw out an already existing solution has the potential of limiting the coverage for H.248. If MGC's find that H.248 will not help their solution or could even hurt it, they will choose to implement a non-compliant H.248 or stick with their protocols (most often MGCP will be the protocol of choice). Regards, Amy > -----Original Message----- > From: Rosen, Brian [SMTP:Brian.Rosen@MARCONI.COM] > Sent: Thursday, November 02, 2000 8:48 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: ServiceChange from a Dead Controller? > > I'm not sure that it's good enough to be on the list. > You get into problems like, more than one redundant MGC > telling you he's your new leader. Usually it's best if the > public makes the choice on the leader, and not the other way > around :) > > The issue of time to discover dead controllers is complex. There are > those parameters that give you information on how long to expect > a reply to take. On well-engineered networks, that time should be > short. I don't think you would be dropping calls unless it's taking > seconds to declare MGCs dead. On the Big-I internet, it might take > that long, but on a well-engineered net, it should be okay. > > We spent a while talking about these issues when these decisions were > made. We may not have the ideal solution for everyone, but we tried > to come up with one we believed would work. If real-life testing > shows it doesn't, we will have to change, but I can assure you that > we did not treat this issue lightly, and there was quite a lot of > discussion on how to do this. The result is, by every measure, a > compromise. At the moment, I'd like to try to make what we have got > work, rather than changing the mechanism. > > Brian > > > -----Original Message----- > > From: Alan Whitton [mailto:awhitton@NORTELNETWORKS.COM] > > Sent: Wednesday, November 01, 2000 6:26 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM; Rosen, Brian > > Cc: Alan Whitton > > Subject: Re: ServiceChange from a Dead Controller? > > > > > > OK, > > > > Security is good, but if it's a message from a machine on the > > Gateway's > > list, wouldn't that be the same? > > > > The concern I have is that if the gateway "ignores" messages > > from a new > > controller, until it figures out that it's OLD controller is > > dead, you'll > > have a fair number of calls "fall on the floor". Is there any > > way around > > losing those calls? > > > > Cheers, > > Alan > > ------_=_NextPart_001_01C04502.13C3BCE0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: ServiceChange from a Dead Controller?

I hate to keep = revisiting decisions made but the fact is, Nortel has more than one MGC = in the market today using protocols which support the equivalent of a = ServiceChange message from the MGC directing its gateway during a = failover.  This mechanism is used both for real failure (dead MGC) = and for software upgrade.  In both cases, the newly activated MGC = instance (as we call it) is the only network element which can reliably = determine who should be in control (back to the issue of more than one = MGC announcing it is the leader -- the protocol used between the MGC = instances should take this case into account).  I question how the = gateway can determine that the MGC is failing at all.  There is no = "heartbeating" mechanism in H.248, which could be a good = option for determining failure for either side of the association, and = the backoff algorithm described in H.248 will likely not determine the = failure in a timely manner especially on gateways which are not doing = the bulk of messaging (in an ISUP or PRI network, the MG mainly = responds to commands from the MGC).

I think to simply = throw out an already existing solution has the potential of limiting = the coverage for H.248.  If MGC's find that H.248 will not help = their solution or could even hurt it, they will choose to implement a = non-compliant H.248 or stick with their protocols (most often MGCP will = be the protocol of choice).  

Regards,
Amy

    -----Original Message-----
    From:   Rosen, Brian = [SMTP:Brian.Rosen@MARCONI.COM]
    Sent:   Thursday, November 02, 2000 8:48 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: ServiceChange from a Dead = Controller?

    I'm not sure that it's good enough to = be on the list.
    You get into problems like, more than = one redundant MGC
    telling you he's your new = leader.  Usually it's best if the
    public makes the choice on the = leader, and not the other way
    around :)

    The issue of time to discover dead = controllers is complex.  There are
    those parameters that give you = information on how long to expect
    a reply to take.  On = well-engineered networks, that time should be
    short.  I don't think you would = be dropping calls unless it's taking
    seconds to declare MGCs dead.  = On the Big-I internet, it might take
    that long, but on a well-engineered = net, it should be okay.

    We spent a while talking about these = issues when these decisions were
    made.  We may not have the ideal = solution for everyone, but we tried
    to come up with one we believed would = work.  If real-life testing
    shows it doesn't, we will have to = change, but I can assure you that
    we did not treat this issue lightly, = and there was quite a lot of
    discussion on how to do this.  = The result is, by every measure, a
    compromise.  At the moment, I'd = like to try to make what we have got
    work, rather than changing the = mechanism.

    Brian

    > -----Original Message-----
    > From: Alan Whitton = [mailto:awhitton@NORTELNETWOR= KS.COM]
    > Sent: Wednesday, November 01, = 2000 6:26 PM
    > To: = MEGACO@STANDARDS.NORTELNETWORKS.COM; Rosen, Brian
    > Cc: Alan Whitton
    > Subject: Re: ServiceChange from = a Dead Controller?
    >
    >
    > OK,
    >
    > Security is good, but if it's a = message from a machine on the
    > Gateway's
    > list, wouldn't that be the = same?
    >
    > The concern I have is that if = the gateway "ignores" messages
    > from a new
    > controller, until it figures out = that it's OLD controller is
    > dead, you'll
    > have a fair number of calls = "fall on the floor". Is there any
    > way around
    > losing those calls?
    >
    > Cheers,
    > Alan
    >

------_=_NextPart_001_01C04502.13C3BCE0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 2 18:21:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21620 for ; Thu, 2 Nov 2000 18:21:35 -0500 (EST) Received: from standards (47.234.32.16:2872) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAECA3@standards.nortelnetworks.com>; Thu, 2 Nov 2000 18:04:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 69915 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 18:04:10 -0500 Received: from egypt.assuredaccess.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAECA2@standards.nortelnetworks.com>; Thu, 2 Nov 2000 17:54:09 -0500 Received: from assuredaccess.com (natxlate.assuredaccess.com [206.169.126.97]) by egypt.assuredaccess.com (8.9.3/8.9.3) with ESMTP id PAA14311; Thu, 2 Nov 2000 15:12:09 -0800 (PST) X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A01F67F.1A8B8209@assuredaccess.com> Date: Thu, 2 Nov 2000 15:19:27 -0800 Reply-To: njain@assuredaccess.com Sender: "Media Gateway Control (megaco)" From: Nitin Jain Organization: Assured Access Subject: Change of local UDP port in a Move. To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, In certain implementation's of MG a MOVE may result is a different UDP port number and possibly a different IP-address for the local descriptor. Can the MG send local descriptor, with new UDP port number and IP-address , in the reply to a Move command by the MGC, so that the remote descriptor on the other end can be modified. Thanks in advance. Nitin Jain From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 2 18:41:57 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26172 for ; Thu, 2 Nov 2000 18:41:56 -0500 (EST) Received: from standards (47.234.32.16:2872) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAECC2@standards.nortelnetworks.com>; Thu, 2 Nov 2000 18:24:36 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 69952 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 18:24:36 -0500 Received: from zhars00u (47.101.112.103:39785) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAECBD@standards.nortelnetworks.com>; Thu, 2 Nov 2000 18:14:35 -0500 Received: from zrtps06s.us.nortel.com by zhars00u; Thu, 2 Nov 2000 23:27:23 +0000 Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com (8.8.8+Sun/SMI-SVR4 CUE5.1) id SAA20426; Thu, 2 Nov 2000 18:27:22 -0500 (EST) Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 2 Nov 2000 18:27:22 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD110250C6CF@zcard00g.ca.nortel.com> Date: Thu, 2 Nov 2000 18:27:18 -0500 Reply-To: "Taylor, Tom-PT" Sender: "Media Gateway Control (megaco)" From: "Taylor, Tom-PT" Subject: Re: Change of local UDP port in a Move. X-To: "njain@assuredaccess.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM I assume you ask that in the context that the Move command did not itself specify a local descriptor. I would say the answer is "yes", based on the priciple that the reply to a command should indicate all of its consequences. > -----Original Message----- > From: Nitin Jain [mailto:njain@ASSUREDACCESS.COM] > Sent: Thursday, November 02, 2000 6:19 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Change of local UDP port in a Move. > > > Hi, > > In certain implementation's of MG a MOVE may result is a different UDP > port number and possibly a different IP-address for the local > descriptor. > Can the MG send local descriptor, with new UDP port number > and IP-address , > in the reply to a Move command by the MGC, so that the remote > descriptor > on the other end can be modified. > > Thanks in advance. > Nitin Jain > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 2 22:19:05 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11345 for ; Thu, 2 Nov 2000 22:19:05 -0500 (EST) Received: from standards (47.234.32.16:4738) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAED55@standards.nortelnetworks.com>; Thu, 2 Nov 2000 22:01:38 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 70135 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 22:01:38 -0500 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAED54@standards.nortelnetworks.com>; Thu, 2 Nov 2000 21:51:38 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eA337Wt17667; Fri, 3 Nov 2000 04:07:32 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA18750; Fri, 3 Nov 2000 04:07:32 +0100 (MET) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA29311; Fri, 3 Nov 2000 04:07:16 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01A6E980@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A0225B7.266C461E@ericsson.com> Date: Fri, 3 Nov 2000 13:40:55 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: IANA Registration X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Brian, Can you allude to what that logic was? Or is just a case of a note saying that the requestor has to see where "like" error codes are already defined. Cheers, Christian "Rosen, Brian" wrote: > > There was some logic to the assignments. If I was writing instructions, > I would say that the requestor (of a new error code assignment) should > specify the first two digits, and IANA assigns the last sequentially. > > Brian > > > -----Original Message----- > > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > > Sent: Thursday, November 02, 2000 10:26 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: IANA Registration > > > > > > You can see the initial package list at > > http://www.isi.edu/in-notes/iana/assignments/megaco-h248 > > > > I would like to clear up one open question, regarding the > > assignment of > > error codes. Do we tell IANA to assign them sequentially > > starting at 1 but > > respecting the initial assignments in section 7.3, or what? > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 2 23:04:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17367 for ; Thu, 2 Nov 2000 23:04:08 -0500 (EST) Received: from standards (47.234.32.16:2127) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAEDD3@standards.nortelnetworks.com>; Thu, 2 Nov 2000 22:46:38 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 70302 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Nov 2000 22:46:37 -0500 Received: from mailcity.com (fes-qout.whowhere.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAEDD2@standards.nortelnetworks.com>; Thu, 2 Nov 2000 22:46:37 -0500 Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Thu Nov 2 20:02:22 2000 Mime-Version: 1.0 X-Sent-Mail: off X-Mailer: MailCity Service X-Sender-Ip: 216.6.89.98 Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Message-ID: Date: Thu, 2 Nov 2000 20:02:22 -0800 Reply-To: kris_albert@lycos.com Sender: "Media Gateway Control (megaco)" From: Kris Albert Organization: Lycos Communications (http://comm.lycos.com:80) Subject: Re: Signal lists X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I will appreciate if you can give me a example for the case when MG is playing a signal list = (s1ka, s2, s3, s4ka) and MG receives a replacement signal descriptor with same signal list, what will the processing 1) when S1KA is playing currently 2) when S2 is playing currently How the keepActive status will work on the case of signal list.? thanks Kris -- On Thu, 2 Nov 2000 10:23:39 Tom-PT Taylor wrote: >I stand corrected and apologize for my carelessness. You're right. So the >only thing that determines whether the signal list keeps playing is the >keepActive setting (or embedded SignalsDescriptor) in the event itself. > >> -----Original Message----- >> From: Sandeep Gautam [mailto:sgautam@HSS.HNS.COM] >> Sent: Thursday, November 02, 2000 8:40 AM >> To: MEGACO@STANDARDS.NORTELNETWORKS.COM >> Subject: Re: Signal lists >> >> >> Hi, >> The keepactive flag that comes in the signals descriptor is >> not remebered. The >> fact whether the currently playing signal arrived with a >> keepcative flag or not >> is immaterial for subsequent processing. >> >> According to text >> >> Signals present in the replacement descriptor and >> containing the KeepActive >> flagshall be continued if they are currently playing and >> have not already >> completed. If a replacement signal descriptor contains a >> signal that is not >> currently playing and contains the KeepActive flag, that >> signal SHALL be >> ignored >> >> Thus the scope of keepactive flag is limited to the signal >> descriptor processing >> of the descriptor in which it arrived. >> >> When subsequently an event is detected the stopping of the >> signal( which may >> have arrived with a keepactive flag) is solely governed by >> the keepactive flag >> associated with the event that is detected. Thus point no. 2 >> is invalid. If the >> KA of event detected is not set then the MG should stop >> application of all >> active signals. >> >> >> Is this understanding correct? >> Regards, >> Sandy G >> >> 1) Check for event flag. If there is one, leave signals playing. >> 2) Otherwise check flag for each signal and keep playing or >> terminate as >> indicated. >> >> > -----Original Message----- >> > From: Kris Albert [mailto:kris_albert@lycos.com] >> > Sent: Thursday, November 02, 2000 7:57 AM >> > To: Taylor, Tom-PT [NORSE:B901:EXCH] >> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM >> > Subject: Re: Signal lists >> > >> > >> > >> > ----- >> > > Signals can also have a KeepActive flag. >> > >> > That's true, but my question is different, I want to ask >> > whether on the detection of event, do we process only the >> > KeepActive flag associated with Events, or do we also >> > consider the KeepActive flag associated with the active Signals. >> > >> > thanks >> > Kris >> > >> > > >> > > > -----Original Message----- >> > > > From: Kris Albert [mailto:kris_albert@LYCOS.COM] >> > > > Sent: Thursday, November 02, 2000 1:27 AM >> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM >> > > > Subject: Re: Signal lists >> > > > >> > > > >> > > > Hi Christian, >> > > > I have few questions on your explanation. >> > > > >> > > > > [CHG] I guess you can view this is several ways. The >> > > > KeepActive on ALL >> > > > > signals certainly makes sense when you don't want any >> > > > interruption. But >> > > > > is it erroneous to specify Keepactive on different signals? >> > > > Certainly >> > > > > weird behaviour but you may want the initial part of a >> > > > message to play >> > > > > irrespective of what event happens and you don't care about >> > > > the rest of >> > > > > the signal. I would say that the Keepactive pertains to a >> > > > moment in time >> > > > > in the playback of a message. >> > > > > ie. Signal list = (s1ka, s2, s3, s4ka) >> > > > > If you receive an event when S1KA is playing the whole >> > list plays. >> > > > > If you receive an event when S2 is playing the whole >> list stops. >> > > > >> > > > I am not able to understand your example here. >> > > > It is specified in MEGACO that " Normally, recognition of an >> > > > event shall cause any active signals to stop. When KeepActive >> > > > is specified in the event, the MG shall not interrupt any >> > > > signals active on the Termination on which the event is >> detected." >> > > > >> > > > how does the 'KeepActive' status of signals matter here. Only >> > > > KeepActive Flag associated with Event Defination should be >> > > > considered. Otherwise Event Defination should have a embedded >> > > > Signal Descriptor. >> > > > >> > > > I will appriciate if you please further explain your example >> > > > w.r.t. the arrival of new signal descriptor with the same >> > > > Signal list. >> > > > >> > > > >> > > > Always, >> > > > Kris >> > > > >> > > > >> > > > >> > > > Get FREE Email/Voicemail with 15MB at Lycos Communications at >> > > http://comm.lycos.com >> > > >> > > >> > >> > >> > Get FREE Email/Voicemail with 15MB at Lycos Communications at >> http://comm.lycos.com >> > Get FREE Email/Voicemail with 15MB at Lycos Communications at http://comm.lycos.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 3 02:35:35 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03419 for ; Fri, 3 Nov 2000 02:35:34 -0500 (EST) Received: from standards (47.234.32.16:4612) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAEEFF@standards.nortelnetworks.com>; Fri, 3 Nov 2000 2:18:00 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 70696 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 02:18:00 -0500 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAEEFE@standards.nortelnetworks.com>; Fri, 3 Nov 2000 2:17:59 -0500 Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eA37Xtt24280; Fri, 3 Nov 2000 08:33:55 +0100 (MET) Received: from uabs28 (uabs28 [134.138.228.5]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id eA37Xsn03035; Fri, 3 Nov 2000 08:33:55 +0100 (MET) Received: from uab.ericsson.se by uabs28 (8.8.8+Sun/client-1.3uab2) id IAA28144; Fri, 3 Nov 2000 08:33:54 +0100 (MET) X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 References: <65256957.00475B7D.00@sandesh.hss.hns.com> Content-Type: multipart/mixed; boundary="------------94E0F6680C969C6D80B2A400" Message-ID: <3A026A62.F9BE9F5D@uab.ericsson.se> Date: Fri, 3 Nov 2000 08:33:54 +0100 Reply-To: Alf Heidermark Sender: "Media Gateway Control (megaco)" From: Alf Heidermark Organization: Ericsson Utvecklings AB Subject: Re: Significance of WARM Boot X-To: klaha@HSS.HNS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------94E0F6680C969C6D80B2A400 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit They are defined in Annex L to H.248 bound for determination in November in SG 16 Kushanava Laha wrote: > > Hi Tom, > Thanks for indicating the procedures in MG for > each type of boot. Can these be included in the protocol document? > > Further w.r.t. Section 7.2.8 that covers the various Service Change Reasons > I propose the scenarios for reporting each Service Change Reason from the > MG be also included in the protocol, as had been done for the error codes. > > A related proposal - Assuming the interpretations of cold and warm boot as > indicated > by you, a new Service Change Reason "MG registration" be also included that > means that the MG is registering with the MGC fresh and has no (or has lost all) > previous > context and state. This shall be included in the Service Change Reason parameter > in the > initial Service Change on root from MG to MGC for registering. > > regards, > Kushanava Laha > > Tom-PT Taylor on 09/11/2000 06:19:28 PM > > Please respond to Tom-PT Taylor > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Kushanava Laha/HSS) > > Subject: Re: Significance of WARM Boot > > In both cases, provisioned values are preserved. The usual distinctions > are: > - cold boot: all non-NULL contexts are cleared > - warm boot: transactions in process may be lost, but otherwise all state > is preserved > - hot standby: no state loss as a result of the transition > > > -----Original Message----- > > From: Prashant Jain [mailto:prjain@HSS.HNS.COM] > > Sent: Sunday, September 10, 2000 8:44 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Significance of WARM Boot > > > > > > Hi Brian, Tom, List, > > > > Can anyone explain the difference between the COLD Boot and > > the WARM Boot as > > Service Change Reasons. > > > > Does it mean that in the case of COLD boot, everything is > > powered on from the > > begining. However in the case of WARM boot, provisioned data > > at MG may be > > preserved as it is, but all the active and the transient > > calls are cleared of > > its own. > > > > Please calrify. > > > > Prashant Jain > > Hughes Software Systems > > --------------94E0F6680C969C6D80B2A400 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Description: Card for Alf Heidermark Content-Disposition: attachment; filename="vcard.vcf" Content-Transfer-Encoding: 7bit begin: vcard fn: Alf Heidermark n: Heidermark;Alf org: Ericsson Core Network product email;internet: Alf.Heidermark@uab.ericsson.se note;quoted-printable:Telphone number +4687273894=0D=0A= Mobile: +46703997883=0D=0A= Address: Armborstv=E4gen 14=0D=0A= =C4lvsj=F6 x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard --------------94E0F6680C969C6D80B2A400-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 3 06:02:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06843 for ; Fri, 3 Nov 2000 06:02:43 -0500 (EST) Received: from standards (47.234.32.16:1429) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAEF89@standards.nortelnetworks.com>; Fri, 3 Nov 2000 5:45:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 70856 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 05:45:09 -0500 Received: from mt-news.com (szptt103-190.szptt.net.cn) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAEF77@standards.nortelnetworks.com>; Fri, 3 Nov 2000 5:35:06 -0500 Received: from h809 [63.30.200.188] by mt-news.com (SMTPD32-5.05) id A8EF1E530144; Fri, 03 Nov 2000 18:48:15 +0800 Message-ID: <200011031849218.SM00234@h809> Date: Fri, 3 Nov 2000 18:52:41 +0800 Reply-To: hv@OF-HACHETAL.DE Sender: "Media Gateway Control (megaco)" From: hv@OF-HACHETAL.DE Subject: At last, Herbal V, the all natural alternative to V----A! To: MEGACO@STANDARDS.NORTELNETWORKS.COM Herbal V: An Incredible All-Natural Healthy Alternative Herbal V is the All Natural Approach to Male Virility, Vitality and Pleasure. Available N o w ! Welcome to the New Sexual Revolution. It's the all natural male potency and pleasure pill that men everywhere are buzzing about. Herbal V is safe, natural and specifically formulated to help support male sexual function and pleasure. You just take two easy-to-swallow tablets one hour before sex. And there's more great news - you can get Herbal V for less than $1 a pill. Amazing word of mouth praise on Herbal V has been spreading like wildfire-already over 1,500,000 men have chosen Herbal V. Since it is 100% natural you will never have to worry about safety. Try doctor-recommended Herbal V today and have the greatest night of your life! Herbal V... Bringing Back the Magic! 1,585,000 men can't be wrong. To date over 1 million men have tried the super supplement Herbal V. Here is why: No Doctor Visit Required Available Over the Counter Not a Drug 100% Natural Safe, No Worries Highest Quality Pharmaceutical-Grade Pure Nutriceuticals Guaranteed Potency & Purity Be a Real Man Again! Questions and Answers What is Herbal V? Herbal V is a proprietary blend that was specifically developed as a safe alternative for men who prefer an all-natural approach to address impotence and boost sexual performance. This amazing formula first became popular with Hollywood insiders and the wealthy elite. They were maximizing their sex lives, long before it was available to the general public. How does Herbal V work? Developed by a team whose goal was to create the perfect all-natural aphrodisiac. Herbal V is the result of that remarkable effort. The Herbal V formula contains a precise blend of cutting edge pro-sexual nutrients from around the world that provide nutritional support, making it possible for a man to have a pleasurable sexual experience. What can Herbal V do for me? Herbal V helps support male sexual function and pleasure in a safe and natural manner. Simply put, it can make your sex life incredible. Is Herbal V Safe? One of the great things about Herbal V is that it is not a drug. It is an incredible herbal dietary supplement that provides nutritional support for male sexual function and pleasure. One of the most comforting features of Herbal V is that you never have to worry about safety. Herbal V: Safe - Natural - Exciting Many have speculated that because Herbal V is so popular with men, it must contain prescription drugs or chemical components. Herbal V does not contain any elements or traces of any prescription drug. Herbal V is made using the world's most technologically advanced state-of-the-art cold processing equipment to ensure maximum purity. Herbal V has been independently analyzed by the nation's premier testing facility to ensure purity, quality and to end the rumors that, because it is so popular, it must somehow be chemical. It is not. Herbal V is natural - just as it says on the label. Herbal V is simply fantastic! Herbal V: Ingredients Yohimbe, saw palmetto, avena sativa, androstenedione, guarana, taurine, siberian ginseng, tribulus terrestris. Tribulus Terrestis is certified to enhanced testosterone levels by increasing Luteinzing hormone (LH) levels. Androstenedione which is a precursor to testosterone unlocks bound testosterone and makes it biologically active again quickly. This means a dramatic surge in desire. Avena Sativa Stimulates the neurotransmitter pleasure centers to maximum capacity. This greatly intensifies pleasure. Just listen to what Herbal V has done for the sex lives of people like you! “On a scale of 1 to 10, it's a 15. Electrifying. It's like a wonder pill!” — Justin Q B., New Haven, Texas “I haven't had sexual relations in 11 years. Then with Herbal V it was... wow! It works again!” — Sid R., Lakeland, Florida “I had sex four times in one night. It made me feel like a 19-year-old again.” — Chip S, Beech Mountain, North Carolina “Herbal V has turned my husband into a Sexual Superman! I like the fact that it's all natural and has no side effects. It's bringing back the good old days.” — Jennifer B, Beverly Hills, California The above testimonials are from product literature, and we have not independently verified them. However, the following testimonial is from a "senior" gentleman who has purchased his second bottle of Herbal V. When we heard his words with our own ears, we asked his permission to print them here. “Man! I'm wild as I can be! I feel like I'm 25 years old again! I'm not believing this!” — Mr. Murphy, age 64, Lampart, IL. Risk Free: Double Your Money Back Guarantee If Herbal V does not give the desired results as stated above, simply return the unused portion for a double-your money back refund. No questions asked ! Order Now: Safe, Fast, Secure, Private Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is available only through this special promotional offer. Herbal V arrives in plain packaging for your privacy. Any and all information is kept strictly confidential. Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express.payments. Money Orders are accepted only by Postal Mail. Each bottle of Herbal V contains 30 tablets, approximately a 1 month supply. Step 1: Place a check by your desired quanity. ______ 1 Bottle of Herbal V $28 ______ 2 Bottles of Herbal V $48 ______ 3 Bottles of Herbal V $59 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$34, 2 bottles=$54, 3 bottles=$65 ] International Orders Please add $16 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ] We cannot accept foreign checks. International money orders or credit cards only. Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: LSN 3502 N. Powerline Rd. #525 Pompano Beach, FL 33069 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: Herbal V is not intended to diagnose, treat, cure or prevent any disease. As individuals differ, so will results. Herbal V helps provide herbal and nutritional support for male sexual performance. The FDA has not evaluated these statements. For details about our double your money back guarantee, please write to the above address, attention consumer affairs department; enclose a self addressed stamped envelope for this and any requested contact information. Thank You. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 3 08:53:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15095 for ; Fri, 3 Nov 2000 08:53:41 -0500 (EST) Received: from standards (47.234.32.16:1694) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAEFF2@standards.nortelnetworks.com>; Fri, 3 Nov 2000 8:36:12 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 71004 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 08:36:12 -0500 Received: from imr1.ericy.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAEFE6@standards.nortelnetworks.com>; Fri, 3 Nov 2000 8:26:11 -0500 Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id HAA19132 for ; Fri, 3 Nov 2000 07:42:09 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.10.2/8.10.2) with ESMTP id eA3DeAk16621 for ; Fri, 3 Nov 2000 07:40:10 -0600 (CST) Received: from b04d01.exu.ericsson.se (b04d01 [138.85.62.101]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id HAA19251 for ; Fri, 3 Nov 2000 07:42:08 -0600 (CST) Received: (from eusdbd@localhost) by b04d01.exu.ericsson.se (8.9.1/8.9.1) id HAA06491 for megaco@standards.nortelnetworks.com; Fri, 3 Nov 2000 07:41:51 -0600 (CST) X-Sun-Charset: US-ASCII Message-ID: <200011031341.HAA06491@b04d01.exu.ericsson.se> Date: Fri, 3 Nov 2000 07:41:51 -0600 Reply-To: David Dykhuizen Sender: "Media Gateway Control (megaco)" From: David Dykhuizen Subject: Misleading ABNF Comment (servChgReplyParm) To: MEGACO@STANDARDS.NORTELNETWORKS.COM Morning: We've looked in the Implementors' Guide for H.248 (Draft_V3) and the mail archive but have not found the following "issue" addressed. According to the ASN.1 definition, reading the comment above the ServiceChangeResult parameter definition, we have: "-- For ServiceChangeResult, no parameters are mandatory. Hence the -- distinction between ServiceChangeParm and ServiceChangeResParm." If we look at the ASN.1 definition for ServiceChangeResParm, all elements are optional. Now when we look at the ABNF definition, and reading the comment above the servChgReplyParm parameter: " ; at-most-once. Version is REQUIRED on first ServiceChange response" Going back to chapter 7.2.8 in the main specification, towards the end of the chapter we have the following statement: The return from ServiceChange is empty except when the Root termination is used. In that case it includes the following parameters as required: ... some text deleted for brevity ... * ServiceChangeVersion, if the responder wishes to negotiate the version of the protocol to be used for the association. Therefore, I suggest that the comment "Version is REQUIRED on first ServiceChange response" be removed. Thanks, /David From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 3 08:57:51 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16410 for ; Fri, 3 Nov 2000 08:57:50 -0500 (EST) Received: from standards (47.234.32.16:1694) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF007@standards.nortelnetworks.com>; Fri, 3 Nov 2000 8:39:44 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 71005 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 08:39:43 -0500 Received: from zmers013 (47.124.1.40:33035) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAEFE7@standards.nortelnetworks.com>; Fri, 3 Nov 2000 8:29:43 -0500 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by zmers013; Fri, 3 Nov 2000 08:42:13 -0500 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Fri, 3 Nov 2000 08:41:47 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 3 Nov 2000 08:41:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0459B.C7839270" Message-ID: <75C9A75D295AD31184E70008C79189D2035A773C@zcard00b.ca.nortel.com> Date: Fri, 3 Nov 2000 08:41:33 -0500 Reply-To: "Whitton, Alan" Sender: "Media Gateway Control (megaco)" From: "Whitton, Alan" Subject: Re: Last Call On NAS Package (Revisited for November) 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_01C0459B.C7839270 Content-Type: text/plain; charset="iso-8859-1" Agreed, Cheers, Alan > -----Original Message----- > From: Mitchell, Julian [MDN05:CV04:EXCH] > Sent: Thursday, November 02, 2000 9:32 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Cc: Whitton, Alan [CAR:5Z00:EXCH] > Subject: RE: Last Call On NAS Package (Revisited for November) > > Hi, > > I think that we should keep the AUTHRES (or AUTHEX) event simple so that > it indicates just service denied, callback service authorized and outgoing > service authorized. > > If the service is denied, then we would expect a NASREL event to be > triggered. I would therefore suggest adding this list of reasons to the > list of possible reason values for the NASREL event, and maybe noting this > behaviour in the procedures for the NAS INCOMING PACKAGE. This has the > advantage of keeping all the NAS release reasons in one event. > > Thanks > > Julian > > -----Original Message----- > From: Whitton, Alan [SMTP:awhitton@americasm01.nt.com] > Sent: Wednesday, November 01, 2000 4:08 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Last Call On NAS Package (Revisited for November) > > Folks, > > OK, so after looking things over the AUTHRES (or AUTHEX) event looks > like > it needs a little more information returned in it other than success > or > failure. > > Once a "call" is UP, the Modems have trained and now the End User's > PC is > connected to the ISP's Radius Server more than simply "authorization > failure" can occur. Port limiting can occur (not enough virtual > modems > available to that customer's domain), or there can be a RADIUS > server > failure (and thus the user cannot log in). > > What I'd like to propose is either adding a reason code for the > AUTHRES (or > AUTHEX), or expand the reason codes for AUTHRES (or AUTHEX). The > following > reasons, come to mind: > 1 other, unspecified > 2 CLID was unacceptable (rejected by CLID filter) > 3 CLID was blocked (rejected because blocked CLIDs not allowed) > 4 dialed number is not acceptable > 5 port limit or overflow port limit reached > 6 no IP address available > 7 all home gateways at capacity or admin state locked > 8 port guarantee prevented call from being taken proxied to > 9 RADIUS server rejected the request > > > Cheers, > Alan Whitton > > Holistic Metaservices Architect > CVX SS7 Gateway > Nortel Networks, ------_=_NextPart_001_01C0459B.C7839270 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Last Call On NAS Package (Revisited for November)

Agreed,

Cheers,
Alan

     -----Original Message-----
    From:   Mitchell, Julian [MDN05:CV04:EXCH]  =
    Sent:   = Thursday, November 02, 2000 9:32 = AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Cc:     Whitton, Alan [CAR:5Z00:EXCH]
    Subject:        RE: Last Call On NAS Package = (Revisited for November)

    Hi,

    I think that we = should keep the AUTHRES (or AUTHEX) event simple so that it indicates = just service denied, callback service authorized and outgoing service = authorized.

    If the service is = denied, then we would expect a NASREL event to be triggered. I would = therefore suggest adding this list of reasons to the list of possible = reason values for the NASREL event, and maybe noting this behaviour in = the procedures for the NAS INCOMING PACKAGE. This has the advantage of = keeping all the NAS release reasons in one event.

    Thanks

    Julian

      -----Original Message-----
      From:   Whitton, Alan  = [SMTP:awhitton@americasm01.nt.com]
      Sent:   Wednesday, November 01, 2000 4:08 PM
      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
      Subject:       = Last Call On NAS Package (Revisited = for November)

      Folks,

      OK, so after looking things over the = AUTHRES (or AUTHEX) event looks like
      it needs a little more information = returned in it other than success or
      failure.

      Once a  "call" is UP, = the Modems have trained and now the End User's PC is
      connected to the ISP's Radius Server = more than simply "authorization
      failure" can occur. Port = limiting can occur (not enough virtual modems
      available to that customer's domain), = or there can be a RADIUS server
      failure (and thus the user cannot log = in).

      What I'd like to propose is either = adding a reason code for the AUTHRES (or
      AUTHEX), or expand the reason codes = for AUTHRES (or AUTHEX). The following
      reasons, come to mind:
        1 other, unspecified
        2 CLID was unacceptable = (rejected by CLID filter)
        3 CLID was blocked (rejected = because blocked CLIDs not allowed)
        4 dialed number is not = acceptable
        5 port limit or overflow port = limit reached
        6  no IP address = available
        7 all home gateways at = capacity or admin state locked
        8 port guarantee prevented = call from being taken proxied to
        9     = RADIUS server rejected the request


      Cheers,
      Alan Whitton

      Holistic Metaservices Architect
      CVX SS7 Gateway
      Nortel Networks,

------_=_NextPart_001_01C0459B.C7839270-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 3 09:09:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20795 for ; Fri, 3 Nov 2000 09:09:31 -0500 (EST) Received: from standards (47.234.32.16:1694) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF023@standards.nortelnetworks.com>; Fri, 3 Nov 2000 8:52:09 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 71085 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 08:52:09 -0500 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF022@standards.nortelnetworks.com>; Fri, 3 Nov 2000 8:52:08 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA24578; Fri, 3 Nov 2000 09:08:03 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA16352; Fri, 3 Nov 2000 09:08:05 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Nov 2000 09:07: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: <4FBEA8857476D311A03300204840E1CF01A6E995@whq-msgusr-02.pit.comms.marconi.com> Date: Fri, 3 Nov 2000 09:07:41 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Change of local UDP port in a Move. X-To: "njain@assuredaccess.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Wow. I don't think the MG could send an unrequested media descriptor. I also think that this is going to be problematic for some, but not all MGCs, so I would caution implementations who plan such designs, but it sure should be allowed. Took me a while to figure out how you would design such an MG, but I guess you could, among other things, have to have contexts which have certain physical terminations end up with ephemerals on one network interface, but if the ephemeral was moved to a context with a different physical termination, the network interface had to move. We might want to think of a package that contains some properties that indicate when such a thing is possible. Then the MGC could include an audit or resend of media when doing a Move when such a circumstance is possible. Brian > -----Original Message----- > From: Nitin Jain [mailto:njain@assuredaccess.com] > Sent: Thursday, November 02, 2000 6:19 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Change of local UDP port in a Move. > > > Hi, > > In certain implementation's of MG a MOVE may result is a different UDP > port number and possibly a different IP-address for the local > descriptor. > Can the MG send local descriptor, with new UDP port number > and IP-address , > in the reply to a Move command by the MGC, so that the remote > descriptor > on the other end can be modified. > > Thanks in advance. > Nitin Jain > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 3 10:25:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10109 for ; Fri, 3 Nov 2000 10:25:05 -0500 (EST) Received: from standards (47.234.32.16:2012) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF0DB@standards.nortelnetworks.com>; Fri, 3 Nov 2000 10:07:38 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 71318 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 10:07:38 -0500 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF0DA@standards.nortelnetworks.com>; Fri, 3 Nov 2000 10:07:38 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA01643 for ; Fri, 3 Nov 2000 10:23:34 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA07775 for ; Fri, 3 Nov 2000 10:23:36 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Nov 2000 10:22:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C045AA.08114400" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E99F@whq-msgusr-02.pit.comms.marconi.com> Date: Fri, 3 Nov 2000 10:23:34 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: FW: I-D ACTION:draft-rosen-megaco-namepatterns-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_000_01C045AA.08114400 Content-Type: text/plain; charset="ISO-8859-1" Amusing slip of the keyboard at the I-D editor (look carefully at the cc line!) -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Friday, November 03, 2000 6:40 AM Cc: megaco@standards.nortel.networks.com.cnri.reston.va Subject: I-D ACTION:draft-rosen-megaco-namepatterns-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Name Pattern Package for Megaco Author(s) : B. Rosen Filename : draft-rosen-megaco-namepatterns-00.txt Pages : 4 Date : 02-Nov-00 To construct meaningful audits of terminations while controlling the amount of data sent in response to the audits, it would be very helpful if the MGC understood the way terminations were named in the MG. This package provides a method for obtaining the naming pattern for terminations in an MG A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosen-megaco-namepatterns-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-rosen-megaco-namepatterns-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-rosen-megaco-namepatterns-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_000_01C045AA.08114400 Content-Type: message/rfc822 To: Subject: Date: Fri, 3 Nov 2000 10:22:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C045AA.08114400" ------_=_NextPart_002_01C045AA.08114400 Content-Type: text/plain ------_=_NextPart_002_01C045AA.08114400 Content-Type: application/octet-stream; name="ATT19233" Content-Disposition: attachment; filename="ATT19233" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001102101634.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosen-megaco-namepatterns-00.txt ------_=_NextPart_002_01C045AA.08114400 Content-Type: message/external-body; site="internet-drafts"; dir="draft-rosen-megaco-namepatterns-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C045AA.08114400-- ------_=_NextPart_000_01C045AA.08114400-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 3 12:00:59 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06417 for ; Fri, 3 Nov 2000 12:00:59 -0500 (EST) Received: from standards (47.234.32.16:3710) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF2B4@standards.nortelnetworks.com>; Fri, 3 Nov 2000 11:39:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 71693 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 11:39:21 -0500 Received: from 206-103-61-194.oresis.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF205@standards.nortelnetworks.com>; Fri, 3 Nov 2000 11:29:21 -0500 Received: from oresisexchange.oresis by 206-103-61-194.oresis.com via smtpd (for h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) with SMTP; 3 Nov 2000 16:39:46 UT Received: by oresisexchange.oresis with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Nov 2000 08:45:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <8AF3E90145A8D411ADC6009027E309D63EF9AA@oresisexchange.oresis> Date: Fri, 3 Nov 2000 08:45:17 -0800 Reply-To: Parag Sharma Sender: "Media Gateway Control (megaco)" From: Parag Sharma Subject: Bearer resource configuration To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, I am new to Megaco and was wondering if there is any work in progress or any specification available on configuration of bearer resources and how exactly is this configuration information correlated between the MGC & MG. For e.g. if groups of TDM circuits on the MG are bundled as a Trunk Group, then how does the MGC map termination ids on the MG into separate trunk groups? Thanks Parag From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 3 12:06:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07682 for ; Fri, 3 Nov 2000 12:06:09 -0500 (EST) Received: from standards (47.234.32.16:3710) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF309@standards.nortelnetworks.com>; Fri, 3 Nov 2000 11:48:25 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 72035 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 11:48:25 -0500 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF306@standards.nortelnetworks.com>; Fri, 3 Nov 2000 11:48:25 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA11017; Fri, 3 Nov 2000 12:04:14 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA06321; Fri, 3 Nov 2000 12:04:17 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Nov 2000 12:03: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: <4FBEA8857476D311A03300204840E1CF01A6E9A4@whq-msgusr-02.pit.comms.marconi.com> Date: Fri, 3 Nov 2000 12:04:14 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Bearer resource configuration X-To: Parag Sharma To: MEGACO@STANDARDS.NORTELNETWORKS.COM The basic answer is that there are no rules, but the protocol encourages the specification of terminationIds reflecting the configuration of the resources. So you might have a terminationId like TG3/2/1 which represented DS0 1 in DS1 2 in Trunk Group 3. Brian > -----Original Message----- > From: Parag Sharma [mailto:psharma@ORESIS.COM] > Sent: Friday, November 03, 2000 11:45 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Bearer resource configuration > > > Hi, > > I am new to Megaco and was wondering if there is any work in > progress or any > specification available on configuration of bearer resources > and how exactly > is this configuration information correlated between the MGC > & MG. For e.g. > if groups of TDM circuits on the MG are bundled as a Trunk > Group, then how > does the MGC map termination ids on the MG into separate trunk groups? > > Thanks > Parag > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 3 13:59:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11497 for ; Fri, 3 Nov 2000 13:59:52 -0500 (EST) Received: from standards (47.234.32.16:3355) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF35C@standards.nortelnetworks.com>; Fri, 3 Nov 2000 13:42:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 72138 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 13:42:21 -0500 Received: from standards (47.234.32.16:3355) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF35B@standards.nortelnetworks.com>; Fri, 3 Nov 2000 13:42:21 -0500 Message-ID: Date: Fri, 3 Nov 2000 13:42:21 -0500 Reply-To: Alan Whitton Sender: "Media Gateway Control (megaco)" From: Alan Whitton Subject: Multiple Adds In One Transaction and Errors To: MEGACO@STANDARDS.NORTELNETWORKS.COM Greetings, A simple question (I think). If I create a transaction which consists of two ADD commands, something like: MEGACO/1 [198.1.2.3]:55555 Transaction=1001 { Context = $ { ADD = TDM1/1 { blah... blah.. blah... } ADD = $ { yatta... yatta... yatta... } } } And the Gateway has issues with these ADDs, what happens if BOTH the adds fail? What would the reply look like, and how would the Controller figure out which error goes with which ADD? Sounds easy, don't it? Cheers, Alan Whitton From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 3 14:20:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17344 for ; Fri, 3 Nov 2000 14:20:31 -0500 (EST) Received: from standards (47.234.32.16:3355) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF416@standards.nortelnetworks.com>; Fri, 3 Nov 2000 14:02:11 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 72383 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 14:02:11 -0500 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF415@standards.nortelnetworks.com>; Fri, 3 Nov 2000 14:02:11 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA20535; Fri, 3 Nov 2000 14:18:06 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA06273; Fri, 3 Nov 2000 14:18:09 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Nov 2000 14:17:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E9A5@whq-msgusr-02.pit.comms.marconi.com> Date: Fri, 3 Nov 2000 14:18:03 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Multiple Adds In One Transaction and Errors X-To: Alan Whitton To: MEGACO@STANDARDS.NORTELNETWORKS.COM Commands are atomic, execute in order, and errors stop processing, therefore, your response will be Reply=1001 {Context=5599 {Add=TDM1/1 {Error{......}}}} The contextId was a bit worrisome. It could have been $, and the context won't exist, but I think you will in fact get the ContextId the MG would have used. Is the latter more grist for the Implementer's Guide? Brian > -----Original Message----- > From: Alan Whitton [mailto:awhitton@NORTELNETWORKS.COM] > Sent: Friday, November 03, 2000 1:42 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Multiple Adds In One Transaction and Errors > > > Greetings, > > A simple question (I think). If I create a transaction which > consists of > two ADD commands, something like: > > MEGACO/1 [198.1.2.3]:55555 > Transaction=1001 { > Context = $ { > ADD = TDM1/1 { > blah... blah.. blah... > } > ADD = $ { > yatta... yatta... yatta... > } > } > } > > And the Gateway has issues with these ADDs, what happens if > BOTH the adds > fail? What would the reply look like, and how would the > Controller figure > out which error goes with which ADD? > > Sounds easy, don't it? > > Cheers, > Alan Whitton > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 3 15:03:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00227 for ; Fri, 3 Nov 2000 15:03:46 -0500 (EST) Received: from standards (47.234.32.16:3355) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF49F@standards.nortelnetworks.com>; Fri, 3 Nov 2000 14:46:09 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 72528 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 14:46:09 -0500 Received: from mtmail.monaco377.com (195.78.6.211:50738) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF486@standards.nortelnetworks.com>; Fri, 3 Nov 2000 14:36:08 -0500 Received: from taffar ([195.78.6.37]) by mtmail.monaco377.com (8.8.8+Sun/8.8.8) with SMTP id UAA07375; Fri, 3 Nov 2000 20:34:31 +0100 (MET) X-Priority: 3 X-MSMail-Priority: Normal Errors-To: Uri78iujobeury36@concentric.net X-Mailer: Mozilla 4.72 [en] (Win98; U) Message-ID: <00001a350ebd$00002f02$0000456a@mindspring (user-3qt5hn.dialup.mindspring.com[99.174.150.55]) by smtp6.mindspring.com (8.9.3/8.8.5) with SMTP id OAA06398 from 110140321worldnet.att.net ([102.70.21.32]) by mtiwmhc98.worldnet.att.net (InterMail v03.02.07.07 118-134) with SMTP id<20090116195452.ZOMX28505@110940321worldnet.att.net> > Date: Fri, 3 Nov 2000 11:03:37 -0700 Reply-To: mgs12wereening@EXO.COM Sender: "Media Gateway Control (megaco)" From: mgs12wereening@EXO.COM Subject: Controversial Marketing Techniques That Work X-To: riverdancers@gate.net To: MEGACO@STANDARDS.NORTELNETWORKS.COM My name is Paul Willis and I am one of the few who have managed to make a very comfortable living marketing products on the Internet. My methods and techniques have been quoted in magazines and newspaper articles. I have marketed everything on the Internet from Personalized Baby Calendars to Information and have made money with everything. It's no secret that the Internet has very recently developed into the hottest marketing medium since television! Those with the skills to take advantage of this new medium are starting to make some very serious money. It's also true that for every small Internet Business success story there are hundreds failing at Web Marketing. I AM LIVING PROOF that with the proper techniques and information sources at hand anyone can turn the Internet into their own personal GOLD MINE. Internet Marketing when done successfully can make you more money than you dare to dream but it must be learned and applied professionally or it will produce nothing but headaches and the depletion of your hard earned cash. So my offer to you is this. You send me $39 bucks I will mail You my "Master Internet Marketing Kit Vol. 3". This amazing CD will supply you with the following information. ***THE MASTER INTERNET MARKETING KIT Vol. 3 CD**** *************WILL SUPPLY YOU WITH **************** 1) >>>> [ THE INTERNET MARKETING KIT E-BOOK ]. Containing the following information. CHAPTER 1...."The Bulk E-mail Handbook." This chapter of the book gives you an in-depth study on he following topics. A>> How to Make a Fortune With Bulk e-mail B>> Finding A Product. C>> How To Write Killer Sales Letters. D>> How To Collect Addresses From The Internet E>> The Fulfillment Of orders CHAPTER 2...How To Make Money With Junk E-mail A complete overview of techniques used by successful Bulk mailers that are making a fortune with Bulk e-mail CHAPTER 3...Cloaking..(The Truths and Myths About Cloaking Software) CHAPTER 4...$10,000 a week with classifieds This is For Real!! Pass it up lightly and you'll be making one of the biggest mistakes of your life! If it's big money your after take a seat and read this section very carefully. CHAPTER 5...How to Write Sales Letters that sell! CHAPTER 6...How to Write Profitable Classified Ads CHAPTER 7...Internet Sites This section will give you a unparalleled list of Internet Sites where you will find the following resources. A>> A list companies offering bulk mailing services. B>> FREE Internet E-mail accounts. C>> Bulk E-mail software sites. D>> A listing of over 200 sites where you can acquire FREE WEB SITES. CHAPTER 8..."250 Free for All Links Pages" A listing of 100 sites that allow you to link your site along with a description absolutely FREE. These 250 are from my own personal list that I have had the highest response rate. CHAPTER 9.."1500 PLACES TO ADVERTISE" 1500 of the best places on the Internet to advertise for FREE. here are many more than 1500 free classified ad boards on the net, but these are the ones you will get the best response from, I use them regularly. CHAPTER 10.."4000 PLACES TO PROMOTE YOUR WEB SITE". Need places to promote your site, these 4000 sites are the answer to your problem. (2) >>>> "THE TARGETED DIRECT E-MAIL HAND BOOK"...This E-Book is a STEP by STEP how to advertise your products and services with direct e-mail effectively. The nine chapters contained in this publication will give you a in depth understanding of the following topics. CHAPTER 1...The Basics CHAPTER 2...The proponents CHAPTER 3...The Opponents CHAPTER 4...The Dangers CHAPTER 5...Collecting Addresses CHAPTER 6...The Message CHAPTER 7...The Mailing CHAPTER 8...The Advertising Process (3)>>>> "THE GUERILLA WEB PROMOTION" And Marketing E-Book... This E-Book will teach you every trick known about How to Work The Web For Tons of Free Publicity and Promotion. As if this wasn't enough, hold on to your seat, I am even going to give you absolutely FREE the following must have software. 1.) A copy of CHECKER CHECKS BY FAX SOFTWARE... This is a fully functional program not a crippled demo. Now you can take payment from your customers by Fax, Phone or E-mail simply by taking their Checking account information. 2.) SMTP LOOKUP SOFTWARE ........this will find you foreign mail servers you can use to send your mail completely undetected. This Software will test mail through hundreds of servers an hour. I will even Supply you with a list of 16000 foreign domains to insert into your testing. IN ADDITION I am going to throw in 500,000 FRESH E-MAIL ADDRESSES. If you are selling a product or service these are the addresses you want. SPECIAL SOFTWARE BONUS!!! Now I defy anyone to find a better value than this on anybody's Marketing Package Program. But Wait! I'm not done yet! If you order by 12/31/00 I will give you the following 3 software programs worth over $800.00 if you had to purchase them separately. >>>> A COPY OF MASS E-MAIL SOFTWARE. That's right I am going to give you absolutely FREE a copy of E-mail software that is capable of speeds in excess of 100k E-mails per hour. >>>> A COPY OF E-MAIL EXTRACTING SOFTWARE. This program will allow you to extract e-mail addresses directly from the top search engines on the Internet. >>>> A COPY OF LIST MANAGEMENT SOFTWARE. A simple and easy software which will allow you to manage your e-mail lists effectively. It can remove non-domains, filter code words, split lists into smaller lists and many more features. All of the Software Programs that are included with this CD are fully functional copies not a bunch of crippled demos. Like I said in the beginning, I have made a very comfortable living marketing for myself and many others over the past five years and you can do the same. All you need are the proper tools, techniques, information and software. Well Now you have it for the pitiful price of $39.00. Everything is there for the taking in my Master Internet Marketing Kit Vol.3. P.S If you have any questions you can call me anytime and I will be glad to help you with any of your marketing efforts. I have sold over 7000 copies of my Marketing CD's over the last two years and have many references. So give me a call at (818)-885-1823 and I will be more than happy to answer any questions about my Marketing Kit or just Marketing in general. *******THE MASTER INTERNET MARKETING KIT CD******* *****************NOW ONLY $39.00 ******************* TO ORDER simply print out the EZ ORDER FORM Below and fax to 818-885-8014 WE ACCEPT....VISA, MC, AMEX, AND DISCOVER AND CHECKS BY FAX. ****************************EZ ORDER FORM********************** _____Yes! I would like to order The Master Internet Marketing Kit CD. *Please select one of the following for shipping..... _____I would like to receive my package by Certified Mail. Please ad $4.00 for shipping and handling. _____I would like to receive my package OVERNIGHT. I am including $15 for shipping. (Outside the U.S add an additional $25 for shipping) _____I would like to receive my package 2 DAY delivery. I'm including $10 for shipping. (Outside the US add an additional $25 for shipping) DATE_________________________________________________________ NAME_________________________________________________________ COMPANY NAME_______________________________________________ ADDRESS______________________________________________________ CITY, STATE, ZIP_______________________________________________ PHONE NUMBERS______________________________________________ FAX NUMBERS_________________________________________________ EMAIL ADDRESS_______________________________________________ TYPE OF CREDIT CARD: VISA_____MASTERCARD______AMEX______DISCOVER______ CREDIT CARD#_________________________________________________ EXPIRATION DATE______________________________________________ NAME ON CARD________________________________________________ AMOUNT_______________________________________________________ (Required) SIGNATURE:__________________________________________ I understand that I am purchasing the Master Internet Marketing Kit CD with Free marketing software, marketing information, and email addresses. It is the users responsibility to comply with any laws applicable to their local area. Once opened the CD may not be returned, however, if found defective it will be replaced with like product at no charge. DATE:__________________________________ CHECKS BY FAX SERVICES! If you would like to fax a check, paste your check below and Fax it to (818)-885-8014 *************************************************************************** ********************24 HOUR FAX SERVICES*********************************** PLEASE PASTE YOUR CHECK HERE AND FAX IT TO US AT 818-885-8014....MAKE ALL CHECKS PAYABLE TO M.F.E. ONLINE **************************************************************************** If you fax a check, there is no need for you to send the original check. We will draft up a new check, with the exact information from your original check. IF YOU PREFER YOU CAN ALSO MAIL YOUR ORDER TO.. M.F.E. ONLINE 18551 Chase Street Northridge, Ca. 91324 MAKE ALL CHECKS PAYABLE TO M.F.E. ONLINE. If you have any questions or would like to discuss how I can help you to effectively market your business via Direct E-mail advertising please call 818-885-1823. To be removed from our mailing list jjust click the link below. malto:paulwi654@quepasa.com?subject=Remove-Me From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 3 15:22:51 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08173 for ; Fri, 3 Nov 2000 15:22:50 -0500 (EST) Received: from standards (47.234.32.16:3355) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF4D0@standards.nortelnetworks.com>; Fri, 3 Nov 2000 15:05:15 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 72593 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 15:05:15 -0500 Received: from netlab.ohio-state.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF4B9@standards.nortelnetworks.com>; Fri, 3 Nov 2000 14:55:14 -0500 Received: from salu (dhcp31187207.columbus.rr.com [24.31.187.207]) by netlab.ohio-state.edu with SMTP (8.8.6 (PHNE_14041)/8.7.1) id PAA03433; Fri, 3 Nov 2000 15:56:42 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: Date: Fri, 3 Nov 2000 15:11:18 -0500 Reply-To: "Sohail Munir (Lucent)" Sender: "Media Gateway Control (megaco)" From: "Sohail Munir (Lucent)" Subject: Re: Controversial Marketing Techniques That Work X-To: mgs12wereening@EXO.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <00001a350ebd$00002f02$0000456a@mindspring (user-3qt5hn.dialup.mindspring.com[99.174.150.55]) by smtp6.mindspring.com (8.9.3/8.8.5) with SMTP id OAA06398 from 110140321worldnet.att.net ([102.70.21.32]) by mtiwmhc98.worldnet.att.net (InterMail v03.02.07.07 118-134) with SMTP id<20090116195452.ZOMX28505@110940321worldnet.att.net> > Content-Transfer-Encoding: 7bit Can we make MEGACO a moderated list where he moderators only screen for such stupid e-mail which waste my time and yours... Sohail Munir. -----Original Message----- From: Media Gateway Control (megaco) [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of mgs12wereening@EXO.COM Sent: Friday, November 03, 2000 1:04 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Controversial Marketing Techniques That Work My name is Paul Willis and I am one of the few who have managed to make a very comfortable living marketing products on the Internet. My methods and techniques have been quoted in magazines and newspaper articles. I have marketed everything on the Internet from Personalized Baby Calendars to Information and have made money with everything. It's no secret that the Internet has very recently developed into the hottest marketing medium since television! Those with the skills to take advantage of this new medium are starting to make some very serious money. It's also true that for every small Internet Business success story there are hundreds failing at Web Marketing. I AM LIVING PROOF that with the proper techniques and information sources at hand anyone can turn the Internet into their own personal GOLD MINE. Internet Marketing when done successfully can make you more money than you dare to dream but it must be learned and applied professionally or it will produce nothing but headaches and the depletion of your hard earned cash. So my offer to you is this. You send me $39 bucks I will mail You my "Master Internet Marketing Kit Vol. 3". This amazing CD will supply you with the following information. ***THE MASTER INTERNET MARKETING KIT Vol. 3 CD**** *************WILL SUPPLY YOU WITH **************** 1) >>>> [ THE INTERNET MARKETING KIT E-BOOK ]. Containing the following information. CHAPTER 1...."The Bulk E-mail Handbook." This chapter of the book gives you an in-depth study on he following topics. A>> How to Make a Fortune With Bulk e-mail B>> Finding A Product. C>> How To Write Killer Sales Letters. D>> How To Collect Addresses From The Internet E>> The Fulfillment Of orders CHAPTER 2...How To Make Money With Junk E-mail A complete overview of techniques used by successful Bulk mailers that are making a fortune with Bulk e-mail CHAPTER 3...Cloaking..(The Truths and Myths About Cloaking Software) CHAPTER 4...$10,000 a week with classifieds This is For Real!! Pass it up lightly and you'll be making one of the biggest mistakes of your life! If it's big money your after take a seat and read this section very carefully. CHAPTER 5...How to Write Sales Letters that sell! CHAPTER 6...How to Write Profitable Classified Ads CHAPTER 7...Internet Sites This section will give you a unparalleled list of Internet Sites where you will find the following resources. A>> A list companies offering bulk mailing services. B>> FREE Internet E-mail accounts. C>> Bulk E-mail software sites. D>> A listing of over 200 sites where you can acquire FREE WEB SITES. CHAPTER 8..."250 Free for All Links Pages" A listing of 100 sites that allow you to link your site along with a description absolutely FREE. These 250 are from my own personal list that I have had the highest response rate. CHAPTER 9.."1500 PLACES TO ADVERTISE" 1500 of the best places on the Internet to advertise for FREE. here are many more than 1500 free classified ad boards on the net, but these are the ones you will get the best response from, I use them regularly. CHAPTER 10.."4000 PLACES TO PROMOTE YOUR WEB SITE". Need places to promote your site, these 4000 sites are the answer to your problem. (2) >>>> "THE TARGETED DIRECT E-MAIL HAND BOOK"...This E-Book is a STEP by STEP how to advertise your products and services with direct e-mail effectively. The nine chapters contained in this publication will give you a in depth understanding of the following topics. CHAPTER 1...The Basics CHAPTER 2...The proponents CHAPTER 3...The Opponents CHAPTER 4...The Dangers CHAPTER 5...Collecting Addresses CHAPTER 6...The Message CHAPTER 7...The Mailing CHAPTER 8...The Advertising Process (3)>>>> "THE GUERILLA WEB PROMOTION" And Marketing E-Book... This E-Book will teach you every trick known about How to Work The Web For Tons of Free Publicity and Promotion. As if this wasn't enough, hold on to your seat, I am even going to give you absolutely FREE the following must have software. 1.) A copy of CHECKER CHECKS BY FAX SOFTWARE... This is a fully functional program not a crippled demo. Now you can take payment from your customers by Fax, Phone or E-mail simply by taking their Checking account information. 2.) SMTP LOOKUP SOFTWARE ........this will find you foreign mail servers you can use to send your mail completely undetected. This Software will test mail through hundreds of servers an hour. I will even Supply you with a list of 16000 foreign domains to insert into your testing. IN ADDITION I am going to throw in 500,000 FRESH E-MAIL ADDRESSES. If you are selling a product or service these are the addresses you want. SPECIAL SOFTWARE BONUS!!! Now I defy anyone to find a better value than this on anybody's Marketing Package Program. But Wait! I'm not done yet! If you order by 12/31/00 I will give you the following 3 software programs worth over $800.00 if you had to purchase them separately. >>>> A COPY OF MASS E-MAIL SOFTWARE. That's right I am going to give you absolutely FREE a copy of E-mail software that is capable of speeds in excess of 100k E-mails per hour. >>>> A COPY OF E-MAIL EXTRACTING SOFTWARE. This program will allow you to extract e-mail addresses directly from the top search engines on the Internet. >>>> A COPY OF LIST MANAGEMENT SOFTWARE. A simple and easy software which will allow you to manage your e-mail lists effectively. It can remove non-domains, filter code words, split lists into smaller lists and many more features. All of the Software Programs that are included with this CD are fully functional copies not a bunch of crippled demos. Like I said in the beginning, I have made a very comfortable living marketing for myself and many others over the past five years and you can do the same. All you need are the proper tools, techniques, information and software. Well Now you have it for the pitiful price of $39.00. Everything is there for the taking in my Master Internet Marketing Kit Vol.3. P.S If you have any questions you can call me anytime and I will be glad to help you with any of your marketing efforts. I have sold over 7000 copies of my Marketing CD's over the last two years and have many references. So give me a call at (818)-885-1823 and I will be more than happy to answer any questions about my Marketing Kit or just Marketing in general. *******THE MASTER INTERNET MARKETING KIT CD******* *****************NOW ONLY $39.00 ******************* TO ORDER simply print out the EZ ORDER FORM Below and fax to 818-885-8014 WE ACCEPT....VISA, MC, AMEX, AND DISCOVER AND CHECKS BY FAX. ****************************EZ ORDER FORM********************** _____Yes! I would like to order The Master Internet Marketing Kit CD. *Please select one of the following for shipping..... _____I would like to receive my package by Certified Mail. Please ad $4.00 for shipping and handling. _____I would like to receive my package OVERNIGHT. I am including $15 for shipping. (Outside the U.S add an additional $25 for shipping) _____I would like to receive my package 2 DAY delivery. I'm including $10 for shipping. (Outside the US add an additional $25 for shipping) DATE_________________________________________________________ NAME_________________________________________________________ COMPANY NAME_______________________________________________ ADDRESS______________________________________________________ CITY, STATE, ZIP_______________________________________________ PHONE NUMBERS______________________________________________ FAX NUMBERS_________________________________________________ EMAIL ADDRESS_______________________________________________ TYPE OF CREDIT CARD: VISA_____MASTERCARD______AMEX______DISCOVER______ CREDIT CARD#_________________________________________________ EXPIRATION DATE______________________________________________ NAME ON CARD________________________________________________ AMOUNT_______________________________________________________ (Required) SIGNATURE:__________________________________________ I understand that I am purchasing the Master Internet Marketing Kit CD with Free marketing software, marketing information, and email addresses. It is the users responsibility to comply with any laws applicable to their local area. Once opened the CD may not be returned, however, if found defective it will be replaced with like product at no charge. DATE:__________________________________ CHECKS BY FAX SERVICES! If you would like to fax a check, paste your check below and Fax it to (818)-885-8014 *************************************************************************** ********************24 HOUR FAX SERVICES*********************************** PLEASE PASTE YOUR CHECK HERE AND FAX IT TO US AT 818-885-8014....MAKE ALL CHECKS PAYABLE TO M.F.E. ONLINE **************************************************************************** If you fax a check, there is no need for you to send the original check. We will draft up a new check, with the exact information from your original check. IF YOU PREFER YOU CAN ALSO MAIL YOUR ORDER TO.. M.F.E. ONLINE 18551 Chase Street Northridge, Ca. 91324 MAKE ALL CHECKS PAYABLE TO M.F.E. ONLINE. If you have any questions or would like to discuss how I can help you to effectively market your business via Direct E-mail advertising please call 818-885-1823. To be removed from our mailing list jjust click the link below. malto:paulwi654@quepasa.com?subject=Remove-Me From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 3 17:47:52 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19540 for ; Fri, 3 Nov 2000 17:47:52 -0500 (EST) Received: from standards (47.234.32.16:1252) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF670@standards.nortelnetworks.com>; Fri, 3 Nov 2000 17:30:23 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 73153 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 17:30:23 -0500 Received: from mail15a.boca15-verio.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF66D@standards.nortelnetworks.com>; Fri, 3 Nov 2000 17:20:23 -0500 Received: from www.snowshore.com (128.241.144.247) by mail15a.boca15-verio.com (RS ver 1.0.57s) with SMTP id 02540311; Fri, 3 Nov 2000 17:36:19 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Loop-Detect: 1 Message-ID: Date: Fri, 3 Nov 2000 17:35:47 -0500 Reply-To: Eric Burger Sender: "Media Gateway Control (megaco)" From: Eric Burger Subject: Re: Controversial Marketing Techniques That Work X-To: "Sohail Munir (Lucent)" To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit I'd rather limit posting to people subscribed to the list. That makes it a bit harder for the "amature" spammer. -----Original Message----- From: Media Gateway Control (megaco) [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Sohail Munir (Lucent) Sent: Friday, November 03, 2000 3:11 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Controversial Marketing Techniques That Work Can we make MEGACO a moderated list where he moderators only screen for such stupid e-mail which waste my time and yours... From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 3 18:42:18 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01587 for ; Fri, 3 Nov 2000 18:42:17 -0500 (EST) Received: from standards (47.234.32.16:1252) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF6F7@standards.nortelnetworks.com>; Fri, 3 Nov 2000 18:24:51 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 73318 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Nov 2000 18:24:51 -0500 Received: from drawbridge.ascend.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF6EA@standards.nortelnetworks.com>; Fri, 3 Nov 2000 18:14:51 -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 PAA08788; Fri, 3 Nov 2000 15:17:36 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 3 Nov 2000 23:25:32 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id PAA04021; Fri, 3 Nov 2000 15:25:31 -0800 (PST) Received: from lucent.com (pitbull.eng.ascend.com [135.140.26.36]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id PAA16858; Fri, 3 Nov 2000 15:25:31 -0800 (PST) X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 i86pc) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A03496B.696381BC@lucent.com> Date: Fri, 3 Nov 2000 15:25:31 -0800 Reply-To: Ilya Akramovich Sender: "Media Gateway Control (megaco)" From: Ilya Akramovich Organization: Lucent Technologies, Inc. Subject: Re: Last Call On NAS Package (Revisited for November) X-To: Alan Whitton To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Alan, That is a nice list and I can come up with a dozen more reasons why a session-level authorization may fail. However, do we really want to dump all of this information to the MGC? Does the latter really need to know specifically what kind of authorization failed at the user level? I don't think so. Besides, information like this is already communicated in, for example, Radius accounting and/or other logging facilities. So I vote for keeping AUTHRES (or, better, AUTHEX) simple. -- Ilya Akramovich Tel: (510) 747-2926 Sr. Software Engineer mailto:iakramov@lucent.com Lucent InterNetworking Systems http://www.lucent.com/ins Alan Whitton wrote: > > Folks, > > OK, so after looking things over the AUTHRES (or AUTHEX) event looks like > it needs a little more information returned in it other than success or > failure. > > Once a "call" is UP, the Modems have trained and now the End User's PC is > connected to the ISP's Radius Server more than simply "authorization > failure" can occur. Port limiting can occur (not enough virtual modems > available to that customer's domain), or there can be a RADIUS server > failure (and thus the user cannot log in). > > What I'd like to propose is either adding a reason code for the AUTHRES (or > AUTHEX), or expand the reason codes for AUTHRES (or AUTHEX). The following > reasons, come to mind: > 1 other, unspecified > 2 CLID was unacceptable (rejected by CLID filter) > 3 CLID was blocked (rejected because blocked CLIDs not allowed) > 4 dialed number is not acceptable > 5 port limit or overflow port limit reached > 6 no IP address available > 7 all home gateways at capacity or admin state locked > 8 port guarantee prevented call from being taken proxied to > 9 RADIUS server rejected the request > > Cheers, > Alan Whitton > > Holistic Metaservices Architect > CVX SS7 Gateway > Nortel Networks, From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Nov 4 00:30:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02749 for ; Sat, 4 Nov 2000 00:30:41 -0500 (EST) Received: from standards (47.234.32.16:2808) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF9EE@standards.nortelnetworks.com>; Sat, 4 Nov 2000 0:13:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 74296 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 4 Nov 2000 00:13:06 -0500 Received: from alemail1.firewall.lucent.com (alemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAF9ED@standards.nortelnetworks.com>; Sat, 4 Nov 2000 0:13:06 -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 AAA02460 for ; Sat, 4 Nov 2000 00:29:07 -0500 (EST) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id AAA02448 for ; Sat, 4 Nov 2000 00:29:06 -0500 (EST) Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id AAA26557; Sat, 4 Nov 2000 00:29:04 -0500 Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id AAA26554; Sat, 4 Nov 2000 00:29:03 -0500 X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15-4mdksecure i686) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A039E7E.D1DCBA72@lucent.com> Date: Sat, 4 Nov 2000 00:28:30 -0500 Reply-To: Troy Cauble Sender: "Media Gateway Control (megaco)" From: Troy Cauble Subject: OCTET STRINGs in H.248 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi all, Maybe I've missed some subtle beauty in the OCTET STRING, but it seems like an OPAQUE structure that's overused in the ASN.1 H.248 encoding. For example, these seem to represent integers: SecurityParmIndex ::= OCTET STRING(SIZE(4)) SequenceNum ::= OCTET STRING(SIZE(4)) But how do I extract an integer value? ntohl()? Feed the octet string to an ASN.1 function for decoding integers? Why wasn't an ASN.1 Integer used? What can I conclude about the internal structure of the following? AuthData ::= OCTET STRING (SIZE (12..32)) The "quotedString" element in the ABNF isn't much better. The worst cases are In the ASN.1 Value ::= OCTET STRING In the ABNF VALUE = quotedString / 1*(SafeChar) Many protocol elements use the above definitions. The value component of a SigParameter (or EventParameter or StatisticsParameter, etc) is OCTET STRING. How do I decode this opaque data representation? From decoding the SignalName and the sigParameterName I'll know the implied type (if I support that package). Section 12.2 lists all the allowable types. But it doesn't specify the ASN.1 or text *encoding* of those types. What is the text representation for an "Integer"? sprintf("%d") ? %x ? 0x%x ? %o ? 0%o ? What about a "Double" ? How do I get the integer value of an OCTET STRING that's known to be "Integer: 4 octet signed integer"? An ASN.1 function for integers or ntohl()? "List" is specified in the ABNF, but they're lists of (OPAQUE) VALUEs. Lists are handled in the ASN.1 *PropertyParm* as "SEQUENCE OF OCTET STRING". But can't lists be used in the parameters to Events and Signals too? Those elements just have a "Value" "OCTET STRING". If I know the type is "String", how do I get from the ASN.1 "OCTET STRING" to a char*? Just cast it? Or call an ASN.1 decode routine specific to "UTF-8 octet strings"? -troy From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Nov 4 08:37:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18440 for ; Sat, 4 Nov 2000 08:37:15 -0500 (EST) Received: from standards (47.234.32.16:4968) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAFB49@standards.nortelnetworks.com>; Sat, 4 Nov 2000 8:19:45 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 74778 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 4 Nov 2000 08:19:45 -0500 Received: from zmers013 (47.124.1.40:62453) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAFB45@standards.nortelnetworks.com>; Sat, 4 Nov 2000 8:09:45 -0500 Received: from zrtps06s.us.nortel.com by zmers013; Sat, 4 Nov 2000 08:23:24 -0500 Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Sat, 4 Nov 2000 08:22:18 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Sat, 4 Nov 2000 08:22:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04662.3FC2E350" X-Orig: Message-ID: <75C9A75D295AD31184E70008C79189D2035A7752@zcard00b.ca.nortel.com> Date: Sat, 4 Nov 2000 08:22:15 -0500 Reply-To: "Whitton, Alan" Sender: "Media Gateway Control (megaco)" From: "Whitton, Alan" Subject: Re: Last Call On NAS Package (Revisited for November) X-To: Ilya Akramovich 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_01C04662.3FC2E350 Content-Type: text/plain; charset="iso-8859-1" Ilya, How does a Controller reflect a problem connecting to an ISP's Radius server, if that Controller chooses not to implement Radius (prefers keeping that functionality in the Gateway)? There a few different models possible in H.248, where the Controller could use this information (and reflect it in messages or tones to the End User). If the Controller is unable to (or chooses not to) use Radius for this information, how does it reflect this information back to the End User? Cheers, Alan -----Original Message----- From: Ilya Akramovich [mailto:iakramov@lucent.com] Sent: November 3, 2000 6:26 PM To: Whitton, Alan [CAR:5Z00:EXCH] Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Last Call On NAS Package (Revisited for November) Alan, That is a nice list and I can come up with a dozen more reasons why a session-level authorization may fail. However, do we really want to dump all of this information to the MGC? Does the latter really need to know specifically what kind of authorization failed at the user level? I don't think so. Besides, information like this is already communicated in, for example, Radius accounting and/or other logging facilities. So I vote for keeping AUTHRES (or, better, AUTHEX) simple. -- Ilya Akramovich Tel: (510) 747-2926 Sr. Software Engineer mailto:iakramov@lucent.com Lucent InterNetworking Systems http://www.lucent.com/ins Alan Whitton wrote: > > Folks, > > OK, so after looking things over the AUTHRES (or AUTHEX) event looks like > it needs a little more information returned in it other than success or > failure. > > Once a "call" is UP, the Modems have trained and now the End User's PC is > connected to the ISP's Radius Server more than simply "authorization > failure" can occur. Port limiting can occur (not enough virtual modems > available to that customer's domain), or there can be a RADIUS server > failure (and thus the user cannot log in). > > What I'd like to propose is either adding a reason code for the AUTHRES (or > AUTHEX), or expand the reason codes for AUTHRES (or AUTHEX). The following > reasons, come to mind: > 1 other, unspecified > 2 CLID was unacceptable (rejected by CLID filter) > 3 CLID was blocked (rejected because blocked CLIDs not allowed) > 4 dialed number is not acceptable > 5 port limit or overflow port limit reached > 6 no IP address available > 7 all home gateways at capacity or admin state locked > 8 port guarantee prevented call from being taken proxied to > 9 RADIUS server rejected the request > > Cheers, > Alan Whitton > > Holistic Metaservices Architect > CVX SS7 Gateway > Nortel Networks, ------_=_NextPart_001_01C04662.3FC2E350 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Last Call On NAS Package (Revisited for November)

Ilya,

How does a Controller reflect a problem connecting to = an ISP's Radius server, if that Controller chooses not to implement = Radius (prefers keeping that functionality in the Gateway)?

There a few different models possible in H.248, where = the Controller could use this information (and reflect it in messages = or tones to the End User). If the Controller is unable to (or chooses = not to) use Radius for this information, how does it reflect this = information back to the End User?

Cheers,
Alan

-----Original Message-----
From: Ilya Akramovich [mailto:iakramov@lucent.com]
Sent: November 3, 2000 6:26 PM
To: Whitton, Alan [CAR:5Z00:EXCH]
Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Last Call On NAS Package (Revisited for = November)


Alan,

That is a nice list and I can come up with a dozen = more reasons why a
session-level authorization may fail.

However, do we really want to dump all of this = information to the MGC?
Does the latter really need to know specifically = what kind of
authorization failed at the user level?  I = don't think so. Besides,
information like this is already communicated in, = for example, Radius
accounting and/or other logging facilities.

So I vote for keeping AUTHRES (or, better, AUTHEX) = simple.

--
Ilya = Akramovich          &n= bsp;         Tel: (510) = 747-2926          &nbs= p; 
Sr. Software = Engineer          &nbs= p;   mailto:iakramov@lucent.com
Lucent InterNetworking = Systems     http://www.lucent.com/ins


Alan Whitton wrote:
>
> Folks,
>
> OK, so after looking things over the AUTHRES = (or AUTHEX) event looks like
> it needs a little more information returned in = it other than success or
> failure.
>
> Once a  "call" is UP, the Modems = have trained and now the End User's PC is
> connected to the ISP's Radius Server more than = simply "authorization
> failure" can occur. Port limiting can = occur (not enough virtual modems
> available to that customer's domain), or there = can be a RADIUS server
> failure (and thus the user cannot log = in).
>
> What I'd like to propose is either adding a = reason code for the AUTHRES (or
> AUTHEX), or expand the reason codes for AUTHRES = (or AUTHEX). The following
> reasons, come to mind:
>   1 other, unspecified
>   2 CLID was unacceptable (rejected = by CLID filter)
>   3 CLID was blocked (rejected = because blocked CLIDs not allowed)
>   4 dialed number is not = acceptable
>   5 port limit or overflow port limit = reached
>   6  no IP address = available
>   7 all home gateways at capacity or = admin state locked
>   8 port guarantee prevented call = from being taken proxied to
>   9     RADIUS = server rejected the request
>
> Cheers,
> Alan Whitton
>
> Holistic Metaservices Architect
> CVX SS7 Gateway
> Nortel Networks,

------_=_NextPart_001_01C04662.3FC2E350-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Nov 4 08:44:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21583 for ; Sat, 4 Nov 2000 08:43:59 -0500 (EST) Received: from standards (47.234.32.16:4968) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAFB5D@standards.nortelnetworks.com>; Sat, 4 Nov 2000 8:26:33 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 74782 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 4 Nov 2000 08:26:33 -0500 Received: from zrchh190 (47.158.65.22:32970) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAFB48@standards.nortelnetworks.com>; Sat, 4 Nov 2000 8:16:31 -0500 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by zrchh190; Sat, 4 Nov 2000 07:32:43 -0600 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Sat, 4 Nov 2000 08:28:27 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Sat, 4 Nov 2000 08:28:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04663.16351CA0" X-Orig: Message-ID: <75C9A75D295AD31184E70008C79189D2035A7754@zcard00b.ca.nortel.com> Date: Sat, 4 Nov 2000 08:28:15 -0500 Reply-To: "Whitton, Alan" Sender: "Media Gateway Control (megaco)" From: "Whitton, Alan" Subject: Re: Last Call On NAS Package (Revisited for November) 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_01C04663.16351CA0 Content-Type: text/plain; charset="iso-8859-1" List, Apologies, I also forgot that Julian and I had agreed that AUTHRES (or AUTHEX) would stay "as is" (i.e. only reflecting whether the call failed or not, etc.,) and that the failure conditions I look for will be reflected in the following NASREL event that is sent as part of the authorization failure. Apologies, I should remember not to answer things on Saturday mornings. Cheers, Alan -----Original Message----- From: Ilya Akramovich [mailto:iakramov@LUCENT.COM] Sent: November 3, 2000 6:26 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Last Call On NAS Package (Revisited for November) Alan, That is a nice list and I can come up with a dozen more reasons why a session-level authorization may fail. However, do we really want to dump all of this information to the MGC? Does the latter really need to know specifically what kind of authorization failed at the user level? I don't think so. Besides, information like this is already communicated in, for example, Radius accounting and/or other logging facilities. So I vote for keeping AUTHRES (or, better, AUTHEX) simple. -- Ilya Akramovich Tel: (510) 747-2926 Sr. Software Engineer mailto:iakramov@lucent.com Lucent InterNetworking Systems http://www.lucent.com/ins Alan Whitton wrote: > > Folks, > > OK, so after looking things over the AUTHRES (or AUTHEX) event looks like > it needs a little more information returned in it other than success or > failure. > > Once a "call" is UP, the Modems have trained and now the End User's PC is > connected to the ISP's Radius Server more than simply "authorization > failure" can occur. Port limiting can occur (not enough virtual modems > available to that customer's domain), or there can be a RADIUS server > failure (and thus the user cannot log in). > > What I'd like to propose is either adding a reason code for the AUTHRES (or > AUTHEX), or expand the reason codes for AUTHRES (or AUTHEX). The following > reasons, come to mind: > 1 other, unspecified > 2 CLID was unacceptable (rejected by CLID filter) > 3 CLID was blocked (rejected because blocked CLIDs not allowed) > 4 dialed number is not acceptable > 5 port limit or overflow port limit reached > 6 no IP address available > 7 all home gateways at capacity or admin state locked > 8 port guarantee prevented call from being taken proxied to > 9 RADIUS server rejected the request > > Cheers, > Alan Whitton > > Holistic Metaservices Architect > CVX SS7 Gateway > Nortel Networks, ------_=_NextPart_001_01C04663.16351CA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Last Call On NAS Package (Revisited for November)

List,

Apologies, I also forgot that Julian and I had agreed = that AUTHRES (or AUTHEX) would stay "as is" (i.e. only = reflecting whether the call failed or not,  etc.,) and that the = failure conditions I look for will be reflected in the following NASREL = event that is sent as part of the authorization failure.

Apologies, I should remember not to answer things on = Saturday mornings.

Cheers,
Alan

-----Original Message-----
From: Ilya Akramovich [mailto:iakramov@LUCENT.COM]
Sent: November 3, 2000 6:26 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Last Call On NAS Package (Revisited for = November)


Alan,

That is a nice list and I can come up with a dozen = more reasons why a
session-level authorization may fail.

However, do we really want to dump all of this = information to the MGC?
Does the latter really need to know specifically = what kind of
authorization failed at the user level?  I = don't think so. Besides,
information like this is already communicated in, = for example, Radius
accounting and/or other logging facilities.

So I vote for keeping AUTHRES (or, better, AUTHEX) = simple.

--
Ilya = Akramovich          &n= bsp;         Tel: (510) = 747-2926
Sr. Software = Engineer          &nbs= p;   mailto:iakramov@lucent.com
Lucent InterNetworking = Systems     http://www.lucent.com/ins


Alan Whitton wrote:
>
> Folks,
>
> OK, so after looking things over the AUTHRES = (or AUTHEX) event looks like
> it needs a little more information returned in = it other than success or
> failure.
>
> Once a  "call" is UP, the Modems = have trained and now the End User's PC is
> connected to the ISP's Radius Server more than = simply "authorization
> failure" can occur. Port limiting can = occur (not enough virtual modems
> available to that customer's domain), or there = can be a RADIUS server
> failure (and thus the user cannot log = in).
>
> What I'd like to propose is either adding a = reason code for the AUTHRES (or
> AUTHEX), or expand the reason codes for AUTHRES = (or AUTHEX). The following
> reasons, come to mind:
>   1 other, unspecified
>   2 CLID was unacceptable (rejected = by CLID filter)
>   3 CLID was blocked (rejected = because blocked CLIDs not allowed)
>   4 dialed number is not = acceptable
>   5 port limit or overflow port limit = reached
>   6  no IP address = available
>   7 all home gateways at capacity or = admin state locked
>   8 port guarantee prevented call = from being taken proxied to
>   9     RADIUS = server rejected the request
>
> Cheers,
> Alan Whitton
>
> Holistic Metaservices Architect
> CVX SS7 Gateway
> Nortel Networks,

------_=_NextPart_001_01C04663.16351CA0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Nov 4 14:13:34 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08343 for ; Sat, 4 Nov 2000 14:13:33 -0500 (EST) Received: from standards (47.234.32.16:2271) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAFD6F@standards.nortelnetworks.com>; Sat, 4 Nov 2000 13:55:57 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 75518 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 4 Nov 2000 13:55:57 -0500 Received: from sapphire.int.ipverse.com (w067.z208037018.sjc-ca.dsl.cnc.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAFD6E@standards.nortelnetworks.com>; Sat, 4 Nov 2000 13:55:56 -0500 Received: from vaio.ipverse.com (lsanca1-ar5-208-149.dsl.gtei.net [4.33.208.149]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id V9K9MA0F; Sat, 4 Nov 2000 11:11:58 -0800 X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.1.2.20001104110908.00cad960@pop3.ipverse.com> Date: Sat, 4 Nov 2000 11:11:46 -0800 Reply-To: Matt Holdrege Sender: "Media Gateway Control (megaco)" From: Matt Holdrege Subject: Re: Last Call On NAS Package (Revisited for November) X-To: "Whitton, Alan" To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <75C9A75D295AD31184E70008C79189D2035A7752@zcard00b.ca.norte l.com> RADIUS is the IETF Draft Standard for communicating that information. Furthermore the AAA WG is working on a new standard for such info. So if a service provider or vendor chooses to not use the IETF standard they can always use a proprietary scheme. But we shouldn't create yet another standard for doing the same thing. It's too confusing and as Ilya mentioned you may end up missing out on the wealth of RADIUS experience already generated. At 08:22 AM 11/4/00 -0500, Whitton, Alan wrote: >Ilya, > >How does a Controller reflect a problem connecting to an ISP's Radius >server, if that Controller chooses not to implement Radius (prefers >keeping that functionality in the Gateway)? > >There a few different models possible in H.248, where the Controller could >use this information (and reflect it in messages or tones to the End >User). If the Controller is unable to (or chooses not to) use Radius for >this information, how does it reflect this information back to the End User? > >Cheers, >Alan > >-----Original Message----- >From: Ilya Akramovich >[mailto:iakramov@lucent.com] >Sent: November 3, 2000 6:26 PM >To: Whitton, Alan [CAR:5Z00:EXCH] >Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM >Subject: Re: Last Call On NAS Package (Revisited for November) > >Alan, > >That is a nice list and I can come up with a dozen more reasons why a >session-level authorization may fail. > >However, do we really want to dump all of this information to the MGC? >Does the latter really need to know specifically what kind of >authorization failed at the user level? I don't think so. Besides, >information like this is already communicated in, for example, Radius >accounting and/or other logging facilities. > >So I vote for keeping AUTHRES (or, better, AUTHEX) simple. > >-- >Ilya Akramovich Tel: (510) 747-2926 >Sr. Software >Engineer mailto:iakramov@lucent.com >Lucent InterNetworking >Systems http://www.lucent.com/ins > >Alan Whitton wrote: > > > > Folks, > > > > OK, so after looking things over the AUTHRES (or AUTHEX) event looks like > > it needs a little more information returned in it other than success or > > failure. > > > > Once a "call" is UP, the Modems have trained and now the End User's PC is > > connected to the ISP's Radius Server more than simply "authorization > > failure" can occur. Port limiting can occur (not enough virtual modems > > available to that customer's domain), or there can be a RADIUS server > > failure (and thus the user cannot log in). > > > > What I'd like to propose is either adding a reason code for the AUTHRES > (or > > AUTHEX), or expand the reason codes for AUTHRES (or AUTHEX). The following > > reasons, come to mind: > > 1 other, unspecified > > 2 CLID was unacceptable (rejected by CLID filter) > > 3 CLID was blocked (rejected because blocked CLIDs not allowed) > > 4 dialed number is not acceptable > > 5 port limit or overflow port limit reached > > 6 no IP address available > > 7 all home gateways at capacity or admin state locked > > 8 port guarantee prevented call from being taken proxied to > > 9 RADIUS server rejected the request > > > > Cheers, > > Alan Whitton > > > > Holistic Metaservices Architect > > CVX SS7 Gateway > > Nortel Networks, From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Nov 5 14:41:48 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14919 for ; Sun, 5 Nov 2000 14:41:47 -0500 (EST) Received: from standards (47.234.32.16:2637) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB00FF@standards.nortelnetworks.com>; 5 Nov 2000 14:24:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 76733 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 5 Nov 2000 14:24:03 -0500 Received: from zmers013 (47.124.1.40:42957) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB00FE@standards.nortelnetworks.com>; 5 Nov 2000 14:13:58 -0500 Received: from smtprch2.nortel.com (actually erchg0k) by zmers013; Sun, 5 Nov 2000 14:28:42 -0500 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Sun, 5 Nov 2000 13:24:31 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Sun, 5 Nov 2000 13:28:40 -0600 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD1102A698A9@zcard00g.ca.nortel.com> Date: Sun, 5 Nov 2000 13:28:39 -0600 Reply-To: "Taylor, Tom-PT" Sender: "Media Gateway Control (megaco)" From: "Taylor, Tom-PT" Subject: Re: Controversial Marketing Techniques That Work X-To: "Sohail Munir (Lucent)" To: MEGACO@STANDARDS.NORTELNETWORKS.COM I can set up the list so I have to approve any message from a non-member. This implies some potential delay for non-list-member postings. > -----Original Message----- > From: Sohail Munir (Lucent) [mailto:smunir@LUCENT.COM] > Sent: Friday, November 03, 2000 3:11 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Controversial Marketing Techniques That Work > > > Can we make MEGACO a moderated list where he moderators only > screen for such stupid e-mail which waste my time and yours... > > Sohail Munir. > -----Original Message----- > From: Media Gateway Control (megaco) > [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of > mgs12wereening@EXO.COM > Sent: Friday, November 03, 2000 1:04 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Controversial Marketing Techniques That Work > > > My name is Paul Willis and I am one of the few who have > managed to make a very comfortable living marketing products > on the Internet. My methods and techniques have been quoted > in magazines and newspaper articles. > > I have marketed everything on the Internet from Personalized > Baby Calendars to Information and have made money with > everything. > > It's no secret that the Internet has very recently developed > into the hottest marketing medium since television! Those > with the skills to take advantage of this new medium are > starting to make some very serious money. > > It's also true that for every small Internet Business success > story there are hundreds failing at Web Marketing. > > I AM LIVING PROOF that with the proper techniques and > information sources at hand anyone can turn the Internet > into their own personal GOLD MINE. > > Internet Marketing when done successfully can make you > more money than you dare to dream but it must be learned > and applied professionally or it will produce nothing but > headaches and the depletion of your hard earned cash. > > So my offer to you is this. You send me $39 bucks I will mail > You my "Master Internet Marketing Kit Vol. 3". This amazing > CD will supply you with the following information. > > > ***THE MASTER INTERNET MARKETING KIT Vol. 3 CD**** > *************WILL SUPPLY YOU WITH **************** > > 1) >>>> [ THE INTERNET MARKETING KIT E-BOOK ]. > Containing the following information. > > CHAPTER 1...."The Bulk E-mail Handbook." This chapter of > the book gives you an in-depth study on he following topics. > > A>> How to Make a Fortune With Bulk e-mail > B>> Finding A Product. > C>> How To Write Killer Sales Letters. > D>> How To Collect Addresses From The Internet > E>> The Fulfillment Of orders > > CHAPTER 2...How To Make Money With Junk E-mail > A complete overview of techniques used by successful > Bulk mailers that are making a fortune with Bulk e-mail > > CHAPTER 3...Cloaking..(The Truths and Myths About Cloaking Software) > > CHAPTER 4...$10,000 a week with classifieds > This is For Real!! Pass it up lightly and you'll be making > one of the biggest mistakes of your life! If it's big money > your after take a seat and read this section very carefully. > > CHAPTER 5...How to Write Sales Letters that sell! > > CHAPTER 6...How to Write Profitable Classified Ads > > CHAPTER 7...Internet Sites > This section will give you a unparalleled list of Internet > Sites where you will find the following resources. > > A>> A list companies offering bulk mailing services. > B>> FREE Internet E-mail accounts. > C>> Bulk E-mail software sites. > D>> A listing of over 200 sites where you can acquire FREE WEB SITES. > > CHAPTER 8..."250 Free for All Links Pages" > A listing of 100 sites that allow you to link your site along > with a description absolutely FREE. These 250 are from my own > personal list that I have had the highest response rate. > > CHAPTER 9.."1500 PLACES TO ADVERTISE" > > 1500 of the best places on the Internet to advertise for FREE. > here are many more than 1500 free classified ad boards on the > net, but these are the ones you will get the best response from, > I use them regularly. > > CHAPTER 10.."4000 PLACES TO PROMOTE YOUR WEB SITE". > Need places to promote your site, these 4000 sites are the answer to > your problem. > > (2) >>>> "THE TARGETED DIRECT E-MAIL HAND BOOK"...This > E-Book is a STEP by STEP how to advertise your products and services > with direct e-mail effectively. The nine chapters contained in this > publication will give you a in depth understanding of the following > topics. > > CHAPTER 1...The Basics > CHAPTER 2...The proponents > CHAPTER 3...The Opponents > CHAPTER 4...The Dangers > CHAPTER 5...Collecting Addresses > CHAPTER 6...The Message > CHAPTER 7...The Mailing > CHAPTER 8...The Advertising Process > > (3)>>>> "THE GUERILLA WEB PROMOTION" And Marketing E-Book... > This E-Book will teach you every trick known about How to Work The > Web For Tons of Free Publicity and Promotion. > > As if this wasn't enough, hold on to your seat, I am even going > to give you absolutely FREE the following must have software. > > 1.) A copy of CHECKER CHECKS BY FAX SOFTWARE... > > This is a fully functional program not a crippled demo. Now you can > take payment from your customers by Fax, Phone or E-mail simply by > taking their Checking account information. > > 2.) SMTP LOOKUP SOFTWARE ........this will find you foreign mail > servers you can use to send your mail completely undetected. This > Software will test mail through hundreds of servers an hour. I will > even Supply you with a list of 16000 foreign domains to insert into > your testing. > > IN ADDITION I am going to throw in 500,000 FRESH E-MAIL ADDRESSES. > If you are selling a product or service these are the > addresses you want. > > SPECIAL SOFTWARE BONUS!!! > > Now I defy anyone to find a better value than this on > anybody's Marketing > Package Program. > > But Wait! I'm not done yet! > > If you order by 12/31/00 I will give you the following 3 > software programs > worth over $800.00 if you had to purchase them separately. > > >>>> A COPY OF MASS E-MAIL SOFTWARE. That's right I am going > to give you absolutely FREE a copy of E-mail software that is capable > of speeds in excess of 100k E-mails per hour. > > >>>> A COPY OF E-MAIL EXTRACTING SOFTWARE. This program will > allow you to extract e-mail addresses directly from the top > search engines > on the Internet. > > >>>> A COPY OF LIST MANAGEMENT SOFTWARE. A simple and easy > software which will allow you to manage your e-mail lists > effectively. It > can remove non-domains, filter code words, split lists into > smaller lists > and many more features. > > All of the Software Programs that are included with this CD are fully > functional > copies not a bunch of crippled demos. > > Like I said in the beginning, I have made a very comfortable living > marketing > for myself and many others over the past five years and you > can do the same. > All > you need are the proper tools, techniques, information and > software. Well > Now > you have it for the pitiful price of $39.00. Everything is > there for the > taking in my > Master Internet Marketing Kit Vol.3. > > P.S > > If you have any questions you can call me anytime and I will > be glad to help > you > with any of your marketing efforts. I have sold over 7000 > copies of my > Marketing > CD's over the last two years and have many references. So > give me a call at > (818)-885-1823 and I will be more than happy to answer any > questions about > my > Marketing Kit or just Marketing in general. > > > *******THE MASTER INTERNET MARKETING KIT CD******* > > *****************NOW ONLY $39.00 ******************* > > > TO ORDER simply print out the EZ ORDER FORM Below and fax to > 818-885-8014 > > WE ACCEPT....VISA, MC, AMEX, AND DISCOVER AND CHECKS BY FAX. > > > ****************************EZ ORDER FORM********************** > > _____Yes! I would like to order The Master Internet Marketing Kit CD. > > *Please select one of the following for shipping..... > > _____I would like to receive my package by Certified Mail. Please ad > $4.00 for shipping and handling. > > _____I would like to receive my package OVERNIGHT. I am including $15 > for shipping. (Outside the U.S add an additional $25 for shipping) > > _____I would like to receive my package 2 DAY delivery. I'm > including $10 > for shipping. (Outside the US add an additional $25 for shipping) > > DATE_________________________________________________________ > > NAME_________________________________________________________ > > COMPANY NAME_______________________________________________ > > ADDRESS______________________________________________________ > > CITY, STATE, ZIP_______________________________________________ > > PHONE NUMBERS______________________________________________ > > FAX NUMBERS_________________________________________________ > > EMAIL ADDRESS_______________________________________________ > > TYPE OF CREDIT CARD: > > VISA_____MASTERCARD______AMEX______DISCOVER______ > > CREDIT CARD#_________________________________________________ > > EXPIRATION DATE______________________________________________ > > NAME ON CARD________________________________________________ > > AMOUNT_______________________________________________________ > > (Required) SIGNATURE:__________________________________________ > I understand that I am purchasing the Master Internet > Marketing Kit CD with > Free marketing software, marketing information, and email > addresses. It is > the > users responsibility to comply with any laws applicable to > their local area. > Once opened the CD may not be returned, however, if found > defective it will > be > replaced with like product at no charge. > > DATE:__________________________________ > > CHECKS BY FAX SERVICES! > > If you would like to fax a check, paste your check below and > Fax it to (818)-885-8014 > ************************************************************** > ************* > > ********************24 HOUR FAX > SERVICES*********************************** > > PLEASE PASTE YOUR CHECK HERE AND FAX IT TO US AT > 818-885-8014....MAKE ALL CHECKS PAYABLE TO M.F.E. ONLINE > > ************************************************************** > ************** > > If you fax a check, there is no need for you to send the original > check. > > We will draft up a new check, with the exact information from your > original check. > > IF YOU PREFER YOU CAN ALSO MAIL YOUR ORDER TO.. > > M.F.E. ONLINE > 18551 Chase Street > Northridge, Ca. 91324 > > MAKE ALL CHECKS PAYABLE TO M.F.E. ONLINE. > > If you have any questions or would like to discuss how I can help you > to effectively market your business via Direct E-mail > advertising please > call 818-885-1823. > > To be removed from our mailing list jjust click the link below. > > malto:paulwi654@quepasa.com?subject=Remove-Me > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Nov 5 15:55:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15871 for ; Sun, 5 Nov 2000 15:55:54 -0500 (EST) Received: from standards (47.234.32.16:4185) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB013A@standards.nortelnetworks.com>; 5 Nov 2000 15:38:16 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 76809 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 5 Nov 2000 15:38:16 -0500 Received: from netlab.ohio-state.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0137@standards.nortelnetworks.com>; 5 Nov 2000 15:28:16 -0500 Received: from salu (dhcp31187207.columbus.rr.com [24.31.187.207]) by netlab.ohio-state.edu with SMTP (8.8.6 (PHNE_14041)/8.7.1) id QAA04316; Sun, 5 Nov 2000 16:30:08 -0500 (EST) MIME-Version: 1.0 X-Priority: 3 (Normal) Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0022_01C0473F.53447140" 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.50.4133.2400 Message-ID: Date: Sun, 5 Nov 2000 15:44:50 -0500 Reply-To: "Sohail Munir (Lucent)" Sender: "Media Gateway Control (megaco)" From: "Sohail Munir (Lucent)" Subject: Re: Controversial Marketing Techniques That Work X-To: "Taylor, Tom-PT" To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <28560036253BD41191A10000F8BCBD1102A698A9@zcard00g.ca.nortel.com> This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C0473F.53447140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit That should do the job Thanks Sohail Munir. -----Original Message----- From: Media Gateway Control (megaco) [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Taylor, Tom-PT Sent: Sunday, November 05, 2000 2:29 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Controversial Marketing Techniques That Work I can set up the list so I have to approve any message from a non-member. This implies some potential delay for non-list-member postings. > -----Original Message----- > From: Sohail Munir (Lucent) [mailto:smunir@LUCENT.COM] > Sent: Friday, November 03, 2000 3:11 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Controversial Marketing Techniques That Work > > > Can we make MEGACO a moderated list where he moderators only > screen for such stupid e-mail which waste my time and yours... > > Sohail Munir. > -----Original Message----- > From: Media Gateway Control (megaco) > [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of > mgs12wereening@EXO.COM > Sent: Friday, November 03, 2000 1:04 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Controversial Marketing Techniques That Work > > > My name is Paul Willis and I am one of the few who have > managed to make a very comfortable living marketing products > on the Internet. My methods and techniques have been quoted > in magazines and newspaper articles. > > I have marketed everything on the Internet from Personalized > Baby Calendars to Information and have made money with > everything. > > It's no secret that the Internet has very recently developed > into the hottest marketing medium since television! Those > with the skills to take advantage of this new medium are > starting to make some very serious money. > > It's also true that for every small Internet Business success > story there are hundreds failing at Web Marketing. > > I AM LIVING PROOF that with the proper techniques and > information sources at hand anyone can turn the Internet > into their own personal GOLD MINE. > > Internet Marketing when done successfully can make you > more money than you dare to dream but it must be learned > and applied professionally or it will produce nothing but > headaches and the depletion of your hard earned cash. > > So my offer to you is this. You send me $39 bucks I will mail > You my "Master Internet Marketing Kit Vol. 3". This amazing > CD will supply you with the following information. > > > ***THE MASTER INTERNET MARKETING KIT Vol. 3 CD**** > *************WILL SUPPLY YOU WITH **************** > > 1) >>>> [ THE INTERNET MARKETING KIT E-BOOK ]. > Containing the following information. > > CHAPTER 1...."The Bulk E-mail Handbook." This chapter of > the book gives you an in-depth study on he following topics. > > A>> How to Make a Fortune With Bulk e-mail > B>> Finding A Product. > C>> How To Write Killer Sales Letters. > D>> How To Collect Addresses From The Internet > E>> The Fulfillment Of orders > > CHAPTER 2...How To Make Money With Junk E-mail > A complete overview of techniques used by successful > Bulk mailers that are making a fortune with Bulk e-mail > > CHAPTER 3...Cloaking..(The Truths and Myths About Cloaking Software) > > CHAPTER 4...$10,000 a week with classifieds > This is For Real!! Pass it up lightly and you'll be making > one of the biggest mistakes of your life! If it's big money > your after take a seat and read this section very carefully. > > CHAPTER 5...How to Write Sales Letters that sell! > > CHAPTER 6...How to Write Profitable Classified Ads > > CHAPTER 7...Internet Sites > This section will give you a unparalleled list of Internet > Sites where you will find the following resources. > > A>> A list companies offering bulk mailing services. > B>> FREE Internet E-mail accounts. > C>> Bulk E-mail software sites. > D>> A listing of over 200 sites where you can acquire FREE WEB SITES. > > CHAPTER 8..."250 Free for All Links Pages" > A listing of 100 sites that allow you to link your site along > with a description absolutely FREE. These 250 are from my own > personal list that I have had the highest response rate. > > CHAPTER 9.."1500 PLACES TO ADVERTISE" > > 1500 of the best places on the Internet to advertise for FREE. > here are many more than 1500 free classified ad boards on the > net, but these are the ones you will get the best response from, > I use them regularly. > > CHAPTER 10.."4000 PLACES TO PROMOTE YOUR WEB SITE". > Need places to promote your site, these 4000 sites are the answer to > your problem. > > (2) >>>> "THE TARGETED DIRECT E-MAIL HAND BOOK"...This > E-Book is a STEP by STEP how to advertise your products and services > with direct e-mail effectively. The nine chapters contained in this > publication will give you a in depth understanding of the following > topics. > > CHAPTER 1...The Basics > CHAPTER 2...The proponents > CHAPTER 3...The Opponents > CHAPTER 4...The Dangers > CHAPTER 5...Collecting Addresses > CHAPTER 6...The Message > CHAPTER 7...The Mailing > CHAPTER 8...The Advertising Process > > (3)>>>> "THE GUERILLA WEB PROMOTION" And Marketing E-Book... > This E-Book will teach you every trick known about How to Work The > Web For Tons of Free Publicity and Promotion. > > As if this wasn't enough, hold on to your seat, I am even going > to give you absolutely FREE the following must have software. > > 1.) A copy of CHECKER CHECKS BY FAX SOFTWARE... > > This is a fully functional program not a crippled demo. Now you can > take payment from your customers by Fax, Phone or E-mail simply by > taking their Checking account information. > > 2.) SMTP LOOKUP SOFTWARE ........this will find you foreign mail > servers you can use to send your mail completely undetected. This > Software will test mail through hundreds of servers an hour. I will > even Supply you with a list of 16000 foreign domains to insert into > your testing. > > IN ADDITION I am going to throw in 500,000 FRESH E-MAIL ADDRESSES. > If you are selling a product or service these are the > addresses you want. > > SPECIAL SOFTWARE BONUS!!! > > Now I defy anyone to find a better value than this on > anybody's Marketing > Package Program. > > But Wait! I'm not done yet! > > If you order by 12/31/00 I will give you the following 3 > software programs > worth over $800.00 if you had to purchase them separately. > > >>>> A COPY OF MASS E-MAIL SOFTWARE. That's right I am going > to give you absolutely FREE a copy of E-mail software that is capable > of speeds in excess of 100k E-mails per hour. > > >>>> A COPY OF E-MAIL EXTRACTING SOFTWARE. This program will > allow you to extract e-mail addresses directly from the top > search engines > on the Internet. > > >>>> A COPY OF LIST MANAGEMENT SOFTWARE. A simple and easy > software which will allow you to manage your e-mail lists > effectively. It > can remove non-domains, filter code words, split lists into > smaller lists > and many more features. > > All of the Software Programs that are included with this CD are fully > functional > copies not a bunch of crippled demos. > > Like I said in the beginning, I have made a very comfortable living > marketing > for myself and many others over the past five years and you > can do the same. > All > you need are the proper tools, techniques, information and > software. Well > Now > you have it for the pitiful price of $39.00. Everything is > there for the > taking in my > Master Internet Marketing Kit Vol.3. > > P.S > > If you have any questions you can call me anytime and I will > be glad to help > you > with any of your marketing efforts. I have sold over 7000 > copies of my > Marketing > CD's over the last two years and have many references. So > give me a call at > (818)-885-1823 and I will be more than happy to answer any > questions about > my > Marketing Kit or just Marketing in general. > > > *******THE MASTER INTERNET MARKETING KIT CD******* > > *****************NOW ONLY $39.00 ******************* > > > TO ORDER simply print out the EZ ORDER FORM Below and fax to > 818-885-8014 > > WE ACCEPT....VISA, MC, AMEX, AND DISCOVER AND CHECKS BY FAX. > > > ****************************EZ ORDER FORM********************** > > _____Yes! I would like to order The Master Internet Marketing Kit CD. > > *Please select one of the following for shipping..... > > _____I would like to receive my package by Certified Mail. Please ad > $4.00 for shipping and handling. > > _____I would like to receive my package OVERNIGHT. I am including $15 > for shipping. (Outside the U.S add an additional $25 for shipping) > > _____I would like to receive my package 2 DAY delivery. I'm > including $10 > for shipping. (Outside the US add an additional $25 for shipping) > > DATE_________________________________________________________ > > NAME_________________________________________________________ > > COMPANY NAME_______________________________________________ > > ADDRESS______________________________________________________ > > CITY, STATE, ZIP_______________________________________________ > > PHONE NUMBERS______________________________________________ > > FAX NUMBERS_________________________________________________ > > EMAIL ADDRESS_______________________________________________ > > TYPE OF CREDIT CARD: > > VISA_____MASTERCARD______AMEX______DISCOVER______ > > CREDIT CARD#_________________________________________________ > > EXPIRATION DATE______________________________________________ > > NAME ON CARD________________________________________________ > > AMOUNT_______________________________________________________ > > (Required) SIGNATURE:__________________________________________ > I understand that I am purchasing the Master Internet > Marketing Kit CD with > Free marketing software, marketing information, and email > addresses. It is > the > users responsibility to comply with any laws applicable to > their local area. > Once opened the CD may not be returned, however, if found > defective it will > be > replaced with like product at no charge. > > DATE:__________________________________ > > CHECKS BY FAX SERVICES! > > If you would like to fax a check, paste your check below and > Fax it to (818)-885-8014 > ************************************************************** > ************* > > ********************24 HOUR FAX > SERVICES*********************************** > > PLEASE PASTE YOUR CHECK HERE AND FAX IT TO US AT > 818-885-8014....MAKE ALL CHECKS PAYABLE TO M.F.E. ONLINE > > ************************************************************** > ************** > > If you fax a check, there is no need for you to send the original > check. > > We will draft up a new check, with the exact information from your > original check. > > IF YOU PREFER YOU CAN ALSO MAIL YOUR ORDER TO.. > > M.F.E. ONLINE > 18551 Chase Street > Northridge, Ca. 91324 > > MAKE ALL CHECKS PAYABLE TO M.F.E. ONLINE. > > If you have any questions or would like to discuss how I can help you > to effectively market your business via Direct E-mail > advertising please > call 818-885-1823. > > To be removed from our mailing list jjust click the link below. > > malto:paulwi654@quepasa.com?subject=Remove-Me > ------=_NextPart_000_0022_01C0473F.53447140 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHwjCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFy eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTla MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3H COGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9q JJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0g BEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9z aXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GB AIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKe wz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiS xVhqwY0DPOvDzQWikK5uMIIEjDCCA/WgAwIBAgIQas05QEUAAJrTi52sB6/yWDANBgkqhkiG9w0B AQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5k aXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMDExMDUwMDAwMDBa Fw0wMTExMDUyMzU5NTlaMIIBEDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90 IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0IEZ1bGwg U2VydmljZTEVMBMGA1UEAxQMU29oYWlsIE11bmlyMR8wHQYJKoZIhvcNAQkBFhBzb2hhaWxAbXVu aXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8iUh9ApcUTV2poYGI1Cst6uWk/XWN SOcIHBI9NPwcSYSjUiZa3fEZ5QM5ljCnq5bhtaTolsLK48sorStn/nmb0qw1LK5cxU/Wwsu301Ez 8yiSKmQJdo5ssqmAHQ182TQkyKEkrBVSZUMQAheDwyD4o3CepXwbf/g2ka7Eg8iFAQIDAQABo4IB JjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBwEIMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwEQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgB hvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5 ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIxNDFiZWFjZjM4YzBmYTgyMGJhZjZkZjFkMzExNDk5Y2Ex YmM0NWZlZjNlYTQ1ZTAwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQB1N40I+HCt+8FSBZYOW+H6jPagUpakrrc4px0p inbXt7rUGm4ZHdBqTG5OW+xjmj9Sae4WNEwHhdRW+sWc+OSZSE6HdJL6hviUxdS7Z6fbm50WpRgd kQ3xVV0WRqDZP8TI2Dofa6tgD/xs3q/j8tluF4JI3M/kfKtK9GHiFmbxhTGCAzgwggM0AgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBqzTlARQAAmtOLnawHr/JYMAkG BSsOAwIaBQCgggGsMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAw MTEwNTIwNDQ0N1owIwYJKoZIhvcNAQkEMRYEFEn3t9/BaDZtCuDoUiCA0J7h2WDPMFgGCSqGSIb3 DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIHyBgkrBgEEAYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQL Ez13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxU RChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGrNOUBFAACa04udrAev8lgwDQYJKoZIhvcNAQEBBQAE gYCmjOJIs3xv7KE2uzA0iuxQG/dGEdW927c5/G42i165gXjNCxdfza6udEGe6HjJyJJu1/J7VA/5 hXkgoELTqPmjAVhFV5yww028OquJPyK/7lgXC5Tt5B5Tg1L0qKJNsUMinNGsDHEhGBc/iIlFEo65 QAs4HC4trf2O2ewS4VjRSAAAAAAAAA== ------=_NextPart_000_0022_01C0473F.53447140-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Nov 5 19:15:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19788 for ; Sun, 5 Nov 2000 19:15:01 -0500 (EST) Received: from standards (47.234.32.16:2431) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB026E@standards.nortelnetworks.com>; 5 Nov 2000 18:57:30 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 77236 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 5 Nov 2000 18:57:30 -0500 Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB026D@standards.nortelnetworks.com>; 5 Nov 2000 18:57:29 -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 TAA07160 for ; Sun, 5 Nov 2000 19:13:35 -0500 (EST) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id TAA07152 for ; Sun, 5 Nov 2000 19:13:34 -0500 (EST) Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id TAA13714; Sun, 5 Nov 2000 19:13:33 -0500 Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id TAA13707; Sun, 5 Nov 2000 19:13:30 -0500 X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15-4mdksecure i686) X-Accept-Language: en MIME-Version: 1.0 Original-CC: MEGACO@STANDARDS.NORTELNETWORKS.COM References: <28560036253BD41191A10000F8BCBD1102A698A9@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A05F798.18817CE3@lucent.com> Date: Sun, 5 Nov 2000 19:13:12 -0500 Reply-To: Troy Cauble Sender: "Media Gateway Control (megaco)" From: Troy Cauble Subject: Re: Controversial Marketing Techniques That Work X-To: "Taylor, Tom-PT" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit "Taylor, Tom-PT" wrote: > > I can set up the list so I have to approve any message from a non-member. > This implies some potential delay for non-list-member postings. > While you're making changes I'd like to propose another. Can you have the list software prepend all message subjects with [MEGACO] or something. If you get a lot of mail this can be a help. -troy From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 6 02:25:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA22986 for ; Mon, 6 Nov 2000 02:25:40 -0500 (EST) Received: from standards (47.234.32.16:2046) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0325@standards.nortelnetworks.com>; Mon, 6 Nov 2000 2:07:57 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 77474 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 02:07:57 -0500 Received: from sj-msg-core-crit.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0324@standards.nortelnetworks.com>; Mon, 6 Nov 2000 2:07:56 -0500 Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by sj-msg-core-crit.cisco.com (8.9.3/8.9.1) with ESMTP id XAA05062; Sun, 5 Nov 2000 23:24:01 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id XAA14691; Sun, 5 Nov 2000 23:24:02 -0800 (PST) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD1102A698A9@zcard00g.ca.nortel.com> <3A05F798.18817CE3@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A065D0E.62D82F5B@cisco.com> Date: Sun, 5 Nov 2000 23:26:06 -0800 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: Controversial Marketing Techniques That Work X-To: Troy Cauble To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit No thanks. I'd suggest people simply use filters instead. -- Flemming Troy Cauble wrote: > "Taylor, Tom-PT" wrote: > > > > I can set up the list so I have to approve any message from a non-member. > > This implies some potential delay for non-list-member postings. > > > > While you're making changes I'd like to propose another. > > Can you have the list software prepend all message subjects > with [MEGACO] or something. > > If you get a lot of mail this can be a help. > > -troy -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 6 09:04:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28510 for ; Mon, 6 Nov 2000 09:04:43 -0500 (EST) Received: from standards (47.234.32.16:4751) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0638@standards.nortelnetworks.com>; Mon, 6 Nov 2000 8:47:01 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 78466 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 08:47:01 -0500 Received: from auemail2.firewall.lucent.com (auemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0637@standards.nortelnetworks.com>; Mon, 6 Nov 2000 8:47:01 -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 JAA04714 for ; Mon, 6 Nov 2000 09:03:08 -0500 (EST) Received: from ihgp2.ih.lucent.com (h135-1-53-26.lucent.com [135.1.53.26]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA04710 for ; Mon, 6 Nov 2000 09:03:08 -0500 (EST) Received: by ihgp2.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA00195; Mon, 6 Nov 2000 08:03:07 -0600 (CST) Received: from il0015varney2.lucent.com by ihgp2.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA00116; Mon, 6 Nov 2000 08:03:01 -0600 (CST) X-Sender: varney@ihgp2.ih.lucent.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.2.7.2.20001106080005.00abd580@ihgp2.ih.lucent.com> Date: Mon, 6 Nov 2000 08:03:00 -0600 Reply-To: Al Varney Sender: "Media Gateway Control (megaco)" From: Al Varney Subject: Re: Controversial Marketing Techniques That Work To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <28560036253BD41191A10000F8BCBD1102A698A9@zcard00g.ca.norte l.com> At 13:28 11/05/2000 -0600, Taylor, Tom-PT wrote: >I can set up the list so I have to approve any message from a non-member. >This implies some potential delay for non-list-member postings. Tom -- does this imply no more "Subject: Subscribe, please" messages??? Wonderful!! By the way, nice article in IEEE Communications. Al Varney - Lucent Technologies +1 630 224-7493 varney@lucent.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 6 09:43:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12001 for ; Mon, 6 Nov 2000 09:43:48 -0500 (EST) Received: from standards (47.234.32.16:4751) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0705@standards.nortelnetworks.com>; Mon, 6 Nov 2000 9:21:16 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 78641 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 09:21:16 -0500 Received: from uwcunx.uwc.ac.za by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB06BB@standards.nortelnetworks.com>; Mon, 6 Nov 2000 9:11:07 -0500 Received: (qmail 13503 invoked from network); 6 Nov 2000 18:30:38 -0000 Received: (ofmipd 192.102.9.71); 6 Nov 2000 18:30:16 -0000 Received: from UWC-Message_Server by SERVICES-02.UWC.AC.ZA with Novell_GroupWise; Mon, 06 Nov 2000 16:23:51 +0200 X-Mailer: Novell GroupWise 5.5.4 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Message-ID: Date: Mon, 6 Nov 2000 16:23:23 +0200 Reply-To: Michael Jeffries Sender: "Media Gateway Control (megaco)" From: Michael Jeffries Subject: Re: Controversial Marketing Techniques That Work To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA12001 Hi I think we are spending to much time discussing this issue and more mail is going about this issue than people that sends spam. >>> "Al Varney" 11/06 4:03 PM >>> At 13:28 11/05/2000 -0600, Taylor, Tom-PT wrote: >I can set up the list so I have to approve any message from a non-member. >This implies some potential delay for non-list-member postings. Tom -- does this imply no more "Subject: Subscribe, please" messages??? Wonderful!! By the way, nice article in IEEE Communications. Al Varney - Lucent Technologies +1 630 224-7493 varney@lucent.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 6 10:19:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22759 for ; Mon, 6 Nov 2000 10:19:11 -0500 (EST) Received: from standards (47.234.32.16:4751) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0766@standards.nortelnetworks.com>; Mon, 6 Nov 2000 9:58:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 78856 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 09:58:05 -0500 Received: from smtp2.cluster.oleane.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0765@standards.nortelnetworks.com>; Mon, 6 Nov 2000 9:58:04 -0500 Received: from oleane (dyn-1-1-152.Vin.dialup.oleane.fr [195.25.4.152]) by smtp2.cluster.oleane.net with SMTP id QAA33770 for ; Mon, 6 Nov 2000 16:14:11 +0100 (CET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EA_01C0480D.0412F5A0" 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: <00ed01c04804$a2a27a00$8001a8c0@oleane.com> Date: Mon, 6 Nov 2000 16:17:10 +0100 Reply-To: Peter Lewis Sender: "Media Gateway Control (megaco)" From: Peter Lewis Subject: IP.Net To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_00EA_01C0480D.0412F5A0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable IP.Net=20 The IP private networks 2001 Event: VPNs, security, VoIP, broadband access, SLAs. A call for proposals is online at: http://www.upperside.fr/baipnet.htm ------=_NextPart_000_00EA_01C0480D.0412F5A0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
IP.Net =
The IP private networks 2001 Event:
VPNs, security, VoIP, broadband = access,=20 SLAs.
A call for proposals is online = at:
http://www.upperside.fr/baip= net.htm
------=_NextPart_000_00EA_01C0480D.0412F5A0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 6 11:10:48 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07497 for ; Mon, 6 Nov 2000 11:10:47 -0500 (EST) Received: from standards (47.234.32.16:4751) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0827@standards.nortelnetworks.com>; Mon, 6 Nov 2000 10:53:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 79108 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 10:53:10 -0500 Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0826@standards.nortelnetworks.com>; Mon, 6 Nov 2000 10:53:09 -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 LAA08317 for ; Mon, 6 Nov 2000 11:09:17 -0500 (EST) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA08289 for ; Mon, 6 Nov 2000 11:09:16 -0500 (EST) Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id LAA00090 for ; Mon, 6 Nov 2000 11:07:39 -0500 (EST) X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------6DF92DAF5D83391B21E51FB4" Message-ID: <3A06D760.6132AFA@lucent.com> Date: Mon, 6 Nov 2000 11:08:01 -0500 Reply-To: Terry L Anderson Sender: "Media Gateway Control (megaco)" From: Terry L Anderson Organization: Lucent Technologies Subject: ServiceChangeMethod Failover To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------6DF92DAF5D83391B21E51FB4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The use of ServiceChangeMethod = Failover and the procedures behind it are not totally clear in 7.2.8. The paragraph describing the use of ServiceChangeAddress indicate that new transaction requests go to the new address but replies and pending indications continue to go to the "address from which the corresponding request originated." The next paragraph discussing ServiceChangeMgcId (which I believe is used with Handoff) does NOT make clear whether a similar distinction is made between new transactions and replies and pending indictions or whether all messages go to the new MGC. The text merely says "the new MGC that will take over from the current MGC." It is not clear what "take over" means. The issue is the procedures behind a handoff: is it gradual (ServiceChange with Handoff is sent but the MGC must wait around for replies and pending indications before it can go out of service) or abrupt (ServiceChange can be sent and then immediately MGC can go out of service and the new MGC handle all subsequent activity). I think that text should be more specific about the procedures relating to Handoff. -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572@skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------6DF92DAF5D83391B21E51FB4 Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;pager:800.759.8352 pin 1704572 tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks / Applications Group version:2.1 email;internet:tla@lucent.com title:DMTS adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA note;quoted-printable:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal)=0D=0A18E343126 / 10034134 x-mozilla-cpt:;-23792 fn:Terry L Anderson end:vcard --------------6DF92DAF5D83391B21E51FB4-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 6 14:10:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28087 for ; Mon, 6 Nov 2000 14:10:48 -0500 (EST) Received: from standards (47.234.32.16:1176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0BC8@standards.nortelnetworks.com>; Mon, 6 Nov 2000 13:48:55 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 80318 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 13:48:55 -0500 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0BC7@standards.nortelnetworks.com>; Mon, 6 Nov 2000 13:48:54 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA14529; Mon, 6 Nov 2000 14:05:00 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA28803; Mon, 6 Nov 2000 14:05:01 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Nov 2000 14:04:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E9C4@whq-msgusr-02.pit.comms.marconi.com> Date: Mon, 6 Nov 2000 14:04:54 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: ServiceChangeMethod Failover X-To: Terry L Anderson To: MEGACO@STANDARDS.NORTELNETWORKS.COM Replies and Pendings ALWAYS go back from whence they came, no exceptions. We do need to make this clear in the text. Brian > -----Original Message----- > From: Terry L Anderson [mailto:tla@LUCENT.COM] > Sent: Monday, November 06, 2000 11:08 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: ServiceChangeMethod Failover > > > The use of ServiceChangeMethod = Failover and the procedures behind it > are not totally clear in 7.2.8. The paragraph describing the use of > ServiceChangeAddress indicate that new transaction requests go to the > new address but replies and pending indications continue to go to the > "address from which the corresponding request originated." > > The next paragraph discussing ServiceChangeMgcId (which I believe is > used with Handoff) does NOT make clear whether a similar > distinction is > made between new transactions and replies and pending indictions or > whether all messages go to the new MGC. The text merely says "the new > MGC that will take over from the current MGC." It is not clear what > "take over" means. The issue is the procedures behind a > handoff: is it > gradual (ServiceChange with Handoff is sent but the MGC must > wait around > for replies and pending indications before it can go out of > service) or > abrupt (ServiceChange can be sent and then immediately MGC > can go out of > service and the new MGC handle all subsequent activity). > > I think that text should be more specific about the > procedures relating > to Handoff. > > -- > ------------------------------------------------------------ > Terry L Anderson mailto:tla@lucent.com > Tel:908.582.7013 Fax:908.582.6729 > Pager:800.759.8352 pin 1704572 1704572@skytel.com > Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 6 14:25:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01525 for ; Mon, 6 Nov 2000 14:25:31 -0500 (EST) Received: from standards (47.234.32.16:1176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0C86@standards.nortelnetworks.com>; Mon, 6 Nov 2000 14:07:44 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 80578 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 14:07:44 -0500 Received: from thalia.fm.intel.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0C85@standards.nortelnetworks.com>; Mon, 6 Nov 2000 14:07:44 -0500 Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id TAA15554; Mon, 6 Nov 2000 19:25:05 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 06 Nov 2000 19:23:47 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Nov 2000 11:23:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Mon, 6 Nov 2000 11:23:17 -0800 Reply-To: "Tulpule, Naren" Sender: "Media Gateway Control (megaco)" From: "Tulpule, Naren" Subject: Re: ServiceChangeMethod Failover X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi Brian, that's what I thought, yet section 11.5 (Failure of an MGC) states: No recommendation is made on how the MGCs involved in the Handoff maintain state information; this is considered to be out of scope of this recommendation. The MGC and MG may take the following steps when Handoff occurs. When the MGC initiates a HandOff, the handover should be transparent to Operations on the Media Gateway. Transactions can be executed in any order, and could be in progress when the ServiceChange is executed. Accordingly, commands in progress continue, transaction replies are sent to the new MGC (after a new control association is established), and the MG should expect outstanding transaction replies from the new MGC. No new messages shall be sent to the new MGC until the control association is established. Repeated transaction requests shall be directed to the new MGC. The MG shall maintain state on all terminations and contexts. -- Naren. These views and opinions are mine alone, not those of Intel (yet ;-) Narendra C. Tulpule SMTS, Trillium (an Intel company) Ph: +1-310-442-9222 Fax: +1-310-442-1162 12100 Wilshire Bl #1800 Los Angeles, CA 90025 -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] Sent: Monday, November 06, 2000 11:05 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: ServiceChangeMethod Failover Replies and Pendings ALWAYS go back from whence they came, no exceptions. We do need to make this clear in the text. Brian > -----Original Message----- > From: Terry L Anderson [mailto:tla@LUCENT.COM] > Sent: Monday, November 06, 2000 11:08 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: ServiceChangeMethod Failover > > > The use of ServiceChangeMethod = Failover and the procedures behind it > are not totally clear in 7.2.8. The paragraph describing the use of > ServiceChangeAddress indicate that new transaction requests go to the > new address but replies and pending indications continue to go to the > "address from which the corresponding request originated." > > The next paragraph discussing ServiceChangeMgcId (which I believe is > used with Handoff) does NOT make clear whether a similar > distinction is > made between new transactions and replies and pending indictions or > whether all messages go to the new MGC. The text merely says "the new > MGC that will take over from the current MGC." It is not clear what > "take over" means. The issue is the procedures behind a > handoff: is it > gradual (ServiceChange with Handoff is sent but the MGC must > wait around > for replies and pending indications before it can go out of > service) or > abrupt (ServiceChange can be sent and then immediately MGC > can go out of > service and the new MGC handle all subsequent activity). > > I think that text should be more specific about the > procedures relating > to Handoff. > > -- > ------------------------------------------------------------ > Terry L Anderson mailto:tla@lucent.com > Tel:908.582.7013 Fax:908.582.6729 > Pager:800.759.8352 pin 1704572 1704572@skytel.com > Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 6 14:33:33 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03357 for ; Mon, 6 Nov 2000 14:33:32 -0500 (EST) Received: from standards (47.234.32.16:1176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0CAB@standards.nortelnetworks.com>; Mon, 6 Nov 2000 14:16:00 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 80630 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 14:16:00 -0500 Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0CAA@standards.nortelnetworks.com>; Mon, 6 Nov 2000 14:16:00 -0500 Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA00527 for ; Mon, 6 Nov 2000 14:32:08 -0500 (EST) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA00520; Mon, 6 Nov 2000 14:32:07 -0500 (EST) Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id OAA19025; Mon, 6 Nov 2000 14:30:30 -0500 (EST) X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01A6E9C4@whq-msgusr-02.pit.comms.marconi.com> Content-Type: multipart/mixed; boundary="------------FBEDA8264E66B551A3D06F77" Message-ID: <3A0706E9.39C398F3@lucent.com> Date: Mon, 6 Nov 2000 14:30:50 -0500 Reply-To: Terry L Anderson Sender: "Media Gateway Control (megaco)" From: Terry L Anderson Organization: Lucent Technologies Subject: Re: ServiceChangeMethod Failover X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------FBEDA8264E66B551A3D06F77 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks for the clarification. Just to be clear then, to take an MGC out of service using Handoff, one must send the ServiceChange with Handoff, then send modifies with EventsDescriptor to cancel any event lists and wait for all replies before shutting down. Then the new MGC must send modifies with EventsDescriptor to reinitiate any event lists still desired. Is this correct. "Rosen, Brian" wrote: > Replies and Pendings ALWAYS go back from whence they came, no exceptions. > > We do need to make this clear in the text. > > Brian > > > -----Original Message----- > > From: Terry L Anderson [mailto:tla@LUCENT.COM] > > Sent: Monday, November 06, 2000 11:08 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: ServiceChangeMethod Failover > > > > > > The use of ServiceChangeMethod = Failover and the procedures behind it > > are not totally clear in 7.2.8. The paragraph describing the use of > > ServiceChangeAddress indicate that new transaction requests go to the > > new address but replies and pending indications continue to go to the > > "address from which the corresponding request originated." > > > > The next paragraph discussing ServiceChangeMgcId (which I believe is > > used with Handoff) does NOT make clear whether a similar > > distinction is > > made between new transactions and replies and pending indictions or > > whether all messages go to the new MGC. The text merely says "the new > > MGC that will take over from the current MGC." It is not clear what > > "take over" means. The issue is the procedures behind a > > handoff: is it > > gradual (ServiceChange with Handoff is sent but the MGC must > > wait around > > for replies and pending indications before it can go out of > > service) or > > abrupt (ServiceChange can be sent and then immediately MGC > > can go out of > > service and the new MGC handle all subsequent activity). > > > > I think that text should be more specific about the > > procedures relating > > to Handoff. > > > > -- > > ------------------------------------------------------------ > > Terry L Anderson mailto:tla@lucent.com > > Tel:908.582.7013 Fax:908.582.6729 > > Pager:800.759.8352 pin 1704572 1704572@skytel.com > > Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > > > -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572@skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------FBEDA8264E66B551A3D06F77 Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;pager:800.759.8352 pin 1704572 tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks / Applications Group version:2.1 email;internet:tla@lucent.com title:DMTS adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA note;quoted-printable:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal)=0D=0A18E343126 / 10034134 x-mozilla-cpt:;-23792 fn:Terry L Anderson end:vcard --------------FBEDA8264E66B551A3D06F77-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 6 14:41:14 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05073 for ; Mon, 6 Nov 2000 14:41:14 -0500 (EST) Received: from standards (47.234.32.16:1176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0CCB@standards.nortelnetworks.com>; Mon, 6 Nov 2000 14:23:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 80674 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 14:23:39 -0500 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0CCA@standards.nortelnetworks.com>; Mon, 6 Nov 2000 14:23:38 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA17626; Mon, 6 Nov 2000 14:39:44 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA09143; Mon, 6 Nov 2000 14:39:44 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Nov 2000 14:39:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E9C9@whq-msgusr-02.pit.comms.marconi.com> Date: Mon, 6 Nov 2000 14:39:34 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: ServiceChangeMethod Failover X-To: Terry L Anderson To: MEGACO@STANDARDS.NORTELNETWORKS.COM I don't think so. I always considered a Notify to be a new command, which would go to the "current" control association. That would mean the "old" MGC would have to deal with currently outstanding transactions, but not outstanding EventsDescriptors. The "new" MGC would get Notifies for events occurring after the ServiceChange. Brian > -----Original Message----- > From: Terry L Anderson [mailto:tla@lucent.com] > Sent: Monday, November 06, 2000 2:31 PM > To: Rosen, Brian > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: ServiceChangeMethod Failover > > > Thanks for the clarification. Just to be clear then, to take > an MGC out of > service using Handoff, one must send the ServiceChange with > Handoff, then > send modifies with EventsDescriptor to cancel any event lists > and wait for > all replies before shutting down. Then the new MGC must > send modifies with > EventsDescriptor to reinitiate any event lists still desired. Is this > correct. > > "Rosen, Brian" wrote: > > > Replies and Pendings ALWAYS go back from whence they came, > no exceptions. > > > > We do need to make this clear in the text. > > > > Brian > > > > > -----Original Message----- > > > From: Terry L Anderson [mailto:tla@LUCENT.COM] > > > Sent: Monday, November 06, 2000 11:08 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: ServiceChangeMethod Failover > > > > > > > > > The use of ServiceChangeMethod = Failover and the > procedures behind it > > > are not totally clear in 7.2.8. The paragraph describing > the use of > > > ServiceChangeAddress indicate that new transaction > requests go to the > > > new address but replies and pending indications continue > to go to the > > > "address from which the corresponding request originated." > > > > > > The next paragraph discussing ServiceChangeMgcId (which I > believe is > > > used with Handoff) does NOT make clear whether a similar > > > distinction is > > > made between new transactions and replies and pending > indictions or > > > whether all messages go to the new MGC. The text merely > says "the new > > > MGC that will take over from the current MGC." It is not > clear what > > > "take over" means. The issue is the procedures behind a > > > handoff: is it > > > gradual (ServiceChange with Handoff is sent but the MGC must > > > wait around > > > for replies and pending indications before it can go out of > > > service) or > > > abrupt (ServiceChange can be sent and then immediately MGC > > > can go out of > > > service and the new MGC handle all subsequent activity). > > > > > > I think that text should be more specific about the > > > procedures relating > > > to Handoff. > > > > > > -- > > > ------------------------------------------------------------ > > > Terry L Anderson mailto:tla@lucent.com > > > Tel:908.582.7013 Fax:908.582.6729 > > > Pager:800.759.8352 pin 1704572 1704572@skytel.com > > > Lucent Technologies/ Voice Over IP Access Networks/ > Applications Grp > > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > > > -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572@skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 6 14:50:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07310 for ; Mon, 6 Nov 2000 14:50:55 -0500 (EST) Received: from standards (47.234.32.16:1176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0D07@standards.nortelnetworks.com>; Mon, 6 Nov 2000 14:33:15 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 80759 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 14:33:15 -0500 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0D06@standards.nortelnetworks.com>; Mon, 6 Nov 2000 14:33:15 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA18613; Mon, 6 Nov 2000 14:49:20 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA11940; Mon, 6 Nov 2000 14:49:21 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Nov 2000 14:48:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E9CA@whq-msgusr-02.pit.comms.marconi.com> Date: Mon, 6 Nov 2000 14:49:05 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: ServiceChangeMethod Failover X-To: "Tulpule, Naren" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Rats! I thought we had been through that text and decided to make it consistent with the "replies go back to the originator" rule. My recollection is that we decided that replies ALWAYS go back to who sent them, ALWAYS, no exceptions. The failure model that I know how to deal with is that transactions not started always work. Transactions completed stay good, but transactions "in the middle" may or may not be completed, and it's too hard to try to keep these in the middle things working across a handover. We often have the same kind of thing in the MGC - calls up stay up, calls started immediately after handover work, calls actually in process, but not established, are often dropped. Brian > -----Original Message----- > From: Tulpule, Naren [mailto:naren@trillium.com] > Sent: Monday, November 06, 2000 2:23 PM > To: Rosen, Brian; MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: RE: ServiceChangeMethod Failover > > > Hi Brian, > that's what I thought, yet section 11.5 (Failure of an MGC) states: > > No recommendation is made on how the MGCs involved in the Handoff > maintain state information; this is considered to be out > of scope of > this recommendation. The MGC and MG may take the following > steps when > Handoff occurs. When the MGC initiates a HandOff, the handover > should be transparent to Operations on the Media Gateway. > Transactions can be executed in any order, and could be in progress > when the ServiceChange is executed. Accordingly, commands in > progress continue, transaction replies are sent to the new > MGC (after > a new control association is established), and the MG should expect > outstanding transaction replies from the new MGC. No new messages > shall be sent to the new MGC until the control association is > established. Repeated transaction requests shall be > directed to the > new MGC. The MG shall maintain state on all terminations and > contexts. > > -- Naren. > These views and opinions are mine alone, not those of Intel > (yet ;-) > Narendra C. Tulpule SMTS, Trillium (an Intel company) > Ph: +1-310-442-9222 Fax: +1-310-442-1162 > 12100 Wilshire Bl #1800 Los Angeles, CA 90025 > > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > Sent: Monday, November 06, 2000 11:05 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: ServiceChangeMethod Failover > > > Replies and Pendings ALWAYS go back from whence they came, no > exceptions. > > We do need to make this clear in the text. > > Brian > > > -----Original Message----- > > From: Terry L Anderson [mailto:tla@LUCENT.COM] > > Sent: Monday, November 06, 2000 11:08 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: ServiceChangeMethod Failover > > > > > > The use of ServiceChangeMethod = Failover and the > procedures behind it > > are not totally clear in 7.2.8. The paragraph describing the use of > > ServiceChangeAddress indicate that new transaction requests > go to the > > new address but replies and pending indications continue to > go to the > > "address from which the corresponding request originated." > > > > The next paragraph discussing ServiceChangeMgcId (which I believe is > > used with Handoff) does NOT make clear whether a similar > > distinction is > > made between new transactions and replies and pending indictions or > > whether all messages go to the new MGC. The text merely > says "the new > > MGC that will take over from the current MGC." It is not clear what > > "take over" means. The issue is the procedures behind a > > handoff: is it > > gradual (ServiceChange with Handoff is sent but the MGC must > > wait around > > for replies and pending indications before it can go out of > > service) or > > abrupt (ServiceChange can be sent and then immediately MGC > > can go out of > > service and the new MGC handle all subsequent activity). > > > > I think that text should be more specific about the > > procedures relating > > to Handoff. > > > > -- > > ------------------------------------------------------------ > > Terry L Anderson mailto:tla@lucent.com > > Tel:908.582.7013 Fax:908.582.6729 > > Pager:800.759.8352 pin 1704572 1704572@skytel.com > > Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 6 16:29:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05229 for ; Mon, 6 Nov 2000 16:29:01 -0500 (EST) Received: from standards (47.234.32.16:1026) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0D9C@standards.nortelnetworks.com>; Mon, 6 Nov 2000 16:11:11 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 80925 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 16:11:11 -0500 Received: from zrchh190 (47.158.65.22:54712) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0D82@standards.nortelnetworks.com>; Mon, 6 Nov 2000 16:01:11 -0500 Received: from smtprch2.nortel.com (actually erchg0k) by zrchh190; Mon, 6 Nov 2000 15:18:07 -0600 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Mon, 6 Nov 2000 15:12:51 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 6 Nov 2000 15:16:59 -0600 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD1102AB7713@zcard00g.ca.nortel.com> Date: Mon, 6 Nov 2000 15:16:48 -0600 Reply-To: "Taylor, Tom-PT" Sender: "Media Gateway Control (megaco)" From: "Taylor, Tom-PT" Subject: Re: ServiceChangeMethod Failover X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM I agree with this view. > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > Sent: Monday, November 06, 2000 2:40 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: ServiceChangeMethod Failover > > > I don't think so. I always considered a Notify to be a new command, > which would go to the "current" control association. That would mean > the "old" MGC would have to deal with currently outstanding > transactions, > but not outstanding EventsDescriptors. The "new" MGC would get > Notifies for events occurring after the ServiceChange. > > Brian > > > -----Original Message----- > > From: Terry L Anderson [mailto:tla@lucent.com] > > Sent: Monday, November 06, 2000 2:31 PM > > To: Rosen, Brian > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: ServiceChangeMethod Failover > > > > > > Thanks for the clarification. Just to be clear then, to take > > an MGC out of > > service using Handoff, one must send the ServiceChange with > > Handoff, then > > send modifies with EventsDescriptor to cancel any event lists > > and wait for > > all replies before shutting down. Then the new MGC must > > send modifies with > > EventsDescriptor to reinitiate any event lists still > desired. Is this > > correct. > > > > "Rosen, Brian" wrote: > > > > > Replies and Pendings ALWAYS go back from whence they came, > > no exceptions. > > > > > > We do need to make this clear in the text. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Terry L Anderson [mailto:tla@LUCENT.COM] > > > > Sent: Monday, November 06, 2000 11:08 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: ServiceChangeMethod Failover > > > > > > > > > > > > The use of ServiceChangeMethod = Failover and the > > procedures behind it > > > > are not totally clear in 7.2.8. The paragraph describing > > the use of > > > > ServiceChangeAddress indicate that new transaction > > requests go to the > > > > new address but replies and pending indications continue > > to go to the > > > > "address from which the corresponding request originated." > > > > > > > > The next paragraph discussing ServiceChangeMgcId (which I > > believe is > > > > used with Handoff) does NOT make clear whether a similar > > > > distinction is > > > > made between new transactions and replies and pending > > indictions or > > > > whether all messages go to the new MGC. The text merely > > says "the new > > > > MGC that will take over from the current MGC." It is not > > clear what > > > > "take over" means. The issue is the procedures behind a > > > > handoff: is it > > > > gradual (ServiceChange with Handoff is sent but the MGC must > > > > wait around > > > > for replies and pending indications before it can go out of > > > > service) or > > > > abrupt (ServiceChange can be sent and then immediately MGC > > > > can go out of > > > > service and the new MGC handle all subsequent activity). > > > > > > > > I think that text should be more specific about the > > > > procedures relating > > > > to Handoff. > > > > > > > > -- > > > > ------------------------------------------------------------ > > > > Terry L Anderson mailto:tla@lucent.com > > > > Tel:908.582.7013 Fax:908.582.6729 > > > > Pager:800.759.8352 pin 1704572 1704572@skytel.com > > > > Lucent Technologies/ Voice Over IP Access Networks/ > > Applications Grp > > > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > > > http://its.lucent.com/~tla (Lucent internal) > http://www.gti.net/tla > > > > > > > > -- > ------------------------------------------------------------ > Terry L Anderson mailto:tla@lucent.com > Tel:908.582.7013 Fax:908.582.6729 > Pager:800.759.8352 pin 1704572 1704572@skytel.com > Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 6 16:29:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05232 for ; Mon, 6 Nov 2000 16:29:02 -0500 (EST) Received: from standards (47.234.32.16:1026) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0DA4@standards.nortelnetworks.com>; Mon, 6 Nov 2000 16:11:46 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 80926 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Nov 2000 16:11:46 -0500 Received: from zrchh190 (47.158.65.22:54773) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB0D83@standards.nortelnetworks.com>; Mon, 6 Nov 2000 16:01:45 -0500 Received: from smtprch1.nortel.com (actually erchg0j) by zrchh190; Mon, 6 Nov 2000 15:18:36 -0600 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Mon, 6 Nov 2000 15:13:26 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 6 Nov 2000 15:12:56 -0600 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD1102AB7703@zcard00g.ca.nortel.com> Date: Mon, 6 Nov 2000 15:12:52 -0600 Reply-To: "Taylor, Tom-PT" Sender: "Media Gateway Control (megaco)" From: "Taylor, Tom-PT" Subject: FW: Internet-Draft Cut-off Dates for San Diego IETF To: MEGACO@STANDARDS.NORTELNETWORKS.COM FYI. If there are pending new initial submissions dealing with outstanding work items please let me know ASAP -- I'm at SG 16 and MGC 2000 next week and E-mail access will be haphazard. Actually, I'm probably the only one affected since I owe the WG an I-D for a bearer capability package in connection with the NAS work. -----Original Message----- From: Internet-Drafts Administrator [mailto:internet-drafts@ietf.org] Sent: Sunday, November 05, 2000 11:23 AM To: IETF-Announce Subject: Internet-Draft Cut-off Dates for San Diego IETF NOTE: There are TWO (2) Internet-Draft Cut-off dates The IESG has authorized an experiment for the upcoming IETF meeting. There will be two Internet-Draft cut-off dates: November 17: Cut-off for Initial Submissions (new documents) All initial submissions (-00) must be submitted by Friday, November 17, 1730 US-EST. Initial submissions received after this time will not be announced nor made available in the internet-drafts directory, and will have to be resubmitted. As before, all initial submissions (-00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prior to processing and announcing. WG Chair approval must be received by Monday, November 20. Do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submissions received the week of November 17 will NOT be accepted. November 24: FINAL Internet-Draft Cut-off All revised Internet-Draft submissions must be submitted by Friday, November 24 2000 at 1700 US-EST. Internet-Drafts received after this time will NOT be announced nor made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concerns. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 7 04:17:27 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA19238 for ; Tue, 7 Nov 2000 04:17:26 -0500 (EST) Received: from standards (47.234.32.16:2098) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB1104@standards.nortelnetworks.com>; Tue, 7 Nov 2000 3:59:44 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 82088 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Nov 2000 03:59:44 -0500 Received: from web5101.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB10F9@standards.nortelnetworks.com>; Tue, 7 Nov 2000 3:49:43 -0500 Received: from [208.220.245.72] by web5101.mail.yahoo.com; Tue, 07 Nov 2000 01:05:53 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20001107090553.16978.qmail@web5101.mail.yahoo.com> Date: Tue, 7 Nov 2000 01:05:53 -0800 Reply-To: Richie Wu Sender: "Media Gateway Control (megaco)" From: Richie Wu Subject: Modem Descriptor Error in ABNF To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello everybody, I think there is a mistake in the Modem Descriptor represented by ABNF after reference ASN.1 Syntax of Modem Descritpor. In ABNF syntax, I think the NAME parmValue need to be replace with propertyParm, viz. change the following syntax modemDescriptor = ModemToken (( EQUAL modemType) / (LSBRKT modemType *(COMMA modemType) RSBRKT)) [ LBRKT NAME parmValue *(COMMA NAME parmValue) RBRKT ] into the following syntax modemDescriptor = ModemToken (( EQUAL modemType) / (LSBRK modemType *(COMMA modemType) RSBRKT)) [ LBRKT propertyParm *(COMMA propertyParm) RBRKT ] The following is ASN.1 and ABNF Modem Descriptor related for your information. The ASN.1 representation is: ModemDescriptor ::= SEQUENCE { mtl SEQUENCE OF ModemType, mpl SEQUENCE OF PropertyParm, nonStandardData NonStandardData OPTIONAL } PropertyParm ::= SEQUENCE { name PkgdName, value SEQUENCE OF OCTET STRING, extraInfo CHOICE { relation Relation, range BOOLEAN, sublist BOOLEAN } OPTIONAL, ... } PkgdName ::= OCTET STRING(SIZE(4)) -- represents Package Name (2 octets) plus Property Name (2 octets) -- To wildcard a package use 0xFFFF for first two octets, choose -- is not allowed. To reference native property tag specified in -- Annex C, use 0x0000 as first two octets. -- Wildcarding of Package Name is permitted only if Property Name is -- also wildcarded. The ABNF syntax is: modemDescriptor = ModemToken (( EQUAL modemType) / (LSBRKT modemType *(COMMA modemType) RSBRKT)) [ LBRKT NAME parmValue *(COMMA NAME parmValue) RBRKT ] parmValue = (EQUAL alternativeValue/ INEQUAL VALUE) alternativeValue = ( VALUE / LSBRKT VALUE *(COMMA VALUE) RSBRKT ; sublist (i.e. A AND B AND ...) / LBRKT VALUE *(COMMA VALUE) RBRKT ; alternatives (i.e. A OR B OR ...) / LSBRKT VALUE COLON VALUE RSBRKT ) ; range INEQUAL = LWSP (">" / "<" / "#" ) LWSP LSBRKT = LWSP "[" LWSP RSBRKT = LWSP "]" LWSP Regards, Richie Wu ===== Huawei Technologies India Private Limited Unit 10, 2nd Floor, Innovator Block International Tech Park, Whitefield Main Road Bangalore 560 066, India TEL: 0091-80-841 0061/0753/0755 FAX: 0091-80-841 0063 __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one Place. http://shopping.yahoo.com/ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 7 04:53:19 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04382 for ; Tue, 7 Nov 2000 04:53:19 -0500 (EST) Received: from standards (47.234.32.16:2098) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB1136@standards.nortelnetworks.com>; Tue, 7 Nov 2000 4:35:45 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 82161 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Nov 2000 04:35:45 -0500 Received: from web5105.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB1133@standards.nortelnetworks.com>; Tue, 7 Nov 2000 4:25:44 -0500 Received: from [208.220.245.72] by web5105.mail.yahoo.com; Tue, 07 Nov 2000 01:41:54 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20001107094154.3191.qmail@web5105.mail.yahoo.com> Date: Tue, 7 Nov 2000 01:41:54 -0800 Reply-To: Richie Wu Sender: "Media Gateway Control (megaco)" From: Richie Wu Subject: Modem Descriptor Error in ABNF To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello everybody, I think there is a mistake in the Modem Descriptor represented by ABNF after reference ASN.1 Syntax of Modem Descritpor. In ABNF syntax, I think the NAME parmValue need to be replace with propertyParm, viz. change the following syntax modemDescriptor = ModemToken (( EQUAL modemType) / (LSBRKT modemType *(COMMA modemType) RSBRKT)) [ LBRKT NAME parmValue *(COMMA NAME parmValue) RBRKT ] to either of the ABNF syntax (a) modemDescriptor = ModemToken (( EQUAL modemType) / (LSBRKT modemType *(COMMA modemType) RSBRKT)) [ LBRKT pkgdName parmValue *(COMMA pkgdName parmValue) RBRKT ] or into the following syntax (b) modemDescriptor = ModemToken (( EQUAL modemType) / (LSBRK modemType *(COMMA modemType) RSBRKT)) [ LBRKT propertyParm *(COMMA propertyParm) RBRKT ] As my understanding goes the parameter id alone is not enough while encoding the modem desc. A combination of package id and modem parameter id is required. The following is ASN.1 and ABNF Modem Descriptor as per the draft for your information. The ASN.1 representation is: ModemDescriptor ::= SEQUENCE { mtl SEQUENCE OF ModemType, mpl SEQUENCE OF PropertyParm, nonStandardData NonStandardData OPTIONAL } PropertyParm ::= SEQUENCE { name PkgdName, value SEQUENCE OF OCTET STRING, extraInfo CHOICE { relation Relation, range BOOLEAN, sublist BOOLEAN } OPTIONAL, ... } PkgdName ::= OCTET STRING(SIZE(4)) -- represents Package Name (2 octets) plus Property Name (2 octets) -- To wildcard a package use 0xFFFF for first two octets, choose -- is not allowed. To reference native property tag specified in -- Annex C, use 0x0000 as first two octets. -- Wildcarding of Package Name is permitted only if Property Name is -- also wildcarded. The ABNF syntax is: modemDescriptor = ModemToken (( EQUAL modemType) / (LSBRKT modemType *(COMMA modemType) RSBRKT)) [ LBRKT NAME parmValue *(COMMA NAME parmValue) RBRKT ] parmValue = (EQUAL alternativeValue/ INEQUAL VALUE) alternativeValue = ( VALUE / LSBRKT VALUE *(COMMA VALUE) RSBRKT ; sublist (i.e. A AND B AND ...) / LBRKT VALUE *(COMMA VALUE) RBRKT ; alternatives (i.e. A OR B OR ...) / LSBRKT VALUE COLON VALUE RSBRKT ) ; range INEQUAL = LWSP (">" / "<" / "#" ) LWSP LSBRKT = LWSP "[" LWSP RSBRKT = LWSP "]" LWSP Regards, Richie Wu ===== Huawei Technologies India Private Limited Unit 10, 2nd Floor, Innovator Block International Tech Park, Whitefield Main Road Bangalore 560 066, India TEL: 0091-80-841 0061/0753/0755 FAX: 0091-80-841 0063 __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one Place. http://shopping.yahoo.com/ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 7 10:10:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17225 for ; Tue, 7 Nov 2000 10:10:06 -0500 (EST) Received: from standards (47.234.32.16:1032) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB146F@standards.nortelnetworks.com>; Tue, 7 Nov 2000 9:52:16 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 83206 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Nov 2000 09:52:15 -0500 Received: from zrchh190 (47.158.65.22:64710) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB1468@standards.nortelnetworks.com>; Tue, 7 Nov 2000 9:42:15 -0500 Received: from smtprch1.nortel.com (actually erchg0j) by zrchh190; Tue, 7 Nov 2000 08:56:58 -0600 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Tue, 7 Nov 2000 08:55:36 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 7 Nov 2000 08:55:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C048CA.C3996EA0" X-Orig: Message-ID: <75C9A75D295AD31184E70008C79189D2035A7765@zcard00b.ca.nortel.com> Date: Tue, 7 Nov 2000 08:55:26 -0600 Reply-To: "Whitton, Alan" Sender: "Media Gateway Control (megaco)" From: "Whitton, Alan" Subject: Re: ServiceChangeMethod Failover 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_01C048CA.C3996EA0 Content-Type: text/plain; charset="iso-8859-1" OK, What happens if you have a call originated from your FIRST (MGC1) controller, MGC1 then gracefully hands over to MGC2 (let's say for a software upgrade). The first call is still "UP" (especially for NAS calls this is VERY likely). MGC1 now goes OFF LINE for it's software update (say 6 hours was waited for). Now our user finally hangs up his modem, and the teardown process begins. Your statements seems to suggest that the EVENT will go to MGC1, even though MGC2 is now completely in control? More likely than not in this model the MG hangs up the call, and the "new" MGC (MGC2) will get REL messages from the SS7 network also, and tear down will occur on both sides, however, there is the question about accounting records (both Radius and AMMA). Food for thought, Cheers, Alan -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] Sent: Monday, November 06, 2000 2:49 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: ServiceChangeMethod Failover Rats! I thought we had been through that text and decided to make it consistent with the "replies go back to the originator" rule. My recollection is that we decided that replies ALWAYS go back to who sent them, ALWAYS, no exceptions. The failure model that I know how to deal with is that transactions not started always work. Transactions completed stay good, but transactions "in the middle" may or may not be completed, and it's too hard to try to keep these in the middle things working across a handover. We often have the same kind of thing in the MGC - calls up stay up, calls started immediately after handover work, calls actually in process, but not established, are often dropped. Brian > -----Original Message----- > From: Tulpule, Naren [mailto:naren@trillium.com] > Sent: Monday, November 06, 2000 2:23 PM > To: Rosen, Brian; MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: RE: ServiceChangeMethod Failover > > > Hi Brian, > that's what I thought, yet section 11.5 (Failure of an MGC) states: > > No recommendation is made on how the MGCs involved in the Handoff > maintain state information; this is considered to be out > of scope of > this recommendation. The MGC and MG may take the following > steps when > Handoff occurs. When the MGC initiates a HandOff, the handover > should be transparent to Operations on the Media Gateway. > Transactions can be executed in any order, and could be in progress > when the ServiceChange is executed. Accordingly, commands in > progress continue, transaction replies are sent to the new > MGC (after > a new control association is established), and the MG should expect > outstanding transaction replies from the new MGC. No new messages > shall be sent to the new MGC until the control association is > established. Repeated transaction requests shall be > directed to the > new MGC. The MG shall maintain state on all terminations and > contexts. > > -- Naren. > These views and opinions are mine alone, not those of Intel > (yet ;-) > Narendra C. Tulpule SMTS, Trillium (an Intel company) > Ph: +1-310-442-9222 Fax: +1-310-442-1162 > 12100 Wilshire Bl #1800 Los Angeles, CA 90025 > > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > Sent: Monday, November 06, 2000 11:05 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: ServiceChangeMethod Failover > > > Replies and Pendings ALWAYS go back from whence they came, no > exceptions. > > We do need to make this clear in the text. > > Brian > > > -----Original Message----- > > From: Terry L Anderson [mailto:tla@LUCENT.COM] > > Sent: Monday, November 06, 2000 11:08 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: ServiceChangeMethod Failover > > > > > > The use of ServiceChangeMethod = Failover and the > procedures behind it > > are not totally clear in 7.2.8. The paragraph describing the use of > > ServiceChangeAddress indicate that new transaction requests > go to the > > new address but replies and pending indications continue to > go to the > > "address from which the corresponding request originated." > > > > The next paragraph discussing ServiceChangeMgcId (which I believe is > > used with Handoff) does NOT make clear whether a similar > > distinction is > > made between new transactions and replies and pending indictions or > > whether all messages go to the new MGC. The text merely > says "the new > > MGC that will take over from the current MGC." It is not clear what > > "take over" means. The issue is the procedures behind a > > handoff: is it > > gradual (ServiceChange with Handoff is sent but the MGC must > > wait around > > for replies and pending indications before it can go out of > > service) or > > abrupt (ServiceChange can be sent and then immediately MGC > > can go out of > > service and the new MGC handle all subsequent activity). > > > > I think that text should be more specific about the > > procedures relating > > to Handoff. > > > > -- > > ------------------------------------------------------------ > > Terry L Anderson mailto:tla@lucent.com > > Tel:908.582.7013 Fax:908.582.6729 > > Pager:800.759.8352 pin 1704572 1704572@skytel.com > > Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > > > > ------_=_NextPart_001_01C048CA.C3996EA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: ServiceChangeMethod Failover

OK,

What happens if you have a call originated from your = FIRST (MGC1) controller, MGC1 then gracefully hands over to MGC2 (let's = say for a software upgrade). The first call is still "UP" = (especially for NAS calls this is VERY likely). MGC1 now goes OFF LINE = for it's software update (say 6 hours was waited for). Now our user = finally hangs up his modem, and the teardown process begins. Your = statements seems to suggest that the EVENT will go to MGC1, even though = MGC2 is now completely in control?

More likely than not in this model the MG hangs up = the call, and the "new" MGC (MGC2) will get REL messages from = the SS7 network also, and tear down will occur on both sides, however, = there is the question about accounting records (both Radius and = AMMA).

Food for thought,

Cheers,
Alan

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
Sent: Monday, November 06, 2000 2:49 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: ServiceChangeMethod Failover


Rats!  I thought we had been through that text = and decided to make
it consistent with the "replies go back to the = originator" rule.
My recollection is that we decided that replies = ALWAYS go back to
who sent them, ALWAYS, no exceptions.

The failure model that I know how to deal with is = that transactions
not started always work.  Transactions = completed stay good, but
transactions "in the middle" may or may = not be completed, and it's
too hard to try to keep these in the middle things = working across a
handover.  We often have the same kind of thing = in the MGC - calls
up stay up, calls started immediately after handover = work, calls actually
in process, but not established, are often = dropped.

Brian

> -----Original Message-----
> From: Tulpule, Naren [mailto:naren@trillium.com]=
> Sent: Monday, November 06, 2000 2:23 PM
> To: Rosen, Brian; = MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: RE: ServiceChangeMethod = Failover
>
>
> Hi Brian,
>   that's what I thought, yet section = 11.5 (Failure of an MGC) states:
>
>  No recommendation is made on how the MGCs = involved in the Handoff
>    maintain state information; = this is considered to be out
> of scope of
>    this recommendation. The MGC = and MG may take the following
> steps when
>    Handoff occurs.  When = the MGC initiates a HandOff, the handover
>    should be transparent to = Operations on the Media Gateway.
>    Transactions can be executed = in any order, and could be in progress
>    when the ServiceChange is = executed.  Accordingly, commands in
>    progress continue, = transaction replies are sent to the new
> MGC (after
>    a new control association is = established), and the MG should expect
>    outstanding transaction = replies from the new MGC.  No new messages
>    shall be sent to the new MGC = until the control association is
>    established.  Repeated = transaction requests shall be
> directed to the
>    new MGC.  The MG shall = maintain state on all terminations and
>    contexts.
>
> -- Naren.
> These views and opinions are mine alone, not = those of Intel
>  (yet ;-)
> Narendra C. Tulpule SMTS, Trillium (an Intel = company)
> Ph: = +1-310-442-9222         &nb= sp;    Fax: +1-310-442-1162
> 12100 Wilshire Bl = #1800         Los Angeles, CA = 90025
>
>
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> Sent: Monday, November 06, 2000 11:05 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: ServiceChangeMethod = Failover
>
>
> Replies and Pendings ALWAYS go back from whence = they came, no
> exceptions.
>
> We do need to make this clear in the = text.
>
> Brian
>
> > -----Original Message-----
> > From: Terry L Anderson [mailto:tla@LUCENT.COM]
> > Sent: Monday, November 06, 2000 11:08 = AM
> > To: = MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: ServiceChangeMethod = Failover
> >
> >
> > The use of ServiceChangeMethod =3D = Failover and the
> procedures behind it
> > are not totally clear in 7.2.8.  The = paragraph describing the use of
> > ServiceChangeAddress indicate that new = transaction requests
> go to the
> > new address but replies and pending = indications continue to
> go to the
> > "address from which the corresponding = request originated."
> >
> > The next paragraph discussing = ServiceChangeMgcId (which I believe is
> > used with Handoff) does NOT make clear = whether a similar
> > distinction is
> > made between new transactions and replies = and pending indictions or
> > whether all messages go to the new = MGC.  The text merely
> says "the new
> > MGC that will take over from the current = MGC." It is not clear what
> > "take over" means.  The = issue is the procedures behind a
> > handoff: is it
> > gradual (ServiceChange with Handoff is = sent but the MGC must
> > wait around
> > for replies and pending indications before = it can go out of
> > service) or
> > abrupt (ServiceChange can be sent and then = immediately MGC
> > can go out of
> > service and the new MGC handle all = subsequent activity).
> >
> > I think that text should be more specific = about the
> > procedures relating
> > to Handoff.
> >
> > --
> > = ------------------------------------------------------------
> > Terry L = Anderson          &nbs= p;   mailto:tla@lucent.com
> > Tel:908.582.7013   = Fax:908.582.6729
> > Pager:800.759.8352 pin 1704572   = 1704572@skytel.com
> > Lucent Technologies/ Voice Over IP Access = Networks/ Applications Grp
> > Rm 2B-121, 600 Mountain Av, Murray Hill, = NJ 07974
> > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
> >
> >
>

------_=_NextPart_001_01C048CA.C3996EA0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 7 13:37:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14791 for ; Tue, 7 Nov 2000 13:36:33 -0500 (EST) Received: from standards (47.234.32.16:1977) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB159D@standards.nortelnetworks.com>; Tue, 7 Nov 2000 13:14:17 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 83597 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Nov 2000 13:14:17 -0500 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB159C@standards.nortelnetworks.com>; Tue, 7 Nov 2000 13:14:15 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA04691; Tue, 7 Nov 2000 13:30:16 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA10821; Tue, 7 Nov 2000 13:30:17 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 7 Nov 2000 13:29:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C048E8.C41A14B0" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E9D7@whq-msgusr-02.pit.comms.marconi.com> Date: Tue, 7 Nov 2000 13:30:12 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: ServiceChangeMethod Failover X-To: Alan Whitton 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_01C048E8.C41A14B0 Content-Type: text/plain; charset="ISO-8859-1" I just dealt with this one on a related thread. The Notify is a new command, and goes to the new (MGC2) controller. Brian -----Original Message----- From: Alan Whitton [mailto:awhitton@nortelnetworks.com] Sent: Tuesday, November 07, 2000 9:55 AM To: Rosen, Brian; megaco@standards.nortelnetworks.com Subject: RE: ServiceChangeMethod Failover OK, What happens if you have a call originated from your FIRST (MGC1) controller, MGC1 then gracefully hands over to MGC2 (let's say for a software upgrade). The first call is still "UP" (especially for NAS calls this is VERY likely). MGC1 now goes OFF LINE for it's software update (say 6 hours was waited for). Now our user finally hangs up his modem, and the teardown process begins. Your statements seems to suggest that the EVENT will go to MGC1, even though MGC2 is now completely in control? More likely than not in this model the MG hangs up the call, and the "new" MGC (MGC2) will get REL messages from the SS7 network also, and tear down will occur on both sides, however, there is the question about accounting records (both Radius and AMMA). Food for thought, Cheers, Alan -----Original Message----- From: Rosen, Brian [ mailto:Brian.Rosen@MARCONI.COM ] Sent: Monday, November 06, 2000 2:49 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: ServiceChangeMethod Failover Rats! I thought we had been through that text and decided to make it consistent with the "replies go back to the originator" rule. My recollection is that we decided that replies ALWAYS go back to who sent them, ALWAYS, no exceptions. The failure model that I know how to deal with is that transactions not started always work. Transactions completed stay good, but transactions "in the middle" may or may not be completed, and it's too hard to try to keep these in the middle things working across a handover. We often have the same kind of thing in the MGC - calls up stay up, calls started immediately after handover work, calls actually in process, but not established, are often dropped. Brian > -----Original Message----- > From: Tulpule, Naren [ mailto:naren@trillium.com ] > Sent: Monday, November 06, 2000 2:23 PM > To: Rosen, Brian; MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: RE: ServiceChangeMethod Failover > > > Hi Brian, > that's what I thought, yet section 11.5 (Failure of an MGC) states: > > No recommendation is made on how the MGCs involved in the Handoff > maintain state information; this is considered to be out > of scope of > this recommendation. The MGC and MG may take the following > steps when > Handoff occurs. When the MGC initiates a HandOff, the handover > should be transparent to Operations on the Media Gateway. > Transactions can be executed in any order, and could be in progress > when the ServiceChange is executed. Accordingly, commands in > progress continue, transaction replies are sent to the new > MGC (after > a new control association is established), and the MG should expect > outstanding transaction replies from the new MGC. No new messages > shall be sent to the new MGC until the control association is > established. Repeated transaction requests shall be > directed to the > new MGC. The MG shall maintain state on all terminations and > contexts. > > -- Naren. > These views and opinions are mine alone, not those of Intel > (yet ;-) > Narendra C. Tulpule SMTS, Trillium (an Intel company) > Ph: +1-310-442-9222 Fax: +1-310-442-1162 > 12100 Wilshire Bl #1800 Los Angeles, CA 90025 > > > -----Original Message----- > From: Rosen, Brian [ mailto:Brian.Rosen@MARCONI.COM ] > Sent: Monday, November 06, 2000 11:05 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: ServiceChangeMethod Failover > > > Replies and Pendings ALWAYS go back from whence they came, no > exceptions. > > We do need to make this clear in the text. > > Brian > > > -----Original Message----- > > From: Terry L Anderson [ mailto:tla@LUCENT.COM ] > > Sent: Monday, November 06, 2000 11:08 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: ServiceChangeMethod Failover > > > > > > The use of ServiceChangeMethod = Failover and the > procedures behind it > > are not totally clear in 7.2.8. The paragraph describing the use of > > ServiceChangeAddress indicate that new transaction requests > go to the > > new address but replies and pending indications continue to > go to the > > "address from which the corresponding request originated." > > > > The next paragraph discussing ServiceChangeMgcId (which I believe is > > used with Handoff) does NOT make clear whether a similar > > distinction is > > made between new transactions and replies and pending indictions or > > whether all messages go to the new MGC. The text merely > says "the new > > MGC that will take over from the current MGC." It is not clear what > > "take over" means. The issue is the procedures behind a > > handoff: is it > > gradual (ServiceChange with Handoff is sent but the MGC must > > wait around > > for replies and pending indications before it can go out of > > service) or > > abrupt (ServiceChange can be sent and then immediately MGC > > can go out of > > service and the new MGC handle all subsequent activity). > > > > I think that text should be more specific about the > > procedures relating > > to Handoff. > > > > -- > > ------------------------------------------------------------ > > Terry L Anderson mailto:tla@lucent.com > > Tel:908.582.7013 Fax:908.582.6729 > > Pager:800.759.8352 pin 1704572 1704572@skytel.com > > Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > > > > ------_=_NextPart_001_01C048E8.C41A14B0 Content-Type: text/html; charset="ISO-8859-1" RE: ServiceChangeMethod Failover
I just dealt with this one on a related thread.  The Notify is a new command, and goes to the new (MGC2) controller.
 
Brian
-----Original Message-----
From: Alan Whitton [mailto:awhitton@nortelnetworks.com]
Sent: Tuesday, November 07, 2000 9:55 AM
To: Rosen, Brian; megaco@standards.nortelnetworks.com
Subject: RE: ServiceChangeMethod Failover

OK,

What happens if you have a call originated from your FIRST (MGC1) controller, MGC1 then gracefully hands over to MGC2 (let's say for a software upgrade). The first call is still "UP" (especially for NAS calls this is VERY likely). MGC1 now goes OFF LINE for it's software update (say 6 hours was waited for). Now our user finally hangs up his modem, and the teardown process begins. Your statements seems to suggest that the EVENT will go to MGC1, even though MGC2 is now completely in control?

More likely than not in this model the MG hangs up the call, and the "new" MGC (MGC2) will get REL messages from the SS7 network also, and tear down will occur on both sides, however, there is the question about accounting records (both Radius and AMMA).

Food for thought,

Cheers,
Alan

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
Sent: Monday, November 06, 2000 2:49 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: ServiceChangeMethod Failover


Rats!  I thought we had been through that text and decided to make
it consistent with the "replies go back to the originator" rule.
My recollection is that we decided that replies ALWAYS go back to
who sent them, ALWAYS, no exceptions.

The failure model that I know how to deal with is that transactions
not started always work.  Transactions completed stay good, but
transactions "in the middle" may or may not be completed, and it's
too hard to try to keep these in the middle things working across a
handover.  We often have the same kind of thing in the MGC - calls
up stay up, calls started immediately after handover work, calls actually
in process, but not established, are often dropped.

Brian

> -----Original Message-----
> From: Tulpule, Naren [mailto:naren@trillium.com]
> Sent: Monday, November 06, 2000 2:23 PM
> To: Rosen, Brian; MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: RE: ServiceChangeMethod Failover
>
>
> Hi Brian,
>   that's what I thought, yet section 11.5 (Failure of an MGC) states:
>
>  No recommendation is made on how the MGCs involved in the Handoff
>    maintain state information; this is considered to be out
> of scope of
>    this recommendation. The MGC and MG may take the following
> steps when
>    Handoff occurs.  When the MGC initiates a HandOff, the handover
>    should be transparent to Operations on the Media Gateway.
>    Transactions can be executed in any order, and could be in progress
>    when the ServiceChange is executed.  Accordingly, commands in
>    progress continue, transaction replies are sent to the new
> MGC (after
>    a new control association is established), and the MG should expect
>    outstanding transaction replies from the new MGC.  No new messages
>    shall be sent to the new MGC until the control association is
>    established.  Repeated transaction requests shall be
> directed to the
>    new MGC.  The MG shall maintain state on all terminations and
>    contexts.
>
> -- Naren.
> These views and opinions are mine alone, not those of Intel
>  (yet ;-)
> Narendra C. Tulpule SMTS, Trillium (an Intel company)
> Ph: +1-310-442-9222              Fax: +1-310-442-1162
> 12100 Wilshire Bl #1800         Los Angeles, CA 90025
>
>
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> Sent: Monday, November 06, 2000 11:05 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: ServiceChangeMethod Failover
>
>
> Replies and Pendings ALWAYS go back from whence they came, no
> exceptions.
>
> We do need to make this clear in the text.
>
> Brian
>
> > -----Original Message-----
> > From: Terry L Anderson [mailto:tla@LUCENT.COM]
> > Sent: Monday, November 06, 2000 11:08 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: ServiceChangeMethod Failover
> >
> >
> > The use of ServiceChangeMethod = Failover and the
> procedures behind it
> > are not totally clear in 7.2.8.  The paragraph describing the use of
> > ServiceChangeAddress indicate that new transaction requests
> go to the
> > new address but replies and pending indications continue to
> go to the
> > "address from which the corresponding request originated."
> >
> > The next paragraph discussing ServiceChangeMgcId (which I believe is
> > used with Handoff) does NOT make clear whether a similar
> > distinction is
> > made between new transactions and replies and pending indictions or
> > whether all messages go to the new MGC.  The text merely
> says "the new
> > MGC that will take over from the current MGC." It is not clear what
> > "take over" means.  The issue is the procedures behind a
> > handoff: is it
> > gradual (ServiceChange with Handoff is sent but the MGC must
> > wait around
> > for replies and pending indications before it can go out of
> > service) or
> > abrupt (ServiceChange can be sent and then immediately MGC
> > can go out of
> > service and the new MGC handle all subsequent activity).
> >
> > I think that text should be more specific about the
> > procedures relating
> > to Handoff.
> >
> > --
> > ------------------------------------------------------------
> > Terry L Anderson              mailto:tla@lucent.com
> > Tel:908.582.7013   Fax:908.582.6729
> > Pager:800.759.8352 pin 1704572   1704572@skytel.com
> > Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp
> > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
> > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
> >
> >
>

------_=_NextPart_001_01C048E8.C41A14B0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 7 16:49:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07751 for ; Tue, 7 Nov 2000 16:48:59 -0500 (EST) Received: from standards (47.234.32.16:2257) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB16C6@standards.nortelnetworks.com>; Tue, 7 Nov 2000 16:26:14 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 83999 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Nov 2000 16:26:13 -0500 Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB16C5@standards.nortelnetworks.com>; Tue, 7 Nov 2000 16:26:13 -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 QAA05689 for ; Tue, 7 Nov 2000 16:42:24 -0500 (EST) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id QAA05685 for ; Tue, 7 Nov 2000 16:42:24 -0500 (EST) Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA07126; Tue, 7 Nov 2000 16:42:22 -0500 Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA07123; Tue, 7 Nov 2000 16:42:21 -0500 X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Original-To: MEGACO list , "Taylor, Tom-PT" , "Rosen, Brian" , John Segers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A0876F7.DF8175B5@lucent.com> Date: Tue, 7 Nov 2000 16:41:11 -0500 Reply-To: Troy Cauble Sender: "Media Gateway Control (megaco)" From: Troy Cauble Subject: Re: OCTET STRINGs in H.248 X-To: "Taylor, Tom-PT" , "Rosen, Brian" , John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Brian, Tom, John, et. al., Anyone want to take a shot at these? -troy -------- Original Message -------- Subject: OCTET STRINGs in H.248 Date: Sat, 4 Nov 2000 00:28:30 -0500 From: Troy Cauble Reply-To: Troy Cauble To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi all, Maybe I've missed some subtle beauty in the OCTET STRING, but it seems like an OPAQUE structure that's overused in the ASN.1 H.248 encoding. For example, these seem to represent integers: SecurityParmIndex ::= OCTET STRING(SIZE(4)) SequenceNum ::= OCTET STRING(SIZE(4)) But how do I extract an integer value? ntohl()? Feed the octet string to an ASN.1 function for decoding integers? Why wasn't an ASN.1 Integer used? What can I conclude about the internal structure of the following? AuthData ::= OCTET STRING (SIZE (12..32)) The "quotedString" element in the ABNF isn't much better. The worst cases are In the ASN.1 Value ::= OCTET STRING In the ABNF VALUE = quotedString / 1*(SafeChar) Many protocol elements use the above definitions. The value component of a SigParameter (or EventParameter or StatisticsParameter, etc) is OCTET STRING. How do I decode this opaque data representation? From decoding the SignalName and the sigParameterName I'll know the implied type (if I support that package). Section 12.2 lists all the allowable types. But it doesn't specify the ASN.1 or text *encoding* of those types. What is the text representation for an "Integer"? sprintf("%d") ? %x ? 0x%x ? %o ? 0%o ? What about a "Double" ? How do I get the integer value of an OCTET STRING that's known to be "Integer: 4 octet signed integer"? An ASN.1 function for integers or ntohl()? "List" is specified in the ABNF, but they're lists of (OPAQUE) VALUEs. Lists are handled in the ASN.1 *PropertyParm* as "SEQUENCE OF OCTET STRING". But can't lists be used in the parameters to Events and Signals too? Those elements just have a "Value" "OCTET STRING". If I know the type is "String", how do I get from the ASN.1 "OCTET STRING" to a char*? Just cast it? Or call an ASN.1 decode routine specific to "UTF-8 octet strings"? -troy From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 8 02:04:54 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03692 for ; Wed, 8 Nov 2000 02:04:53 -0500 (EST) Received: from standards (47.234.32.16:1095) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB1B4F@standards.nortelnetworks.com>; Wed, 8 Nov 2000 1:47:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 85514 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Nov 2000 01:47:05 -0500 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB1B34@standards.nortelnetworks.com>; Wed, 8 Nov 2000 1:37:04 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eA86rFZ05582; Wed, 8 Nov 2000 07:53:15 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id HAA05542; Wed, 8 Nov 2000 07:53:14 +0100 (MET) Received: from ericsson.com ([130.100.249.198]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id HAA16888; Wed, 8 Nov 2000 07:53:07 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01A6E9A5@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A07EBFF.C0480CBE@ericsson.com> Date: Tue, 7 Nov 2000 22:48:15 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Multiple Adds In One Transaction and Errors X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Brian, Wouldn't you just get back a "?" for the context ID? No termination is added so there can't be a context. Cheers, Christian "Rosen, Brian" wrote: > > Commands are atomic, execute in order, and errors stop processing, > therefore, your response will be > Reply=1001 {Context=5599 {Add=TDM1/1 {Error{......}}}} > The contextId was a bit worrisome. It could have been $, > and the context won't exist, but I think you will in fact get > the ContextId the MG would have used. > > Is the latter more grist for the Implementer's Guide? > > Brian > > > -----Original Message----- > > From: Alan Whitton [mailto:awhitton@NORTELNETWORKS.COM] > > Sent: Friday, November 03, 2000 1:42 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Multiple Adds In One Transaction and Errors > > > > > > Greetings, > > > > A simple question (I think). If I create a transaction which > > consists of > > two ADD commands, something like: > > > > MEGACO/1 [198.1.2.3]:55555 > > Transaction=1001 { > > Context = $ { > > ADD = TDM1/1 { > > blah... blah.. blah... > > } > > ADD = $ { > > yatta... yatta... yatta... > > } > > } > > } > > > > And the Gateway has issues with these ADDs, what happens if > > BOTH the adds > > fail? What would the reply look like, and how would the > > Controller figure > > out which error goes with which ADD? > > > > Sounds easy, don't it? > > > > Cheers, > > Alan Whitton > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 8 05:25:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07057 for ; Wed, 8 Nov 2000 05:25:42 -0500 (EST) Received: from standards (47.234.32.16:4316) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB1D1B@standards.nortelnetworks.com>; Wed, 8 Nov 2000 5:07:49 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 86102 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Nov 2000 05:07:49 -0500 Received: from mail-in.audiocodes.com (AC-INT-LP.ser.netvision.net.il) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB1D1A@standards.nortelnetworks.com>; Wed, 8 Nov 2000 5:07:49 -0500 Received: by MAIL-IN with Internet Mail Service (5.5.2650.21) id ; Wed, 8 Nov 2000 12:23:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Message-ID: <81C3E8FE6C0AD4119D49009027C3AAB25DAC11@MAIL-IN> Date: Wed, 8 Nov 2000 12:23:40 +0200 Reply-To: Nurit Shenhar Sender: "Media Gateway Control (megaco)" From: Nurit Shenhar Subject: EventBuffer alogorithm To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi I am not sure I understood correclly the logic of the EventBuffer. Here is my understanding: We have two lists: One is the RequestedEvents list, and the other is the EventBufferDescriptor list, Both contain list of events, and we are In a LockStep situation. When we get the first event, it is compared against the RequestedEvents list. If it is found there: (option one) It is compared against the list of events in the EventBufferDescriptor and buffered if found or discarded if not found. (option two) It is notified. (option three) It is buffered. Now we get another event, and: (Option one) It is compared against the two lists. (Option two) It is compared only against the EventBuffer descriptor. Now we have a list of events buffered and we get a new EventsDescriptor. According to section 7.1.9 case 1, we send a notify for the first event in the buffer that matches an event in the RequestedEvent, remove it from the buffer and continue the buffering. And another point: What happens if we get a new EventBuffer descriptor? Best regards Nurit Shenhar AudioCodes Ltd. Direct: +972-3-539-4155 Tel: +972-3-539-4000 Fax: +972-3-539-4040 email: nurit.shenhar@audiocodes.com web: From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 8 10:59:11 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14550 for ; Wed, 8 Nov 2000 10:59:11 -0500 (EST) Received: from standards (47.234.32.16:4702) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB1ED8@standards.nortelnetworks.com>; Wed, 8 Nov 2000 10:41:12 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 86675 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Nov 2000 10:41:12 -0500 Received: from zrchh190 (47.158.65.22:58849) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB1ED4@standards.nortelnetworks.com>; Wed, 8 Nov 2000 10:31:11 -0500 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by zrchh190; Wed, 8 Nov 2000 09:47:09 -0600 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Tue, 7 Nov 2000 20:37:07 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 7 Nov 2000 20:36:47 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD1102AF3863@zcard00g.ca.nortel.com> Date: Tue, 7 Nov 2000 20:36:45 -0500 Reply-To: "Taylor, Tom-PT" Sender: "Media Gateway Control (megaco)" From: "Taylor, Tom-PT" Subject: Re: OCTET STRINGs in H.248 X-To: Troy Cauble To: MEGACO@STANDARDS.NORTELNETWORKS.COM In general you have to go into the detailed description of each field to understand how to parse it. For example, I've just put to bed an update of the Advanced Audio Server packages. The parameters in this package are defined in gross terms as strings, but there's a lot of detail in the package definition telling how the strings are constructed and interpreted. To take your first few examples, interpretation of SecurityParmIndex, SequenceNumber, and Authdata are covered by the text of section 10.2. When it comes to signal parameters, each has to be tackled on its own. > -----Original Message----- > From: Troy Cauble [mailto:troy@LUCENT.COM] > Sent: Tuesday, November 07, 2000 4:41 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: OCTET STRINGs in H.248 > > > Brian, Tom, John, et. al., > > Anyone want to take a shot at these? > > -troy > > > -------- Original Message -------- > Subject: OCTET STRINGs in H.248 > Date: Sat, 4 Nov 2000 00:28:30 -0500 > From: Troy Cauble > Reply-To: Troy Cauble > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Hi all, > > Maybe I've missed some subtle beauty in the OCTET STRING, > but it seems like an OPAQUE structure that's overused in > the ASN.1 H.248 encoding. > > For example, these seem to represent integers: > > SecurityParmIndex ::= OCTET STRING(SIZE(4)) > > SequenceNum ::= OCTET STRING(SIZE(4)) > > But how do I extract an integer value? ntohl()? Feed the > octet string to an ASN.1 function for decoding integers? > Why wasn't an ASN.1 Integer used? > > What can I conclude about the internal structure of the > following? > AuthData ::= OCTET STRING (SIZE (12..32)) > > > The "quotedString" element in the ABNF isn't much better. > The worst cases are > > In the ASN.1 Value ::= OCTET STRING > In the ABNF VALUE = quotedString / 1*(SafeChar) > > Many protocol elements use the above definitions. > > The value component of a SigParameter (or EventParameter or > StatisticsParameter, etc) is OCTET STRING. How do I decode > this opaque data representation? > > From decoding the SignalName and the sigParameterName > I'll know the implied type (if I support that package). > > Section 12.2 lists all the allowable types. But it > doesn't specify the ASN.1 or text *encoding* of those > types. > > What is the text representation for an "Integer"? > sprintf("%d") ? %x ? 0x%x ? %o ? 0%o ? > What about a "Double" ? > > How do I get the integer value of an OCTET STRING > that's known to be "Integer: 4 octet signed integer"? > An ASN.1 function for integers or ntohl()? > > "List" is specified in the ABNF, but they're lists > of (OPAQUE) VALUEs. > > Lists are handled in the ASN.1 *PropertyParm* as > "SEQUENCE OF OCTET STRING". But can't lists be > used in the parameters to Events and Signals too? > Those elements just have a "Value" "OCTET STRING". > > If I know the type is "String", how do I get from > the ASN.1 "OCTET STRING" to a char*? Just cast it? > Or call an ASN.1 decode routine specific to "UTF-8 > octet strings"? > > -troy > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 8 11:22:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20046 for ; Wed, 8 Nov 2000 11:22:02 -0500 (EST) Received: from standards (47.234.32.16:4702) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB1F31@standards.nortelnetworks.com>; Wed, 8 Nov 2000 11:04:16 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 86782 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Nov 2000 11:04:16 -0500 Received: from hvmta03-stg.us.psimail.psi.net (hvmta03-ext.us.psimail.psi.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB1F30@standards.nortelnetworks.com>; Wed, 8 Nov 2000 11:04:15 -0500 Received: from dev_4 ([38.150.216.6]) by hvmta03-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20001108162029.GEBE24415.hvmta03-stg@dev_4>; Wed, 8 Nov 2000 11:20:29 -0500 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 V4.72.3110.3 Message-ID: <007201c0499f$efdfe770$70d8a8c0@dev_4.us.radvision.com> Date: Wed, 8 Nov 2000 11:21:23 -0500 Reply-To: delbert@radvision.com Sender: "Media Gateway Control (megaco)" From: Dan Elbert Subject: Re: Audit capability with Media descriptor token in Audit descrip tor. X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4FBEA8857476D311A03300204840E1CF678882@whq-msgusr-02.pit.comms.marconi.com> Content-Transfer-Encoding: 7bit I understand that this refered to Audit using Termination Id = wildcard. What about Audit Capabilities using Termination Id = Root ? Does it have the same meaning ? Dan Elbert RADVISION > -----Original Message----- > From: Media Gateway Control (megaco) > [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Rosen, Brian > Sent: Friday, September 15, 2000 10:59 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Audit capability with Media descriptor token in Audit > descrip tor. > > > There has been some discussion on this lately. > > There are two issues: > 1) what is the descriptors returned > 2) what is the contents of the Local/Remote descriptor > > The former is easy. It's somewhat dependent on the capability > of the MG, but you would get a stream descriptor for each of > the streams the MG could possibly support, with local, remote > and localControl descriptors for each of them. If the MG only > supported one stream, it COULD return just the local, remote, > localControl (and TerminationState) descriptors in the Media > descriptor. > > The latter is a little less certain. > I think that you get a pretty expansive SDP (let's stick with > text encoding), with each possible value of each of the lines > (m=, a=..) listed. > > A sticky issue is whether you need to return combinations of > values when there is more than one parameter in a line. I'd > say no. You also are not expected to return all address > possibilities, or even address formats. > > Does that help? > > Brian > > > -----Original Message----- > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > Sent: Friday, September 15, 2000 10:12 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Audit capability with Media descriptor token in Audit > > descriptor. > > > > > > What is the response expected from MG when MGC generates > > Audit capability > > command with Media descriptor token present in Audit descriptor. > > Regards > > -Madhubabu > > Hughes Software Systems. > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 8 14:06:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03745 for ; Wed, 8 Nov 2000 14:06:42 -0500 (EST) Received: from standards (47.234.32.16:4997) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB21D1@standards.nortelnetworks.com>; Wed, 8 Nov 2000 13:48:47 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 87654 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Nov 2000 13:48:47 -0500 Received: from drawbridge.ascend.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB21D0@standards.nortelnetworks.com>; Wed, 8 Nov 2000 13:48:47 -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 KAA23154 for ; Wed, 8 Nov 2000 10:57:02 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 8 Nov 2000 19:05:00 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id LAA07307 for ; Wed, 8 Nov 2000 11:05:00 -0800 (PST) Received: from mastif.eng.ascend.com (mastif.eng.ascend.com [135.92.55.18]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id LAA18919 for ; Wed, 8 Nov 2000 11:04:59 -0800 (PST) Received: from sramannt-pc ([135.92.55.142]) by mastif.eng.ascend.com (8.8.8+Sun/8.8.8) with SMTP id OAA06847 for ; Wed, 8 Nov 2000 14:04:57 -0500 (EST) X-Sender: sraman@mastif.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <200011081904.OAA06847@mastif.eng.ascend.com> Date: Wed, 8 Nov 2000 14:06:10 -0500 Reply-To: Sankar Raman Sender: "Media Gateway Control (megaco)" From: Sankar Raman Subject: ContextId/TermId combination To: MEGACO@STANDARDS.NORTELNETWORKS.COM I would like clarification on contextId and termIationId combination as follows: Command: ContextId = Specific terminationId = WildCard (not ALL) Interpretation for Matching Terminations: 1) All physical terminations in the specified context that match the termination wildcarding pattern ?? OR 2) All physical Terminations that match the termination wildcarding pattern ?? There is a difference between the two interpretations - If the second interpretation is used, an error may result if one of the matching terminations was not in the specified context. If the first interpretation is used, this error will not happen even if a termination that matches the termination wildcarding alone, is not in this context. Also, can I assume that the following combination is invalid in any command ? ContextId = ALL terminationID = Specific. Please clarify. Thanks Sankar Raman Lucent Technologies From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 8 14:28:19 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09094 for ; Wed, 8 Nov 2000 14:28:19 -0500 (EST) Received: from standards (47.234.32.16:4997) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB220B@standards.nortelnetworks.com>; Wed, 8 Nov 2000 14:10:36 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 87738 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Nov 2000 14:10:36 -0500 Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB220A@standards.nortelnetworks.com>; Wed, 8 Nov 2000 14:10:35 -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 OAA20304 for ; Wed, 8 Nov 2000 14:26:49 -0500 (EST) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id OAA20285 for ; Wed, 8 Nov 2000 14:26:49 -0500 (EST) Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA18875; Wed, 8 Nov 2000 14:26:47 -0500 Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA18867; Wed, 8 Nov 2000 14:26:39 -0500 X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Original-CC: MEGACO@STANDARDS.NORTELNETWORKS.COM References: <28560036253BD41191A10000F8BCBD1102AF3863@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A09A8A9.21F19DF6@lucent.com> Date: Wed, 8 Nov 2000 14:25:29 -0500 Reply-To: Troy Cauble Sender: "Media Gateway Control (megaco)" From: Troy Cauble Subject: Re: OCTET STRINGs in H.248 X-To: "Taylor, Tom-PT" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Tom (or anyone), I hope I'm being dense and missing something, but... OK. Your package uses strings as parameters and tells me how to build those strings. This I understand. My question is: How are those strings ENCODED as ASN.1 OCTET STRINGs? Byte for byte copy? If so, is the null sent? Note that an ASN.1 "OCTET STRING" does not mean the same as an ASCII or UTF-8 "string". It means a sequence of opaque bytes of storage. So if a package says to use the string "foo" does the OCTET STRING contain a series of 3 bytes that contain 'f', 'o', 'o' ? Or 4 bytes that contain 'f', 'o', 'o', '\0' ? Or some less obvious guess? *The ASN.1 encoding is not fully specified for parameter values.* Similarly, if a package says a parameter type is "Integer", we know from section 12.2 that "Integer" means "4 octet signed integer". But we don't know how to encode it as an ASN.1 OCTET STRING. Is the ASN.1 OCTET STRING four bytes long consisting of the four bytes of a NETWORK BYTE ORDER integer representation? Or do we sprintf() it to a string representation and encode it like the "foo" example? (Is "OCTET STRING" being used to mean "string"?!) Does anyone get my point? Please point out whatever I've missed. Similarly, the ABNF "VALUE" specification stops at "quotedString", which (technically) doesn't fully specify the text ENCODING of types like "Integer". For the text encoding of "Integer" parameters, I doubt that we want to allow "three". But the text encoding specs stop at "quotedString", so I guess it's valid. A more reasonable GUESS would be "anything compatible with atoi()", but it's not fully specified. Anyone? -troy "Taylor, Tom-PT" wrote: > > In general you have to go into the detailed description of each field to > understand how to parse it. For example, I've just put to bed an update of > the Advanced Audio Server packages. The parameters in this package are > defined in gross terms as strings, but there's a lot of detail in the > package definition telling how the strings are constructed and interpreted. > > To take your first few examples, interpretation of SecurityParmIndex, > SequenceNumber, and Authdata are covered by the text of section 10.2. When > it comes to signal parameters, each has to be tackled on its own. > > > -----Original Message----- > > From: Troy Cauble [mailto:troy@LUCENT.COM] > > Sent: Tuesday, November 07, 2000 4:41 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: OCTET STRINGs in H.248 <...> From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 8 14:32:12 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09985 for ; Wed, 8 Nov 2000 14:32:11 -0500 (EST) Received: from standards (47.234.32.16:4997) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB221B@standards.nortelnetworks.com>; Wed, 8 Nov 2000 14:13:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 87760 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Nov 2000 14:13:05 -0500 Received: from drawbridge.ascend.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB221A@standards.nortelnetworks.com>; Wed, 8 Nov 2000 14:13: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 LAA25342 for ; Wed, 8 Nov 2000 11:21: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; 8 Nov 2000 19:29:18 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id LAA21603 for ; Wed, 8 Nov 2000 11:29:17 -0800 (PST) Received: from mastif.eng.ascend.com (mastif.eng.ascend.com [135.92.55.18]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id LAA21110 for ; Wed, 8 Nov 2000 11:29:16 -0800 (PST) Received: from sramannt-pc ([135.92.55.142]) by mastif.eng.ascend.com (8.8.8+Sun/8.8.8) with SMTP id OAA07390 for ; Wed, 8 Nov 2000 14:29:10 -0500 (EST) X-Sender: sraman@mastif.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <200011081929.OAA07390@mastif.eng.ascend.com> Date: Wed, 8 Nov 2000 14:30:24 -0500 Reply-To: Sankar Raman Sender: "Media Gateway Control (megaco)" From: Sankar Raman Subject: ContextId/TermId combination: IGNORE LAST EMAIL To: MEGACO@STANDARDS.NORTELNETWORKS.COM Please ignore my last email with this subject as it has some obvious errors. I would like clarification on contextId and termIationId combination as follows: Command: ContextId = Specific terminationId = WildCard (ALL) Interpretation for Matching Terminations: 1) All terminations (both physical & ephemeral) in the specified context that match the termination wildcarding pattern ?? OR 2) All terminations (both physical & ephemeral) that match the termination wildcarding pattern ?? There is a difference between the two interpretations - If the second interpretation is used, an error may result if one of the matching terminations was not in the specified context. If the first interpretation is used, this error will not happen even if a termination that matches the termination wildcarding alone, is not in this context. Also, can I assume that the following combination is invalid in any command ? ContextId = ALL terminationID = Specific. Please clarify. Thanks Sankar Raman Lucent Technologies From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 8 16:02:20 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02327 for ; Wed, 8 Nov 2000 16:02:20 -0500 (EST) Received: from standards (47.234.32.16:3856) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2349@standards.nortelnetworks.com>; Wed, 8 Nov 2000 15:44:28 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 88149 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Nov 2000 15:44:28 -0500 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2348@standards.nortelnetworks.com>; Wed, 8 Nov 2000 15:44:27 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA07851; Wed, 8 Nov 2000 16:00:39 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA26103; Wed, 8 Nov 2000 16:00:37 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 8 Nov 2000 15:59: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: <4FBEA8857476D311A03300204840E1CF021152C8@whq-msgusr-02.pit.comms.marconi.com> Date: Wed, 8 Nov 2000 16:00:35 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Audit capability with Media descriptor token in Audit descrip tor. X-To: delbert@radvision.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM Audit of root audits capabilities of the MG, not the terminations of the gateway. Essentially, you get the things that are defined as packages on root. Brian > -----Original Message----- > From: Dan Elbert [mailto:delbert@radvision.com] > Sent: Wednesday, November 08, 2000 11:21 AM > To: MEGACO@STANDARDS. NORTELNETWORKS. COM; Rosen, Brian > Subject: RE: Audit capability with Media descriptor token in Audit > descrip tor. > > > I understand that this refered to Audit using Termination Id > = wildcard. > What about Audit Capabilities using Termination Id = Root ? > Does it have the same meaning ? > > Dan Elbert > RADVISION > > > -----Original Message----- > > From: Media Gateway Control (megaco) > > [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of > Rosen, Brian > > Sent: Friday, September 15, 2000 10:59 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Audit capability with Media descriptor token in Audit > > descrip tor. > > > > > > There has been some discussion on this lately. > > > > There are two issues: > > 1) what is the descriptors returned > > 2) what is the contents of the Local/Remote descriptor > > > > The former is easy. It's somewhat dependent on the capability > > of the MG, but you would get a stream descriptor for each of > > the streams the MG could possibly support, with local, remote > > and localControl descriptors for each of them. If the MG only > > supported one stream, it COULD return just the local, remote, > > localControl (and TerminationState) descriptors in the Media > > descriptor. > > > > The latter is a little less certain. > > I think that you get a pretty expansive SDP (let's stick with > > text encoding), with each possible value of each of the lines > > (m=, a=..) listed. > > > > A sticky issue is whether you need to return combinations of > > values when there is more than one parameter in a line. I'd > > say no. You also are not expected to return all address > > possibilities, or even address formats. > > > > Does that help? > > > > Brian > > > > > -----Original Message----- > > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > > Sent: Friday, September 15, 2000 10:12 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Audit capability with Media descriptor token in Audit > > > descriptor. > > > > > > > > > What is the response expected from MG when MGC generates > > > Audit capability > > > command with Media descriptor token present in Audit descriptor. > > > Regards > > > -Madhubabu > > > Hughes Software Systems. > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 8 23:30:37 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA19057 for ; Wed, 8 Nov 2000 23:30:37 -0500 (EST) Received: from standards (47.234.32.16:1467) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2627@standards.nortelnetworks.com>; Wed, 8 Nov 2000 23:12:45 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 89163 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Nov 2000 23:12:45 -0500 Received: from zmers013 (47.124.1.40:37379) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2626@standards.nortelnetworks.com>; Wed, 8 Nov 2000 23:02:45 -0500 Received: from smtprch2.nortel.com (actually erchg0k) by zmers013; Wed, 8 Nov 2000 23:18:37 -0500 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Wed, 8 Nov 2000 22:14:23 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 8 Nov 2000 22:18:33 -0600 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD1102B375F8@zcard00g.ca.nortel.com> Date: Wed, 8 Nov 2000 22:18:32 -0600 Reply-To: "Taylor, Tom-PT" Sender: "Media Gateway Control (megaco)" From: "Taylor, Tom-PT" Subject: Revised H.248 Annex M (Advanced Audio Server packages) X-To: itu-sg16@mailbag.intel.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM Dear Dr. Okubo-san: I have uploaded a new draft of H.248 Annex M (Advanced Audio Server packages) in the Incoming directory of the PictureTel site. I realize it is too late for consideration at the present meeting, but please assign an APC number so it can be reviewed at a future date. Tom Taylor +1 613 736 0961 taylor@nortelnetworks.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 9 02:53:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16767 for ; Thu, 9 Nov 2000 02:53:07 -0500 (EST) Received: from standards (47.234.32.16:2135) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB26B1@standards.nortelnetworks.com>; Thu, 9 Nov 2000 2:35:22 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 89339 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 02:35:22 -0500 Received: from sj-msg-core-1.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB26AC@standards.nortelnetworks.com>; Thu, 9 Nov 2000 2:25:22 -0500 Received: from kaspit.cisco.com (kaspit.cisco.com [144.254.91.49]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id XAA06213 for ; Wed, 8 Nov 2000 23:41:40 -0800 (PST) Received: from kkogannt (dhcp-tel-hynex-64-103-120-56.cisco.com [64.103.120.56]) by kaspit.cisco.com (Mirapoint) with SMTP id ABB17465; Thu, 9 Nov 2000 09:41:35 +0200 (GMT-2) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_085F_01C04A30.EC33B070" 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: <086201c04a20$2938efa0$38786740@cisco.com> Date: Thu, 9 Nov 2000 09:39:14 +0200 Reply-To: Krill Kogan Sender: "Media Gateway Control (megaco)" From: Krill Kogan Organization: Cisco Systems Subject: H.248, MGCP To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_085F_01C04A30.EC33B070 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have to choose H.248 or MGCP. Where i can find comparing of them. Kirill ------=_NextPart_000_085F_01C04A30.EC33B070 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
We have to choose H.248 or = MGCP.
 
Where i can find comparing of = them.
 
Kirill
------=_NextPart_000_085F_01C04A30.EC33B070-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 9 11:21:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29863 for ; Thu, 9 Nov 2000 11:21:46 -0500 (EST) Received: from standards (47.234.32.16:1191) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2AAC@standards.nortelnetworks.com>; Thu, 9 Nov 2000 11:03:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 90641 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 11:03:05 -0500 Received: from roll.cefriel.it by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2A9A@standards.nortelnetworks.com>; Thu, 9 Nov 2000 10:53:04 -0500 Received: from pcntw1 (pcntw1.cefriel.it [131.175.55.204]) by roll.cefriel.it with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WQBSRAQ5; Thu, 9 Nov 2000 17:09:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <000201c04a66$375dfd00$cc37af83@cefriel.it> Date: Thu, 9 Nov 2000 17:00:42 +0100 Reply-To: Glauco Bigini Sender: "Media Gateway Control (megaco)" From: Glauco Bigini Subject: Megaco and universal signalling To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Anyone please help me! How do MGCs communicate between each other? Is there a standard protocol for inter-MGC communication? The Megaco protocol has been designed for the control of Media Gateways, can it be used for signalling between different network? A GREAT question: an ipothetic MGC cloud can be used as a core for Internet telephony signalling (an Internet-version of SS7)? I mean: any SIP, H323, SS7 network connected via Media Gateways and Signalling Gateways to a global MGC cloud that does signalling and MG connection via RTP(or another similar protocol)?? If not, what is(are) the main reason(s) why this would not eventually work? thanks to everyone.. ========================= Bigini Glauco CEFRIEL Network Systems Area bigini@cefriel.it ========================= From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 9 11:21:48 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29872 for ; Thu, 9 Nov 2000 11:21:47 -0500 (EST) Received: from standards (47.234.32.16:1191) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2AB3@standards.nortelnetworks.com>; Thu, 9 Nov 2000 11:04:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 90642 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 11:04:07 -0500 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2A9B@standards.nortelnetworks.com>; Thu, 9 Nov 2000 10:54:07 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eA9GAKZ28905; Thu, 9 Nov 2000 17:10:20 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id RAA00256; Thu, 9 Nov 2000 17:10:19 +0100 (MET) Received: from ericsson.com ([130.100.249.202]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id RAA22262; Thu, 9 Nov 2000 17:10:10 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD1102AF3863@zcard00g.ca.nortel.com> <3A09A8A9.21F19DF6@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A0ACC4B.67374CEF@ericsson.com> Date: Fri, 10 Nov 2000 03:09:47 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: OCTET STRINGs in H.248 X-To: Troy Cauble To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Troy, I believe that the easiest way to cope with the use of Octet Strings in ASN.1 is to say that if a package says a property is Integer (or string etc) then it should be encoded in the Octet String has it would have been if you have said "property INTEGER," in ASN.1 BER. T L V the value would resemble INTEGER rather than OCTET STRING. OCTET STRING was used to give you flexibility in the length. Something could go into the implementors' guide to this effect. The use of "\o" is a problem in both the text and ASN1 definitions. The package probably needs to say whether this is to be encoded or not. Cheers, Christian Troy Cauble wrote: > > Tom (or anyone), > > I hope I'm being dense and missing something, but... > > OK. Your package uses strings as parameters and tells > me how to build those strings. This I understand. > > My question is: How are those strings ENCODED as ASN.1 > OCTET STRINGs? Byte for byte copy? If so, is the null sent? > > Note that an ASN.1 "OCTET STRING" does not mean the > same as an ASCII or UTF-8 "string". It means a sequence > of opaque bytes of storage. > > So if a package says to use the string "foo" does the OCTET > STRING contain a series of 3 bytes that contain 'f', 'o', 'o' ? > Or 4 bytes that contain 'f', 'o', 'o', '\0' ? > Or some less obvious guess? > > *The ASN.1 encoding is not fully specified for parameter values.* > > Similarly, if a package says a parameter type is "Integer", > we know from section 12.2 that "Integer" means "4 octet > signed integer". But we don't know how to encode it as an > ASN.1 OCTET STRING. > > Is the ASN.1 OCTET STRING four bytes long consisting of > the four bytes of a NETWORK BYTE ORDER integer representation? > Or do we sprintf() it to a string representation and > encode it like the "foo" example? (Is "OCTET STRING" being > used to mean "string"?!) > > Does anyone get my point? Please point out whatever I've missed. > > Similarly, the ABNF "VALUE" specification stops at "quotedString", > which (technically) doesn't fully specify the text ENCODING of > types like "Integer". > > For the text encoding of "Integer" parameters, I doubt that we > want to allow "three". But the text encoding specs stop at > "quotedString", so I guess it's valid. A more reasonable GUESS > would be "anything compatible with atoi()", but it's not fully > specified. > > Anyone? > -troy > > "Taylor, Tom-PT" wrote: > > > > In general you have to go into the detailed description of each field to > > understand how to parse it. For example, I've just put to bed an update of > > the Advanced Audio Server packages. The parameters in this package are > > defined in gross terms as strings, but there's a lot of detail in the > > package definition telling how the strings are constructed and interpreted. > > > > To take your first few examples, interpretation of SecurityParmIndex, > > SequenceNumber, and Authdata are covered by the text of section 10.2. When > > it comes to signal parameters, each has to be tackled on its own. > > > > > -----Original Message----- > > > From: Troy Cauble [mailto:troy@LUCENT.COM] > > > Sent: Tuesday, November 07, 2000 4:41 PM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: OCTET STRINGs in H.248 > > <...> From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 9 11:58:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13204 for ; Thu, 9 Nov 2000 11:58:48 -0500 (EST) Received: from standards (47.234.32.16:4025) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2AF2@standards.nortelnetworks.com>; Thu, 9 Nov 2000 11:40:45 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 90756 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 11:40:45 -0500 Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2AF1@standards.nortelnetworks.com>; Thu, 9 Nov 2000 11:40:45 -0500 Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA27908 for ; Thu, 9 Nov 2000 11:57:02 -0500 (EST) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id LAA27896 for ; Thu, 9 Nov 2000 11:57:01 -0500 (EST) Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id LAA00086; Thu, 9 Nov 2000 11:56:59 -0500 Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id LAA00079; Thu, 9 Nov 2000 11:56:58 -0500 X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Original-CC: MEGACO@STANDARDS.NORTELNETWORKS.COM References: <28560036253BD41191A10000F8BCBD1102AF3863@zcard00g.ca.nortel.com> <3A09A8A9.21F19DF6@lucent.com> <3A0ACC4B.67374CEF@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A0AD713.2E809261@lucent.com> Date: Thu, 9 Nov 2000 11:55:47 -0500 Reply-To: Troy Cauble Sender: "Media Gateway Control (megaco)" From: Troy Cauble Subject: Re: OCTET STRINGs in H.248 X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Christian, Thanks for responding! Are you proposing they be "double wrapped"? The "double wrapping" approach is used in other protocols: ASN.1 BER encoding PRODUCES octet strings. So to encode an integer (or whatever) you first use an ASN.1 BER function for encoding integers (or whatever). The octet data OUTPUT from that function is the INPUT to the OCTET STRING encoding. This would give a consistent approach that doesn't change the current ASN.1 specification. If on the other hand, you're proposing to encode an ASN.1 INTEGER *instead of* an OCTET STRING, I think that would lead to decoding troubles. If an application doesn't support a package it won't know how to decode the message. -troy Christian Groves wrote: > > G'Day Troy, > > I believe that the easiest way to cope with the use of Octet Strings in > ASN.1 is to say that if a package says a property is Integer (or string > etc) then it should be encoded in the Octet String has it would have > been if you have said "property INTEGER," in ASN.1 BER. T L V the value > would resemble INTEGER rather than OCTET STRING. OCTET STRING was used > to give you flexibility in the length. Something could go into the > implementors' guide to this effect. A standard ASN.1 "CHOICE" statement would've given the flexibility we need. OCTET STRING is a protocol "hole" that should be avoided. > > The use of "\o" is a problem in both the text and ASN1 definitions. The > package probably needs to say whether this is to be encoded or not. > > Cheers, Christian > > Troy Cauble wrote: > > > > Tom (or anyone), > > > > I hope I'm being dense and missing something, but... > > > > OK. Your package uses strings as parameters and tells > > me how to build those strings. This I understand. > > > > My question is: How are those strings ENCODED as ASN.1 > > OCTET STRINGs? Byte for byte copy? If so, is the null sent? > > > > Note that an ASN.1 "OCTET STRING" does not mean the > > same as an ASCII or UTF-8 "string". It means a sequence > > of opaque bytes of storage. > > > > So if a package says to use the string "foo" does the OCTET > > STRING contain a series of 3 bytes that contain 'f', 'o', 'o' ? > > Or 4 bytes that contain 'f', 'o', 'o', '\0' ? > > Or some less obvious guess? > > > > *The ASN.1 encoding is not fully specified for parameter values.* > > > > Similarly, if a package says a parameter type is "Integer", > > we know from section 12.2 that "Integer" means "4 octet > > signed integer". But we don't know how to encode it as an > > ASN.1 OCTET STRING. > > > > Is the ASN.1 OCTET STRING four bytes long consisting of > > the four bytes of a NETWORK BYTE ORDER integer representation? > > Or do we sprintf() it to a string representation and > > encode it like the "foo" example? (Is "OCTET STRING" being > > used to mean "string"?!) > > > > Does anyone get my point? Please point out whatever I've missed. > > > > Similarly, the ABNF "VALUE" specification stops at "quotedString", > > which (technically) doesn't fully specify the text ENCODING of > > types like "Integer". > > > > For the text encoding of "Integer" parameters, I doubt that we > > want to allow "three". But the text encoding specs stop at > > "quotedString", so I guess it's valid. A more reasonable GUESS > > would be "anything compatible with atoi()", but it's not fully > > specified. > > > > Anyone? > > -troy > > > > "Taylor, Tom-PT" wrote: > > > > > > In general you have to go into the detailed description of each field to > > > understand how to parse it. For example, I've just put to bed an update of > > > the Advanced Audio Server packages. The parameters in this package are > > > defined in gross terms as strings, but there's a lot of detail in the > > > package definition telling how the strings are constructed and interpreted. > > > > > > To take your first few examples, interpretation of SecurityParmIndex, > > > SequenceNumber, and Authdata are covered by the text of section 10.2. When > > > it comes to signal parameters, each has to be tackled on its own. > > > > > > > -----Original Message----- > > > > From: Troy Cauble [mailto:troy@LUCENT.COM] > > > > Sent: Tuesday, November 07, 2000 4:41 PM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: OCTET STRINGs in H.248 > > > > <...> From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 9 12:22:52 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21674 for ; Thu, 9 Nov 2000 12:22:52 -0500 (EST) Received: from standards (47.234.32.16:1700) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2B42@standards.nortelnetworks.com>; Thu, 9 Nov 2000 12:04:12 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 90868 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 12:04:12 -0500 Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2B41@standards.nortelnetworks.com>; Thu, 9 Nov 2000 12:04:12 -0500 Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA29679 for ; Thu, 9 Nov 2000 12:20:29 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA29666 for ; Thu, 9 Nov 2000 12:20:28 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id SAA03467; Thu, 9 Nov 2000 18:20:27 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id SAA03436; Thu, 9 Nov 2000 18:20:25 +0100 (MET) X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD1102AF3863@zcard00g.ca.nortel.com> <3A09A8A9.21F19DF6@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A0AD53E.9503542D@lucent.com> Date: Thu, 9 Nov 2000 17:47:58 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: OCTET STRINGs in H.248 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Troy, It's not you being dense, this is underspecified. The intention of the OCTET STRING use is to have a general container that can be used for new parameters defined in packages (signals, events, properties). The package defines a type such as boolean, integer. The encoding of an integer value should be done according to ASN.1 BER (X.690), and the resulting octets are put into the octet string. On the receiving end, you get an octet string that is not decoded into an integer value by the ASN.1 decoder because it does not know about an H.248 package that says that this is really a integer. The price that you pay for the flexibility of adding new parameters by means of packages is the need to interpret the values for which OCTET STRING is used in the application that knows the package. Something similar holds for the text encoding. There are some additional issues with the text encoding because the octetstring of the ABNF is really a text string and does not allow null characters. Something that we did not specify is which type of string is used inside the octet string if a package specifies that a variable is of a string type. It would be best to align with the strings allowed in the ABNF. Cheers, John Troy Cauble wrote: > > Tom (or anyone), > > I hope I'm being dense and missing something, but... > > OK. Your package uses strings as parameters and tells > me how to build those strings. This I understand. > > My question is: How are those strings ENCODED as ASN.1 > OCTET STRINGs? Byte for byte copy? If so, is the null sent? > > Note that an ASN.1 "OCTET STRING" does not mean the > same as an ASCII or UTF-8 "string". It means a sequence > of opaque bytes of storage. > > So if a package says to use the string "foo" does the OCTET > STRING contain a series of 3 bytes that contain 'f', 'o', 'o' ? > Or 4 bytes that contain 'f', 'o', 'o', '\0' ? > Or some less obvious guess? > > *The ASN.1 encoding is not fully specified for parameter values.* > > Similarly, if a package says a parameter type is "Integer", > we know from section 12.2 that "Integer" means "4 octet > signed integer". But we don't know how to encode it as an > ASN.1 OCTET STRING. > > Is the ASN.1 OCTET STRING four bytes long consisting of > the four bytes of a NETWORK BYTE ORDER integer representation? > Or do we sprintf() it to a string representation and > encode it like the "foo" example? (Is "OCTET STRING" being > used to mean "string"?!) > > Does anyone get my point? Please point out whatever I've missed. > > Similarly, the ABNF "VALUE" specification stops at "quotedString", > which (technically) doesn't fully specify the text ENCODING of > types like "Integer". > > For the text encoding of "Integer" parameters, I doubt that we > want to allow "three". But the text encoding specs stop at > "quotedString", so I guess it's valid. A more reasonable GUESS > would be "anything compatible with atoi()", but it's not fully > specified. > > Anyone? > -troy > > "Taylor, Tom-PT" wrote: > > > > In general you have to go into the detailed description of each field to > > understand how to parse it. For example, I've just put to bed an update of > > the Advanced Audio Server packages. The parameters in this package are > > defined in gross terms as strings, but there's a lot of detail in the > > package definition telling how the strings are constructed and interpreted. > > > > To take your first few examples, interpretation of SecurityParmIndex, > > SequenceNumber, and Authdata are covered by the text of section 10.2. When > > it comes to signal parameters, each has to be tackled on its own. > > > > > -----Original Message----- > > > From: Troy Cauble [mailto:troy@LUCENT.COM] > > > Sent: Tuesday, November 07, 2000 4:41 PM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: OCTET STRINGs in H.248 > > <...> -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 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 Nov 9 12:22:54 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21679 for ; Thu, 9 Nov 2000 12:22:53 -0500 (EST) Received: from standards (47.234.32.16:1700) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2B4A@standards.nortelnetworks.com>; Thu, 9 Nov 2000 12:04:23 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 90878 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 12:04:23 -0500 Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2B49@standards.nortelnetworks.com>; Thu, 9 Nov 2000 12:04:22 -0500 Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA29923 for ; Thu, 9 Nov 2000 12:20:39 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA29912 for ; Thu, 9 Nov 2000 12:20:38 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id SAA03477; Thu, 9 Nov 2000 18:20:37 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id SAA03472; Thu, 9 Nov 2000 18:20:31 +0100 (MET) X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <81C3E8FE6C0AD4119D49009027C3AAB25DAC11@MAIL-IN> Content-Type: multipart/mixed; boundary="------------F545B0F04B0B159BF06C5EB4" Message-ID: <3A0AD953.9F1A8075@lucent.com> Date: Thu, 9 Nov 2000 18:05:24 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: EventBuffer alogorithm To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------F545B0F04B0B159BF06C5EB4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Nurit, I went and had a look at the text and tried to write it down clearly. The result of this you can find in the attached MS Word document. I hope that this format does not inconvenience anyone. Cheers, John Nurit Shenhar wrote: > > Hi > > I am not sure I understood correclly the logic of the EventBuffer. Here is > my understanding: > > We have two lists: One is the RequestedEvents list, and the other is the > EventBufferDescriptor list, Both contain list of events, and we are In a > LockStep situation. > > When we get the first event, it is compared against the RequestedEvents > list. If it is found there: > (option one) > It is compared against the list of events in the EventBufferDescriptor and > buffered if found or discarded if not found. > (option two) > It is notified. > (option three) > It is buffered. > > Now we get another event, and: > (Option one) > It is compared against the two lists. > (Option two) > It is compared only against the EventBuffer descriptor. > > Now we have a list of events buffered and we get a new EventsDescriptor. > According to section 7.1.9 case 1, we send a notify for the first event in > the buffer that matches an event in the RequestedEvent, remove it from the > buffer and continue the buffering. > > And another point: What happens if we get a new EventBuffer descriptor? > > Best regards > > Nurit Shenhar > AudioCodes Ltd. > Direct: +972-3-539-4155 > Tel: +972-3-539-4000 > Fax: +972-3-539-4040 > email: nurit.shenhar@audiocodes.com > > web: -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 --------------F545B0F04B0B159BF06C5EB4 Content-Type: application/msword; name="Megaco-events-mechanism.doc" Content-Disposition: inline; filename="Megaco-events-mechanism.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAANQAAAAAA AAAAEAAANwAAAAEAAAD+////AAAAADQAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAcQAJDAAAABK/AAAAAAAAEAAAAAAABAAA FxoAAA4AYmpianQrdCsAAAAAAAAAAAAAAAAAAAAAAAAJBBYAIiwAABZBAQAWQQEAFxYAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAF0AAAAAAIAFAAAAAAAAgAUAAIAFAAAAAAAAgAUAAAAAAACABQAA AAAAAIAFAAAAAAAAgAUAABQAAAAAAAAAAAAAAJQFAAAAAAAAlAUAAAAAAACUBQAAAAAAAJQF AAAAAAAAlAUAAAwAAACgBQAAHAAAAJQFAAAAAAAAexYAAPYAAADQBQAAAAAAANAFAAAAAAAA 0AUAAAAAAADQBQAAAAAAANAFAAAAAAAAqwYAAAAAAACrBgAAAAAAAKsGAAAAAAAAQBYAAAIA AABCFgAAAAAAAEIWAAAAAAAAQhYAAAAAAABCFgAAAAAAAEIWAAAAAAAAQhYAACQAAABxFwAA 9AEAAGUZAACQAAAAZhYAABUAAAAAAAAAAAAAAAAAAAAAAAAAgAUAAAAAAACrBgAAAAAAAAAA AAAAAAAAAAAAAAAAAACrBgAAAAAAAKsGAAAAAAAAqwYAAAAAAACrBgAAAAAAAGYWAAAAAAAA LQcAAAAAAACABQAAAAAAAIAFAAAAAAAA0AUAAAAAAAAAAAAAAAAAANAFAADbAAAA0AUAAAAA AAAtBwAAAAAAAC0HAAAAAAAALQcAAAAAAACrBgAAggAAAIAFAAAAAAAA0AUAAAAAAACABQAA AAAAANAFAAAAAAAAQBYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlAUAAAAAAACUBQAAAAAAAIAF AAAAAAAAgAUAAAAAAACABQAAAAAAAIAFAAAAAAAAqwYAAAAAAABAFgAAAAAAAC0HAACsBQAA LQcAAAAAAADZDAAA+gEAAKoUAABsAQAAgAUAAAAAAACABQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQBYAAAAAAADQBQAA AAAAALwFAAAUAAAAIIqXmG5KwAGUBQAAAAAAAJQFAAAAAAAALQcAAAAAAAAWFgAAKgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATWVnYWNvL0guMjQ4IEV2ZW50cyBNZWNoYW5pc20N OSBOb3ZlbWJlciAyMDAwDUpvaG4gU2VnZXJzIChqc2VnZXJzQGx1Y2VudC5jb20pDQ0NSW50 cm9kdWN0aW9uDVJlY29tbWVuZGF0aW9uIEguMjQ4IJYgb3IgaXRzIGVxdWl2YWxlbnQsIHRo ZSBNZWdhY28gcHJvdG9jb2wgYXMgc3BlY2lmaWVkIGluLCBSRkNzIDI5ODUsIDI5ODYgliBj b250YWlucyBhIGZhaXJseSBjb21wbGV4IGRlc2NyaXB0aW9uIG9mIGFuIGV2ZW50IGhhbmRs aW5nIG1lY2hhbmlzbS4gIFRoaXMgZG9jdW1lbnQgYWltcyB0byBjbGFyaWZ5IHRoZSBwcm9j ZWR1cmVzIHNwZWNpZmllZCBpbiB0aGUgc3RhbmRhcmQuDU5vdGUgdGhhdCB0aGlzIGRvY3Vt ZW50IHJlZmxlY3RzIHRoZSBhdXRob3IncyB1bmRlcnN0YW5kaW5nIG9mIHRoZSBzdGFuZGFy ZC4gIEluIGNhc2UgdGhlcmUgYXJlIGRpc2NyZXBhbmNpZXMgYmV0d2VlbiB0aGUgaW5mb3Jt YXRpb24gcHJlc2VudGVkIGhlcmUgYW5kIHRoYXQgaW4gdGhlIHN0YW5kYXJkLCB0aGVuLCBv ZiBjb3Vyc2UsIHRoZSBwcm9jZWR1cmVzIGZyb20gdGhlIHN0YW5kYXJkIHRha2UgcHJlY2Vk ZW5jZS4NVGVybWlub2xvZ3kNRXZlbnRzIG1heSBiZSBkZXRlY3RlZCBpbiBhIG1lZGlhIGdh dGV3YXkgKE1HKS4gIEV2ZW50IGRldGVjdGlvbiBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiBI LjI0ODsgaXQgaXMgZG9uZSBieSB0aGUgTUcgaGFyZHdhcmUvc29mdHdhcmUuICBBbHRlcm5h dGl2ZWx5LCB3ZSBzYXkgdGhhdCBhbiBldmVudCBpcyByYWlzZWQgYnkgdGhlIE1HLg1UaGUg SC4yNDggc3Vic3l0ZW0gcmVjZWl2ZXMgZGV0ZWN0ZWQgZXZlbnRzLiAgSXQgaXMgYXNzdW1l ZCBoZXJlIHRoYXQgdGhlIEguMjQ4IHN1YnN5c3RlbSBpcyBpbmZvcm1lZCBvZiB0aGUgdGVy bWluYXRpb24gb24gd2hpY2ggZXZlbnRzIGFyZSBkZXRlY3RlZC4NVGhlIGV2ZW50IGhhbmRs aW5nIG1lY2hhbmlzbSBvZiB0aGUgSC4yNDggc3Vic3lzdGVtIGVpdGhlciBwcm9jZXNzZXMg dGhlIGV2ZW50IGltbWVkaWF0ZWx5LCB1c2luZyBhbiBILjI0OCBFdmVudHNEZXNjcmlwdG9y LCBvciBpdCBidWZmZXJzIHRoZSBldmVudCBpbiBhbiBFdmVudEJ1ZmZlciBmb3IgZGVsYXll ZCBwcm9jZXNzaW5nLg1TdGF0ZSB2YXJpYWJsZXMNRXZlcnkgSC4yNDggdGVybWluYXRpb24g ZXhjZXB0IHRoZSBST09UIHRlcm1pbmF0aW9uIGhhcyBhIG51bWJlciBvZiBzdGF0ZSB2YXJp YWJsZXMgYXNzb2NpYXRlZCB3aXRoIGV2ZW50IHByb2Nlc3NpbmcsIG5hbWVseSwNYW4gRXZl bnRCdWZmZXIgdmFyaWFibGUgKEVCKSCWIGZvciBzdG9yaW5nIGRldGVjdGVkIGV2ZW50cyBi ZWZvcmUgcHJvY2Vzc2luZyB0aGVtLA1hbiBFdmVudEJ1ZmZlckNvbnRyb2wgdmFyaWFibGUg KEVCQykgliBmb3IgY29udHJvbGxpbmcgdXNlIG9mIEVCLA1hIERpYWxTdHJpbmdCdWZmZXIg dmFyaWFibGUgKERTQikgliBmb3Igc3RvcmluZyBkaWdpdHMgZHVyaW5nIGRpZ2l0bWFwIGNv bGxlY3Rpb24sDWFuIEV2ZW50c0Rlc2NyaXB0b3IgdmFyaWFibGUgKEVEKSCWIHNwZWNpZnlp bmcgaG93IGV2ZW50cyBhcmUgcHJvY2Vzc2VkLCBhbmQNYW4gRXZlbnRCdWZmZXJEZXNjcmlw dG9yIHZhcmlhYmxlIChFQkQpIJYgc3BlY2lmeWluZyB3aGljaCBldmVudHMgYXJlIHN0b3Jl ZCBpbiBFQi4NUHJvY2VkdXJlcyBmb3IgaGFuZGxpbmcgYSBuZXcgZGV0ZWN0ZWQgZXZlbnQN V2hlbiB0aGUgSC4yNDggc3Vic3lzdGVtIHJlY2VpdmVzIGEgbmV3IGRldGVjdGVkIGV2ZW50 LCBpdCBpcyBlaXRoZXIgcHJvY2Vzc2VkIGltbWVkaWF0ZWx5IG9yIGl0IGlzIHN0b3JlZCBp biB0aGUgZXZlbnRidWZmZXIgRUIgZm9yIGRlbGF5ZWQgcHJvY2Vzc2luZy4gIEluIHRoaXMg c2VjdGlvbiB3ZSBmaXJzdCBkZXNjcmliZSB0aGUgcHJvY2VkdXJlcyBmb3IgYnVmZmVyaW5n IGV2ZW50cyBhbmQgdGhlbiB0aGUgcHJvY2VkdXJlcyBmb3IgcHJvY2Vzc2luZyBldmVudHMu DVRvIGJ1ZmZlciBvciBub3QNVGhlIHZhbHVlIG9mIHN0YXRlIHZhcmlhYmxlIEVCQyBkZXRl cm1pbmVzIHdoZXRoZXIgZXZlbnQgcHJvY2Vzc2luZyBpcyBpbW1lZGlhdGUgb3IgZGVsYXll ZC4gIA1JZiBFQkMgPSBPZmYsIHRoZW4gdGhlIGV2ZW50YnVmZmVyIGlzIGJ5cGFzc2VkIGFu ZCB0aGUgZXZlbnQgaXMgcHJvY2Vzc2VkIGltbWVkaWF0ZWx5Lg1JZiBFQkMgPSBMb2NrU3Rl cCwgYW5kIHRoZSBkZXRlY3RlZCBldmVudCBvY2N1cnMgaW4gRUJELCB0aGVuIGl0IGlzIGFw cGVuZGVkIHRvIEVCLg1JZiBFQkMgPSBMb2NrU3RlcCwgYW5kIHRoZSBkZXRlY3RlZCBldmVu dCBkb2VzIG5vdCBvY2N1ciBpbiBFQkQsIHRoZW4gaXQgaXMgZGlzY2FyZGVkLg1Ob3RlOiAg VGhlIHRleHQgb2YgUmVjLiBILjI0OCBpcyBub3QgY2xlYXIgYWJvdXQgb25lIHBhcnRpY3Vs YXIgY2FzZS4gIFNlY3Rpb24gNy4xLjkvSC4yNDggZG9lcyBub3Qgc3BlY2lmeSBjbGVhcmx5 IHdoZXRoZXIgRUJEIGlzIHVzZWQgaWYgRUJDID0gTG9ja1N0ZXAsIEVCIGlzIGVtcHR5LCBF RCBpcyBub24tZW1wdHkgYW5kIEVCRCBpcyBub24tZW1wdHkuICBPbmUgY291bGQgY29uY2x1 ZGUgZnJvbSB0aGUgdGV4dCBvZiBDYXNlIDEuMSBpbiBTZWN0aW9uIDcuMS45IHRoYXQgRUJE IGlzIG5vdCB1c2VkIGluIHRoaXMgY2FzZS4gIEkuZS4sIG9uZSBjb3VsZCBjb25jbHVkZSB0 aGF0IGlmIEVCQyA9IExvY2tTdGVwLCBldmVudGJ1ZmZlciBFQiBpcyBlbXB0eSBhbmQgRUQg aXMgbm9uLWVtcHR5LCB0aGUgZXZlbnRidWZmZXIgaXMgYnlwYXNzZWQgZW50aXJlbHkgYW5k IHRoZSBkZXRlY3RlZCBldmVudCBpcyBwcm9jZXNzZWQgaW1tZWRpYXRlbHkuDUkgYXNzdW1l IHRoYXQgaW4gdGhpcyBjYXNlLCB0aGUgZXZlbnRidWZmZXIgaXMgbm90IGJ5cGFzc2VkLiAg VGhpcyBhc3N1bXB0aW9uIGxlYWRzIHRvIGEgY2xlYW5lciBtb2RlbCwgd2l0aCBldmVudCBi dWZmZXJpbmcgYW5kIGV2ZW50IHByb2Nlc3Npbmcgc3BlY2lmaWVkIGJ5IEVCRCBhbmQgRUQs IHJlc3BlY3RpdmVseSwgYW5kIHRoZSB1c2Ugb2YgRUJEIHNwZWNpZmllZCBieSB0aGUgdmFs dWUgb2YgRUJDLCBpbmRlcGVuZGVudCBvZiBlbXB0aW5lc3Mgb2YgdGhlIGJ1ZmZlci4NVGhp cyBwb2ludCBoYXMgdG8gYmUgY2xhcmlmaWVkIGluIHRoZSBzdGFuZGFyZC4NVGhlIHZhbHVl IG9mIEVCQyBtYXkgYmUgbW9kaWZpZWQgYnkgdGhlIE1HQyBieSBpbmNsdWRpbmcgaXQgYXMg YSBwYXJhbWV0ZXIgdG8sIGZvciBpbnN0YW5jZSwgYSBNb2RpZnkgY29tbWFuZCAoaW4gdGhl IFRlcm1pbmF0aW9uU3RhdGUgZGVzY3JpcHRvcikuICBJZiB0aGUgdmFsdWUgb2YgRUJDIGlz IHNldCB0byBPZmYsIGFsbCBldmVudHMgaW4gRUIgbXVzdCBiZSBkaXNjYXJkZWQuDVRodXMs IGlmIEVCQyA9IE9mZiwgRUIgcmVtYWlucyBlbXB0eSB1bnRpbCB0aGUgdmFsdWUgb2YgRUJD IGlzIHNldCB0byBMb2NrU3RlcC4NRXZlbnQgcHJvY2Vzc2luZw1UaGVyZSBhcmUgdHdvIGNh c2VzIHRvIGNvbnNpZGVyIGluIGV2ZW50IHByb2Nlc3NpbmcuICBQcm9jZXNzaW5nIHdoZW4g RUJDID0gT2ZmIGFuZCBwcm9jZXNzaW5nIHdoZW4gRUJDID0gTG9ja1N0ZXAuICBCZWZvcmUg aW52ZXN0aWdhdGluZyB0aGVzZSB0d28gY2FzZXMsIHdlIGRlZmluZSB3aGF0IGl0IG1lYW5z IGZvciBhIGRldGVjdGVkIGV2ZW50IHRvIGJlIHJlY29nbml6ZWQuICBBbiBldmVudCBpcyBy ZWNvZ25pemVkIGlmDWl0IG9jY3VycyBpbiBFRCwNb3IgRUQgY29udGFpbnMgYSBkaWdpdG1h cCBjb21wbGV0aW9uIGV2ZW50LCBhbmQgRUQgY29udGFpbnMgYW4gZXZlbnRETSBwYXJhbWV0 ZXIsIGFuZCB0aGUgZXZlbnQgb2NjdXJzIGluIHRoZSBhbHBoYWJldCBvZiB0aGUgZGlnaXRt YXAuDUluIHRoZSBsYXR0ZXIgY2FzZSBhIGRpZ2l0bWFwIGlzIGFjdGl2ZS4NV2Ugbm93IHR1 cm4gdG8gdGhlIHR3byBjYXNlcy4NRUJDID0gT2ZmLg1JZiB0aGUgZGV0ZWN0ZWQgZXZlbnQg aXMgbm90IHJlY29nbml6ZWQsIHRoZW4gaXQgaXMgZGlzY2FyZGVkLg1JZiB0aGUgZGV0ZWN0 ZWQgZXZlbnQgaXMgcmVjb2duaXplZCwgdGhlbiBhbGwgYWN0aXZlIHNpZ25hbHMgb24gdGhl IHRlcm1pbmF0aW9uIGFyZSBzdG9wcGVkLCB1bmxlc3MgdGhlIEtlZXBBY3RpdmUgZmxhZyBp cyBzZXQgZm9yIHRoZSBkZXRlY3RlZCBldmVudC4NSWYgdGhlIGV2ZW50IGlzIGluIHRoZSBh bHBoYWJldCBvZiBhbiBhY3RpdmUgZGlnaXRtYXAsIHRoZW4gdGhlIHByb2NlZHVyZXMgb2Yg U2VjdGlvbiA3LjE0LjUvSC4yNDggYXJlIGFwcGxpZWQuDUlmIHRoZSBldmVudCBpcyByZWNv Z25pemVkIGFuZCBpdCBvY2N1cnMgaW4gRUQsIHRoZW4NYSBOb3RpZnkgaXMgc2VudCB0byB0 aGUgTUdDLA1pZiBFRCBjb250YWlucyBhbiBlbWJlZGRlZCBzaWduYWxzIGRlc2NyaXB0b3Ig Zm9yIHRoaXMgZXZlbnQsIHRoaXMgc2lnbmFscyBkZXNjcmlwdG9yIGlzIGFjdGl2YXRlZCwg YW5kDWlmIEVEIGNvbnRhaW5zIGFuIGVtYmVkZGVkIGV2ZW50cyBkZXNjcmlwdG9yIGZvciB0 aGlzIGV2ZW50LCB0aGlzIHJlcGxhY2VzIHRoZSBjdXJyZW50IGV2ZW50cyBkZXNjcmlwdG9y IEVELg1Ob3RlOiBpdCBpcyBwb3NzaWJsZSB0aGF0IGFuIGV2ZW50IGlzICBwcm9jZXNzZWQg YWNjb3JkaW5nIHRvIGFuIGFjdGl2ZSBkaWdpdCBtYXAgKHN0ZXAgMykgYW5kIGEgTm90aWZ5 IGlzIHNlbnQgKHN0ZXAgNCkgaWYgdGhlIGV2ZW50IGlzIGV4cGxpY2l0bHkgcmVxdWVzdGVk IGluIHRoZSBzYW1lIGV2ZW50cyBkZXNjcmlwdG9yIGFzIGEgZGlnaXRtYXAgY29tcGxldGlv biBldmVudC4gIEFuIGVtYmVkZGVkIGV2ZW50cyBkZXNjcmlwdG9yIGFjdGl2YXRlZCBhY2Nv cmRpbmcgdG8gc3RlcCA0IGNhbiB0aHVzIGRlYWN0aXZhdGUgdGhlIGRpZ2l0bWFwIGNvbXBs ZXRpb24gZXZlbnQuDUVCQyA9IExvY2tTdGVwLgtJbiB0aGlzIGNhc2UsIGV2ZW50cyBhcmUg dGFrZW4gZnJvbSB0aGUgYnVmZmVyIGluIHRoZSBvcmRlciB0aGV5IHdlcmUgcmVjZWl2ZWQs IHByb2Nlc3NlZCwgYW5kIHJlbW92ZWQgZnJvbSB0aGUgYnVmZmVyLg1ObyBldmVudCBwcm9j ZXNzaW5nIG9jY3VycyBpZiB0aGVyZSBhcmUgbm8gZXZlbnRzIGluIEVCLg1JZiBhbiBldmVu dCB0YWtlbiBmcm9tIHRoZSBldmVudCBidWZmZXIgaXMgbm90IHJlY29nbml6ZWQsIGl0IGlz IHJlbW92ZWQgZnJvbSB0aGUgYnVmZmVyLCBhbmQgdGhlIG5leHQgZXZlbnQgaW4gdGhlIGJ1 ZmZlciBpcyBwcm9jZXNzZWQuDUlmIGFuIGV2ZW50IHRha2VuIGZyb20gdGhlIGV2ZW50IGJ1 ZmZlciBpcyByZWNvZ25pemVkLCBpdCBpcyBwcm9jZXNzZWQgYXMgc3BlY2lmaWVkIGluIHN0 ZXBzIFAxLjIgdGhyb3VnaCBQMS40LCBpdCBpcyByZW1vdmVkIGZyb20gdGhlIGJ1ZmZlci4g IFRoZSBNRyB0aGVuIGF3YWl0cyB0aGUgYWN0aXZhdGlvbiBvZiBhIG5ldyBFRCBiZWZvcmUg cHJvY2Vzc2luZyB0aGUgbmV4dCBldmVudCBpbiB0aGUgYnVmZmVyLiAgQSBuZXcgRUQgaXMg YWN0aXZhdGVkIGlmIGEgY29tbWFuZCBmcm9tIHRoZSBNR0MgaXMgcHJvY2Vzc2VkIHRoYXQg Y29udGFpbnMgYSBuZXcgRUQsIG9yIHRoZSBFRCBpcyByZXBsYWNlZCBieSBhbiBlbWJlZGRl ZCBldmVudHMgZGVzY3JpcHRvciAoc3RlcCBQMS40IGMpIG9mIHRoZSBldmVudCBwcm9jZXNz aW5nKS4NDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAEAABaBgAAYgYAAPwGAAACBwAA4AcAAOkHAAAoCAAALwgAACkNAAAtDQAA PQ8AAEAPAAAhEAAAURAAAFwSAABmEgAAwBIAAMMSAADmEgAA6RIAAM8UAADSFAAANhYAADkW AAAXGgAAAP0A/QD9AP0A+wD9APsA/QD9AP0A+wD7AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADNQiBAzYIgQAZAAQAAB4EAAAuBAAATwQAAFAE AABRBAAAXgQAAE4FAABABgAATAYAAA4HAAClBwAAZAgAAHQIAADyCAAARQkAAIcJAADaCQAA JwoAAHsKAACoCgAAtwsAAMgLAAAnDAAAfgwAANIMAAApDQAA/QAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD2AAAAAAAA AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA+AAAAAAAAAAA AAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPgAAAAAAAAAAAAA AADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA 8QAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAPgA AAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAABQAACiYAC0YJAAABAgAFAAAKJgALRggAAAEBAAABAAADAAAD JAEAARgAABoABAAAHgQAAC4EAABPBAAAUAQAAFEEAABeBAAATgUAAEAGAABMBgAADgcAAKUH AABkCAAAdAgAAPIIAABFCQAAhwkAANoJAAAnCgAAewoAAKgKAAC3CwAAyAsAACcMAAB+DAAA 0gwAACkNAAAODwAAIRAAAFEQAAAtEQAAfREAAI4RAACDEgAA/Pn28/Dq5+Tc2dbTy8jCurKq opqXi4iCenJvbGlmY1WIABsCAgAFAQb++P//BwEIAQAJAQoBAAAAC/74//8FBor6//8FBmb7 //8FBpb7//8FBqn8//8FBo7+//8PBuX+//8ICQAJAQoCAAAADwY5////CAkACQEKAQAAAAoG kP///wgJAAkBAAUG7////xYCAgAFAQbE/v//BwEIAQAJAQvE/v//AAUG0////w8CAQAFAAgB AAkBCgMAAAAPBj3+//8ICAAJAQoEAAAADwaK/v//CAgACQEKAwAAAA8G3f7//wgIAAkBCgIA AAAPBh////8ICAAJAQoBAAAACgZy////CAgACQEABQbw////DwIBAAUACAEACQEKAgAAAAUG m/7//wUGMv///wUG9P///w8CAQAFAAgBAAkBCgEAAAAFBgP///8FBvP///8KAgEABQAIAQAJ AQAFBrD///8FBrH///8FBtL///8FBuL///8FAhgABQAAISkNAAAODwAAIRAAAFEQAAAtEQAA fREAAI4RAACDEgAAlBIAABwTAABFEwAAYxMAAG4TAACtEwAARBQAALQUAADpFAAABhUAAG4V AADbFQAAJxcAAK8XAADoFwAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA APIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADt AAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA4QAA AAAAAAAAAAAAANUAAAAAAAAAAAAAAADVAAAAAAAAAAAAAAAA1QAAAAAAAAAAAAAAAPsAAAAA AAAAAAAAAADtAAAAAAAAAAAAAAAAyQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAwAAAomAAtGEgAPhNACDcYHAWgBAdACBgwAAAomAAtGDQAPhDgEDcYHAWgBATgEBgwA AAomAAtGDAAPhNACDcYHAWgBAdACBgUAAAomAAtGDgAFAAAKJgALRgsAAAECAAABAAAAAwAA D4RoAQAWgxIAAJQSAAAcEwAARRMAAGMTAABuEwAArRMAAEQUAAC0FAAA6RQAAAYVAABuFQAA 2xUAACcXAACvFwAA6BcAAHEYAAAUGgAAFRoAABYaAAAXGgAA+vLv7Obg2NDIwrqyAKqknJYA AJQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAg8ACggSAAkBCgIAAAAADwaV+f// CBIACQEKAQAAAAoGzvn//wgSAAkBAA8GVvr//wgOAAkBCgEAAAAPBg/8//8IDQAJAQoCAAAA DwZ3/P//CA0ACQEKAQAAAAoGlPz//wgNAAkBAA8Gyfz//wgMAAkBCgMAAAAPBjn9//8IDAAJ AQoCAAAADwbQ/f//CAwACQEKAQAAAAoGD/7//wgMAAkBAAoGGv7//wgOAAkBAAUGOP7//wUG Yf7//w8G6f7//wgLAAkBCgEAAAAKBvr+//8ICwAJARToFwAAcRgAABQaAAAVGgAAFhoAABca AAD4AAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA 6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAABDwAAAQAADAAACiYAC0YSAA+E0AINxgcBaAEB0AIGBwAACiYAC0YSAA+E 0AIABSAAHFABAB+w0C8gsOA9IbCgBSKwoAUjkKAFJJCgBSWwAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgAZAAoAAQBbAA8AAgAAAAAAAAAwAABA 8f8CADAAAAAGAE4AbwByAG0AYQBsAAAABgAAABOkeAALAGgIAG1ICQRuSAkEADwAAUABAAIA PAAAAAkASABlAGEAZABpAG4AZwAgADEAAAAPAAEABiQBCiYAC0YBAEAmAAAHADUIgUNKHAAA QAACQAEAAgBAAAAACQBIAGUAYQBkAGkAbgBnACAAMgAAAA8AAgAGJAEKJgELRgEAQCYBAAwA Q0oYAE9KAgBRSgIASAADQAEAAgBIAAAACQBIAGUAYQBkAGkAbgBnACAAMwAAABcAAwAGJAEK JgILRgEAE6TwABSkPABAJgIADABDShgAT0oCAFFKAgBMAARAAQACAEwAAAAJAEgAZQBhAGQA aQBuAGcAIAA0AAAAFwAEAAYkAQomAwtGAQATpPAAFKQ8AEAmAwAPADUIgUNKGABPSgIAUUoC AAA8AAVAAQACADwAAAAJAEgAZQBhAGQAaQBuAGcAIAA1AAAAFAAFAAomBAtGAQATpPAAFKQ8 AEAmBAQAQ0oWAEAABkABAAIAQAAAAAkASABlAGEAZABpAG4AZwAgADYAAAAUAAYACiYFC0YB ABOk8AAUpDwAQCYFBwA2CIFDShYAAEAAB0ABAAIAQAAAAAkASABlAGEAZABpAG4AZwAgADcA AAAUAAcACiYGC0YBABOk8AAUpDwAQCYGCABPSgIAUUoCAEQACEABAAIARAAAAAkASABlAGEA ZABpAG4AZwAgADgAAAAUAAgACiYHC0YBABOk8AAUpDwAQCYHCwA2CIFPSgIAUUoCAABKAAlA AQACAEoAAAAJAEgAZQBhAGQAaQBuAGcAIAA5AAAAFAAJAAomCAtGAQATpPAAFKQ8AEAmCBIA NQiBNgiBQ0oSAE9KAgBRSgIAPABBQPL/oQA8AAAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIA YQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAAAAAAAAAAAAAC4AHUABAPIALgAAAA0ARgBvAG8A dABuAG8AdABlACAAVABlAHgAdAAAAAIADwAAADgAJkCiAAEBOAAAABIARgBvAG8AdABuAG8A dABlACAAUgBlAGYAZQByAGUAbgBjAGUAAAADAEgqAQB2AP5PAQASAXYADAAaAEMAbwByAHIA ZQBjAHQAaQBvAG4AIABTAGUAcABhAHIAYQB0AG8AcgAgAEIAZQBnAGkAbgAAACEAEQADJAEG JAExJAAOhKAFD4SgBROk8AAUpPAAJmQGAQABAA0ANQiBNgiBaAgBbkgABABEAP5PogAhAUQA BAAJAEEAUwBOADEAXwB3AG8AcgBkAAAAIQA1CIFCKgBDShYAT0oAAFFKAABrSOQEbUgABG5I AAR1CAEAZgD+TwEAMgFmAAwADgBDAG8AcgByAGUAYwB0AGkAbwBuACAAZQBuAGQAAAAoABMA AyQBDoS9BQ+EoAUTpGgBJGQMAQABDcYOAAQaA6cENAbBBwAAAAAQADUIgTYIgUIqAWgIAW5I AAQ6AEJAAQBCAToAAAAJAEIAbwBkAHkAIABUAGUAeAB0AAAACgAUABOkAAAUpHgACwBDShYA aAgBbkgABAA4AENAAQBSATgAAAAQAEIAbwBkAHkAIABUAGUAeAB0ACAASQBuAGQAZQBuAHQA AAAGABUAD4TQAgAAPABaQAEAYgE8AAAACgBQAGwAYQBpAG4AIABUAGUAeAB0AAAABgAWABOk AAAPAE9KAwBRSgMAaAgBbkgABAAAAEAAPkABAIIBQAAAAAUAVABpAHQAbABlAAAAEAAYAAMk AROk8AAUpDwAQCYAEwA1CIFDSiAAS0gcAE9KAgBRSgIAAAAAAAAXFgAABQAALAAABAD///// AAQAABcaAAAQAAAAAAQAACkNAADoFwAAFxoAABEAAAATAAAAFQAAAAAEAACDEgAAFxoAABIA AAAUAAAADwAA8DgAAAAAAAbwGAAAAAIIAAACAAAAAQAAAAEAAAABAAAAAgAAAEAAHvEQAAAA //8AAAAA/wCAgIAA9wAAEAAPAALwkgAAABAACPAIAAAAAQAAAAEEAAAPAAPwMAAAAA8ABPAo AAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAABAAABQAAAA8ABPBCAAAAEgAK 8AgAAAABBAAAAA4AAFMAC/AeAAAAvwEAABAAywEAAAAA/wEAAAgABAMJAAAAPwMBAAEAAAAR 8AQAAAABAAAAAAAAAAcAAAAeAAAAIwAAAIYAAACrAAAAsAAAALEAAAC0AAAAvAAAAAACAAAR AgAAgw4AAIMOAADPEAAA4hAAANoRAAAmEwAAJxMAACcTAABwFAAAGRYAAAQAAwAEAAMABAAD AAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAP//FAAAAAsASgBvAGgAbgAgAFMAZQBn AGUAcgBzADYAQwA6AFwAVABFAE0AUABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBh AHYAZQAgAG8AZgAgAEgAMgA0ADgALQBlAHYAZQBuAHQAcwAtAG0AZQBjAGgAYQBuAGkAcwBt AC4AYQBzAGQACwBKAG8AaABuACAAUwBlAGcAZQByAHMANgBDADoAXABUAEUATQBQAFwAQQB1 AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAASAAyADQAOAAtAGUAdgBl AG4AdABzAC0AbQBlAGMAaABhAG4AaQBzAG0ALgBhAHMAZAALAEoAbwBoAG4AIABTAGUAZwBl AHIAcwA2AEMAOgBcAFQARQBNAFAAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2 AGUAIABvAGYAIABIADIANAA4AC0AZQB2AGUAbgB0AHMALQBtAGUAYwBoAGEAbgBpAHMAbQAu AGEAcwBkAAsASgBvAGgAbgAgAFMAZQBnAGUAcgBzADYAQwA6AFwAVABFAE0AUABcAEEAdQB0 AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAEgAMgA0ADgALQBlAHYAZQBu AHQAcwAtAG0AZQBjAGgAYQBuAGkAcwBtAC4AYQBzAGQACwBKAG8AaABuACAAUwBlAGcAZQBy AHMANgBDADoAXABUAEUATQBQAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBl ACAAbwBmACAASAAyADQAOAAtAGUAdgBlAG4AdABzAC0AbQBlAGMAaABhAG4AaQBzAG0ALgBh AHMAZAALAEoAbwBoAG4AIABTAGUAZwBlAHIAcwBAAFwAXABoAHoAcwBmAHMAMAAxAFwAagBz AGUAZwBlAHIAcwBcAEgALgAyADQAOAAgAEkAbgB0AGUAcgBvAHAAIABMAHUAYwBlAG4AdABc AEgAMgA0ADgALQBlAHYAZQBuAHQAcwAtAG0AZQBjAGgAYQBuAGkAcwBtAC4AZABvAGMACwBK AG8AaABuACAAUwBlAGcAZQByAHMAQQBDADoAXAB1AHMAZQByAHMAXABqAHMAZQBnAGUAcgBz AFwASAAuADIANAA4ACAASQBuAHQAZQByAG8AcAAgAEwAdQBjAGUAbgB0AFwATQBlAGcAYQBj AG8ALQBlAHYAZQBuAHQAcwAtAG0AZQBjAGgAYQBuAGkAcwBtAC4AZABvAGMACwBKAG8AaABu ACAAUwBlAGcAZQByAHMAQABDADoAXABXAEkATgBEAE8AVwBTAFwAVABFAE0AUABcAEEAdQB0 AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAE0AZQBnAGEAYwBvAC0AZQB2 AGUAbgB0AHMALQBtAGUAYwBoAGEAbgBpAHMAbQAuAGEAcwBkAAsASgBvAGgAbgAgAFMAZQBn AGUAcgBzAEEAQwA6AFwAdQBzAGUAcgBzAFwAagBzAGUAZwBlAHIAcwBcAEgALgAyADQAOAAg AEkAbgB0AGUAcgBvAHAAIABMAHUAYwBlAG4AdABcAE0AZQBnAGEAYwBvAC0AZQB2AGUAbgB0 AHMALQBtAGUAYwBoAGEAbgBpAHMAbQAuAGQAbwBjAAsASgBvAGgAbgAgAFMAZQBnAGUAcgBz AEEAQwA6AFwAdQBzAGUAcgBzAFwAagBzAGUAZwBlAHIAcwBcAEgALgAyADQAOAAgAEkAbgB0 AGUAcgBvAHAAIABMAHUAYwBlAG4AdABcAE0AZQBnAGEAYwBvAC0AZQB2AGUAbgB0AHMALQBt AGUAYwBoAGEAbgBpAHMAbQAuAGQAbwBjABIA4hwKAXpDXI//DwAAAAAAAAAAAAAAAAAAAAAB AFdftgR6Q1yP/w8AAAAAAAAAAAAAAAAAAAAAAQADLXwIAQAJBP8PAAAAAAAAAAAAAAAAAAAA AAEApFwQCYBZ2nT/DwAAAAAAAAAAAAAAAAAAAAABAJwujBLEeObS/w8AAAAAAAAAAAAAAAAA AAAAAQASZgYXDwAJBP8PAAAAAAAAAAAAAAAAAAAAAAEAR3EMNOKUvmL/DwAAAAAAAAAAAAAA AAAAAAABALcMfjQBAAkE/w8AAAAAAAAAAAAAAAAAAAAAAQBGTlo6DwAJBP8PAAAAAAAAAAAA AAAAAAAAAAEAMnmyReKUvmL/DwAAAAAAAAAAAAAAAAAAAAABAL4sEU6AWdp0/w8AAAAAAAAA AAAAAAAAAAAAAQCjVudUAQAJBP8PAAAAAAAAAAAAAAAAAAAAAAEAoDM5XOKUvmL/DwAAAAAA AAAAAAAAAAAAAAABANoGkGUBAAkE/w8AAAAAAAAAAAAAAAAAAAAAAQAJa4RooMfuEAEAAgAD AAQABQAGAAcACAAJAAAAIFNcfsR45tL/DwAAAAAAAAAAAAAAAAAAAAABAEllan8BAAkE/w8A AAAAAAAAAAAAAAAAAAAAAQBGM6J/DwAJBP8PAAAAAAAAAAAAAAAAAAAAAAEAAQAAAAAAAgAA AAAAAAAAAAAAAAAAAAAAABAAAA+EaAERhJj+FcYFAAFoAQYDAEIAAAAuAAEAAAAAAAIAAAAA AAAAAAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAwBCAAAALgABAAAAFwAAAAAAAAAA AAAAAAAAAAAAAAALGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+T0oBAFFKAQBvKAABALfw AQAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAABAAAA+EaAERhJj+FcYFAAFoAQYDAFAAAAAuAAEA AAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAgAAAC4AAQAAAAAA AQAAAAAAAAAAAAAAAAAAAAAAABAAAA+EaAERhJj+FcYFAAFoAQYCAAAALgABAAAABAABAAAA AAAAAAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUAAWgBBgIAAAApAAEAAAAXAAAAAAAAAAAA AAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAAAAAAQAA AAAAAAAAAAAAAAAAAAAAABAAAA+EaAERhJj+FcYFAAFoAQYCAAAALgABAAAABAABAAAAAAAA AAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUAAWgBBgIAAAApAAEAAAAAAAIAAAAAAAAAAAAA AAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAwBQAAAALgABAAAAFwAAAAAAAAAAAAAAAAAA AAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAEAAEAAAAAAAAA AAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAgAAACkAAQAAABcAAAAAAAAAAAAAAAAA AAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAAAABAAAAAAAA AAAAAAAAAAAAAAAAEAAAD4SwARGEUP4VxgUAAbABBgEAAAABAAAAAAABAwAAAAAAAAAAAAAA AAAAAAAAEAAAD4RAAhGEwP0VxgUAAUACBgMAAAAuAAEAAQAAAAAAAQMFAAAAAAAAAAAAAAAA AAAAABAAAA+E0AIRhDD9FcYFAAHQAgYFAAAALgABAC4AAgABAAAAAAABAwUHAAAAAAAAAAAA AAAAAAAAEAAAD4RgAxGEoPwVxgUAAWADBgcAAAAuAAEALgACAC4AAwABAAAAAAABAwUHCQAA AAAAAAAAAAAAAAAAEAAAD4TwAxGEEPwVxgUAAfADBgkAAAAuAAEALgACAC4AAwAuAAQAAQAA AAAAAQMFBwkLAAAAAAAAAAAAAAAAABAAAA+EgAQRhID7FcYFAAGABAYLAAAALgABAC4AAgAu AAMALgAEAC4ABQABAAAAAAABAwUHCQsNAAAAAAAAAAAAAAAAEAAAD4QQBRGE8PoVxgUAARAF Bg0AAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgABAAAAAAABAwUHCQsNDwAAAAAAAAAAAAAA EAAAD4SgBRGEYPoVxgUAAaAFBg8AAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcAAQAA AAAAAQMFBwkLDQ8RAAAAAAAAAAAAABAAAA+EMAYRhND5FcYFAAEwBgYRAAAALgABAC4AAgAu AAMALgAEAC4ABQAuAAYALgAHAC4ACAABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4Ro ARGEmP4VxgUAAWgBBgIAAAAuAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhGgBEYSY /hXGBQABaAEGXoRoAWCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAAAABAAAAAAAAAAAAAAAAAAAA AAAAEAAAD4RoARGEmP4VxgUAAWgBBgIAAAAuABIAAAAJa4RoAAAAAAAAAAAAAAAARk5aOgAA AAAAAAAAAAAAAAMtfAgAAAAAAAAAAAAAAABJZWp/AAAAAAAAAAAAAAAAEmYGFwAAAAAAAAAA AAAAAEYzon8AAAAAAAAAAAAAAACjVudUAAAAAAAAAAAAAAAA2gaQZQAAAAAAAAAAAAAAAFdf tgQAAAAAAAAAAAAAAADiHAoBAAAAAAAAAAAAAAAAtwx+NAAAAAAAAAAAAAAAACBTXH4AAAAA AAAAAAAAAAAyebJFAAAAAAAAAAAAAAAApFwQCQAAAAAAAAAAAAAAAKAzOVwAAAAAAAAAAAAA AACkXBAJAAAAAAAAAAAAAAAAR3EMNAAAAAAAAAAAAAAAAJwujBIAAAAAAAAAAAAAAAD///// //////////////////////////////////////////////////////////////////////// /////////////////////xIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD/QAOAAQAmEwAAJhMAAKBp6AABAAEAJhMAAAAAAAC2EgAAAAAAAAIQAAAAAAAAABcWAABQ AAAIAEAAAAQAAABHFpABAAACAgYDBQQFAgMEhwIAAAAAAAAAAAAAAAAAAJ8AAAAAAAAAVABp AG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAA AAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIEhwIAAAAAAAAA AAAAAAAAAJ8AAAAAAAAAQQByAGkAYQBsAAAAPzWQAQAAAgcDCQICBQIEBIcCAAAAAAAAAAAA AAAAAACfAAAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAAACIABAABAIwYAADQAgAAaAEA AAAAdUxLhoBMS4YAAAAABAAHAAAAMgMAADcSAAABAAkAAAAEAAMQJgAAAAAAAAAAAAAAAQAB AAAAAQAAAAAAAAAkAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAEgAAABAAGQBkAAAAGQAAAF4WAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB5EgAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAA//8S AAAAAAAAAB0ATQBlAGcAYQBjAG8ALwBIAC4AMgA0ADgAIABFAHYAZQBuAHQAcwAgAE0AZQBj AGgAYQBuAGkAcwBtAAAAAAAAAAsASgBvAGgAbgAgAFMAZQBnAGUAcgBzAAsASgBvAGgAbgAg AFMAZQBnAGUAcgBzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAA AAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACMAQAAEQAAAAEAAACQAAAA AgAAAJgAAAADAAAAwAAAAAQAAADMAAAABQAAAOAAAAAGAAAA7AAAAAcAAAD4AAAACAAAAAwB AAAJAAAAIAEAABIAAAAsAQAACgAAAEgBAAAMAAAAVAEAAA0AAABgAQAADgAAAGwBAAAPAAAA dAEAABAAAAB8AQAAEwAAAIQBAAACAAAA5AQAAB4AAAAeAAAATWVnYWNvL0guMjQ4IEV2ZW50 cyBNZWNoYW5pc20ATWkeAAAAAQAAAABlZ2EeAAAADAAAAEpvaG4gU2VnZXJzAB4AAAABAAAA AG9obh4AAAABAAAAAG9obh4AAAALAAAATm9ybWFsLmRvdAAAHgAAAAwAAABKb2huIFNlZ2Vy cwAeAAAAAgAAADQAaG4eAAAAEwAAAE1pY3Jvc29mdCBXb3JkIDguMAAgQAAAAADqVvoAAAAA QAAAAAD+bIRtSsABQAAAAADow35uSsABAwAAAAEAAAADAAAAMgMAAAMAAAA3EgAAAwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAA AAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rlgBAAAUAQAA DAAAAAEAAABoAAAADwAAAHAAAAAFAAAAjAAAAAYAAACUAAAAEQAAAJwAAAAXAAAApAAAAAsA AACsAAAAEAAAALQAAAATAAAAvAAAABYAAADEAAAADQAAAMwAAAAMAAAA9gAAAAIAAADkBAAA HgAAABQAAABMdWNlbnQgVGVjaG5vbG9naWVzAAMAAAAmAAAAAwAAAAkAAAADAAAAXhYAAAMA AAAxFQgACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAB4AAABNZWdh Y28vSC4yNDggRXZlbnRzIE1lY2hhbmlzbQAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEA AACYAAAAAwAAAAAAAAAgAAAAAQAAADYAAAACAAAAPgAAAAEAAAACAAAACgAAAF9QSURfR1VJ RAACAAAA5AQAAEEAAABOAAAAewAxAEMANwA4AEIAMQBDADAALQA2AEQAMgAzAC0AMQAxAEQA NAAtADgAQQAyADQALQAwADAANgAwAEIAMABGADgAMAAzAEMANQB9AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcA AAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAA FQAAABYAAAD+////GAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIA AAAjAAAA/v///yUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAD+////LQAAAC4AAAAvAAAA MAAAADEAAAAyAAAAMwAAAP7////9////NgAAAP7////+/////v////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAODlJqNtSsAB AFOomG5KwAE4AAAAgAAAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAP///////////////wAAAAAAAAAA BQEAoHyiQABsk0AAYQAAAAYAAAAAAAAAAAAAABcAAAD1GQAAZAAAAFcAbwByAGQARABvAGMA dQBtAGUAbgB0AAAAAABIAAAABwAAAGkAAAACAAAASgAAAAUAAAAAAAAAAAAAAGwAAAAaAAIB BQAAAP//////////BAAAAG8AAAAGAAAAAAAAAAAAAAAAAAAAAAAAADIAAAAGAAAAAAAAACIs AAA0AAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAACgAAgECAAAABAAAAP////8AAAAAAAAAAPgNQgAaAQDwTgBvAHIA bQBhAGwALgBkAG8AdAAkAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEA cgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAf///////////////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAEAAAAAAAAAEAQwBvAG0A cABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAASAAIBAQAAAAYAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAGoAAACIF0EATwBiAGoAZQBjAHQAUABvAG8AbAAAAGcAaQBlAHMAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABYAAQD///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAABTqJhuSsABAFOomG5KwAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////////// /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA AAD+//////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARhgA AABNaWNyb3NvZnQgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3Vt ZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --------------F545B0F04B0B159BF06C5EB4-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 9 12:29:23 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24171 for ; Thu, 9 Nov 2000 12:29:22 -0500 (EST) Received: from standards (47.234.32.16:1700) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2B9F@standards.nortelnetworks.com>; Thu, 9 Nov 2000 12:11:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 90835 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 12:11:37 -0500 Received: from emerald.telecom.sna.samsung.com (63.166.115.4:3154) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2B2A@standards.nortelnetworks.com>; Thu, 9 Nov 2000 12:01:35 -0500 Received: by emerald.telecom.sna.samsung.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Nov 2000 11:17:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <0C9947CED778D411B8BD0008C7FAA6420FAB50@emerald.telecom.sna.samsung.com> Date: Thu, 9 Nov 2000 11:17:58 -0600 Reply-To: Hai Nguyen Sender: "Media Gateway Control (megaco)" From: Hai Nguyen Subject: Question about Megaco Audit Value Command To: MEGACO@STANDARDS.NORTELNETWORKS.COM I have the following question about the Megaco AuditValue command: In section 7.3.3.5, AuditValue command, it is mentioned that if we set the ContextID to unspecified, and the TerminationID to all, then MG will return a list of all terminations on MG and the contexts to which they are associated. Since MG usually has a lot of terminations and contexts, the list will be huge and would not fit into one AuditAccept message. Does MG need to send the result back to MGC in several AuditAccept messages? If so, how does MGC know what AuditAccept message is the end of the list? Your info is very much appreciated. > Hai Nguyen > > Samsung Telecommunications America, Inc. > 1130 E. Arapaho Road > Richardson, Texas 75081 > Office 972-761-7703 Fax 972-761-7799 > E-Mail: hnguyen@sta.samsung.com > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 9 17:01:57 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24317 for ; Thu, 9 Nov 2000 17:01:57 -0500 (EST) Received: from standards (47.234.32.16:2571) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2FFD@standards.nortelnetworks.com>; Thu, 9 Nov 2000 16:44:09 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 92510 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Nov 2000 16:44:09 -0500 Received: from auemail2.firewall.lucent.com (auemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB2FFC@standards.nortelnetworks.com>; Thu, 9 Nov 2000 16:44:08 -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 RAA00473 for ; Thu, 9 Nov 2000 17:00:26 -0500 (EST) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id RAA00461 for ; Thu, 9 Nov 2000 17:00:25 -0500 (EST) Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id RAA03238; Thu, 9 Nov 2000 17:00:23 -0500 Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id RAA03221; Thu, 9 Nov 2000 17:00:22 -0500 X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Original-CC: MEGACO@STANDARDS.NORTELNETWORKS.COM References: <28560036253BD41191A10000F8BCBD1102AF3863@zcard00g.ca.nortel.com> <3A09A8A9.21F19DF6@lucent.com> <3A0AD53E.9503542D@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A0B1E2E.89EFE35B@lucent.com> Date: Thu, 9 Nov 2000 16:59:10 -0500 Reply-To: Troy Cauble Sender: "Media Gateway Control (megaco)" From: Troy Cauble Subject: Re: OCTET STRINGs in H.248 X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit John Segers wrote: > > Troy, > > It's not you being dense, this is underspecified. Thank you. I was starting to wonder :) > The intention of the OCTET STRING use is to have a general container > that can be used for new parameters defined in packages (signals, > events, properties). The package defines a type such as boolean, > integer. The encoding of an integer value should be done according to > ASN.1 BER (X.690), and the resulting octets are put into the octet > string. > > On the receiving end, you get an octet string that is not decoded into > an integer value by the ASN.1 decoder because it does not know about an > H.248 package that says that this is really a integer. I think this is the same as the "double wrapping" that I described in my reply to Christian. > The price that you pay for the flexibility of adding new parameters by > means of packages is the need to interpret the values for which OCTET > STRING is used in the application that knows the package. I believe an ASN.1 "CHOOSE" would've given this flexibility. But I'm not trying to change anything -- I'll be happy with any technique that's fully specified. I hope that statements in (or associated with) sections 12.1.2 and 12.2 will define how to encode these types for ALL packages. Not that each package will define how *it's* integers are encoded. > Something similar holds for the text encoding. There are some > additional issues with the text encoding because the octetstring of the > ABNF is really a text string and does not allow null characters. I don't understand. "octetstring" is not mentioned as one of the possible parameter types...(?) "octetString" is used for the SDP information in the text encoding, but I just took that to mean the UTF-8 SDP information. I do think text encoding of parameter values should be more tightly specified. > Something that we did not specify is which type of string is used inside > the octet string if a package specifies that a variable is of a string > type. It would be best to align with the strings allowed in the ABNF. Section 12.2 mentioned UTF-8 strings. I believe there is an UTF-8 string type defined in X.690. "Integer" and "enum", too, I think. "List" might be less obvious. > Cheers, > > John Thanks, -troy From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 10 07:56:22 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10057 for ; Fri, 10 Nov 2000 07:56:21 -0500 (EST) Received: from standards (47.234.32.16:3532) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB3938@standards.nortelnetworks.com>; Fri, 10 Nov 2000 7:38:17 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 95585 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Nov 2000 07:38:16 -0500 Received: from mars.hss.co.in (202.54.26.197:45612) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB3937@standards.nortelnetworks.com>; Fri, 10 Nov 2000 7:38:14 -0500 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id eAACsxC27295 for ; Fri, 10 Nov 2000 18:25:05 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256993.0045E185 ; Fri, 10 Nov 2000 18:13:17 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256993.0045E162.00@sandesh.hss.hns.com> Date: Fri, 10 Nov 2000 18:24:28 +0530 Reply-To: sgautam@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sandeep Gautam Subject: choosing of parameter value and audit To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, The text says that if some value ( lets say signal parameter value) is chosen by MG ( lets say it was overspecified) , then the descriptor should be returned in reply with the resolved value. What does it mean? Do we have to return the entire descriptor, or just the parameter value that was changed? Further , suppose an audit descriptor with a token for the affected descriptor ( lets say signal token) is present in the same command after the affected descriptor(say SD) . Does the population of SD as return parameter in response ( due to choose resolution) to MGC, gets overwritten by the audit information at the time of audit descriptor processing? { We might have resolved the value of a brief signal and by the time we reach audit descriptor processing, the brief signal might not be active on the termination. Further, some event detection might have caused invocation of embedded SD replacing the processed SD.} Also, if audit descriptor ( with signal token) was present before signal descriptor, we should send to MGC a list of signals that were playing before the next-in-sequence SD was processed. What happens when subsequently a value is resolved while doing SD processing. Do we overwrite the return SD due to audit descriptor processing? Thanx and regards, Sandy G From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Nov 12 18:02:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05107 for ; Sun, 12 Nov 2000 18:02:55 -0500 (EST) Received: from standards (47.234.32.16:2449) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4365@standards.nortelnetworks.com>; 12 Nov 2000 17:44:44 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 98997 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 12 Nov 2000 17:44:44 -0500 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4363@standards.nortelnetworks.com>; 12 Nov 2000 17:34:43 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eACMp9t27358 for ; Sun, 12 Nov 2000 23:51:10 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id XAA11729 for ; Sun, 12 Nov 2000 23:51:09 +0100 (MET) Received: from ericsson.com ([130.100.249.251]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id XAA28189 for ; Sun, 12 Nov 2000 23:51:07 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <3A0ECACB.311A955D@ericsson.com> Date: Mon, 13 Nov 2000 03:52:27 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Implementors' Guide - ABNF Case Insensitivity To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit G'Day all, I drafted some text about case sensitivity of ABNF in lieu of anyone providing some text. See below. Any additions? 6.36 Case sensitivity of ABNF and text encoding Description: It is unclear whether or the ABNF and its text encoding is case sensistive. The ABNF is not case sensistive. [Begin Clarification] Section B.2 ABNF specification The protocol syntax is presented in ABNF according to RFC2234. The ABNF and text encoding is case insensitive. … [End Clarification] Cheers, Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Nov 12 18:02:56 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05112 for ; Sun, 12 Nov 2000 18:02:56 -0500 (EST) Received: from standards (47.234.32.16:2449) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB436D@standards.nortelnetworks.com>; 12 Nov 2000 17:45:02 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 98998 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 12 Nov 2000 17:45:02 -0500 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4364@standards.nortelnetworks.com>; 12 Nov 2000 17:35:01 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eACMpSt27407 for ; Sun, 12 Nov 2000 23:51:28 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id XAA11741 for ; Sun, 12 Nov 2000 23:51:27 +0100 (MET) Received: from ericsson.com ([130.100.249.251]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id XAA28209 for ; Sun, 12 Nov 2000 23:51:20 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------EF392F2F9AE06B700ED90779" Message-ID: <3A0F09F1.49829988@ericsson.com> Date: Mon, 13 Nov 2000 08:21:53 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: H.248 Implementors' Guide Additions To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------EF392F2F9AE06B700ED90779 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit G'Day all, Attached is a zipped PDF file that contains proposed Implementors' guide issues that were identified last week. Please review and comment. Cheers, Christian --------------EF392F2F9AE06B700ED90779 Content-Type: application/x-zip-compressed; name="TD-xxx_H248_Implementors_Additions.zip" Content-Disposition: inline; filename="TD-xxx_H248_Implementors_Additions.zip" Content-Transfer-Encoding: base64 UEsDBBQAAgAIADRCbSkteAcn6jUAADlCAAAmAAAAVEQteHh4X0gyNDhfSW1wbGVtZW50b3Jz X0FkZGl0aW9ucy5QREatvAdYk0vTP0wNAZIQqjQ1hN7TSEFUQu+EIqKCEiD0EpKg2OkCAtKk CUgXAelgQ6VLly6gIE1EQEHs/Quo5z3neJ7v/zzP+3Jdy+7Ozs7Mzu49O787AVmSnoEqUg0F A/PIzs0/GAbzMFtIBAwB83f2AvNoaYF51M0ofu4MDxgSyaRaM/sGnj4MCg2mbnZwvx7Fxd+V wpyyZw+Yh86gUci+YJ5gaEzwYO6IA1IMCJgnB99wwkOBPOHaHk1EkfOSsXMsHo1xIqKx5Faj aFIvWKTVgB2ZPmnicr71HLuxjNFLmJCwsSyRpU7bBpXeH2lztVPbFRUFjuRnvTFNw6abRyZn hC954i6VLNqkBy85iMUZyPVwRnX4Yy9ZFM8bx1+zx0m2I6Vt7U4Ct4Hh/HCZd7YoUdN8G27S Y2eNpL52wZrydzIULMlXpIxyq/LA5WyQ3LxU+IIrJufaxxhOnst0JUfnlkdN04Kn7ulG6mac anPCSU53p18d2ThdpGmz4swWuKfAZlC0D8ta1V9vVCTqXWQWaaroi9go0+gzKD2BCjOXuT5h hndGZF5EJMxWtblHZwn1n7ORWtAmobLKAESWNppk5Kw3iygAsiQOz3WJwYvmsza5ikU018AS pRQ8XJMgJkYVxQVRUAkA58ANIpcONLkjPqo5xvmOzFVNW1Gsb6nKJXleBX92IotHfjyR9EWC qwWRpZPeRuokgsu0fXZD9axkwgQLBq0lROBWtO2i2FhxtQ+cvGzbJGEB4xI7mhMlQwR1kmSQ YN0kay45mSSG2V19gaSNKZMBGRdVA9/HXmKRs+XN2w0THM4K5LPmUzQ4BDCJkL7ZNl1874sh hQs6tY0HY/KaLw2KmYYqLH6sYz/NhTRL0bqMaRl2uIDtYqRcMulm00AryfTUfQirf71Ogtq+ UTmNtuJb3kjaV+czITOGlbmsacPv8MoCwEcfajGN0Q9DDowxzPXhIubb7a2xb1WF7N5l2qZW Wdr4SAL8TYWkrvEUpKbeHGN7zt6LFeohwFkTHCQdMNkX90+kqbEenMI86mEDVJ76qAacT5jW jBeZsqFzQEMPGTgEmZ+LmBSuLzIvMtOqPSZVifcUNgjRXfi0Z+xxqvgQMcZBwj0da5Kgw9p3 Inl2toTWtp/WymiHE0a54mYD3cAJQ/zvwElweoWl0mRIMP3oI7Goz3GHbjgKiRc9FE4r7Rdd NI1cOf+VmB4VFtShGVeg8FjTJ2O7RxjAXuV8fd+jt+evrwR2f2cxMKLSLvbE507iFVffeZ++ jxbandYiCSTmACbe1VzY/ZzHMCUgL9i70jRt2BrQAtRrGJeeZHHMo/AhvA/f8b3V3hkVQn01 G842Q1KO4Vs6ks0bYgYSGYDmw0SK07erQBkXlvUtV9LP3KnCYisuxPjrKqwiIi4suY0BXsKm d4EKPNq+hEMleXuJu1Q9r1KDDMbLUwrOMTyK2q6kVD0e3cD6l339Wogd+Z6l7OvNc5hNVmPk 4vAjFdPoIAntettMGN2GGtNeVmZgkn2xDRCmGslRwsnxTQj+mNp9Tb7p7U4OJ3a/YN/m9h2U eTaQzYmw3oBvSkv+3MJZbKEJr7bhH7r2OgYE0pU/8SWyga7M1ix4Dcq6t97gqd9+8OFRrw+E yI3U6UPjlChfA+i98fhCsoqJI//pPTk3cirzY75EqhLv5W/j5M8fAcWbGvDuSrsJyIjOhfiR GgDS0uKjeWDv1VD+qhLzbYXKAdHdb4uNOWOa0mVSQnmx3PcJaD67shnLYoVlrrAw+bx8ufMq MdzGQWnbgXR+Z2upI4CEKRV+TO6F1R24VswzOaHhAKzZq5Gw9DO9Jp0+tJd3FVsVOcGOtz3D reNNjbDminNet+M3jooqnXtTvZ8jP732sEvP8aZ61vyQKI4ZxF3qkPUCwyur2ireTHEU5lwG SgO2yBOgPcoFvaN0p1F9dpTAYJRPnkXiyCPNBrth6Z48PeM3d2/vH3kxKT5CQsbsSw6OeT1x fFbmAjEEXdDxjg1ddNK9KB+VBksN0baCFFF7Ip/FSk57aGo3TUd1oD6ZhBTsvMLSJq51Q/Nu s6+ek/vpgaFnHl0FdzRMFoQma2E5wjoJusDc0jz1W4U3PE/yaYGlUqE03kMgkjVIqrmbS3rx K1s0F2AUD+Wgw+1CUWKq5ISrkYiB1yuEJ4Alg7Sk0gleWfIu7hCRmlufBQ13cksdC297b4Gi ConWpkDIKd84oJ0eis8d8bBgmZtoaXEIkAZxyrl7jjTEYEe2cPOYScKcdU36vO4U1LW/0Dx2 q9vyzWtO1jOLDo+y6S/pD4jJRUvsqYATfhINxwQVvUp4bgkceiQCChnJ28YB8poYUPMVurN6 y5PPrsis1ORpRGdkaImP7Csjf3IhGpB0w0ZXEQeWBWEvPqJZhYGvNFFaRgEbjeI85rd1FnTG zvEenr4WV9vQ8LgwG0Y8pz71tS44GLnT6Xm4OuGYk8Gtuvx1j+6pJQ1AZX16eAqUP4TFHJSX tTozV1zSfFTxVgOqbKpUp9vvtaBfhNXtc4hnx9Omlhjqh98NYyW7veYOnhzR/JSSIZxMO54O nr3ElZLQK6pb4gNJP1URSR36wjMmr6jg2nn36Ptz63I77+kf4d/ZdTqDyEKtk2osjWwieqwp Hugk6OWE7Sq/7de38zYtj3f8Q4fzNRb/On1TqcNZVwPUAzGyoELJIzJO/QIzxn3HnhA9r3FH vTjMvTejE3ooYVyCPehYWpvf6IqZzHlExTZ/yl4wx0kfa5VyaxhDT2K0L6M2fUcfksMj3mOl 4qst6AyH6J2B6Vq++iGkfJ7Xax9Hj5f6wJZDk1G5SfuyDY4XMywGh1bbFWHrp/s7vUFSl/nD Z1qmqR8Pcuc1FgIGtPl5Zlz2ElvG16HaUB2oBbCbzxv52s0oOyUi4XbEuKOfCiSoFTx//FL8 izPqN7FPly8Z1cYjt+kYE/aK2ThcOBg87XD4SCXscZaneUC/kmlIal/pqdepNIuzDfKWenDJ TyuCexJtP5qvLIZfvvQaEt5s5W6z2HY9i7EjuffjmsH8FLvPzee81z8dU13JPtAUGC5HvG0p o9tpDHzNVXZiKfv1TQcYYT13uJU3sou1UGUb5b6uzPId1I3uxXqbE5P15h2Os7Nm8tBT9Oad F7hmtdQjU4++E6W8clRMjcUPVz0W7bZw2fiyTTvjxTcxk+01wzcqZvcI7HQbP5GTvzA/6kQr yGyJ/Pjk5PuHoXOy4fiz/PcF9T4fn9dYcunznnxHPhcmCPK1P5OMJOJh4QMxQPY776raJXFP NrKeKJ0bet5RO+k83Nu7LdCLa2dTu7Aq1Xx97zXQyZUzwrc/qcac+PAg9Lt/5PeuU80uCIjT gPPM+N5zixx8qw+VjQY9S2BOPpebXHeXiT43gMisq524v8JuYfdiQJO1IHO9IoRDR4gB3+H6 Er+7p1yLhJIhGXL2GwN4iBwID5dCSSu/umPOggAqdhUSs1gVwkWKXFFrWazakwJzTZLFkKB0 zhfXAKRc/YTCY5BD3M9WeOakeOEC8/GL1to+i+xslfpezON/8gE0LWYOlNu7V+7NWz6O9Qug S8rjI6DyG/OuHRd2AGb8PF3mILltYJ1QSDDjrT9qLf7LbFg4MHfBuSX2wUvYnKUbZ689lqux R31OltTtWCAEDC0HVQvwxBw9LT+Jz109UwiUZnHmMrTlMoAHVeVIBVO1w0E8wba16jNy7N0y 6oum59lU+QU4WApVy1Z1tZc5WIIgM8t88BrQzAgYFswLC+VmyeGecQA65XDnnt6GPPpe/mig qsm3UCpP8BPRykbgTJhEcDCPUwkQlgUMDuXRjuJxcuBuyuHRLgHmpnO3QXleveMOeCURnEmi ZjrJBC+Q0tg7tJYEtnFST0sV7uWpIMMRBJ7z5cegOfSqICfSIa71m9Ilutyk8+xdXz51cCzr YwL9VjhqBPYWOMJpZs/9jOVQ++QSjOYTmEeKzlnJLYNS5GJvl0fZ6yc5gqpMFeIeydEi5GpS J+8HyK/f46q5LDcQx5sUB6hJ2td/Vdk6myNJTwpV4vqyTrdNrdp1UHYQFewC1Xq6je9c+7YC n72DvftnGoBmRx88fS6AhKix3CI568DaBgAxpbLtcw4c4VqkNpgzz+NQ6OUOU7BZhcmqayDM F7XojGeb4WAJNwpQus9SzKe+Z3qmGMIWei+s6kohiLgi4rI2zjCHj8iTuowEEMDDgQucPDZk 7uXi0jlHNeghNX2qHAsJXIkAV4u+DguHo7O4qoXA1QNgtzdBhbf2z8TwwEqBsHQOwYSZ3BI+ NOn4larhK4VFT88Shkd30yd2G8ZyBxcDtQu5nY/vejavhSZxsNgGDYG4c8N2DSfvZenRCi7a g17kOZd5vAgAYwIIip/rL/zAbG6Bjy3AsdVCI1Ho/6Fj/oJObI9TKTB1EtmdwuyQyDSKHwOm 8ROpWFPo/oE0FwodtsVq4M8cQ2J/DpJo/i42FAYM9aO/iWDUdZkcTAF02BYE+kn9wx7sXxQb IGC/RBkgYbhfTRSM8KuJhiFRv9oYGBL9q60BQ2J+tbEwpMY/qML/IwIj/FcILOqGNzdUGBg8 GByqLEwQa2MZPC7qAxON5WxlbQqFu8UYx0QiWRr0EOLGzvIBLPnmuCwLd5sAM70RsGjsQrV9 tMAh9fTuohSdwgHSIaggUB9+gETcrWT5HNON6FA9EtvRzsWe2DhDIWznk2Xn7nxkfzluVqPr Kj7UHB4FERn2tG/x0czwYxlSAbkhxJpnEY1GkyZ4cf2IkeTEFKKCGGi2Koo0QlWTcDVYHz9s qpiaor/Kn+sx4gkX86idBMXGPIVFxhbedLiB5eQIcwfMO0YaxIAvWXy0ybOiknTlk40LxRs/ BeNHrVyFP3TU3KfUTvoe690xvaRw+7D6/p537JxjLWEGuol3lTVRXVEocd/pglOtXKBHInOc fTG20fUWy21q8uUS+NcxJpmlUN5yiblKDVPeBTG8ir3Hp0iPzwbbMFcFLaabpTgwD/Eltnu2 6akk+4leV1858aQ1TkZPtA34OT4+8irb4QyeaB2HxEgqCl6Uu3Qytrg4fzwGBwphicTFm5V0 aIKlg6Z47gIlPcKQnSTXT7156R5tkbExEth2yw09ScCSsqymxXDWCqyVmE7btpdc5ZdoLMXi IRnZSdsjmvvgUVAKbkn5BREQpXUqWhbRYx/f1xkeA+icDSPI1hjL5FxBzzcRFWNdgjoxcZ0D 02gONmCxPGyW5bJqbEGutmJ82EUndEsv5rto9YiR84W2bgl5CVnBN04XJjC1H70HZ3yLtM+J WO/VHZS6luHer7rkDb2HvZbmPXFdyYo+qBI3GlB2TLbW8wBr3bevU9d911wm00ZZJh+nvf7q O20v+J5qZdf6NcgRb8d9ou396cHwJ0HZ2TGP7FmIRNL57C4Dp2P0Q+fn30iSExUJspLfcat0 zwuTto3QxGoe67sZxfmwbkLsUeismmnzcI/eQJ2p3wvpvEvUxK4N1GExBcLQEZnhbmryEbB0 ujYirgA6hO4pqGjEgJ/nJuEgYQr9dZwhLG24uHmnbkRcM+eJVO/bA1N2sWEqZfYc7LkDPXaj LY271ufpgJiIEv3OF7ZSwf5w2Ys8YlfcQ7RzpGJiVc8o8egYZUmHS7zsa6YWnPnahOqB99aZ ZnxwdA7Jq12XlMmrb894cr326xRp+9qZgakcwRMSSKxh/KCVopzkdAn6y+wTqz2GYfEn8qi0 8M9imeFfTthr9Iqd2nE2OV7qu2Vt3AlPw+hpt+SzsxDtm7jbK7Vml18So0wmTleOflc99orl QAi7m6VUXyZHlN7ILMymzzhLIbLcJIZqDcpLrwPYfRM7iByT8rl24c6iD1Dc21KOo5SHnR21 KKwUCFh3yoxALIuGkSimTktQYknQsyluOx6/xGGOo42zbDqccmpaqTflUvViduExPs9Jd6M8 eNhgZN+qdeUbcnPGOlR/SFOwGDuw14g1V1M3sUQylOXGJ9YqBD64RY4guG7tUGCDsyKlhXFl CLcgKeCqdSUR0sbFMBDOryl4hwp0eocOixlPHggePlPCGx9szjXITH7nYkuIGXxebXF+F59p CrOf0uLgnJEOF8yFwkWJ3M1QWAQsSqiZasE9azwQ3pRF1mm8zU2bM7t9bnHNTEvutDfxcePo VZRTnfSpSoWUvfVPMdsKJDIuBK7V6uhzXpYsPCPXoKzVdQ/rLnmfA3A84RoDuCHSuwzInYrt bTDXulIge5KOXFQlPNxj+XjokuVzT3nuCe5tPmsoZTdvy48re5bgZy/V9p/oFyv+DK/nItXJ JFoCdhp4sK+f6rmbQHrHq8H3cUP/eYr4JUxKsQCbTpZeNklg3RlCQSrb1k1npcxoi7QI+lGj HVVai6PSplpcQoav0UfqRoqOFLxz7daH9Nclmz0PNoCXDJbodHslsTaibcOjRJOFQp/pZBuY XluA3UsTqNBJP+4bErGPE9Uv2mrkBpaKV7WrBbhZrZrv5dcqEGpJE54/RUM4NTRZPoPHkbQU pEe6ntvo6+5QHFDgzK1bvphc0T8XrADOi9QtnVycZfcIBEdT8UZVq0d6gXQ/qQhhXOT0Y+vW IxZSNXeL5tXEdRV8QPGPVwgCpi4DKny7vDyqD9zWtGyO1q2B5cqUmXocbhX1Bqk2QvHibyQy PkeA+b2mdkm3HMw2PezrW3/9nNwc9FLBUX/wkiYAOzd74XTOHiWjfgW6IM78+Fu9ujyh/Noj AikIwr3VaLEJztp9fPVuNxUkc7e32R4L8Qw7kGbRD5t7xlhD3eGTA4mTX9eZh2XPg0Oqb4p5 aK1KShy/t00rV9JU2ypEv3L3+KBoTlDwUr5EEeNZmuBBkXv8o7me+5sfI+pXGsslBW/cC5dJ vx8IyhyUWTqEFxqD9/JftOxqkNKg7Z7Z4EoZQQW2RDmNPn6sGVgRj5O7ieNzh/uIEanunE1h 20Wh2s+zgYbAPOMbz4ZVoKFBlkxYe8DBVGsU0kvqCfdr1RdwSlR8a3wzyCHuMoYzk/EVJ3Mz yU06JiCcbnV/KPCsafMxzR0tSpWQaCfB+pnHEnOT90AVUgJsLFUerF3CoC4Xc4fWkFLMxwzL D+B4r8bGkIRvl3vN96Iuz925BB3zgNXtY/cyuZKxXIIJSuU3WxxOTG49anLNKeTArbcOVe+d 6/b71h9R4Qwvpz+tesBtL2dKSuIP7Tx9TEKr88XNN9HoHZCQXTu+zQSOBTRrk7QgA69SZ7Qh IQO7988KKUQcUJZV/oCuQj4KPyCwy67TR7k401bIPsHb+cnqFGe94wKmKTbBGGwfUdguX9ie eubxi70mnnb5sqXx6epDzq7RKQ9HbUcuCTI4e7xYd185U5qTXHM6v+SuFaK9zUjIl3f2eD4p YcSltKpGPFQpzrLd5pnCiro/vbRoX9El2sxBdp0xctfI9fSWNHbMOVRex/g5Q+pd4CepjOGJ sw/WhPeWnIvbe2a36NvVutYJw5RsobjkSihxsdGFy6Wr5FPLPemlRpr6m5HseMSFvcs3lKLI dwOixHYa7z+tufh6T+vApSf8Kw/K8x3Lb1efrNz94pug9Oqu048z3ie4pZjxwWNn+23y020y 3h8Hq0LqWyR2AyfNuhf7NCtoFY/Ms98UxDY9WW5OZ0i0eviGNSdNX09P8jFWPAuOK6o89mlj Xbt7PfIMJLJxzEm7rmkJJA9UZetei1/3UG9Yc1ocbDlD49askdUxiGm7YlQ6KpPLyVJCXZjb Vzn3zX/5du50o6rf/qbFirVvHCzLJqEDHFyilU6DLDNDEO0OSO4khCoQtniHNS5Ks6mE01yl +OWJKxRIzPqONb0q75ZJ1AAIpKtix9KB4GLrgGl/f8BmgeDkGpCTacpphEK6ClQCojQbDT55 X8XHr1xkh9HiSjuM2cJjntmBemzvqH26TrrJAr27/z6oMYGfVXuKpUrPd6XJXucA0OIDKHc1 rP3UFJe9HXRyoWTDnRdBhydEz2UBYY8bOW2B+RDt8ndw2CDYrTGQWtfh9QFC7Q8oC+RnG1Bf fPNyUIJ/cfyONBew9CjJ3JH9aaiP9ySVpICIEjrmbAIISJlZVLicmPD6VeqRC/aXL2wT0xXI lc/P9RLNrfQVV9Ir4r4hhSx3LVWVMNkradX4vtR4O3+lxCI+Ww+f6xLpWt1wolV6h2zlDrfD p+YEd3I+2mkZYw0U+jj4smkFEcoSa1PaSCtRsQ0mhRnhUSV7PrfMeXI1C3TmRqh3e6naIyMZ tcZxYgv4D3IHJO+nvqIZSLVuk1DsyKux/ojMzJe/s/PqM1nLPVxcXTKDY7FJ3nICjGMovQVd 7YPL/nKeawrSy8RXVxSexcQmRShaO+egrBQ37LIsCbJD4dkCMZeql4PLJJQEzkqishWR7fIC 5UVAQHVNXb4R/86kjj0P6PK0ezJXOwx57GSKS2CtJoYv/WrCoyJKg77asC0pBZcYbCyVjpj2 J8gvqD2nrfdeOFwKNli26Cgty0e/3FGGEqrp9vGqWlRA72ZfHjL1HdtTxsXrS/3+UueT8gVl T606Xgi9wqHaBa0RlYnegNRYCJTV4suBTuXRi8Ns3hzSKmGkb9zwWFTuEiT3KbSsHV/Ftl6b sNtpwYfzJMB3ssPp/DYo8DMC5uFNhyJZ7LUfiLqWdlA/mTyYqXO9KlqlCh5AyD5/xu6a7hVZ I1d8nc/KNrAKYsqudD3yEWGGyOm1UUm1gKxeBKy6rfvzNJp2iaK7w64AIImm+Mi3u6LiO0h6 4Mhb+3tsuJq0GwN2tJfsFigDDvWa7gmTMUyYi3kjxuJuD2kaaoh11+GdnBa8LsDybNdA1tp5 Gqi4hUqq1XnDuF18dtfL9wCWx35Nz6DDefi5WP98JcKAF8hpcBs1NoWn5aXgYszip3G/j3xs Q9SXH7malkHBG8TkKewzuRjQONHcPkW99FlP/tfacxza50VGjrMp0+o8+XiCicKDNGryoAbi VlcZA5W7WK9/aqruNWu5x/ADqT1wAwxi4VMLBCWsptjk1a9MMETSQNrLoCE4asUWnBhzz6t0 ZGHo5GpLU/xQTzlEuxVWuOCGnvc7BGf7ZxxK+AOHovEaf6Lj/ldAFIX4t4Ao/nd0iEL8SyD6 f4I+Uah/Qp8o9H+CPhNGnNUk4sLZA4LnoKi/f/4XqwEFGbAt+eiVuAHOu7qwpnd6yiHb21v5 y2+ZHYPy8LraBCRo6+Ky4g1sxAaG/HHb9JHSJMx5dtE+zlZym4ozIcm0w4WYfsNTPexhmxCS I98ALxEnI3LSvNzRo95+3mkw2ylAXeKgdwtr7oKPmnhL6f6TYqnd4BB2Xxt8xOJ2bLS+NP/J FNpupyi9IoGrsPso2/TODtRE46JkEFRwqdgmN3iRQRA376Cnh7nCNMUsxYcVb3T4o3xi39QU YS8zykGzuuTeeF9p8X0nhA/J5C+rPQUSsp6ftaAMtsx++mAxfsv39L2Zk1/NMLne3Xc+Hn/7 Mm249eWHw4S7fmuPGpdvQlpTJcryumFre9d82FYrESqQ73sG2DsatUMYoLvqvWzCHFVrJ77z EB846LPoPohV5m2GxgqtNJ8f/rSO8Dxl9OW2FUNf9O6qDqBUybvlRqXsaoxSkmx0mEK0PKt2 FCreRcIZr9CtzZhTLDGt6mjptIFDpZszdcIiBXgsUorICdTSfHMeI4lzUrdNhHhcgibHwOhL Xpj6AlMvlHGY0QIiVtcFpAl+0fYNB3FBdBM42E/ajdW/OO82GWvu9BJ1PY8lUzqcneekOXBO 1FEJnsdy8IHUc0S0jayna1t6bUiwj3jfkA5NCQzCfEBjbVricVYFGhKG9X1h4Y/s2YCPcTgi S/gjbAF1eiz2xQsRRFwI+wlcfAF+AGpdINqiGe+DeeVhG1VvIbZnaMo5UUbQ3D5Jduitj5Bx msLjgkPsTq8troNHpVywZBpc/iBjacIn1kW7dW+9S7L3uaqHS09Mr/Tdpk2N1yV7hsH39Q3b 7GO9vXff1GyE18BhcqiDaN88dSUiXNRvB2JOiuWGEIC9yUmUN8bhrcU4eKAFGy8kHBbsNh5G N4CkM157zOIbkK429bASYUqJB11allxCx/AkWeBC5kfFM6ynjnnJpxZNOIwi6uhBoQ/B804r CuNC0lSMh0vwAm5AWuGRB05ItStmvG6969yV1hutZ+PeCZ54ckM151urVV/n88QXNzX2VZzT /PrUvmgK2501hN1FuQfCQwhjMyVRuXld16LaXa6CcLJn10ZKiO3zWM7PmbE4hWfXvNNOXK9C 59W/GI1gx1IxcclNLY8bCkoeY2K7+fh6bojslYRaZrVfaF7zTcmox9+mkNYdR72Nh4tO2yZT Dgb2ic5kwUOps1Naqu/yyWGigQoGb8bK6k88ET+UrRFiHspf61eTSi4BajfK7GyiLokpy1Ny 28RxCgb2abd1g59ezBIfy3834kHFVWZYRiLGJVoz74PMiHJsLJM3wd4txudjxAQXj4oTqRSn fmA+wPaD2A5XaUDH6Zs1xU53WgW+H5WKzgJULUrsMPLwUAlxwKDP3B3+2KxQPCbcxLKac/Gz vUORCD6M5nbo0RcEDxmqoL+NBMq5RFeOPC3TWEKz3qmna/xifbLjWItkmFdORLeQIodTJFCG BWU+8OVhBUBJtFWUYsJP+CDpevS2IGES0BY3CE9uCoZn+CvlTu4rzXA4Cdo1pG1dasfPUW5M mlXAUJyqTY1PRBUDweke9h09+/VAzS2r6cCrkDDFS8intwhytYcPSXEfDi2KvQooxGptn/Mg DtxiyaDEBCTML8cCMb2XbOyhFhPdp69obWgDZHewOx8+YqTptk+PIS0WauY26nnGh7tREbBP iNS3TjHxvaYsrvNdJ2nS0fSpW1ix3tibJIQCZ2nCfL9A2e44mYlUTsbqUPSpI4tZTxCvy9OG nidqyPE/1Hkz6WGu+ESNj/GmeKSUahJayjCiqSsVHT5te8D1CK/eRknSYsE+4GqM3Ftt1pql 1WzxStMu2b2GmKES2xQ/O3kTnvKLJ67uy7xvERXho/PmXVU+Rhi7ongyazQ3Cm783CHh+EyG xlyTzQlXE5BpgFLgjoNSpQDDaFZ4RbHXBXa2SuEJsnLN80YoZ1W4mC7hugJUTVMoNGWyn2AF aFC5q4/QtmsuslRR6OIUTRZxP78wYIrdE5okuFdnWy46QaZbwEFmWqhbBhrGq+EeYcDREPf6 Kd1iX18okCUP/GnC3QdutLtqaHuYMtE2iW3X9tTJrxLHd8DbDeIP6Kg0Vp4c4Q3uFGU/aKTd XILZFbGhLYxyXcrjITSMVTxm1ydNAAsQKFePHg7vh/5D21NN7ShwrF4SNL4J1sj4KN3wGXP0 SDMaIERe5oiM/WRTOm7vdzxzCvZA70n0/Ya3HV0ibENGligCytX15pNL78+UPf0OB8SPwU3f nFU94XsfvZPlQQ1X7IvTVte5eTnFzMSIAm9XzTCBz5Q+GHQnn5HjYz0nZCxcyxHnvUw3B49f 0dDydT0eEX1+qYBwxfkFcGqkD2QeXf0wqOpiv0tvmfPn9HKgnlxEWYXiQdteBmt8bwn4/gTc 45AERynNt77r046HaVe/am9UaEnH1Ek6oPG2Abfe47HhmlwIeyBM2grHOqVTaq51zFG8mjJx 0qZMRcUi8GAQtoiP0NQeL3ag5UmfQCqFXed7QWBfJhcO0odaIYiZV3jcEiuJO4cYuM5O3hNk KWivnHqe4dDVWi/u0+E5Or6Up5a6p+K8YYa5fmENAQugXTfz+/S5uA77gmCTl9x77UVh4Jig HUfF7IHw5IbalmP+pU8nxB81tRXEjcRVQFZx2RmxdbPd8OFDpq4qgc0bd5OfmEe99tc6d694 7KPyIc37rv3k5BvgGzeMznJQfUQc3g7VGXW3P5eTSeKP4ZmcwJePeX2wg7B637ZmTcGf2692 M65sIXr5KNZbm5hLl9JrV3Z3Wh4DQdMIIhEOVoeR8ntvfeyPUj6KF2eHV0WOWrx9tkC/KFwW fujBS5bFL+wKAiPtoccNtWtt9JeUYfTW6K6qvtl6LYmETshDtmfmU+WtBuxH7r9318wcHRnM 3y4ZWndOcdGuUQxKr+27/SB8AVcTQrEUMNQYlG1TKSsQzBksM7JXlV218c0CZj9Uq/RNvhNG fKc9XKZxpvrQty8RX4IzhcZOPvt0GTQZ/qB64p1wpawJI2/pCG/U04nB0rtZrZ+yTi43Zy0M f2s9cVL10VRUwPK7qTVgUg9i1tlIvQsor1b34VnSrZJFRbZTH+Pbeu8PfFxY/6TAc6C933QA 8mmtxmatBD4A+dyL+NKHf9nybXh5KdN/+Wul3xPedy977Mr4ON5JQ5r8X3LxOD27pjMke1A7 RuTwTEyvWwJJe7GD2+ylIkJtzk3KeO7tupPKgPVaVYxyftu3uG+6lXbJxlVPqlINdYB3QkuS WbzqXYDffcrVXNQKfBpqIpztYhsx2n6j8iUaZvbLpuUn3XLAfTxv8/l483mUq24B5nfsLRVa I3WsJZSqXz2avrJkWM4Bc0mR0uEF8UGeDQJqqu7GxGoaq7StwjpWfXn5q+7wRbvpI9neQi/x FEwbQcwA0kNSFtRMtn6louWpqrbp9aGJbp1HiZpc/IeTQfF5lnOXqg05+T5yd7Fy+LN1+uaU +y2bPEdIxZt9jY4QczHmGbzMqxxTkFjytsxOrsJMR9vrO3K72EAlx3z50xhO8XBl3upcpM7B 6wFXJanFstxc2wfbLlV3ThRNiLvMfKNYr83XSgw2JfO/F105XJRoT7RazLM6z298YecQHwCe q6m0nNk+3nYB+j1Uq9O1yYyUftggyH0uv6bJeaDESKrFJLObrWTN7AqnqSi1FKCwSlxlkRp8 iZROaZAehZ8/JuIHNSvbKIRFhb2clVvZLgs5KAO/VaVU93WQm5Pm1OWLlEuc38mfngA9JGdd LaZzq4dWnmNVhxCohQnEAGiV4tVrKqHVkhudOVZDT9voUsjtqlRHFaVRcR3Y2xoXYVShIaoL hnqlJODOi5pJFrisDHNR9wuQqZGTDYW20NQFvOfkYCQluF5Nx1mZJFmZRYeKwjNlvHyy1fLc LZWqw3yyST6Xh84jQwVGoNac3BqCtVbyaKxMmUy5Fcf0az0f2lvZKOOdqDVhPdiTxDXxjZt4 9mblVze30z4r1MapDl+UHCQT8rcJ8d+W4n8kZVO0g/8irkWny8auKxmqH3C3uqUifvieEppT c55zV/8rBMobjjK7So09MycvYL6GohhLuEImpXfxrknwPp07EXlW2zlfBq0qw/sQVaskLcQt I4jcA9fJRAojVpyLUAcUE2y7BMgwdDNmUAwrzbnHjxewWpGHYcPITAM9jGAtywBBsryQjmPc HqQLMAODxJC+LNYOol+fFEvuLkiuy9Y708M4i699q1nQruUyalTDTdgYuuqT0kN7ZMz/dLfN rfje60aolV0pOLGUXXjaqgxi8t5IXTGjVQ74YnfNc7Ohho6RYUTKBcIGu2md6u6hKwRGmhlj 1CT0uaZQu/mbK9vpXBbJYC1pPhLjrcrQFSuhJ2YFj98G2A4nFPFTo+TOO7+3WdFL6GzuOVVQ hpnVcXV/cYYThJBdxVaUze3zxqhXRGJ09M7q0AXVM5/HFy9XVAJ1st6oROYgbinN2V31oWNf SGOM5xHDJc9AueEXHJHDq0NKmB5rfE2+nk8Ci18CgBOwxpqIY+2HLceX58tDbdrrGjmD3bQn rYtEb12sW6XuGI1zcFKEYQ0bPizVOLEEAZ0KuQa0p0rHUtERSgx/a97AIyuneRGu19m1pPr2 yqeYoKv3cbmXeJYctPInWue6qr+YkeoW3n6U7Z7LbktfNJwNmIO2G6lpun5eev/qjdkwWEuo J6UwSZ6yp845si4/WSa0iPda8TrvYcO5tgZX2r/4QHcLQf4A0hp4/J/oyP8VkP4LCIb9CQXD /gyDYX/GwbA/A+Gf8PX/H4ejUP+AkzX+ESdj/12cDOJsDbkx4AULIcIGoiRFIDR0FGsBshfk AZOIjcyfDXfwIEjwRhaQWTqw+PNZsfnsCEy4LaA5opU/xckVHxLPwcaWBxVHhJOc+aWOi6tj si/K5o9Dm5zxSZYganNUf57xrihOwbCm4FwaLgt0RTpvQZuME+MA6Cr2dtAwWZDI1wnBq2Ts dt989uPp2nTN9Phz0tyxS5R6STBXckbh/aAc+77i5ICt79vGO2fMlojrp+tzthJkRAQ1Q8Aa bC9IoftUotsZiSHFOWLXRvrrN6aECjwbLnS6njw9UnFQY8gb9zpHHncUvGDk/MnP7Vl2x/jS mwKpwhjjsRX6m0P4B8fOzYwFHJWYvkxvhM18/rI7/oJyz8abt+92HvG/dPfLXf9Dri8KPFYy k+F99KWFO1VKaitE8OuctJC8GqoEfLaK9jKSeyjosmJesFthqRdbUHkEG3zyeoXKbdR2dGiB lkShVKZXQiGPURRUoVrUWbQg6lZQ0dW88wevSsUwPMqVdXIHLlbNNy3dVW/Rdngpr5u+1KMe cF4rU4EfdQKqGDWHyezi8fEQ7QrRXsKgemYeY1VaQ5uqVc6jXjZW+hTACSifcgccD+0RpPYa al1cpFcQ7vGl9TU8UwwgqH1VoBP5ZVIOvBo0LlWrIjqNVQ04OHNTLSxLCBuLXl/FVBdAxy/G bwQ9rg0H2YjeR7EVyHSjetv97a1MOEXFODt7A42lU8qN3QBSwf5YveVhlmZELBoqwsFevtgw alP1ZH91eQ/0rvmK6Jo9KC9QSInTzvWie2eJY6kQd1m+HaFcV3QIvT/M9bkfj4symCwtcNtg W/dQy3dddfqpecZD9K2Omoqelrf7ZHUb1I9NoxWcRLkQb9WPA4g1+Ur6vDnKAWMiwg92z3vP PPU7MsvyGDePniHaU97LuaIOpeePo0HSJROKi2Gq5w0PCGh1FB94rZov+jRA/2PYkXnzfrRa CEBW8bFNS/c2+SA1SG84N6TgXM9Fu47amX1KUzYVLhdtURfYRbtver7bnWxqeFzESHK51MNL su3YndPa9kLbedWsePcRLG3ZA/WtXW7cbc8BFXgtaEXMihzLqSRCiQdj62+0JhwmxuJOSIdk Z598aOa7e+8AFjKRK6ubu0wAP9zjGMPdUpIux8G+XfeuyUm+A+TuEwDWO5As8M6r1LqsuMmD xDSJVGXToB41jxDAx3tqjo6+uYs41AhuSvriGGHq7mgixZogUNoVc+kbgbs+MnNghqxrTwY9 XVVjC14UZz9pAgqh9otpdxw2dS7yBCsWI/PfjfOWUZxfHL8ps9E72JtL4YxvTmSXv5vpWM5+ +EXEtcqZ3gOXLhmAqnyLboXaDWwT1DljngvlOHfwSeoMmYMVIx2ObcsSyAiGsDbd4tLFumt7 rR+Fzb66GqFEfdhoEvw04T4mtxXopMcj69m8D9BwdPtoumuIp7V80g29HPIbWQuZkibdgV57 du9P1mBz4zDA/m0hCTjXPo+mdDQPpTWAP9pge6eCbAQ/m7Y/ZPbiBXQgv8Ccpzf46YvsIvyU 3GW6oPEG9zcjHfxqaoG84lXuDbao0C+HFb08S0vu1rzr4xb7dF01bkqk9OJAck+ZgN3L3dM3 5aR4hTLET7GMlssNDTxNeR5EV/OpTSqJSs5kK1fp7kWkFjtQZPLIKuRwJCBhXNy+Zc7OIpxw rb2xvDVL1nOQ7LK7wew9JQhzvqL9KjwqQzDTyDWHp6RRyZDW5DifaG+LQBsbZpb0kJzBa4Pd Sa0KYrIzgSb0GmCRxrCypHR1pHVnPOqqc4zsradpqI/nr5RoST5k2GOA+1zZQxl1Q6y1uwF1 z8K8TloOfpwklHCkhjm5W5dykmQUGF8Fhkr1iXnDVzW4WXYmX97XTCXI1etNXKQk7lMiDwD2 xV+7/Dpg/4Uib2nhhqKH7GSrePIrg/vYbbAFIR9lzgN7OIIHk22uHbEGn8W/7b5j7/LaGYoS lAPab5MKm4VfOLGTtUio4KprVK1Vt6d5nsn2VHy8mFW4vUGqcMOYiF384HNZI6CYVEndqE1q EBP4K2U/jDnt1KXJV1YPXbVdTjF8yS1a6lYxZ8+u71Shw13iXlomrtROhZq7Saehlu3yvRnm b4erbTcaw2i4wIEQ4VtvRQomaDinSuHVxut3Z+0+X7LxOl4LSEsf274rbZ+2b4j0w403O9Mo 9sbXjtz8APm0/9BasF/9k3upPC/sYl44r198Vt1xnX361nyk/0vI7dyxDvKulWPq4kK7gqe7 k/NB5+S/XgK2bfeYqkl276YSUpEn7OUGtEVaoBTQ848kLrjtZCvV8Xp4887EOpVTwI9wudz+ 8qy2EKfyRKQ0BSZulKXrFqOAa7CTm2yC84FkNFIPz67CB4o3uEdti+rB0UtmwofJrbDTViak hAmng3Hx1okKNwaKa3yocUX56TL3A7ARVTEHiQD9zmU+WZvy9FDU8XrpwNQQZ8kKE4tm1n9O Mf74jhYSr/Gnd/UozP9BivFvpRLqBjgYCvfv5xX/8P4d+w+2bprB7NgEOjO2+ra0QMrmCJNm QfbdZEAwmzpkOmXLYHUizZPso6Lj7+PKJOv7MdMPTz93mPp+Tz+iH93zF+GvenH/lV7kX/Ta HPd19vfZyn5odIauB5kGQ29ymJF/9lCb28K0w5XhQYcdgmERCCYJAUOj0TAc06MazL4GhgDD b/ZxeBgGTdga2yy/xjb5f9XMrWVybY38G2WTd4ufOftXAfNgMJitFo6Z5GGxuB81crMgYTgs mmkjeou2aQMWjfwxjsfC8Pgfc5ieY/7GYfEwHAYJ09DAwjQIP2ZjCYitFWyOYTEaMBxBY4u+ KQmP/bEqrAaeKeGXhZvyf1mGIWC2ZmswE2TMpjSmHWgUYav+YwU47NY4U8IvCuqHhE2urdlM jk3PblqMIfyqmZLxTH8wNW7WP/ywuRf/m/J/KgHFtA6D27IMubknP88GTgP9l4JEYJjZPh63 tdzNelMEc+E/j8qm2345ZlPE1sKxiL8cgC0ViC296B8NpgzmpuBRP5y1uWmbkrc2GPuD/qu9 KfOfCvNIINH/w8E8BpsFv1lQ6D8O79a2INA/Ff/zQpgGb+75LxE4/I/dROMx/1i2FvizME82 8/emNzcloHCYreX8Kv+ehM3Zjj/DoB6F7kLzpDL8abB/+FQS/y+ix//M+inmR9z4n0DhQ3an w7A/B3V0/IOYYUF10z0IZrxlqt/akk0bzD3pdGbQ2oodm4dhMy4xKL52MALyZ9PoR9OYQfbx dCH6uftQYJtcumSqEcXT3YOxJYtJsP/ZxW31iHSXzQvg59imvZtdxBakI2/Fzc22OTnoh+af fMSjf7bkz54g/FdxFPWXOGrr6UuhW1COWfv7kv3+/RCORP1XutG/3x3/gU70f6UT86/X+x/e W0jMf2WAxv/DgB+n6D8wQ+O/MgP7FzN0mbmHJ4XGNOTfV4z67y5u3L9IGP7Tdf9x5A4xUyo9 A6YqShADtvnE/uL4q2NMPV2ZN/+PfAn5I1PaegPErH4QHbcSpECmVZi/5Gr0zaeQ4upJ/hEj NgOEBjM245mB0/FvW/EXhbrMHHEzaCmYe7rQ/On+bgzYfn+aK0zx15inv58emUFhMvj7uZKP q2ymdhb+Rym+zhTa5h3J1ITXROI2+W09GcygomCrpxoUFHTECIXBHzH2pfpQfJkhw59GP0J0 dfXclEffZCYGMjw29ep60DzpDE+yH8yQxhS7NcbMCl0DXZjyFYhMo5zJDBjTd/tpnpuvjNBq CBTMjTmT6XdX/2Nb/KaU48eYRtNhCoo/ttWL4sLY6vx54X99FLec9kdi+8ORumTm9vq7bwU6 N3KgD8OQRj4OQ/0M6L+I1oY6MBiK8A/vvP4I84eYonw2J/9Utt+DaTvJ35O5bYcQagQNBDMp hiHVEHgCcmtHDcm+vmQYQg2FweJ/psZ/OiIowl/kMvX/R2IP/ZT712rr0iAzaJ5BmwwYNBa5 OYLazLnVEEhmboRQQ+M1Nok4JHazhyDgNntIDHqzQmAR2K0xDPLXAfuTxUE0ihuYh3m3MqM/ 4o8fZjqngdaAuf2kITU0cExtWyN+f9Awm178Gw2/efj/QkOgURqo3+dif6OhUYjfdKDRqN9o mM1s6O80LA73d70IBAr5uy2/28zMHBG/0QibfybzN5sRmN99gMQjftOBxv19bQgs4XcaGoMj /M6H+bt9CByCme7+TS8Cj9f4jQ+JJ/zOh/3NV2imF/5OQyKwhN/5EL/vLxrxmzwmSviNxsy3 /iSPQSN7+lBoPx8FG88TlK3jpm7t78+A/fo+lrGfmz/s1z9nMNaDHdIiYMgEF2eKmwYC7eKG RiKRLgiUK4KMQ2NxbmgXvNue/zeH46931WQa48dJR2KReOaVISurb2kA5vn/AFBLAQIUABQA AgAIADRCbSkteAcn6jUAADlCAAAmAAAAAAAAAAAAIAC2gQAAAABURC14eHhfSDI0OF9JbXBs ZW1lbnRvcnNfQWRkaXRpb25zLlBERlBLBQYAAAAAAQABAFQAAAAuNgAAAAA= --------------EF392F2F9AE06B700ED90779-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 13 00:43:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04905 for ; Mon, 13 Nov 2000 00:43:11 -0500 (EST) Received: from standards (47.234.32.16:3115) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4421@standards.nortelnetworks.com>; Mon, 13 Nov 2000 0:25:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 99239 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Nov 2000 00:25:04 -0500 Received: from hindon.hss.co.in (202.54.26.202:40092) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4420@standards.nortelnetworks.com>; Mon, 13 Nov 2000 0:25:03 -0500 Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id eADGAOa12157 for ; Mon, 13 Nov 2000 11:10:44 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256996.001E2ABD ; Mon, 13 Nov 2000 10:59:30 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256996.001E2970.00@sandesh.hss.hns.com> Date: Mon, 13 Nov 2000 11:10:40 +0530 Reply-To: sgautam@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sandeep Gautam Subject: Digit map completion event To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi , A digit map becomes deactivated when a DM CE event is generated. sec 7.1.14.4 Does it mean that we can flush this event from the active Events Descriptor at the MG? Is the recognition and notification of DM CE different from other events notification and detection? regards, Sandy G From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 13 00:50:12 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06471 for ; Mon, 13 Nov 2000 00:50:12 -0500 (EST) Received: from standards (47.234.32.16:3115) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4433@standards.nortelnetworks.com>; Mon, 13 Nov 2000 0:32:01 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 99264 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Nov 2000 00:32:01 -0500 Received: from hindon.hss.co.in (202.54.26.202:40400) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4432@standards.nortelnetworks.com>; Mon, 13 Nov 2000 0:31:59 -0500 Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id eADGHn212436 for ; Mon, 13 Nov 2000 11:18:04 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256996.001ED95C ; Mon, 13 Nov 2000 11:06:57 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256996.001ED846.00@sandesh.hss.hns.com> Date: Mon, 13 Nov 2000 11:18:07 +0530 Reply-To: sgautam@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sandeep Gautam Subject: Digit Map deactivation To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, in section 7.1.14.4 it is mentioned that DM becomes deactivated when DM CE is generated. Does the reverse also hold true? If An ED containing DM CE is disactivated, ( say because of new ED arrival wiht or without DM CE) , do we need to generate a DM CE with current dial string and no termination method( simillar to audit value processing) ? Or if some termination method has to be specified what is it? regards, Sandy G From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 13 02:19:52 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29830 for ; Mon, 13 Nov 2000 02:19:52 -0500 (EST) Received: from standards (47.234.32.16:3528) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB447F@standards.nortelnetworks.com>; Mon, 13 Nov 2000 2:01:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 99355 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Nov 2000 02:01:39 -0500 Received: from hindon.hss.co.in (202.54.26.202:43433) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB447E@standards.nortelnetworks.com>; Mon, 13 Nov 2000 2:01:36 -0500 Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id eADHlK815777 for ; Mon, 13 Nov 2000 12:47:41 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256996.00270A68 ; Mon, 13 Nov 2000 12:36:25 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256996.00270A05.00@sandesh.hss.hns.com> Date: Mon, 13 Nov 2000 12:47:37 +0530 Reply-To: sgautam@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sandeep Gautam Subject: DM completion event To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, if an event descriptor containing DM CE gets deactivated due to say Event buffer control property becoming lockstep and subsequently one event being notified; do we need to deactivae the digit map? will it become activated if the Eventsbuffer control property changes to off (and as no new ED has been specified, so the deactivated ED becomes active)? Regards, Sandy G From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 13 02:26:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02854 for ; Mon, 13 Nov 2000 02:26:54 -0500 (EST) Received: from standards (47.234.32.16:3528) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4491@standards.nortelnetworks.com>; Mon, 13 Nov 2000 2:08:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 99380 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Nov 2000 02:08:54 -0500 Received: from hindon.hss.co.in (202.54.26.202:43604) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4490@standards.nortelnetworks.com>; Mon, 13 Nov 2000 2:08:52 -0500 Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id eADHsgS15935 for ; Mon, 13 Nov 2000 12:54:58 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256996.0027B50A ; Mon, 13 Nov 2000 12:43:42 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256996.0027B4C0.00@sandesh.hss.hns.com> Date: Mon, 13 Nov 2000 12:49:26 +0530 Reply-To: chassija@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Chanchal Hassija Subject: ADD TermID = $ To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello, Sorry about regenerating a thread on an old discussion. But do we have a consensus on this that ADD TermID = $ means that ADD is for an ephemeral termination since the protocol also says in 7.2.1 " For a termination that does not yet exist, TerminationID is specified as CHOOSE in the ADD command" And TermID=$ is the only way in which MGC can specify an Ephemeral Term in ADD command. Because it is the responsibility of MG to allocate a name for ephemeral term. Thanks for your time Chanchal... From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 13 02:31:33 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA04834 for ; Mon, 13 Nov 2000 02:31:32 -0500 (EST) Received: from standards (47.234.32.16:3528) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB449F@standards.nortelnetworks.com>; Mon, 13 Nov 2000 2:13:18 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 99399 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Nov 2000 02:13:18 -0500 Received: from hindon.hss.co.in (202.54.26.202:43694) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB449E@standards.nortelnetworks.com>; Mon, 13 Nov 2000 2:13:16 -0500 Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id eADHx7w16036 for ; Mon, 13 Nov 2000 12:59:22 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256996.00281181 ; Mon, 13 Nov 2000 12:47:39 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256996.00281059.00@sandesh.hss.hns.com> Date: Mon, 13 Nov 2000 12:53:20 +0530 Reply-To: chassija@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Chanchal Hassija Subject: ErrorDescriptor in Notify To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello, ObservedEventDescriptor is a mandatory parameter in Notify command as per protocol. And it can't be empty also as per grammar. So, if MG has detected an error which it wants to Notify (using error descriptor), how can MG do that if the ObservedEventDescriptor is empty. Thanks for your time Chanchal.... From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 13 06:04:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA16902 for ; Mon, 13 Nov 2000 06:04:46 -0500 (EST) Received: from standards (47.234.32.16:1772) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4585@standards.nortelnetworks.com>; Mon, 13 Nov 2000 5:46:16 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 99705 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Nov 2000 05:46:16 -0500 Received: from hindon.hss.co.in (202.54.26.202:49851) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4583@standards.nortelnetworks.com>; Mon, 13 Nov 2000 5:46:14 -0500 Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id eADLWJv22294 for ; Mon, 13 Nov 2000 16:32:20 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256996.003BA3AE ; Mon, 13 Nov 2000 16:21:25 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256996.003BA361.00@sandesh.hss.hns.com> Date: Mon, 13 Nov 2000 16:32:37 +0530 Reply-To: sgautam@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sandeep Gautam Subject: signal suppression with DM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, according to text of 7.1.14.7 "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" Does this mean that event detection is enabled for events that may not be part of the DMAP, but are defined in the package. For ex if dmap was {011} and the satrt timer is very long, and before the start timer expiry 2 is detected; do we stop the signals that are applied.(if KA of DM CE is off) Further if the DM CE has some embedded events/signal descriptor, will that descriptor be invoked in the above example? (remeber no partial match has been reported till now as the sart timer is very long) If an embedded events descriptor is activated, will it cause deactivation of DM CE? thanx and regards. Sandy G From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 13 08:27:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01171 for ; Mon, 13 Nov 2000 08:27:48 -0500 (EST) Received: from standards (47.234.32.16:4815) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB460D@standards.nortelnetworks.com>; Mon, 13 Nov 2000 8:09:33 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 99886 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Nov 2000 08:09:33 -0500 Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB460C@standards.nortelnetworks.com>; Mon, 13 Nov 2000 8:09:33 -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 IAA26078 for ; Mon, 13 Nov 2000 08:26:01 -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 IAA25802 for ; Mon, 13 Nov 2000 08:25:47 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA26259; Mon, 13 Nov 2000 14:25:42 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA26251; Mon, 13 Nov 2000 14:25:41 +0100 (MET) X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <65256996.0027B4C0.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A0FEB83.8542DBF@lucent.com> Date: Mon, 13 Nov 2000 14:24:19 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: ADD TermID = $ To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Chanchal, I don't think that it is as simple as that. If I have and ADD $ and the parameters of the command apply to a TDM termination (e.g. because the TDM circuit package is used), then the MG should get a TDM termination from the NULL context rather than creating an ephemeral. It seems to me that the current text in 7.2.1 is overly restrictive in the use of CHOOSE in Add commands. See also the message that Christian sent on implementors' guide additions for a change proposal. Cheers, John Chanchal Hassija wrote: > > Hello, > > Sorry about regenerating a thread on an old discussion. But do we have a > consensus on this that > > ADD TermID = $ means that ADD is for an ephemeral termination since the protocol > also says in 7.2.1 > > " For a termination that does not yet exist, TerminationID is specified as > CHOOSE in the ADD command" > > And TermID=$ is the only way in which MGC can specify an Ephemeral Term in ADD > command. Because it is the responsibility of MG to allocate a name for > ephemeral term. > > Thanks for your time > > Chanchal... -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 13 08:51:27 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11486 for ; Mon, 13 Nov 2000 08:51:27 -0500 (EST) Received: from standards (47.234.32.16:2296) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB465B@standards.nortelnetworks.com>; Mon, 13 Nov 2000 8:30:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 99989 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Nov 2000 08:30:38 -0500 Received: from hindon.hss.co.in (202.54.26.202:53873) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB465A@standards.nortelnetworks.com>; Mon, 13 Nov 2000 8:30:37 -0500 Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id eAE0Giv26091 for ; Mon, 13 Nov 2000 19:16:44 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256996.004AB071 ; Mon, 13 Nov 2000 19:05:48 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256996.004AAF0A.00@sandesh.hss.hns.com> Date: Mon, 13 Nov 2000 19:16:58 +0530 Reply-To: sgautam@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sandeep Gautam Subject: deafault value of mode To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, What is the default value of mode? Can it be provisioned at the MG? The text in 7.1.7 says "A new setting of the LocalControl Descriptor completely replaces the previous setting of that descriptor in the MG. " Does this mean that if no mode is specified in subsequent commands from MGC in the Local Control Descriptor then the mode specified earlier becomes invalid? If we take the exapmle of Automatic Gain, then if some LCD contained ec/gain = 2 and a subsequent LCD does not contain ec/gain, then the MG is supposed to forget this value " If the MGC wishes to delete some information from the existing descriptor, it merely resends the descriptor (in a Modify command) with the unwanted information stripped out. " What does forgetting the previous value set by MGC mea? Does it mean that the value of Gain reverts to the value as provisioned at MGC (say automatic)? Does the same logic apply to mode? If mode is not specified in a subsequent LCD and the provisioned value for mode at MG is inactive, will we make the mode inactive;-) what happens on subtract? Thanx and Regards, Sandy G From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 13 10:48:56 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01308 for ; Mon, 13 Nov 2000 10:48:55 -0500 (EST) Received: from standards (47.234.32.16:2141) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB46F2@standards.nortelnetworks.com>; Mon, 13 Nov 2000 10:30:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 100190 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Nov 2000 10:30:42 -0500 Received: from ties.itu.ch by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB46EF@standards.nortelnetworks.com>; Mon, 13 Nov 2000 10:20:41 -0500 Received: from ericsson.com ([156.106.209.40]) by ties.itu.ch (8.9.3/8.9.3) with ESMTP id QAA09495 for ; Mon, 13 Nov 2000 16:37:05 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <3A0FE14C.33A1428C@ericsson.com> Date: Mon, 13 Nov 2000 23:40:44 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Additional Implementors' guide issue To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit G'Day all, Another correction has come up. FYI. 8.x Annex C USI Correction Description: H.248 Annex C lists tag 9008 as being for the USI. However the values only represent the User Information Layer 1. The whole USI value should be supported and the layer 1 protocol. Reference: Editor [Begin Correction] Section Annex C.9 Bearer Capabilities … layer1prot 9008 5 BITS User Information Layer 1 Protocol Reference: ITU Recommendation Q.931 Bits 5 4 3 2 1 00001 - CCITT standardized rate adaption V.110 and X.30. 00010 - Recommendation G.711 u-law 00011 - Recommendation G.711 A-law 00100 - Recommendation G.721 32 kbit/s ADPCM and Recommendation I.460. 00101 - Recommendations H.221 and H.242 00110 - Recommendations H.223 and H.245 00111 - Non-ITU-T standardized rate adaption. 01000 - ITU-T standardized rate adaption V.120. 01001 - CCITT standardized rate adaption X.31 HDLC flag stuffing. All other values are reserved. ... USI 9023 OCTET STRING User Service Information Reference ITU Recommendation Q.763 Section 3.57 [End Correction] Cheers, Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 13 10:53:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02717 for ; Mon, 13 Nov 2000 10:53:07 -0500 (EST) Received: from standards (47.234.32.16:2141) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4703@standards.nortelnetworks.com>; Mon, 13 Nov 2000 10:33:35 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 100216 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Nov 2000 10:33:35 -0500 Received: from hvmta03-stg.us.psimail.psi.net (hvmta03-ext.us.psimail.psi.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4702@standards.nortelnetworks.com>; Mon, 13 Nov 2000 10:33:35 -0500 Received: from dev_4 ([38.150.216.6]) by hvmta03-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20001113155004.CCSB24415.hvmta03-stg@dev_4> for ; Mon, 13 Nov 2000 10:50:04 -0500 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 V4.72.3612.1700 Message-ID: <000e01c04d89$76e71d50$70d8a8c0@dev_4.us.radvision.com> Date: Mon, 13 Nov 2000 10:50:36 -0500 Reply-To: delbert@radvision.com Sender: "Media Gateway Control (megaco)" From: Dan Elbert Subject: Use of CHOOSE To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Can more than one CHOOSE termination id be used in an action? Foe example: Context = $ { Add = A4444{}, Add = $ {}, Add = $ {} } If this is the case, seems like we can have some ambiguity, for example if we have a topology descriptor in the action using the A4444 and $, how can we know to what $ refers ? Dan Elbert RADVISION From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 13 12:36:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12232 for ; Mon, 13 Nov 2000 12:36:31 -0500 (EST) Received: from standards (47.234.32.16:3416) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB475F@standards.nortelnetworks.com>; Mon, 13 Nov 2000 12:18:19 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 100321 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Nov 2000 12:18:19 -0500 Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4752@standards.nortelnetworks.com>; Mon, 13 Nov 2000 12:08:19 -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 MAA07301 for ; Mon, 13 Nov 2000 12:24:48 -0500 (EST) Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA07287 for ; Mon, 13 Nov 2000 12:24:47 -0500 (EST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Nov 2000 12:24: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: Date: Mon, 13 Nov 2000 12:24:40 -0500 Reply-To: "Griffeth, Nancy D (Nancy)" Sender: "Media Gateway Control (megaco)" From: "Griffeth, Nancy D (Nancy)" Subject: use of CHOOSE To: MEGACO@STANDARDS.NORTELNETWORKS.COM John, We are also having some trouble with the use of CHOOSE. If an Add command gives the properties of a TDM, how do we know to use a termination NULL context? Maybe that's a no-brainer, but it seems more difficult in the general case - how do we determine, given set of properties in an Add command, that the termination for a wildcarded ID should be ephemeral as opposed to using an existing one in the NULL context? Nancy From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 13 16:31:25 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00423 for ; Mon, 13 Nov 2000 16:31:25 -0500 (EST) Received: from standards (47.234.32.16:1476) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4884@standards.nortelnetworks.com>; Mon, 13 Nov 2000 16:13:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 100736 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Nov 2000 16:13:21 -0500 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4883@standards.nortelnetworks.com>; Mon, 13 Nov 2000 16:13:20 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA08011; Mon, 13 Nov 2000 16:29:48 -0500 (EST) Received: from stl-server-01.pit.comms.marconi.com (stl-server-01.pit.comms.marconi.com [169.144.36.27]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA17588; Mon, 13 Nov 2000 16:29:49 -0500 (EST) Received: by stl-server-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Nov 2000 15:29:49 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6EA03@whq-msgusr-02.pit.comms.marconi.com> Date: Mon, 13 Nov 2000 15:29:47 -0600 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Implementors' Guide - ABNF Case Insensitivity X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Add the caution that the SDP is case sensitive as per the RFC. Brian > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > Sent: Sunday, November 12, 2000 11:52 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Implementors' Guide - ABNF Case Insensitivity > > > G'Day all, > > I drafted some text about case sensitivity of ABNF in lieu of anyone > providing some text. See below. Any additions? > > 6.36 Case sensitivity of ABNF and text encoding > > Description: It is unclear whether or the ABNF and its > text encoding is > case sensistive. The ABNF is not case sensistive. > > [Begin Clarification] > Section B.2 ABNF specification > The protocol syntax is presented in ABNF according to RFC2234. > The ABNF and text encoding is case insensitive. > ... > [End Clarification] > > Cheers, Christian > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 13 18:13:21 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29056 for ; Mon, 13 Nov 2000 18:13:21 -0500 (EST) Received: from standards (47.234.32.16:3757) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4970@standards.nortelnetworks.com>; Mon, 13 Nov 2000 17:55:18 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 101033 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Nov 2000 17:55:18 -0500 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4965@standards.nortelnetworks.com>; Mon, 13 Nov 2000 17:45:18 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eADN1jZ18704; Tue, 14 Nov 2000 00:01:45 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id AAA17446; Tue, 14 Nov 2000 00:01:44 +0100 (MET) Received: from ericsson.com ([130.100.249.211]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id AAA00511; Tue, 14 Nov 2000 00:01:42 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <65256996.0027B4C0.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A103D8C.834D9A60@ericsson.com> Date: Tue, 14 Nov 2000 06:14:20 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: ADD TermID = $ X-To: chassija@HSS.HNS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Chanchal, You can also add a ephemeral TermID = a/b/? Christian Chanchal Hassija wrote: > > Hello, > > Sorry about regenerating a thread on an old discussion. But do we have a > consensus on this that > > ADD TermID = $ means that ADD is for an ephemeral termination since the protocol > also says in 7.2.1 > > " For a termination that does not yet exist, TerminationID is specified as > CHOOSE in the ADD command" > > And TermID=$ is the only way in which MGC can specify an Ephemeral Term in ADD > command. Because it is the responsibility of MG to allocate a name for > ephemeral term. > > Thanks for your time > > Chanchal... From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 13 19:26:37 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18465 for ; Mon, 13 Nov 2000 19:26:36 -0500 (EST) Received: from standards (47.234.32.16:3029) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB49B6@standards.nortelnetworks.com>; Mon, 13 Nov 2000 19:08:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 101145 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Nov 2000 19:08:37 -0500 Received: from standards (47.234.32.16:3029) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB49B5@standards.nortelnetworks.com>; Mon, 13 Nov 2000 19:08:37 -0500 Message-ID: Date: Mon, 13 Nov 2000 19:08:37 -0500 Reply-To: Alan Whitton Sender: "Media Gateway Control (megaco)" From: Alan Whitton Subject: Testing To: MEGACO@STANDARDS.NORTELNETWORKS.COM Have not received any mail from this list for over a week. Testing to make sure things are making it to Nortel. Cheers, Alan Whitton From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 14 03:24:29 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA28302 for ; Tue, 14 Nov 2000 03:24:28 -0500 (EST) Received: from standards (47.234.32.16:3846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4EF7@standards.nortelnetworks.com>; Tue, 14 Nov 2000 3:06:16 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 102877 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Nov 2000 03:06:16 -0500 Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4EF6@standards.nortelnetworks.com>; Tue, 14 Nov 2000 3:06:16 -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 DAA23127 for ; Tue, 14 Nov 2000 03:22:47 -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 DAA23117 for ; Tue, 14 Nov 2000 03:22:46 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA22300; Tue, 14 Nov 2000 09:22:45 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA22294; Tue, 14 Nov 2000 09:22:44 +0100 (MET) X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <000e01c04d89$76e71d50$70d8a8c0@dev_4.us.radvision.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A10F602.587FE241@lucent.com> Date: Tue, 14 Nov 2000 09:21:22 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Use of CHOOSE To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dan, See section 7.1.18 of the spec, below the two bullet lists: "The CHOOSE wildcard in a topology descriptor matches the TerminatinID that the MG assigns in the first Add command that uses a CHOOSE wildcard in the same action." ^^^^^ If you want to use this functionality, the order of creation of the terminations is important! Cheers, John Dan Elbert wrote: > > Can more than one CHOOSE termination id be used in an action? > Foe example: > > Context = $ { > Add = A4444{}, > Add = $ {}, > Add = $ {} > } > > If this is the case, seems like we can have some ambiguity, for example if > we have a topology descriptor in the action using the A4444 and $, how can > we know to what $ refers ? > > Dan Elbert > RADVISION -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 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 Nov 14 03:33:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01932 for ; Tue, 14 Nov 2000 03:33:00 -0500 (EST) Received: from standards (47.234.32.16:3846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4F17@standards.nortelnetworks.com>; Tue, 14 Nov 2000 3:14:57 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 102922 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Nov 2000 03:14:57 -0500 Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4F16@standards.nortelnetworks.com>; Tue, 14 Nov 2000 3:14:57 -0500 Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id DAA18471 for ; Tue, 14 Nov 2000 03:31:28 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id DAA18461 for ; Tue, 14 Nov 2000 03:31:27 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA23869; Tue, 14 Nov 2000 09:31:26 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA23864; Tue, 14 Nov 2000 09:31:26 +0100 (MET) X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A10F80C.46680965@lucent.com> Date: Tue, 14 Nov 2000 09:30:04 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: use of CHOOSE To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Nancy, Normally I would expect naming hierarchies where the first level in the hierarchy identifies the class of the termination. And I would expect that MGCs use Add commands with partially specified names, e.g. Add=TDMC/$, or Add=RTP/$. When the MG has to resolve Add=$, then it's really parameters that determine what kind of termination is needed. I don't believe that the spec describes a procedure for the case that multiple kinds of terminations match. This means that the MG can really go ahead and choose one. Do we need an additional implementors' guide entry? Cheers, John "Griffeth, Nancy D (Nancy)" wrote: > > John, > > We are also having some trouble with the use of CHOOSE. If an Add command > gives > the properties of a TDM, how do we know to use a termination NULL context? > Maybe that's > a no-brainer, but it seems more difficult in the general case - how do we > determine, > given set of properties in an Add command, that the termination for a > wildcarded ID > should be ephemeral as opposed to using an existing one in the NULL context? > > Nancy -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 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 Nov 14 03:47:56 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08110 for ; Tue, 14 Nov 2000 03:47:55 -0500 (EST) Received: from standards (47.234.32.16:3846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4F37@standards.nortelnetworks.com>; Tue, 14 Nov 2000 3:29:52 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 102968 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Nov 2000 03:29:52 -0500 Received: from hindon.hss.co.in (202.54.26.202:33412) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB4F36@standards.nortelnetworks.com>; Tue, 14 Nov 2000 3:29:37 -0500 Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id eAEJFVq10369 for ; Tue, 14 Nov 2000 14:15:32 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256997.002F1A03 ; Tue, 14 Nov 2000 14:04:28 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256997.002F197F.00@sandesh.hss.hns.com> Date: Tue, 14 Nov 2000 14:15:40 +0530 Reply-To: sgautam@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sandeep Gautam Subject: Services Sate To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, According to 6.2.4 "If not provisioned otherwise, all descriptors except TerminationState and LocalControl default to empty/"no value" when a Termination is first created or returned to the null Context. The default contents of the two exceptions are described in sections 7.1.5 and 7.1.7. " Sec 7.1.5 says the default value of Services state is "in service" Does this mean that the default value of "in service" is restored for Services State, whenever a termination is subtracted? Suppose a terination was in context and a forced Service Change occured ( say MG generated it due to a physical card being pullled out/failing). The state becomes immediately OOS. It is also said that a subtract should be honored in OOS state. A subtract comes subsequently ( for context clearing) and MG should now restore the Services State to default value i.e. "in service". Isnt this somewhat awkward? MG or MGC indicated that some termination went OOS , and a subsequent subtract (for context clearing) brought it "in service"! Is this the intended behaviour? Thanx and regards, Sandy G PS: what is the default value of Events Buffer Control Property? From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 14 06:38:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06834 for ; Tue, 14 Nov 2000 06:38:08 -0500 (EST) Received: from standards (47.234.32.16:3008) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB51C8@standards.nortelnetworks.com>; Tue, 14 Nov 2000 6:19:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 103839 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Nov 2000 06:19:56 -0500 Received: from hindon.hss.co.in (202.54.26.202:37700) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB51C7@standards.nortelnetworks.com>; Tue, 14 Nov 2000 6:19:53 -0500 Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id eAEM5tV14701 for ; Tue, 14 Nov 2000 17:06:01 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256997.003EB7BE ; Tue, 14 Nov 2000 16:55:02 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256997.003EA9CA.00@sandesh.hss.hns.com> Date: Tue, 14 Nov 2000 16:54:49 +0530 Reply-To: sgautam@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sandeep Gautam Subject: Audit of media descriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, We have a termination in NULL context s.t. no media descriptors have arrived from the MGC ( thus no streams have been created) The termination supports TDMC package. The default value of Echo cancellation has been provisioned at MG as ON. The termination is audited for Media descriptor. What do we return? Do we return a Local Control Descriptor with tdmc/ec=on. If so what is the stream ID we use in the media descriptor. Thanx and regards, Sandy G From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 14 11:14:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06457 for ; Tue, 14 Nov 2000 11:14:35 -0500 (EST) Received: from standards (47.234.32.16:4659) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB546E@standards.nortelnetworks.com>; Tue, 14 Nov 2000 10:56:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 104725 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Nov 2000 10:56:10 -0500 Received: from zmers013 (47.124.1.40:53503) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB5467@standards.nortelnetworks.com>; Tue, 14 Nov 2000 10:46:08 -0500 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by zmers013; Tue, 14 Nov 2000 10:45:33 -0500 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Tue, 14 Nov 2000 10:41:59 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 14 Nov 2000 10:41:56 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD1102C4ED3C@zcard00g.ca.nortel.com> Date: Tue, 14 Nov 2000 10:41:52 -0500 Reply-To: "Taylor, Tom-PT" Sender: "Media Gateway Control (megaco)" From: "Taylor, Tom-PT" Subject: Re: Issues with draft-ietf-megaco-ipphone-03.txt X-To: Bob Lukas X-cc: "Blatherwick, Peter" To: MEGACO@STANDARDS.NORTELNETWORKS.COM In response to your concern, text has been added to the description of the keydown event in the Key package of Annex G, stating that if the key is already down when the event is activated the event will be reported immediately. As I read the description of action of the hookswitch key, this will give you what you need. -----Original Message----- From: Bob Lukas [mailto:blukas@BROADCOM.COM] Sent: Friday, October 13, 2000 12:35 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Issues with draft-ietf-megaco-ipphone-03.txt Peter, I have been considering your comments and hoping for additional feedback from MGC vendors. I agree my issues are not really specific to the ipphone draft, but with the Annex G packages used by the IPPhone profile. And I concede that most things work fine for MGCs that want "raw" event reporting, ie. not using digitmaps or event descriptors for filtering. It would be useful for an MGC vendor that is planning to support IP Phones to express an opinion here. Maybe these are issues for the implementors guide or for version 2 update of Megaco annexes. One issue that I am stuck on, however, is that I can't find a way to audit the current value of the hookswitch (or any persistent-state key, for that matter). Even if the MGC is hot-standby/auto-failover, there will be times where it is conceivable that the current state of a particular IP Phone will be unknown. e.g. powering up a phone while the handset is knocked off the cradle. I would like to be able to apply off-hook warning tone in this case. Relying on user-behaviour to jiggle the hookswitch a few times, or have the phone possibly ring while off-hook is not optimal. You make reference to having the Phone generate immediate events for each key on event descriptor download - I'm not aware how to make the phone do that w.r.t. the key package. On the issue of multiple terminations, I absolutely agree that it is a good architecture to separate the terminations. But until we can find a way to allow reflex operations between terminations, we will have to admit that we either avoid reflex operations or make the device have some implicit knowledge of local interactions. -----Original Message----- From: Peter Blatherwick [mailto:blather@NORTELNETWORKS.COM] Sent: Thursday, October 05, 2000 10:23 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Issues with draft-ietf-megaco-ipphone-03.txt Bob: I believe your comments below do not actually affect the Megaco IP Phone draft itself. However, I agree with some of the issues you raise. Since the Megaco IP Phone draft is currently in last call, its important to identify where the issues reside. See [pb] comments below. -- Peter Blatherwick -----Original Message----- From: Bob Lukas [ mailto:blukas@BROADCOM.COM ] Sent: Thursday, October 05, 2000 01:10 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Issues with draft-ietf-megaco-ipphone-03.txt We've been looking at implementing draft-ietf-megaco-ipphone-03.txt and a few thorny issues have come up that I haven't seen discussed. Keypad and hookswitch are extensions of the basic annex G key package in the UI termination - this means: [pb] A quick clarification: all the UI packages used by IP Phone are Annex G packages, no extensions to Annex G are proposed. Your statement above is correct, but wanted to make sure all understood it. 1. There is no "current state" property value of these switches, only keyup and keydown events that are generated. e.g. the event reported is key/ku{keyid=kh} for an off-hook event. Not normally an issue for momentary push-buttons, but it means an MGC cannot audit for whether the phone is currently off-hook. Kind of a problem for an MGC that is trying to recover state at startup... [pb} True, there is no current state property. I like the general approach you suggest below to time 0 state problem. I personally think the MGC side of things must be responsible for recovering state if their is a failure cut-over (not sure if that's the scenario you are concerned about) since there's a heck of a lot more than hookswitch state involved in call state. At device startup, the worst that can happen is the user will get bored and hang up, generating the event anyway. [pb] Since this is a limitation of what is specified in Annex G, this does not directly affect the Megaco IP Phone draft. I don't think this is serious though. 2. At times, I'm only interested in events from a subset of the possible keys. How can I set an event descriptor to only monitor hookswitch (for example), and not random other button presses? Is this syntax legal? ...modify = ui { events =1 { key/ku { keyid = kh }, key/kd { keyid = f001} } If it was, it would help overcome the audit issue, by getting an immediate event if currently off-hook. [pb] I like it, even though I personally favour the all events on all the time approach. But I am personally unclear if this syntax is valid or not (its been a while). Unless someone on the list can clarify, I'll look into it. Even if suggested syntax is not valid, immediate Events could be returned indicating key states at the time the EventsDescriptor is received at the MG. [pb] This is an issue related to Megaco/H.248 Protocol overall, not specifically Megaco IP Phone. Useful for Implementer's Guide? 3. The audio transducers are separate terminations from the UI. This has great impact on wanting to automatically stop call progress tones immediately when keys are pressed. As far as I understand, an event occurring in one termination must not affect the signals active in another termination (which would be a huge problem for a multiple line device for example). For example, I cannot have dialtone automatically stop when I press a key - the MGC must send down a signal to explicitly stop it. Even worse, if I choose to implement a digitmap on my keypad, the MGC has no way of knowing when to stop dialtone, because it gets no event until after the entire dial string is entered. Saying the IP Phone should know and understand the implicit interactions between the terminations is also problematic and against the general Megaco philosophy of centralized control. [pb] The issue of Termination organization has been picked apart at length several times before, resulting in the current organization. While I certainly understand there is a tradeoff around causing reflex actions to occur as a result of Events, grouping of all termination functionality into a single termination (the implied solution) would result in drastically reduced flexibility for the model overall, and make several powerful applications non-intuitive at best. For example, applications like group listening (talker on a handset while others listen on handsfree) require individual control over the audio input/outputs, hence separate Transducer Terminations to allow them to be freely manipulated. Paging while on a call, IP-radio and several other applications would also be awkward without separate terminations. Since the MGC can control everything, albeit with some extra load, the flexible model is favoured, with the intent to open up new applications well beyond what "phones" can do today. [pb] I strongly agree with you statement that MGs should have no knowledge of call-related interactions (or any other application-level knowledge for that matter), and it would indeed break the Megaco/H.248 master/slave model. I think we all agree we don't go there. [pb] Since this topic has been visited several times, and good agreement achieved that this flexibility is important, I would not favour opening the issues again. I believe the general issue of inter-termination interaction may be a useful area for work in future versions of Megaco/H.248, as I can see several other example where it might be helpful. -- PB _____________________________________________________ Bob Lukas Broadcom Canada Richmond B.C. blukas@broadcom.com 604-233-8665 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 14 11:42:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13859 for ; Tue, 14 Nov 2000 11:42:07 -0500 (EST) Received: from standards (47.234.32.16:4659) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB551C@standards.nortelnetworks.com>; Tue, 14 Nov 2000 11:21:44 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 104961 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Nov 2000 11:21:44 -0500 Received: from drawbridge.ascend.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB551B@standards.nortelnetworks.com>; Tue, 14 Nov 2000 11:21:43 -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 IAA27627 for ; Tue, 14 Nov 2000 08:30:17 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 14 Nov 2000 16:38:15 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id IAA20351 for ; Tue, 14 Nov 2000 08:38:14 -0800 (PST) Received: from mastif.eng.ascend.com (mastif.eng.ascend.com [135.92.55.18]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id IAA26672 for ; Tue, 14 Nov 2000 08:38:09 -0800 (PST) Received: from sramannt-pc (h135-92-55-142.outland.lucent.com [135.92.55.142]) by mastif.eng.ascend.com (8.8.8+Sun/8.8.8) with SMTP id LAA00429 for ; Tue, 14 Nov 2000 11:38:07 -0500 (EST) X-Sender: sraman@mastif.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <200011141638.LAA00429@mastif.eng.ascend.com> Date: Tue, 14 Nov 2000 11:39:22 -0500 Reply-To: Sankar Raman Sender: "Media Gateway Control (megaco)" From: Sankar Raman Subject: Terminations in NULL context To: MEGACO@STANDARDS.NORTELNETWORKS.COM The standards say that when a Add command has a CHOOSE terminationID, a termination in the NULL context (assuming it is physical) is to be picked. Does this apply to all terminations in NULL context independent of whether they are in use or not ? In other words, some terminations may be in NULL context but may have signals active on them or events pending. Are we to distinguish between terminations in NULL context that are in use versus those that are truly not in use ? From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 14 13:23:18 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12195 for ; Tue, 14 Nov 2000 13:23:17 -0500 (EST) Received: from standards (47.234.32.16:4659) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB56F4@standards.nortelnetworks.com>; Tue, 14 Nov 2000 13:05:16 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 105588 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Nov 2000 13:05:16 -0500 Received: from 206-103-61-194.oresis.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB56F3@standards.nortelnetworks.com>; Tue, 14 Nov 2000 13:05:15 -0500 Received: from oresisexchange.oresis by 206-103-61-194.oresis.com via smtpd (for h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) with SMTP; 14 Nov 2000 18:16:04 UT Received: by oresisexchange.oresis with Internet Mail Service (5.5.2650.21) id ; Tue, 14 Nov 2000 10:21:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <8AF3E90145A8D411ADC6009027E309D63EF9EA@oresisexchange.oresis> Date: Tue, 14 Nov 2000 10:21:15 -0800 Reply-To: Parag Sharma Sender: "Media Gateway Control (megaco)" From: Parag Sharma Subject: Re: Bearer resource configuration X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Thanks for your response. So Megaco in itself is fine without rules but is there some thought being given to standardize MGC/MG configuration? I would appreciate any pointers. Thanks Parag -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] Sent: Friday, November 03, 2000 9:04 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Bearer resource configuration The basic answer is that there are no rules, but the protocol encourages the specification of terminationIds reflecting the configuration of the resources. So you might have a terminationId like TG3/2/1 which represented DS0 1 in DS1 2 in Trunk Group 3. Brian > -----Original Message----- > From: Parag Sharma [mailto:psharma@ORESIS.COM] > Sent: Friday, November 03, 2000 11:45 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Bearer resource configuration > > > Hi, > > I am new to Megaco and was wondering if there is any work in > progress or any > specification available on configuration of bearer resources > and how exactly > is this configuration information correlated between the MGC > & MG. For e.g. > if groups of TDM circuits on the MG are bundled as a Trunk > Group, then how > does the MGC map termination ids on the MG into separate trunk groups? > > Thanks > Parag > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 14 16:37:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08466 for ; Tue, 14 Nov 2000 16:37:29 -0500 (EST) Received: from standards (47.234.32.16:4152) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB57AC@standards.nortelnetworks.com>; Tue, 14 Nov 2000 16:19:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 105845 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Nov 2000 16:19:04 -0500 Received: from hvmta01-stg.us.psimail.psi.net (hvmta01-ext.us.psimail.psi.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB57AB@standards.nortelnetworks.com>; Tue, 14 Nov 2000 16:19:04 -0500 Received: from dev_4 ([38.150.216.6]) by hvmta01-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20001114213537.PFRU1216.hvmta01-stg@dev_4> for ; Tue, 14 Nov 2000 16:35:37 -0500 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 V4.72.3612.1700 Message-ID: <001101c04e82$eab5c570$70d8a8c0@dev_4.us.radvision.com> Date: Tue, 14 Nov 2000 16:36:15 -0500 Reply-To: delbert@radvision.com Sender: "Media Gateway Control (megaco)" From: Dan Elbert Subject: Alternatives in SDP To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit "the following exceptions to the syntax of RFC 2327 are allowed: . the "s=", "t=" and "o=" lines are optional, . the use of CHOOSE is allowed in place of a single parameter value, and . the use of alternatives is allowed in place of a single parameter value." Can anyone clarify what is meant by "alternatives in place of a single parameter value" ? Thanks Dan Elbert RADVISION From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 15 12:43:21 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00651 for ; Wed, 15 Nov 2000 12:43:20 -0500 (EST) Received: from standards (47.234.32.16:4328) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB5CAC@standards.nortelnetworks.com>; Wed, 15 Nov 2000 12:24:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 107510 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Nov 2000 12:24:54 -0500 Received: from ties.itu.ch by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB5CA1@standards.nortelnetworks.com>; Wed, 15 Nov 2000 12:14:53 -0500 Received: from ericsson.com ([156.106.209.40]) by ties.itu.ch (8.9.3/8.9.3) with ESMTP id SAA20588 for ; Wed, 15 Nov 2000 18:31:23 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A12C83B.33D33B7F@ericsson.com> Date: Thu, 16 Nov 2000 04:30:35 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: H.248 Implementors' Guide at SG16 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day all, The updated Implementors' Guide from the SG16 Meeting is now available at: ftp://standard.pictel.com/avc-site/Incoming/ plen-xxx_H248_Implementors_guide_v7.pdf or plen-xxx_H248_Implementors_guide_v7.doc This is now going for approval. Cheers, Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 15 21:53:50 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11141 for ; Wed, 15 Nov 2000 21:53:49 -0500 (EST) Received: from standards (47.234.32.16:1600) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB5E50@standards.nortelnetworks.com>; Wed, 15 Nov 2000 21:35:42 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 108085 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Nov 2000 21:35:42 -0500 Received: from thalia.fm.intel.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB5E4F@standards.nortelnetworks.com>; Wed, 15 Nov 2000 21:35:41 -0500 Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id CAA04181 for ; Thu, 16 Nov 2000 02:53:35 GMT Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 16 Nov 2000 02:52:17 0000 (GMT) Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Nov 2000 18:52:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: Date: Wed, 15 Nov 2000 18:52:15 -0800 Reply-To: "Tulpule, Naren" Sender: "Media Gateway Control (megaco)" From: "Tulpule, Naren" Subject: conflicting IDs in NAS packages To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, apologies if this has already been pointed out. In http://www.ietf.org/internet-drafts/draft-ietf-megaco-naspkg-01.txt the 'nasin' package extends 'nas' package. Yet they have identical property IDs (for clgstat and sessid resp, both = 0x0001), event IDs (authres = nasfail = 1) etc. Has this been resolved? If so, where can I find the draft? Also, what's the name of the NAS root package? 'nasroot'? I assume it doesn't extend any other package? -- Naren. These views and opinions are mine alone, not those of Intel (yet ;-) Narendra C. Tulpule SMTS, Trillium (an Intel company) Ph: +1-310-442-9222 Fax: +1-310-442-1162 12100 Wilshire Bl #1800 Los Angeles, CA 90025 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 16 01:19:50 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA11575 for ; Thu, 16 Nov 2000 01:19:50 -0500 (EST) Received: from standards (47.234.32.16:1508) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB5ECB@standards.nortelnetworks.com>; Thu, 16 Nov 2000 1:01:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 108247 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Nov 2000 01:01:37 -0500 Received: from mailgate.sbell.com.cn by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB5ECA@standards.nortelnetworks.com>; Thu, 16 Nov 2000 1:01:31 -0500 Received: from bellnet-mail3.sbell.com.cn (bellnet-mail3.sbell.com.cn [202.96.203.172]) by mailgate.sbell.com.cn (8.9.2/8.9.2) with ESMTP id OAA14772 for ; Thu, 16 Nov 2000 14:09:35 +0800 (CST) Received: by bellnet-mail3.sbell.com.cn with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Nov 2000 14:19:00 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <8003294F05B0D411907E00508BF99A9F590137@bellnet-mail1.sbell.com.cn> Date: Thu, 16 Nov 2000 14:15:48 +0800 Reply-To: SRD Tian YaMin Sender: "Media Gateway Control (megaco)" From: SRD Tian YaMin Subject: announcement To: MEGACO@STANDARDS.NORTELNETWORKS.COM Dear all: Can anybody tell me whether announcements are properties of terminations? If announcements like IVRs are configured by other management agent,not the MGC, how the MGC get the knowledge of annoucement IDs? From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 16 03:44:52 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04395 for ; Thu, 16 Nov 2000 03:44:52 -0500 (EST) Received: from standards (47.234.32.16:3399) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB5F22@standards.nortelnetworks.com>; Thu, 16 Nov 2000 3:26:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 108369 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Nov 2000 03:26:38 -0500 Received: from tama5.ecl.ntt.co.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB5F21@standards.nortelnetworks.com>; Thu, 16 Nov 2000 3:26:38 -0500 Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id RAA20897 for ; Thu, 16 Nov 2000 17:43:13 +0900 (JST) (envelope-from yamamoto.susumu@lab.ntt.co.jp) Received: from imb.m.ecl.ntt.co.jp by nttmail3.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/10/05/00) with ESMTP id RAA29522 for ; Thu, 16 Nov 2000 17:43:13 +0900 (JST) (envelope-from yamamoto.susumu@lab.ntt.co.jp) Received: from nesoug-host26 ([129.60.11.38]) by imb.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id RAA05681 for ; Thu, 16 Nov 2000 17:43:12 +0900 (JST) X-Sender: sy001@imb.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.0.58.J.20001116171732.00bca790@imb.m.ecl.ntt.co.jp> Date: Thu, 16 Nov 2000 17:48:27 +0900 Reply-To: yamamoto.susumu@lab.ntt.co.jp Sender: "Media Gateway Control (megaco)" From: Susumu YAMAMOTO Subject: Can I handle a LSP of MPLS in megaco protocol? To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi all, Can I handle a Label Switching Path(LSP) of MPLS in MEGACO/ H.248 protocol? Is there a package for handling MPLS bearer and policy control? I want to apply MEGACO/H.248 protocol to the GW for MPLS network. Please let me know the proper way to control MPLS bearer and policy in this scheme. If there is multiple LSPs to the same destination(they may be deferent in priorities), how can MGC ADD an ephemeral termination related to the specific LSP to a context? Thanks in advance, Susumu -*-*-* SUSUMU YAMAMOTO Mega-media Network Systems Project NTT Network Service Systems Laboratories mailto: yamamoto.susumu@lab.ntt.co.jp TEL:+81 422 59 2744 FAX:+81 422 37 7467 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 16 05:04:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09111 for ; Thu, 16 Nov 2000 05:04:39 -0500 (EST) Received: from standards (47.234.32.16:3983) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB603D@standards.nortelnetworks.com>; Thu, 16 Nov 2000 4:46:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 108751 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Nov 2000 04:46:21 -0500 Received: from hindon.hss.co.in (202.54.26.202:51120) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB603C@standards.nortelnetworks.com>; Thu, 16 Nov 2000 4:36:18 -0500 Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id eAG9sH324519 for ; Thu, 16 Nov 2000 15:24:18 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256999.00353872 ; Thu, 16 Nov 2000 15:11:18 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256999.003532D5.00@sandesh.hss.hns.com> Date: Thu, 16 Nov 2000 15:19:59 +0530 Reply-To: ssikri@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sachin Sikri Subject: enumerations in unicode pages To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi H.248 Annex G provides packages for User Interface Elements and Actions. Package Display defines one of the property as supported unicode code pages. The description of the property is list of supported unicode pages and Type is list of enumerated type Can anybody tell me about the enumerations that are to be included in the list. Regards Sachin Sikri From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 16 14:01:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00876 for ; Thu, 16 Nov 2000 14:01:15 -0500 (EST) Received: from standards (47.234.32.16:3314) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB6316@standards.nortelnetworks.com>; Thu, 16 Nov 2000 13:42:49 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 109729 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Nov 2000 13:42:49 -0500 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB6315@standards.nortelnetworks.com>; Thu, 16 Nov 2000 13:42:49 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA04982; Thu, 16 Nov 2000 13:59:24 -0500 (EST) Received: from stl-server-01.pit.comms.marconi.com (stl-server-01.pit.comms.marconi.com [169.144.36.27]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA29993; Thu, 16 Nov 2000 13:59:27 -0500 (EST) Received: by stl-server-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Nov 2000 13:59: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: <4FBEA8857476D311A03300204840E1CF021156E2@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 16 Nov 2000 13:59:25 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: H.248 Implementors' Guide at SG16 X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM The question of "going for approval" bothers me. Of course, I try hard to avoid worrying about ITU process. but I have had a reasonable amount of experience with debugging. That's what we are doing - debugging the document. One of the metrics we use is rate of discovery of new bugs. You look for the rate to take a significant drop. I don't see that -- the rate of new bugs is still pretty high. I don't see any advantage of freezing the document yet, and if there are any consequences of doing that now, as opposed to in a couple of months, I'd wait. Brian ps - the nice part about debugging documents rather than code is that the effort and time to find-and-fix is much more predictable, and shorter! pps - you now know why the IETF calls the kind of document we are working from as "Proposed Standard" > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > Sent: Wednesday, November 15, 2000 12:31 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: H.248 Implementors' Guide at SG16 > > > G'Day all, > > The updated Implementors' Guide from the SG16 Meeting is now available > at: > ftp://standard.pictel.com/avc-site/Incoming/ > > plen-xxx_H248_Implementors_guide_v7.pdf > or > plen-xxx_H248_Implementors_guide_v7.doc > > This is now going for approval. > > Cheers, Christian > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 16 20:38:05 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15954 for ; Thu, 16 Nov 2000 20:38:05 -0500 (EST) Received: from standards (47.234.32.16:4305) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB6536@standards.nortelnetworks.com>; Thu, 16 Nov 2000 20:19:55 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 110434 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Nov 2000 20:19:55 -0500 Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB652F@standards.nortelnetworks.com>; Thu, 16 Nov 2000 20:09:54 -0500 Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id UAA00149 for ; Thu, 16 Nov 2000 20:26:34 -0500 (EST) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id UAA00145 for ; Thu, 16 Nov 2000 20:26:33 -0500 (EST) Received: from urinotes01.bcs.lucent.com (urinotes01.bcs.lucent.com [135.35.228.30]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id UAA27709; Thu, 16 Nov 2000 20:26:31 -0500 (EST) X-MIMETrack: Serialize by Router on Notes01/SVR/Yurie(Release 5.0.4 |June 8, 2000) at 11/16/2000 20:24:53 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Thu, 16 Nov 2000 20:24:52 -0500 Reply-To: scliang@LUCENT.COM Sender: "Media Gateway Control (megaco)" From: Shihchang Liang Subject: Audit new resource To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, After the initial Audit following the MG-to-MGC registration, how is the MGC informed for new resource, such as more TDM physical terminations becoming available? Thanks, Shihchang From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 16 21:05:13 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23118 for ; Thu, 16 Nov 2000 21:05:13 -0500 (EST) Received: from standards (47.234.32.16:4305) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB6567@standards.nortelnetworks.com>; Thu, 16 Nov 2000 20:47:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 110504 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Nov 2000 20:47:07 -0500 Received: from ns.1dz.cz by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB655F@standards.nortelnetworks.com>; Thu, 16 Nov 2000 20:37:05 -0500 Received: from 1dz-ova-gate.1dz.cz (ns2.ova.1dz.cz [195.47.13.165]) by ns.1dz.cz (8.9.3/8.9.3) with SMTP id DAA22594; Fri, 17 Nov 2000 03:41:19 +0100 Received: from bend1-1-181.transport.com ([209.177.158.181]) by 1dz-ova-gate.1dz.cz (602Pro INTERNET SERVER v3.32c) id 002e7fd6; Thu, 16 Nov 2000 23:47:48 +0100 X-Priority: 3 X-MSMail-Priority: Normal Errors-To: c21116@concentric.net X-Mailer: Mozilla 4.72 [en] (Win98; U) Message-ID: <000047bf26b7$000013b3$000027a3@mindspring (user-3qt5hn.dialup.mindspring.com[99.174.150.55]) by smtp6.mindspring.com (8.9.3/8.8.5) with SMTP id OAA06398 from 110140321worldnet.att.net ([102.70.21.32]) by mtiwmhc98.worldnet.att.net (InterMail v03.02.07.07 118-134) with SMTP id<20090116195452.ZOMX28505@110940321worldnet.att.net>> Date: Thu, 16 Nov 2000 10:35:31 -0700 Reply-To: anna@MAILSERVER5.SNC-LAVALIN.COM Sender: "Media Gateway Control (megaco)" From: anna@MAILSERVER5.SNC-LAVALIN.COM Subject: Finally, A Real Snoring Solution! X-To: boyd@mailhost.vitrashop.fr To: MEGACO@STANDARDS.NORTELNETWORKS.COM Snoring-Is it affecting your life? Tired of waking up at all hours? Tired of not getting a good nights sleep? Tired of waking up every morning to hear how you snored the night before? Tired of sleeping in seperate rooms? Just Tired of being Tired? It is not your fault,there is a solution! SNOR-GON IS HERE!! For more information on your special introductory offer Call Toll Free 1-888-258-4753 SNOR-GON is a safe,natural solution to your snoring problem: -Works first time every time -All Natural -No side effects -Guarenteed results For more information on your special introductory offer Call Toll Free 1-888-258-4753 Solve your problem, make the call and change your life for the better! --------------------------------------------------- If you have received this message in error and would like to be removed from future mailings regarding this product, please send an email to rmv1@china.com with the word REMOVE in the subject. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 17 01:40:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA01309 for ; Fri, 17 Nov 2000 01:40:42 -0500 (EST) Received: from standards (47.234.32.16:4770) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB6621@standards.nortelnetworks.com>; Fri, 17 Nov 2000 1:22:27 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 110745 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Nov 2000 01:22:27 -0500 Received: from tama5.ecl.ntt.co.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB661C@standards.nortelnetworks.com>; Fri, 17 Nov 2000 1:12:27 -0500 Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id PAA27459 for ; Fri, 17 Nov 2000 15:29:05 +0900 (JST) (envelope-from matsuda.takao@lab.ntt.co.jp) Received: from ima.m.ecl.ntt.co.jp by nttmail3.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/10/05/00) with ESMTP id PAA16730 for ; Fri, 17 Nov 2000 15:29:04 +0900 (JST) (envelope-from matsuda.takao@lab.ntt.co.jp) Received: from [129.60.11.116] ([129.60.11.116]) by ima.m.ecl.ntt.co.jp (8.9.3/3.7W) with SMTP id PAA15262; Fri, 17 Nov 2000 15:29:04 +0900 (JST) X-Sender: tm009@ima.m.ecl.ntt.co.jp MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-Mailer: Eudora-J(1.3.8.5-J13) Message-ID: <200011170629.PAA15262@ima.m.ecl.ntt.co.jp> Date: Fri, 17 Nov 2000 15:33:37 +0900 Reply-To: Matsuda Sender: "Media Gateway Control (megaco)" From: Matsuda Subject: Announcement Package, noc To: MEGACO@STANDARDS.NORTELNETWORKS.COM Dear, I have a question about the use of "number of cycles" parameter in announcements (Generic Announcement Package, Annex K). I need to indicate playing an announcement endlessly from MGC to MG, because a telephone user need to listen the announcement endlessly until on-hook (until the MGC indicates the MG "Signals{}"). What value of "number of cycles" can we use in the case of playing an announcement endlessly ? Can we use "0" value for "number of cycles" ("number of cycles"=0) in the case of playing an announcement endlessly ? I hope to specify a value of "number of cycles" for unlimited number of cycles (endless playing) in Annex K. Takao Matsuda NTT Network Service Systems Laboratories From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 17 01:44:56 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03981 for ; Fri, 17 Nov 2000 01:44:55 -0500 (EST) Received: from standards (47.234.32.16:4770) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB6637@standards.nortelnetworks.com>; Fri, 17 Nov 2000 1:24:59 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 110746 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Nov 2000 01:24:59 -0500 Received: from web5101.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB661D@standards.nortelnetworks.com>; Fri, 17 Nov 2000 1:14:59 -0500 Received: from [208.220.245.72] by web5101.mail.yahoo.com; Thu, 16 Nov 2000 22:31:38 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20001117063138.24664.qmail@web5101.mail.yahoo.com> Date: Thu, 16 Nov 2000 22:31:38 -0800 Reply-To: Richie Wu Sender: "Media Gateway Control (megaco)" From: Richie Wu Subject: ABNF syntax error of LocalControlDescriptor and TerminationStateDescriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello every body, I found there are inconsistent between ASN.1 and ABNF syntax of Local Control Descriptor as well as Termination State Descriptor. According to the ASN.1 syntax the property parameter is SEQQUENCE, it can be only one as per the ABNF syntax. So I think there is an editorial error. We can add a comment “at-most-once per item, except for propertyParm” to solve this issue. Please refer to the following (comments between square brackets): LocalControlDescriptor ::= SEQUENCE { streamMode StreamMode OPTIONAL, reserveValue BOOLEAN, reserveGroup BOOLEAN, propertyParms SEQUENCE OF PropertyParm, ... } localControlDescriptor = LocalControlToken LBRKT localParm *(COMMA localParm) RBRKT ; at-most-once per item ; [except for propertyParm] localParm = ( streamMode / propertyParm / reservedValueMode / reservedGroupMode ) TerminationStateDescriptor ::= SEQUENCE { propertyParms SEQUENCE OF PropertyParm, eventBufferControl EventBufferControl OPTIONAL, serviceState ServiceState OPTIONAL, ... } terminationStateDescriptor = TerminationStateToken LBRKT terminationStateParm *( COMMA terminationStateParm ) RBRKT ; at-most-once per item ; [except for propertyParm] terminationStateParm =(propertyParm / serviceStates / eventBufferControl ) Regards, Richie Wu ===== Huawei Technologies India Private Limited Unit 10, 2nd Floor, Innovator Block International Tech Park, Whitefield Main Road Bangalore 560 066, India TEL: 0091-80-841 0061/0753/0755 FAX: 0091-80-841 0063 __________________________________________________ Do You Yahoo!? Yahoo! Calendar - Get organized for the holidays! http://calendar.yahoo.com/ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 17 05:17:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA11113 for ; Fri, 17 Nov 2000 05:17:15 -0500 (EST) Received: from standards (47.234.32.16:1172) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB66FD@standards.nortelnetworks.com>; Fri, 17 Nov 2000 4:58:57 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 111034 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Nov 2000 04:58:57 -0500 Received: from zmers013 (47.124.1.40:33638) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB66FC@standards.nortelnetworks.com>; Fri, 17 Nov 2000 4:48:56 -0500 Received: from qnsgs000.nortel.com (actually znsgs016.europe.nortel.com) by zmers013; Fri, 17 Nov 2000 05:03:43 -0500 Received: from zhard00e.europe.nortel.com by qnsgs000.nortel.com; Fri, 17 Nov 2000 10:03:37 +0000 Received: by zhard00e.europe.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 17 Nov 2000 10:03:36 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0507D.A78550C0" Message-ID: Date: Fri, 17 Nov 2000 10:03:37 -0000 Reply-To: "Watson, Mark" Sender: "Media Gateway Control (megaco)" From: "Watson, Mark" Subject: Uniqueness of IDs for package elements 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_01C0507D.A78550C0 Content-Type: text/plain; charset="iso-8859-1" Are the IDs of package elements (Properties, Events, Signals, Statistics, Parameters to Events and Parameters to Signals) unique within the whole package, or just unique within each type of element. i.e. could a Property and an Event both have the same ID within a package ? It seems the type of the element (Property, Events, Signal, Statistic, Parameter to an Event and Parameter to a Signal) can be derived from the context in which the element in found in a message, so the IDs could be unique only within each type of element, or in the case of parameters unique only within the particular Event or Signal which the parameter is defined with. Couldn't find any description of this in the spec. Regards, Mark Watson Nortel Networks ------_=_NextPart_001_01C0507D.A78550C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Uniqueness of IDs for package elements

Are the IDs of package elements = (Properties, Events, Signals, = Statistics, Parameters to Events and Parameters to Signals) unique = within the whole package, or just unique within each type of = element.

i.e. could a Property and an Event = both have the same ID within a package ?

It seems the type of the = element (Property, Events, Signal, Statistic, Parameter to an = Event and Parameter to a Signal) can be derived from the context in = which the element in found in a message, so the IDs could be unique = only within each type of element, or in the case of parameters unique = only within the particular Event or Signal which the parameter is = defined with.

Couldn't find any description of = this in the spec.

Regards,

Mark Watson
Nortel Networks

------_=_NextPart_001_01C0507D.A78550C0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 17 08:33:17 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24959 for ; Fri, 17 Nov 2000 08:33:16 -0500 (EST) Received: from standards (47.234.32.16:2665) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB682D@standards.nortelnetworks.com>; Fri, 17 Nov 2000 8:14:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 111388 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Nov 2000 08:14:55 -0500 Received: from ties.itu.ch by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB680F@standards.nortelnetworks.com>; Fri, 17 Nov 2000 8:04:54 -0500 Received: from ericsson.com ([156.106.209.40]) by ties.itu.ch (8.9.3/8.9.3) with ESMTP id OAA09738; Fri, 17 Nov 2000 14:21:30 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF021156E2@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A14EC00.D6416156@ericsson.com> Date: Fri, 17 Nov 2000 19:27:44 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: H.248 Implementors' Guide at SG16 X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Brian, Obviously I don't share your concern. The Implementors' guide is still a living document. The approval is more of a stamp that "at this period of time this is the known bugs." This version gets approved and frozen, put on the official website for everyone to see but we continue to work on the new version. Its a living process, the next drop of the guide has more information. Cheers, Christian "Rosen, Brian" wrote: > > The question of "going for approval" bothers me. > > Of course, I try hard to avoid worrying about ITU process. but I have had > a reasonable amount of experience with debugging. That's what we > are doing - debugging the document. One of the metrics we use is > rate of discovery of new bugs. You look for the rate to take > a significant drop. > > I don't see that -- the rate of new bugs is still pretty high. > > I don't see any advantage of freezing the document yet, and if there > are any consequences of doing that now, as opposed to in a couple of > months, I'd wait. > > Brian > > ps - the nice part about debugging documents rather than code is that > the effort and time to find-and-fix is much more predictable, and > shorter! > > pps - you now know why the IETF calls the kind of document we are > working from as "Proposed Standard" > > > -----Original Message----- > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > > Sent: Wednesday, November 15, 2000 12:31 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: H.248 Implementors' Guide at SG16 > > > > > > G'Day all, > > > > The updated Implementors' Guide from the SG16 Meeting is now available > > at: > > ftp://standard.pictel.com/avc-site/Incoming/ > > > > plen-xxx_H248_Implementors_guide_v7.pdf > > or > > plen-xxx_H248_Implementors_guide_v7.doc > > > > This is now going for approval. > > > > Cheers, Christian > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 17 14:36:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03251 for ; Fri, 17 Nov 2000 14:36:14 -0500 (EST) Received: from standards (47.234.32.16:1392) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB6AC3@standards.nortelnetworks.com>; Fri, 17 Nov 2000 14:17:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 112319 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Nov 2000 14:17:55 -0500 Received: from zrchh190 (47.158.65.22:40847) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB6ABE@standards.nortelnetworks.com>; Fri, 17 Nov 2000 14:07:55 -0500 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by zrchh190; Fri, 17 Nov 2000 13:20:34 -0600 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Fri, 17 Nov 2000 14:19:14 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 17 Nov 2000 14:19:14 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD1102D50431@zcard00g.ca.nortel.com> Date: Fri, 17 Nov 2000 14:19:11 -0500 Reply-To: "Taylor, Tom-PT" Sender: "Media Gateway Control (megaco)" From: "Taylor, Tom-PT" Subject: Re: Alternatives in SDP X-To: delbert@radvision.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM Look at the name of the production in the ABNF. It covers ranges and lists of values. > -----Original Message----- > From: Dan Elbert [mailto:delbert@RADVISION.COM] > Sent: Tuesday, November 14, 2000 4:36 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Alternatives in SDP > > > "the following exceptions to the syntax > of RFC 2327 are allowed: > . the "s=", "t=" and "o=" lines are optional, > . the use of CHOOSE is allowed in place of a single > parameter value, > and > . the use of alternatives is allowed in place of a single parameter > value." > > Can anyone clarify what is meant by "alternatives in place of a single > parameter value" ? > > Thanks > > Dan Elbert > RADVISION > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 17 15:00:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07388 for ; Fri, 17 Nov 2000 15:00:40 -0500 (EST) Received: from standards (47.234.32.16:1392) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB6B03@standards.nortelnetworks.com>; Fri, 17 Nov 2000 14:42:22 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 112408 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Nov 2000 14:42:21 -0500 Received: from hvmta02-stg.us.psimail.psi.net (hvmta02-ext.us.psimail.psi.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB6B02@standards.nortelnetworks.com>; Fri, 17 Nov 2000 14:42:09 -0500 Received: from dev_4 ([38.150.216.6]) by hvmta02-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20001117195851.PSIJ26052.hvmta02-stg@dev_4>; Fri, 17 Nov 2000 14:58:51 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C050A6.E387B990" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Importance: Normal Message-ID: <000401c050d0$cc1bfda0$70d8a8c0@dev_4.us.radvision.com> Date: Fri, 17 Nov 2000 14:58:47 -0500 Reply-To: delbert@radvision.com Sender: "Media Gateway Control (megaco)" From: Dan Elbert Subject: Re: Alternatives in SDP X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <28560036253BD41191A10000F8BCBD1102D50431@zcard00g.ca.nortel.com> This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C050A6.E387B990 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit What production ? Is not clear. LocalDescriptor and RemoteDescriptor in the ABNF are defined as octetString. Then it says in the protocol that in the text encoding SDP is used, but allows exceptions to the syntax of RFC 2327 which are not well defined. -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Friday, November 17, 2000 2:19 PM To: delbert@radvision.com; megaco@standards.nortelnetworks.com Subject: RE: Alternatives in SDP Look at the name of the production in the ABNF. It covers ranges and lists of values. > -----Original Message----- > From: Dan Elbert [mailto:delbert@RADVISION.COM] > Sent: Tuesday, November 14, 2000 4:36 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Alternatives in SDP > > > "the following exceptions to the syntax > of RFC 2327 are allowed: > . the "s=", "t=" and "o=" lines are optional, > . the use of CHOOSE is allowed in place of a single > parameter value, > and > . the use of alternatives is allowed in place of a single parameter > value." > > Can anyone clarify what is meant by "alternatives in place of a single > parameter value" ? > > Thanks > > Dan Elbert > RADVISION > ------=_NextPart_000_0005_01C050A6.E387B990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Alternatives in SDP

What production ?

Is not=20 clear. LocalDescriptor and RemoteDescriptor in the ABNF are defined as=20 octetString.

Then it says in the protocol that in the text = encoding SDP is=20 used, but allows exceptions to the syntax
of RFC 2327 = which are=20 not well defined.

-----Original Message-----
From: Tom-PT Taylor=20 [mailto:taylor@nortelnetworks.com]
Sent: Friday, November = 17, 2000=20 2:19 PM
To: delbert@radvision.com; megaco@standards.nort= elnetworks.com
Subject:=20 RE: Alternatives in SDP

Look at the name of the production in the = ABNF.  It=20 covers ranges and lists of values.

> -----Original Message-----
>=20 From: Dan Elbert [mailto:delbert@RADVISION.COM]=20
> Sent: Tuesday, November 14, 2000 4:36 = PM=20
> To: MEGACO@STANDARDS.NORT= ELNETWORKS.COM=20
> Subject: Alternatives in SDP =
>
>
>=20 "the following exceptions to the syntax
>    of RFC 2327 are allowed: =
>    . the "s=3D", = "t=3D" and=20 "o=3D" lines are optional,
>    . the use of CHOOSE is allowed in = place of a=20 single
> parameter value, =
>      and
>    . the use of alternatives is allowed = in place=20 of a single parameter
>      value." =
>
> Can anyone clarify what = is meant by=20 "alternatives in place of a single
>=20 parameter value" ?
> =
> Thanks
>
>=20 Dan Elbert
> RADVISION
>

------=_NextPart_000_0005_01C050A6.E387B990-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 17 17:07:48 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12361 for ; Fri, 17 Nov 2000 17:07:47 -0500 (EST) Received: from standards (47.234.32.16:4390) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB6C22@standards.nortelnetworks.com>; Fri, 17 Nov 2000 16:49:36 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 112794 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Nov 2000 16:49:36 -0500 Received: from thalia.fm.intel.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB6C21@standards.nortelnetworks.com>; Fri, 17 Nov 2000 16:49:36 -0500 Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id WAA05129 for ; Fri, 17 Nov 2000 22:07:34 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 17 Nov 2000 22:06:16 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Nov 2000 14:06:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 17 Nov 2000 14:06:08 -0800 Reply-To: "Tulpule, Naren" Sender: "Media Gateway Control (megaco)" From: "Tulpule, Naren" Subject: REPOST: conflicting IDs in NAS packages To: MEGACO@STANDARDS.NORTELNETWORKS.COM > -----Original Message----- > Sent: Wednesday, November 15, 2000 6:52 PM > > Hi, > apologies if this has already been pointed out. > In http://www.ietf.org/internet-drafts/draft-ietf-megaco-naspkg-01.txt the > 'nasin' package extends 'nas' package. Yet they have identical property > IDs (for clgstat and sessid resp, both = 0x0001), event IDs (authres = > nasfail = 1) etc. Has this been resolved? If so, where can I find the > draft? > Also, what's the name of the NAS root package? 'nasroot'? I assume it > doesn't extend any other package? > > -- Naren. > These views and opinions are mine alone, not those of Intel (yet ;-) > Narendra C. Tulpule SMTS, Trillium (an Intel company) > Ph: +1-310-442-9222 Fax: +1-310-442-1162 > 12100 Wilshire Bl #1800 Los Angeles, CA 90025 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 17 17:37:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13648 for ; Fri, 17 Nov 2000 17:37:43 -0500 (EST) Received: from standards (47.234.32.16:4390) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB6D2A@standards.nortelnetworks.com>; Fri, 17 Nov 2000 17:16:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 112977 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Nov 2000 17:16:21 -0500 Received: from zrchh190 (47.158.65.22:57024) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB6CA3@standards.nortelnetworks.com>; Fri, 17 Nov 2000 17:06:19 -0500 Received: from smtprch1.nortel.com (actually erchg0j) by zrchh190; Fri, 17 Nov 2000 16:23:02 -0600 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Fri, 17 Nov 2000 16:21:58 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 17 Nov 2000 16:21:56 -0600 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD1102D5080E@zcard00g.ca.nortel.com> Date: Fri, 17 Nov 2000 16:21:51 -0600 Reply-To: "Taylor, Tom-PT" Sender: "Media Gateway Control (megaco)" From: "Taylor, Tom-PT" Subject: Re: Alternatives in SDP X-To: delbert To: MEGACO@STANDARDS.NORTELNETWORKS.COM I meant the alternativeValue production on which the definition of parmValue depends, but you definitely have a point -- whatever we intended, it's not spelled out in the grammar. -----Original Message----- From: Dan Elbert [mailto:delbert@radvision.com] Sent: Friday, November 17, 2000 2:59 PM To: MEGACO@STANDARDS. NORTELNETWORKS. COM; Taylor, Tom-PT [NORSE:B901:EXCH] Subject: RE: Alternatives in SDP What production ? Is not clear. LocalDescriptor and RemoteDescriptor in the ABNF are defined as octetString. Then it says in the protocol that in the text encoding SDP is used, but allows exceptions to the syntax of RFC 2327 which are not well defined. -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Friday, November 17, 2000 2:19 PM To: delbert@radvision.com ; megaco@standards.nortelnetworks.com Subject: RE: Alternatives in SDP Look at the name of the production in the ABNF. It covers ranges and lists of values. > -----Original Message----- > From: Dan Elbert [ mailto:delbert@RADVISION.COM ] > Sent: Tuesday, November 14, 2000 4:36 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Alternatives in SDP > > > "the following exceptions to the syntax > of RFC 2327 are allowed: > . the "s=", "t=" and "o=" lines are optional, > . the use of CHOOSE is allowed in place of a single > parameter value, > and > . the use of alternatives is allowed in place of a single parameter > value." > > Can anyone clarify what is meant by "alternatives in place of a single > parameter value" ? > > Thanks > > Dan Elbert > RADVISION > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 17 17:49:52 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13918 for ; Fri, 17 Nov 2000 17:49:51 -0500 (EST) Received: from standards (47.234.32.16:4390) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB6D73@standards.nortelnetworks.com>; Fri, 17 Nov 2000 17:31:46 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 113260 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Nov 2000 17:31:46 -0500 Received: from zrchh190 (47.158.65.22:58267) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB6D69@standards.nortelnetworks.com>; Fri, 17 Nov 2000 17:21:45 -0500 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by zrchh190; Fri, 17 Nov 2000 16:36:22 -0600 Received: from zcard015.ca.nortel.com (actually zcard015) by ertpg14e1.nortelnetworks.com; Fri, 17 Nov 2000 17:35:18 -0500 Received: from ztcfd004.ca.nortel.com ([47.211.192.106]) by zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id W4S0W07N; Fri, 17 Nov 2000 17:35:18 -0500 Received: from americasm10.nt.com (michael-brown.us.nortel.com [47.142.213.27]) by ztcfd004.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id T7R3CY2A; Fri, 17 Nov 2000 17:35:16 -0500 X-Sybari-Space: 00000000 00000000 00000000 X-Sender: "Brown, Michael [NC1:3T19:EXCH]" X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Message-ID: <3A15B490.2B82648B@americasm10.nt.com> Date: Fri, 17 Nov 2000 17:43:28 -0500 Reply-To: "Brown, Michael" Sender: "Media Gateway Control (megaco)" From: "Brown, Michael" Organization: Nortel Networks Subject: Problem with syntax of auditOther To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Came across a discrepancy between the text description and the ABNF for auditOther construction. In the text of section 7.2.5 on AuditValue, the following can be found: "Specifying an empty Audit Descriptor results in only the TerminationID being returned." In the syntax in Annex B, this would be achieved by using the auditOther construction. However, the syntax is: auditOther = EQUAL TerminationID LBRKT terminationAudit RBRKT In order to return only the TerminationID, the syntax should be: auditOther = EQUAL TerminationID [ LBRKT terminationAudit RBRKT ] The optionality is shown correctly in the ASN.1 syntax. This needs to be added to the implementor's guide. Michael From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Nov 18 18:15:05 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13520 for ; Sat, 18 Nov 2000 18:15:05 -0500 (EST) Received: from standards (47.234.32.16:4365) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB7245@standards.nortelnetworks.com>; Sat, 18 Nov 2000 17:56:41 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 114931 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 18 Nov 2000 17:56:41 -0500 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB723A@standards.nortelnetworks.com>; Sat, 18 Nov 2000 17:46:40 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eAIN3ED24771; Sun, 19 Nov 2000 00:03:15 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id AAA24694; Sun, 19 Nov 2000 00:03:13 +0100 (MET) Received: from ericsson.com (arael26m41.ericsson.se [130.100.249.41]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id AAA12331; Sun, 19 Nov 2000 00:03:12 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <200011170629.PAA15262@ima.m.ecl.ntt.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A16B1E9.6404258F@ericsson.com> Date: Sun, 19 Nov 2000 03:44:25 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Announcement Package, noc X-To: Matsuda To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Takao San, Yes you can use "0" for the number of cycles. Since the August there has been text that says: Number of cycles ParameterID: noc (0x0002) type: integer. Values: any 0 is used to represent an announcement that continuously plays or loops. (OO) Default: provisioned per announcement in the MG. Regards, Christian Matsuda wrote: > > Dear, > > I have a question about the use of "number of cycles" parameter > in announcements (Generic Announcement Package, Annex K). > > I need to indicate playing an announcement endlessly > from MGC to MG, because a telephone user need to listen the announcement > endlessly until on-hook (until the MGC indicates the MG "Signals{}"). > What value of "number of cycles" can we use in the case of playing > an announcement endlessly ? Can we use "0" value for "number of cycles" > ("number of cycles"=0) in the case of playing an announcement endlessly ? > > I hope to specify a value of "number of cycles" for unlimited number > of cycles (endless playing) in Annex K. > > Takao Matsuda > NTT Network Service Systems Laboratories From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Nov 18 20:40:13 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17708 for ; Sat, 18 Nov 2000 20:40:13 -0500 (EST) Received: from standards (47.234.32.16:3044) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB72A5@standards.nortelnetworks.com>; Sat, 18 Nov 2000 20:22:00 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 115080 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 18 Nov 2000 20:22:00 -0500 Received: from zmers013 (47.124.1.40:61270) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB72A4@standards.nortelnetworks.com>; Sat, 18 Nov 2000 20:12:00 -0500 Received: from smtprch2.nortel.com (actually erchg0k) by zmers013; Sat, 18 Nov 2000 20:25:56 -0500 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Sat, 18 Nov 2000 19:21:41 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Sat, 18 Nov 2000 19:25:53 -0600 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD1102D50928@zcard00g.ca.nortel.com> Date: Sat, 18 Nov 2000 19:25:54 -0600 Reply-To: "Taylor, Tom-PT" Sender: "Media Gateway Control (megaco)" From: "Taylor, Tom-PT" Subject: Re: H.248 Implementors' Guide at SG16 To: MEGACO@STANDARDS.NORTELNETWORKS.COM I'll get it out in I-D form so it's more clearly a living document. > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > Sent: Friday, November 17, 2000 3:28 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: H.248 Implementors' Guide at SG16 > > > G'Day Brian, > > Obviously I don't share your concern. The Implementors' guide > is still a > living document. The approval is more of a stamp that "at > this period of > time this is the known bugs." This version gets approved and > frozen, put > on the official website for everyone to see but we continue to work on > the new version. Its a living process, the next drop of the guide has > more information. > > Cheers, Christian > > "Rosen, Brian" wrote: > > > > The question of "going for approval" bothers me. > > > > Of course, I try hard to avoid worrying about ITU process. > but I have had > > a reasonable amount of experience with debugging. That's what we > > are doing - debugging the document. One of the metrics we use is > > rate of discovery of new bugs. You look for the rate to take > > a significant drop. > > > > I don't see that -- the rate of new bugs is still pretty high. > > > > I don't see any advantage of freezing the document yet, and if there > > are any consequences of doing that now, as opposed to in a couple of > > months, I'd wait. > > > > Brian > > > > ps - the nice part about debugging documents rather than > code is that > > the effort and time to find-and-fix is much more predictable, and > > shorter! > > > > pps - you now know why the IETF calls the kind of document we are > > working from as "Proposed Standard" > > > > > -----Original Message----- > > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > > > Sent: Wednesday, November 15, 2000 12:31 PM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: H.248 Implementors' Guide at SG16 > > > > > > > > > G'Day all, > > > > > > The updated Implementors' Guide from the SG16 Meeting is > now available > > > at: > > > ftp://standard.pictel.com/avc-site/Incoming/ > > > > > > plen-xxx_H248_Implementors_guide_v7.pdf > > > or > > > plen-xxx_H248_Implementors_guide_v7.doc > > > > > > This is now going for approval. > > > > > > Cheers, Christian > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Nov 19 05:01:17 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07887 for ; Sun, 19 Nov 2000 05:01:16 -0500 (EST) Received: from standards (47.234.32.16:1172) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB747F@standards.nortelnetworks.com>; 19 Nov 2000 4:42:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 115738 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 19 Nov 2000 04:42:54 -0500 Received: from multitech.co.in (202.54.39.98:3156) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB747D@standards.nortelnetworks.com>; 19 Nov 2000 4:32:53 -0500 Received: from ramganesh [192.168.2.153] by multitech.co.in [202.54.39.98] with SMTP (MDaemon.v3.0.2.R) for ; Sun, 19 Nov 2000 15:18:52 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004F_01C0523D.B9ABCA60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-MDaemon-Deliver-To: megaco@standards.nortelnetworks.com X-Return-Path: ramganesh@multitech.co.in X-MDRcpt-To: megaco@standards.nortelnetworks.com X-MDRemoteIP: 192.168.2.153 Message-ID: <005201c0520f$a5632860$9902a8c0@multitech.co.in> Date: Sun, 19 Nov 2000 15:31:02 +0530 Reply-To: Ram Ganesh Shetty M Sender: "Media Gateway Control (megaco)" From: Ram Ganesh Shetty M Organization: Multitech Software Sysytems Subject: on megaco X-To: vovida org mgcp To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_004F_01C0523D.B9ABCA60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi, i got a seminar on megaco, please do send me some slides or material on = it for the same. thank u - ram =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=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 work address : ----------------------- Ram Ganesh Shetty M. Assistant Software Engineer. Multitech Software Systems India Pvt. Ltd. 95 , 17th 'B' Main Road , 5th Block Koramangala , Bangalore - 560 095 , India. Ph : 5534471 , 5534476. std code : 080. email : ramganesh@multitech.co.in Fax : 5536646. web : www.multitech.co.in =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=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 ------=_NextPart_000_004F_01C0523D.B9ABCA60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
hi,
 i got a seminar on megaco, please = do send me=20 some slides or material on it for the same. thank u - ram
 
=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=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
work=20 address :
-----------------------
Ram Ganesh Shetty = M.
Assistant=20 Software Engineer.
 
Multitech Software Systems India Pvt. = Ltd.
95 ,=20 17th 'B' Main Road , 5th Block
Koramangala , Bangalore - 560 095 ,=20 India.
 
Ph : 5534471 , 5534476.   std = code :=20 080.
 
email : ramganesh@multitech.co.inFax  =20 : 5536646.
web   : www.multitech.co.in
=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=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
------=_NextPart_000_004F_01C0523D.B9ABCA60-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Nov 19 05:06:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07916 for ; Sun, 19 Nov 2000 05:06:08 -0500 (EST) Received: from standards (47.234.32.16:1172) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB749D@standards.nortelnetworks.com>; 19 Nov 2000 4:47:14 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 115739 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 19 Nov 2000 04:47:14 -0500 Received: from multitech.co.in (202.54.39.98:3160) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB747E@standards.nortelnetworks.com>; 19 Nov 2000 4:37:13 -0500 Received: from ramganesh [192.168.2.153] by multitech.co.in [202.54.39.98] with SMTP (MDaemon.v3.0.2.R) for ; Sun, 19 Nov 2000 15:23:24 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01C0523E.60CD6F60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-MDaemon-Deliver-To: megaco@standards.nortelnetworks.com X-Return-Path: ramganesh@multitech.co.in X-MDRcpt-To: megaco@standards.nortelnetworks.com X-MDRemoteIP: 192.168.2.153 Message-ID: <006401c05210$4736c520$9902a8c0@multitech.co.in> Date: Sun, 19 Nov 2000 15:35:43 +0530 Reply-To: Ram Ganesh Shetty M Sender: "Media Gateway Control (megaco)" From: Ram Ganesh Shetty M Organization: Multitech Software Sysytems Subject: on megaco X-To: vovida org mgcp To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0061_01C0523E.60CD6F60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Megaco Protocol on voip technology Megaco H.248 ------=_NextPart_000_0061_01C0523E.60CD6F60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Megaco Protocol on voip = technology
Megaco
H.248
------=_NextPart_000_0061_01C0523E.60CD6F60-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Nov 19 10:22:23 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10422 for ; Sun, 19 Nov 2000 10:22:22 -0500 (EST) Received: from standards (47.234.32.16:2492) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB75BF@standards.nortelnetworks.com>; 19 Nov 2000 10:04:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 116193 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 19 Nov 2000 10:04:10 -0500 Received: from mail-in.audiocodes.com (AC-INT-LP.ser.netvision.net.il) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB75BE@standards.nortelnetworks.com>; 19 Nov 2000 10:04:09 -0500 Received: by MAIL-IN with Internet Mail Service (5.5.2650.21) id ; Sun, 19 Nov 2000 17:20:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Message-ID: <81C3E8FE6C0AD4119D49009027C3AAB25DAC1B@MAIL-IN> Date: Sun, 19 Nov 2000 17:20:25 +0200 Reply-To: Nurit Shenhar Sender: "Media Gateway Control (megaco)" From: Nurit Shenhar Subject: Digit map timers To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello list In section 7.1.14.2 there is a description of the 3 digit map timers: T S and L. The end of the section says: The timers are configurable parameters to a DigitMap. The Start timer is started at the beginning of every digit map use, but can be overridden. I would like to know: 1. Are there any default/recommended values for this three timer? 2. What is the mean of "configurable"? Does it mean that the timers values can be changed by an MGC command, or it only refers to the fact the L and S can be part of the digit map? 3. How can the Start Timer be overridden? Best regards Nurit Shenhar AudioCodes Ltd. Direct: +972-3-539-4155 Tel: +972-3-539-4000 Fax: +972-3-539-4040 email: nurit.shenhar@audiocodes.com web: From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Nov 19 15:43:35 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12461 for ; Sun, 19 Nov 2000 15:43:34 -0500 (EST) Received: from standards (47.234.32.16:4846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB76FF@standards.nortelnetworks.com>; 19 Nov 2000 15:25:28 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 116656 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 19 Nov 2000 15:25:28 -0500 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB76FE@standards.nortelnetworks.com>; 19 Nov 2000 15:15:27 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eAJKW9t15453; Sun, 19 Nov 2000 21:32:09 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id VAA18320; Sun, 19 Nov 2000 21:32:09 +0100 (MET) Received: from ericsson.com (arael26m86.ericsson.se [130.100.249.86]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id VAA13453; Sun, 19 Nov 2000 21:32:07 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <3A15B490.2B82648B@americasm10.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A183235.57D7CDB0@ericsson.com> Date: Mon, 20 Nov 2000 07:04:05 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Problem with syntax of auditOther X-To: "Brown, Michael" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Mike, Certainly seems like an inconsistency. I'll add it to the implementors guide addition document which i'll record against the approved implementors' guide. Cheers, Christian "Brown, Michael" wrote: > > Came across a discrepancy between the text description and the ABNF for > auditOther construction. > > In the text of section 7.2.5 on AuditValue, the following can be found: > > "Specifying an empty Audit Descriptor results in only the TerminationID > being returned." > > In the syntax in Annex B, this would be achieved by using the auditOther > construction. However, the syntax is: > > auditOther = EQUAL TerminationID LBRKT terminationAudit > RBRKT > > In order to return only the TerminationID, the syntax should be: > > auditOther = EQUAL TerminationID [ LBRKT terminationAudit > RBRKT ] > > The optionality is shown correctly in the ASN.1 syntax. This needs to be > added to the implementor's guide. > > Michael From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Nov 19 17:49:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13392 for ; Sun, 19 Nov 2000 17:49:36 -0500 (EST) Received: from standards (47.234.32.16:1545) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB7781@standards.nortelnetworks.com>; 19 Nov 2000 17:31:24 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 116833 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 19 Nov 2000 17:31:23 -0500 Received: from alemail1.firewall.lucent.com (alemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB7780@standards.nortelnetworks.com>; 19 Nov 2000 17:31:23 -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 RAA00770 for ; Sun, 19 Nov 2000 17:48:11 -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 RAA00762 for ; Sun, 19 Nov 2000 17:48:10 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id XAA29215; Sun, 19 Nov 2000 23:48:09 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id XAA29210; Sun, 19 Nov 2000 23:48:05 +0100 (MET) X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD1102D50928@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A1858A8.F540832D@lucent.com> Date: Sun, 19 Nov 2000 23:48:08 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: H.248 Implementors' Guide at SG16 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Tom, I thought that we agreed in Pittsburgh that it wouldn't be necessary to reproduce the content of the IG, but that a pointer to the ITU website would suffice. Should save you some ascii formatting... Cheers, John "Taylor, Tom-PT" wrote: > I'll get it out in I-D so it's more clearly a living document. > > > -----Original Message----- > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > > Sent: Friday, November 17, 2000 3:28 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: H.248 Implementors' Guide at SG16 > > > > > > G'Day Brian, > > > > Obviously I don't share your concern. The Implementors' guide > > is still a > > living document. The approval is more of a stamp that "at > > this period of > > time this is the known bugs." This version gets approved and > > frozen, put > > on the official website for everyone to see but we continue to work on > > the new version. Its a living process, the next drop of the guide has > > more information. > > > > Cheers, Christian > > > > "Rosen, Brian" wrote: > > > > > > The question of "going for approval" bothers me. > > > > > > Of course, I try hard to avoid worrying about ITU process. > > but I have had > > > a reasonable amount of experience with debugging. That's what we > > > are doing - debugging the document. One of the metrics we use is > > > rate of discovery of new bugs. You look for the rate to take > > > a significant drop. > > > > > > I don't see that -- the rate of new bugs is still pretty high. > > > > > > I don't see any advantage of freezing the document yet, and if there > > > are any consequences of doing that now, as opposed to in a couple of > > > months, I'd wait. > > > > > > Brian > > > > > > ps - the nice part about debugging documents rather than > > code is that > > > the effort and time to find-and-fix is much more predictable, and > > > shorter! > > > > > > pps - you now know why the IETF calls the kind of document we are > > > working from as "Proposed Standard" > > > > > > > -----Original Message----- > > > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > > > > Sent: Wednesday, November 15, 2000 12:31 PM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: H.248 Implementors' Guide at SG16 > > > > > > > > > > > > G'Day all, > > > > > > > > The updated Implementors' Guide from the SG16 Meeting is > > now available > > > > at: > > > > ftp://standard.pictel.com/avc-site/Incoming/ > > > > > > > > plen-xxx_H248_Implementors_guide_v7.pdf > > > > or > > > > plen-xxx_H248_Implementors_guide_v7.doc > > > > > > > > This is now going for approval. > > > > > > > > Cheers, Christian > > > > > > -- John Segers email: jsegers@lucent.com Lucent Technologies phone: +31 35 687 4724 Forward Looking Work EMEA fax: +31 35 687 5954 P.O. Box 18, 1270 AA Huizen, The Netherlands Room HE 303 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Nov 19 18:00:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13440 for ; Sun, 19 Nov 2000 18:00:06 -0500 (EST) Received: from standards (47.234.32.16:1545) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB77A5@standards.nortelnetworks.com>; 19 Nov 2000 17:42:01 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 116881 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 19 Nov 2000 17:42:00 -0500 Received: from alemail1.firewall.lucent.com (alemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB77A4@standards.nortelnetworks.com>; 19 Nov 2000 17:42:00 -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 RAA02991 for ; Sun, 19 Nov 2000 17:58:48 -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 RAA02981 for ; Sun, 19 Nov 2000 17:58:48 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id XAA29424; Sun, 19 Nov 2000 23:58:47 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id XAA29419; Sun, 19 Nov 2000 23:58:45 +0100 (MET) X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <81C3E8FE6C0AD4119D49009027C3AAB25DAC1B@MAIL-IN> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A185B28.19883933@lucent.com> Date: Sun, 19 Nov 2000 23:58:48 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Digit map timers To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Nurit, The timers are configurable by including them in the "header" of a digitmap, there's S for the short timer, L for the long timer and T for the sTart timer. No default values have been specified. Cheers, John Nurit Shenhar wrote: > Hello list > > In section 7.1.14.2 there is a description of the 3 digit map timers: T S > and L. > > The end of the section says: > The timers are configurable parameters to a DigitMap. The Start > timer is started at the beginning of every digit map use, but can be > overridden. > > I would like to know: > 1. Are there any default/recommended values for this three timer? > 2. What is the mean of "configurable"? Does it mean that the timers values > can be changed by an MGC command, or it only refers to the fact the L and S > can be part of the digit map? > 3. How can the Start Timer be overridden? > > Best regards > > Nurit Shenhar > AudioCodes Ltd. > Direct: +972-3-539-4155 > Tel: +972-3-539-4000 > Fax: +972-3-539-4040 > email: nurit.shenhar@audiocodes.com > > web: -- John Segers email: jsegers@lucent.com Lucent Technologies phone: +31 35 687 4724 Forward Looking Work EMEA fax: +31 35 687 5954 P.O. Box 18, 1270 AA Huizen, The Netherlands Room HE 303 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Nov 19 21:11:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14340 for ; Sun, 19 Nov 2000 21:11:07 -0500 (EST) Received: from standards (47.234.32.16:1687) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB7854@standards.nortelnetworks.com>; 19 Nov 2000 20:52:18 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 117076 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 19 Nov 2000 20:52:18 -0500 Received: from tama5.ecl.ntt.co.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB7830@standards.nortelnetworks.com>; 19 Nov 2000 20:42:18 -0500 Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id KAA03494; Mon, 20 Nov 2000 10:58:45 +0900 (JST) (envelope-from matsuda.takao@lab.ntt.co.jp) Received: from ima.m.ecl.ntt.co.jp by nttmail3.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/10/05/00) with ESMTP id KAA12093; Mon, 20 Nov 2000 10:58:45 +0900 (JST) (envelope-from matsuda.takao@lab.ntt.co.jp) Received: from [129.60.11.116] ([129.60.11.116]) by ima.m.ecl.ntt.co.jp (8.9.3/3.7W) with SMTP id KAA00306; Mon, 20 Nov 2000 10:58:44 +0900 (JST) X-Sender: tm009@ima.m.ecl.ntt.co.jp MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-Mailer: Eudora-J(1.3.8.5-J13) Message-ID: <200011200158.KAA00306@ima.m.ecl.ntt.co.jp> Date: Mon, 20 Nov 2000 11:03:18 +0900 Reply-To: Matsuda Sender: "Media Gateway Control (megaco)" From: Matsuda Subject: Re: Announcement Package, noc X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello Mr.Christian, What is the URL to get the most recent version of H.248 ANNEX K? Best regards, Takao >Hello Takao San, > >Yes you can use "0" for the number of cycles. Since the August there has >been text that says: > >Number of cycles >ParameterID: noc (0x0002) >type: integer. > >Values: any > 0 is used to represent an announcement > that continuously plays or loops. (OO) >Default: provisioned per announcement in the MG. > >Regards, Christian > >Matsuda wrote: >> >> Dear, >> >> I have a question about the use of "number of cycles" parameter >> in announcements (Generic Announcement Package, Annex K). >> >> I need to indicate playing an announcement endlessly >> from MGC to MG, because a telephone user need to listen the announcement >> endlessly until on-hook (until the MGC indicates the MG "Signals{}"). >> What value of "number of cycles" can we use in the case of playing >> an announcement endlessly ? Can we use "0" value for "number of cycles" >> ("number of cycles"=0) in the case of playing an announcement endlessly ? >> >> I hope to specify a value of "number of cycles" for unlimited number >> of cycles (endless playing) in Annex K. >> >> Takao Matsuda >> NTT Network Service Systems Laboratories From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Nov 19 23:06:17 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16893 for ; Sun, 19 Nov 2000 23:06:17 -0500 (EST) Received: from standards (47.234.32.16:3911) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB78AB@standards.nortelnetworks.com>; 19 Nov 2000 22:47:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 117235 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 19 Nov 2000 22:47:56 -0500 Received: from mail.winsocket.com (sdsl-216-46-65-3.dsl.nyc.megapath.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB78A8@standards.nortelnetworks.com>; 19 Nov 2000 22:37:56 -0500 Received: from Default [24.219.94.197] by mail.winsocket.com (SMTPD32-6.04) id A08443C6005A; Sun, 19 Nov 2000 22:54:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: Date: Sun, 19 Nov 2000 21:54:41 -0600 Reply-To: plong@ipdialog.com Sender: "Media Gateway Control (megaco)" From: Paul Long Subject: Re: Announcement Package, noc To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200011200158.KAA00306@ima.m.ecl.ntt.co.jp> Content-Transfer-Encoding: 7bit Takao, Everything you need should be here: http://www.packetizer.com/iptel/h248/doc_status.html Paul Long ipDialog, Inc. -----Original Message----- From: Media Gateway Control (megaco) [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Matsuda Sent: Sunday, November 19, 2000 8:03 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Announcement Package, noc Hello Mr.Christian, What is the URL to get the most recent version of H.248 ANNEX K? Best regards, Takao >Hello Takao San, > >Yes you can use "0" for the number of cycles. Since the August there has >been text that says: > >Number of cycles >ParameterID: noc (0x0002) >type: integer. > >Values: any > 0 is used to represent an announcement > that continuously plays or loops. (OO) >Default: provisioned per announcement in the MG. > >Regards, Christian > >Matsuda wrote: >> >> Dear, >> >> I have a question about the use of "number of cycles" parameter >> in announcements (Generic Announcement Package, Annex K). >> >> I need to indicate playing an announcement endlessly >> from MGC to MG, because a telephone user need to listen the announcement >> endlessly until on-hook (until the MGC indicates the MG "Signals{}"). >> What value of "number of cycles" can we use in the case of playing >> an announcement endlessly ? Can we use "0" value for "number of cycles" >> ("number of cycles"=0) in the case of playing an announcement endlessly ? >> >> I hope to specify a value of "number of cycles" for unlimited number >> of cycles (endless playing) in Annex K. >> >> Takao Matsuda >> NTT Network Service Systems Laboratories From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 20 00:04:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17640 for ; Mon, 20 Nov 2000 00:04:06 -0500 (EST) Received: from standards (47.234.32.16:1740) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB7901@standards.nortelnetworks.com>; 19 Nov 2000 23:45:48 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 117354 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 19 Nov 2000 23:45:48 -0500 Received: from godzilla.ipdialog.com (ipsniffers-122.fiasj.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB78FE@standards.nortelnetworks.com>; 19 Nov 2000 23:35:47 -0500 Received: from ipdialog.com (IDENT:root@godzilla.ipdialog.com [208.238.222.122]) by godzilla.ipdialog.com (8.9.3/8.8.7) with ESMTP id UAA03184 for ; Sun, 19 Nov 2000 20:51:58 -0800 X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A18ADE7.EA84BC2C@ipdialog.com> Date: Sun, 19 Nov 2000 22:51:51 -0600 Reply-To: Paul Long Sender: "Media Gateway Control (megaco)" From: Paul Long Organization: ipDialog, Inc. Subject: Re: Announcement Package, noc To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit ...except of course, as I just noticed, a link to that particular annex. Sorry. :-) Paul Long wrote: > Takao, > > Everything you need should be here: > http://www.packetizer.com/iptel/h248/doc_status.html > > Paul Long > ipDialog, Inc. > > -----Original Message----- > From: Media Gateway Control (megaco) > [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Matsuda > Sent: Sunday, November 19, 2000 8:03 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Announcement Package, noc > > Hello Mr.Christian, > > What is the URL to get the most recent version of H.248 ANNEX K? > > Best regards, > Takao From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 20 08:54:52 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09788 for ; Mon, 20 Nov 2000 08:54:51 -0500 (EST) Received: from standards (47.234.32.16:3096) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB7CE8@standards.nortelnetworks.com>; Mon, 20 Nov 2000 8:36:15 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 118688 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Nov 2000 08:36:15 -0500 Received: from mel.alcatel.fr (mail2.alcatel.fr) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB7CE7@standards.nortelnetworks.com>; Mon, 20 Nov 2000 8:36:14 -0500 Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id OAA02910; Mon, 20 Nov 2000 14:52:51 +0100 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id OAA11118; Mon, 20 Nov 2000 14:49:34 +0100 (MET) Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id OAA14580; Mon, 20 Nov 2000 14:52:55 +0100 (MET) Received: from ms.alcatel.fr ([188.9.247.87]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id OAA13052; Mon, 20 Nov 2000 14:52:54 +0100 (MET) X-Mailer: Mozilla 4.71 [en] (WinNT; I) X-Accept-Language: en,fr MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------0F5F0059D8CF0FF45F94F71B" Message-ID: <3A192CBE.2B5B24B1@ms.alcatel.fr> Date: Mon, 20 Nov 2000 14:53:02 +0100 Reply-To: Thomas LEVY Sender: "Media Gateway Control (megaco)" From: Thomas LEVY Organization: Alcatel Subject: draft-levy-megaco-mgdiscovery-01.txt, X-cc: sdp-ng@egroups.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------0F5F0059D8CF0FF45F94F71B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, You will find enclosed the revision of the internet draft "Megaco/H.248 Media Gateway Resources Discovery". It has been enhanced in accordance to comments received on the initial version. It also shortly raises the issue of the relationship between the draft and the SDP-ng activities on Capability Description. The impacted points in the document are : -Addition from "7.4 Implementation considerations" and "8. Conclusion" parts. -Very minor editorial corrections. Please let me know, if you have any comment, Thomas, --------------0F5F0059D8CF0FF45F94F71B Content-Type: text/plain; charset=iso-8859-1; name="draft-levy-megaco-mgdiscovery-01.txt" Content-Disposition: inline; filename="draft-levy-megaco-mgdiscovery-01.txt" Content-Transfer-Encoding: 8bit Megaco Working Group T.Levy L-P.Anquetil Internet Draft Alcatel Document: draft-levy-megaco-mgdiscovery-01.txt November 2000 Category: Informational Megaco/H.248 Media Gateway Resources Discovery Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document addresses the need for a Media Gateway Controller (MGC) to be informed from the media resources of its Media Gateways (MG) in the context of the Megaco/H.248 protocol. The draft discusses alternative solutions for an effective media gateway resources discovery mechanism. The document is provided as an informational draft for discussion within the Megaco Working Group. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 3. Abbreviations MG: Media Gateway MGC: Media Gateway Controller SNMP: Simple Network Management Protocol SDP: Session Description Protocol Levy, Anquetil Informational - Expires May 2001 1 Media Gateway Discovery November 2000 4. Introduction Megaco/H.248 protocol [3] stands as a Media Gateway Control Protocol between MGC and MG. Each MG owns a limited amount of resources (hardware and software) potentially realizing media processing. As an MGC may control a set of MGs, an efficient control requires a precise knowledge (qualitatively and quantitatively) of the MG’s resources. The draft firstly justifies why Megaco/H.248 is the candidate for a media gateway resources discovery mechanism. It then compares alternative mechanisms to solve this issue. 5. Justifications The RFC 2805 [4] describes requirements for the Megaco/H.248 protocol. Section 6.1 deals with Resource Status Management. A requirement of the protocol is to "Provide an MG Resource Discovery mechanism which must allow an MGC to discover what resources the MG has". A solution could rely on SNMP between MGC and MG to exchange resources values with MGC acting as a manager and MG acting as an agent. However, MGC requires a high availability protocol because of its link with call processing. As SNMP doesn’t fulfill this needs, Megaco/H.248 protocol must not require an MGC to implement an SNMP manager function in order to discover capabilities of an MG. Thus, resources discovery is not under the scope of SNMP. 6. Solution using ServiceChange command Megaco/H.248 protocol currently offers the ServiceChange command. This command allows a MG to notify a MGC that a Termination, group of Terminations or a whole MG has just been returned to service. The ServiceChangeProfile parameter specifies what features of the Megaco/H.248 protocol is implemented by the MG. This solution proposes to extend the meaning of the ServiceChangeProfile parameter in order to express the media functions supported by the MG. Thus, when it starts up, the MG announces its media functions with a ServiceChangeProfile value issued in a ServiceChange command. The main drawback of this solution is its lack of flexibility. A profile value must reflect each potential set of media functions possessed by a MG. Levy, Anquetil Informational - Expires May 2001 2 Media Gateway Discovery November 2000 Furthermore, the failure of an hardware resource in an MG may cause the alteration of its media resources. This change should be reflected by a new profile value. 7. Solution using AuditValue command. Megaco/H.248 protocol currently offers the AuditValue commands. The command returns the current values of the properties, events, signals and statistics associated with terminations. The knowledge of terminations gives an external vision of the MG but it does not inform how a context of the MG is able to associate the terminations. The solution proposes to make use of the AuditValue command to discover the internal media functions of the MG. 7.1 Atomic model The solution relies on an atomic model of the media functions to be performed by the MG. It is based on the four logically separated basic functions: 1. Modify the transport without modifying the media encoding (application part) (e.g. moving from PCMU/RTP to G711 mu-law/TDM). 2. Modify the media encoding using the same transport (e.g. moving from PCMU/RTP to GSM/RTP). 3. Mix media streams using the same transport and the same media encoding (e.g. mix three PCMA/RTP flows for conferencing purposes). 4. Terminate (or initiate) a media stream (e.g. terminate PCMU/RTP acting as an Interactive Voice Response unit). The functions may be : . oneway or bothway for functions 1 and 2. . send, receive or bothway for function 4. Any context realized by the MG should result in a combination of the previous basic functions. For instance, a context associating a termination with a stream G723 over RTP and a termination with a PCMU over a TDM channel makes use of the transport modification and the encoding modification functions. 7.2 Extension Description The extension introduces MediaResources and MediaFunctions descriptors. General knowledge of the descriptors semantics provides interoperability between MG and MGC. An MGC issues an AuditValue command with a MediaResources Descriptor as parameter to an MG which answers with its available media resources in the value of the descriptor. 7.2.1 MediaFunctions Descriptor Levy, Anquetil Informational - Expires May 2001 3 Media Gateway Discovery November 2000 The Media Functions descriptor defines a set of identical functions such as those detailed in section 7.1. The descriptor includes the following properties: . FunctionID . Type . Cardinality . Description . Condition . Direction The FunctionID identifies the MediaFunctions. The possible values for the Type property are: Transportmodification, Encodingmodification, Mixstream and Terminatestream. The Cardinality value defines the number of identical functions that may be realized by the MG. The Description value describes the core of the function. The syntax of this value is not completely defined in this version of the draft. In general, the value shall be a string with the input value followed by the output value (if any) separated by a "-" character. The input and output value may be multiple: "|" character separates alternative values, "*" character describes a factorization, "/" describes an ordered succession. For Transportmodification, the input and output values define the transport protocol before and after the modification. "/" character is used to separate multiple successive protocol layer. It begins with the upper layer and terminates with the lower specified layer. For Encodingmodification, the input and output values describe the media format before and after the modification. For audio media, it means the audio format. Eventual additional encoding parameters such as the sampling rate may be added after a "/" character. For Mixstream, the input and output values describe the media encoding before and after the mixing. An integer value followed by "*" character is used to express the maximum number of input streams that may be mixed. For Terminatestream, the input value describes the media encoding getting in or out the MG. The Condition value defines the necessary conditions to realize the function. For Transportmodification, it describes the media encoding required for the modification. As for the other functions, it describes the transport protocol required for the modification. The Condition may have the ALL value. The Direction property can have the following values : Bothway, Oneway, Send, Receive. Bothway means that the transformation is bi-directional and symmetrical. Levy, Anquetil Informational - Expires May 2001 4 Media Gateway Discovery November 2000 Oneway means that the modification only operates from input stream to output stream. Send and receive are only for Terminatestream type function. It means that the function initiates (and respectively ends) the media stream. It is noted that properties corresponding to other transformation (such as echo cancellation) should be added to the descriptor through packages. 7.2.2 MediaRessources Descriptor The Media Resources descriptor groups MediaFunctions which forms the simultaneous media resources of an MG. 7.2.3 Audit Descriptor The Audit Descriptor specifies the list of descriptors to be returned by the reply. In addition to possible items defined in [3], MediaResources is provided in order to audit the media resources of an MG. 7.3 Call Flow Example This example illustrates the uses of the presented mechanism to discover the media resources of a Media Gateway. We assume that a Media Gateway Controller (MGC1) controls a Media Gateway (MG1). The registration of MG1 is not shown with these call flows but it is supposed that it has been previously performed. 1. The MGC1 decides to audit the MG1 media resources. It issues an AuditValue command to MG1 From MGC1 to MG1: MEGACO/1 MGC1 Transaction = 10001 { Context = Null { AuditValue = Root { Audit{MediaResources } } } } 2. The MG1 replies. In this example, MG1 is able to handle 16 simultaneous bi-directional transport modifications from RTP to TDM with any media encoding AND to handle 8 simultaneous bi-directional media encoding conversions from PCMU to G723 or GSM using RTP transport. From MG1 to MGC1: MEGACO/1 MG1 Reply = 10001 { Context = Null { AuditValue = Root { MediaResources { Levy, Anquetil Informational - Expires May 2001 5 Media Gateway Discovery November 2000 MediaFunctions = 1 { Type = Transportmodification, Cardinality = 16, Description = RTP/UDP/IPv4 - TDM, Condition = *, Direction = Bothway }, MediaFunctions = 2 { Type = Encodingmodification, Cardinality = 8, Description = PCMU-G723|GSM, Condition = RTP, Direction = Bothway } } } } } 7.4 Implementation considerations An audit of the available media resources of an MG should be performed by the MGC, immediately after the MG has restarted. The MGC detects the restart, because it receives a ServiceChange command with ServiceChangeMethod corresponding to "Restart". After this audit, the MGC is able to control the resources of the MG in order to realize media connections. Under normal utilization, at any time, the MGC may ask the MG to return its available media resources. However, due to synchronization problems, some MG may fail in computing available resources, while resources are being allocated. In case of failure, the MG reports a "502-Not ready" error code. Therefore, it is highly recommended, that once knowing the initial media resources of the MG, the MGC performs its own accountancy of the available resources of the MG. Thus, the MGC does not need to audit the available resources anymore, until the MG stops. 8. Conclusion Experiment demonstrates, that it is an error to oppose the 2 previously described solutions. While the ServiceChangeProfile allows to get the high level characteristics of a MG, the MediaResources descriptor gives precise knowledge of its media resources. Thus, authors are convinced of the interest of both solutions. Furthermore, SDP-ng initiative [5] aims at developing a successor of SDP [6] allowing to describe capabilities of a system. Therefore, Levy, Anquetil Informational - Expires May 2001 6 Media Gateway Discovery November 2000 future works would carry on integrating the MediaResources and MediaDescription descriptor into SDP-ng. 9. Security Considerations Already covered by [3]. No specific extension needed for the proposed solutions. 10. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 3 ITU-T Recommendation H.248, "Gateway Control Protocol", Geneva, June 2000. See also RFC 2885, August 2000. 4 Greene, Ramalho, Rosen, "Media Gateway Control Protocol Architecture and Requirements", RFC 2805, April 1999. 5 Kutscher, Ott, Bormann, "Requirements for Session Description and Capability Negotiation", draft-kutscher-mmusic-sdpng-req-00.txt, July 2000. 6 Handley, Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. 11. Author's Addresses Thomas Levy Alcatel Route de Nozay 91461 Marcoussis France Phone: + 33 (0)1 69 63 41 02 Email: thomas.levy@ms.alcatel.fr Laurent-Philippe Anquetil Alcatel Route de Nozay 91461 Marcoussis France Phone: + 33 (0)1 69 63 17 03 Email: laurent.anquetil@ms.alcatel.fr Levy, Anquetil Informational - Expires May 2001 7 Media Gateway Discovery November 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Levy, Anquetil Informational - Expires May 2001 8 --------------0F5F0059D8CF0FF45F94F71B-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 20 09:41:58 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11299 for ; Mon, 20 Nov 2000 09:41:57 -0500 (EST) Received: from standards (47.234.32.16:3096) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB7D77@standards.nortelnetworks.com>; Mon, 20 Nov 2000 9:23:40 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 118841 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Nov 2000 09:23:40 -0500 Received: from zrchh190 (47.158.65.22:59526) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB7D55@standards.nortelnetworks.com>; Mon, 20 Nov 2000 9:13:39 -0500 Received: from smtprch2.nortel.com (actually erchg0k) by zrchh190; Mon, 20 Nov 2000 08:29:52 -0600 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Mon, 20 Nov 2000 08:24:11 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 20 Nov 2000 08:28:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C052FE.0D94CBC0" X-Orig: X-Orig: Message-ID: <353093573B82D411889E0000F808216648E4DF@zcard00q.ca.nortel.com> Date: Mon, 20 Nov 2000 08:27:46 -0600 Reply-To: "Blatherwick, Peter" Sender: "Media Gateway Control (megaco)" From: "Blatherwick, Peter" Subject: Re: H.248 Implementors' Guide at SG16 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_01C052FE.0D94CBC0 Content-Type: text/plain; charset="iso-8859-1" Darned if I could find it. Not in any other obvious folder I could find either... Did the stuff re package extension rules we were on about a while back (wording clarifications) make it in? Peter Blatherwick -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] Sent: Wednesday, November 15, 2000 12:31 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: H.248 Implementors' Guide at SG16 G'Day all, The updated Implementors' Guide from the SG16 Meeting is now available at: ftp://standard.pictel.com/avc-site/Incoming/ plen-xxx_H248_Implementors_guide_v7.pdf or plen-xxx_H248_Implementors_guide_v7.doc This is now going for approval. Cheers, Christian ------_=_NextPart_001_01C052FE.0D94CBC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: H.248 Implementors' Guide at SG16

Darned if I could find it.  Not in any other = obvious folder I could find either... 

Did the stuff re package extension rules we were on = about a while back (wording clarifications) make it in? 

Peter Blatherwick

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@ER= ICSSON.COM]
Sent: Wednesday, November 15, 2000 12:31
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: H.248 Implementors' Guide at SG16


G'Day all,

The updated Implementors' Guide from the SG16 Meeting = is now available
at:
ftp://standard.pictel.com/avc-site/Incoming/

plen-xxx_H248_Implementors_guide_v7.pdf
or
plen-xxx_H248_Implementors_guide_v7.doc

This is now going for approval.

Cheers, Christian

------_=_NextPart_001_01C052FE.0D94CBC0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 20 12:27:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01190 for ; Mon, 20 Nov 2000 12:27:42 -0500 (EST) Received: from standards (47.234.32.16:2196) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB7F18@standards.nortelnetworks.com>; Mon, 20 Nov 2000 12:08:58 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 119434 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Nov 2000 12:08:57 -0500 Received: from ind.alcatel.com (postal.xylan.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB7F0D@standards.nortelnetworks.com>; Mon, 20 Nov 2000 11:58:57 -0500 Received: from mailhub.ind.alcatel.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with ESMTP id JAA21939 for ; Mon, 20 Nov 2000 09:15:53 -0800 (PST) X-Origination-Site: Received: from newman.xylan.com (localhost [127.0.0.1]) by mailhub.ind.alcatel.com (8.9.3+Sun/8.9.3/(mailhub 3.2.4 [HUB])) with ESMTP id JAA03919 for ; Mon, 20 Nov 2000 09:15:31 -0800 (PST) X-InterScan: Passed Received: from ind.alcatel.com ([10.193.100.186]) by newman.xylan.com (Netscape Messaging Server 4.15) with ESMTP id G4C2PS00.TYQ for ; Mon, 20 Nov 2000 09:17:52 -0800 X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A196ACE.C6926A2A@ind.alcatel.com> Date: Mon, 20 Nov 2000 10:17:50 -0800 Reply-To: Isabelle Cnudde Sender: "Media Gateway Control (megaco)" From: Isabelle Cnudde Organization: Alcatel Subject: MEGACO meeting To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit The meeting will take place in Golden Gate, 9:30. Isabelle -- Isabelle Cnudde ----------------- CID - media gateway tel: +1 408 957 6234 | A L C A T E L | 720 South Milpitas Blvd fax: +1 408 941 1818 ----------------- Milpitas, CA 95035 mailto:Isabelle.Cnudde@ind.alcatel.com USA From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 20 12:35:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03139 for ; Mon, 20 Nov 2000 12:35:39 -0500 (EST) Received: from standards (47.234.32.16:2196) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB7F4E@standards.nortelnetworks.com>; Mon, 20 Nov 2000 12:17:04 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 119443 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Nov 2000 12:17:04 -0500 Received: from ind.alcatel.com (postal.xylan.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB7F14@standards.nortelnetworks.com>; Mon, 20 Nov 2000 12:07:03 -0500 Received: from mailhub.ind.alcatel.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with ESMTP id JAA22412 for ; Mon, 20 Nov 2000 09:24:00 -0800 (PST) X-Origination-Site: Received: from newman.xylan.com (localhost [127.0.0.1]) by mailhub.ind.alcatel.com (8.9.3+Sun/8.9.3/(mailhub 3.2.4 [HUB])) with ESMTP id JAA05232 for ; Mon, 20 Nov 2000 09:23:38 -0800 (PST) X-InterScan: Passed Received: from ind.alcatel.com ([10.193.100.186]) by newman.xylan.com (Netscape Messaging Server 4.15) with ESMTP id G4C33B00.8ZY for ; Mon, 20 Nov 2000 09:25:59 -0800 X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------C5B1EA12C5C630BDE6E8942D" Message-ID: <3A196CB6.49AE2C87@ind.alcatel.com> Date: Mon, 20 Nov 2000 10:25:58 -0800 Reply-To: Isabelle Cnudde Sender: "Media Gateway Control (megaco)" From: Isabelle Cnudde Organization: Alcatel Subject: [Fwd: FW: Question about the Trillium stack] To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------C5B1EA12C5C630BDE6E8942D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Don't remember if I forward you those answers from Trillium... Isabelle -- Isabelle Cnudde ----------------- CID - media gateway tel: +1 408 957 6234 | A L C A T E L | 720 South Milpitas Blvd fax: +1 408 941 1818 ----------------- Milpitas, CA 95035 mailto:Isabelle.Cnudde@ind.alcatel.com USA --------------C5B1EA12C5C630BDE6E8942D Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from mailhub.ind.alcatel.com ([198.206.181.70]) by newman.xylan.com (Netscape Messaging Server 4.15) with ESMTP id G3ZY5900.A9M for ; Mon, 13 Nov 2000 20:07:57 -0800 Received: from ind.alcatel.com (localhost [127.0.0.1]) by mailhub.ind.alcatel.com (8.9.3+Sun/8.9.3/(mailhub 3.2.3 [HUB])) with ESMTP id UAA24426 for ; Mon, 13 Nov 2000 20:05:32 -0800 (PST) X-InterScan: Passed Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (Alcatel-IND-mgw 3.0 [in])) with ESMTP id UAA29697 for ; Mon, 13 Nov 2000 20:05:56 -0800 (PST) Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id EAA19240 for ; Tue, 14 Nov 2000 04:06:08 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 14 Nov 2000 04:04:50 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Nov 2000 20:04:49 -0800 Message-ID: From: "Goel, Mukesh" To: "'Isabelle Cnudde'" Cc: "Robinson, Loraine" , "Odermatt, Andre" , "Chan, Vien" , "Bhan, Mahesh" Subject: RE: FW: Question about the Trillium stack Date: Mon, 13 Nov 2000 20:04:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Mozilla-Status2: 00000000 Hi Isabelle, Please find the responses embedded. Regards, Mukesh. -----Original Message----- Here are some further questions we have on the stack. Could you help us with an answer? Q1. For a wild card response, what is the format of the response that the stack expects from the application and in which data structures? Answer: There is one example in H.248 implmenter's guide where it uses W- in Audit reply. The ABNF in RFC and H.248 shows W- being used in Requests only. We have not yet come to implementing all issues in implementer's guide as it is still evolving at this point. We would implement wilcard response for Audit in the released code. Q2. Does trillium support a list of termination's and a list of context ID's in the response? If so, in which data structure? Answer: Yes, we do support this complete hierarchy. Please follow structures in mgt.x. Take MgMgcoTxnReply as the root and go all the way up to MgMgcoCmdReply. MgMgcoTxnReply->MgMgcoActnReplyLst->MgMgcoActnReply (per context) ->MgMgcoCxtCmdReply->mgMgcoCmdReplyLst->MgMgcoCmdReply (per termination) Q3. In the following data structure: /**** Termination ID ****/ typedef struct mgMgcoTermId { TknU8 type; /* "ROOT", "*", "$" or other */ MgMgcoPathName name; /* If other */ } MgMgcoTermId; Questions: a. If term_id is 'ROOT', then type = MGT_TERMID_ROOT and what is the value of name? b. If term_id is partial wildcard, such 'abc*', then what are the values of type and name? Answer: a) In case of MGT_TERMID_ROOT, the "name" is not present and is not significant. b) In case of partial wildcard, "type" is MGT_TERMID_OTHER, "name" is 'abc*'. Thanks a lot! Isabelle --- Isabelle Cnudde ----------------- CID - media gateway tel: +1 408 957 6234 | A L C A T E L | 720 South Milpitas Blvd fax: +1 408 941 1818 ----------------- Milpitas, CA 95035 mailto:Isabelle.Cnudde@ind.alcatel.com USA --------------C5B1EA12C5C630BDE6E8942D-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 20 12:35:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03157 for ; Mon, 20 Nov 2000 12:35:40 -0500 (EST) Received: from standards (47.234.32.16:2196) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB7F5A@standards.nortelnetworks.com>; Mon, 20 Nov 2000 12:18:38 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 119447 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Nov 2000 12:18:38 -0500 Received: from ind.alcatel.com (postal.xylan.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB7F17@standards.nortelnetworks.com>; Mon, 20 Nov 2000 12:08:38 -0500 Received: from mailhub.ind.alcatel.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with ESMTP id JAA22470 for ; Mon, 20 Nov 2000 09:25:35 -0800 (PST) X-Origination-Site: Received: from newman.xylan.com (localhost [127.0.0.1]) by mailhub.ind.alcatel.com (8.9.3+Sun/8.9.3/(mailhub 3.2.4 [HUB])) with ESMTP id JAA05392 for ; Mon, 20 Nov 2000 09:25:13 -0800 (PST) X-InterScan: Passed Received: from ind.alcatel.com ([10.193.100.186]) by newman.xylan.com (Netscape Messaging Server 4.15) with ESMTP id G4C35X00.KXH for ; Mon, 20 Nov 2000 09:27:33 -0800 X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------87EF07F50FD2C1F998D18DCE" Message-ID: <3A196D14.F679AF21@ind.alcatel.com> Date: Mon, 20 Nov 2000 10:27:32 -0800 Reply-To: Isabelle Cnudde Sender: "Media Gateway Control (megaco)" From: Isabelle Cnudde Organization: Alcatel Subject: [Fwd: [Fwd: FW: Question about the Trillium stack]] To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------87EF07F50FD2C1F998D18DCE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Oops! Please ignore my previous mail. It was not intended for this audience! Isabelle --------------87EF07F50FD2C1F998D18DCE Content-Type: message/rfc822 Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <3A196CB6.49AE2C87@ind.alcatel.com> Date: Mon, 20 Nov 2000 10:25:58 -0800 From: Isabelle Cnudde Organization: Alcatel X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en MIME-Version: 1.0 To: megaco Subject: [Fwd: FW: Question about the Trillium stack] Content-Type: multipart/mixed; boundary="------------C5B1EA12C5C630BDE6E8942D" This is a multi-part message in MIME format. --------------C5B1EA12C5C630BDE6E8942D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Don't remember if I forward you those answers from Trillium... Isabelle -- Isabelle Cnudde ----------------- CID - media gateway tel: +1 408 957 6234 | A L C A T E L | 720 South Milpitas Blvd fax: +1 408 941 1818 ----------------- Milpitas, CA 95035 mailto:Isabelle.Cnudde@ind.alcatel.com USA --------------C5B1EA12C5C630BDE6E8942D Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from mailhub.ind.alcatel.com ([198.206.181.70]) by newman.xylan.com (Netscape Messaging Server 4.15) with ESMTP id G3ZY5900.A9M for ; Mon, 13 Nov 2000 20:07:57 -0800 Received: from ind.alcatel.com (localhost [127.0.0.1]) by mailhub.ind.alcatel.com (8.9.3+Sun/8.9.3/(mailhub 3.2.3 [HUB])) with ESMTP id UAA24426 for ; Mon, 13 Nov 2000 20:05:32 -0800 (PST) X-InterScan: Passed Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (Alcatel-IND-mgw 3.0 [in])) with ESMTP id UAA29697 for ; Mon, 13 Nov 2000 20:05:56 -0800 (PST) Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id EAA19240 for ; Tue, 14 Nov 2000 04:06:08 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 14 Nov 2000 04:04:50 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Nov 2000 20:04:49 -0800 Message-ID: From: "Goel, Mukesh" To: "'Isabelle Cnudde'" Cc: "Robinson, Loraine" , "Odermatt, Andre" , "Chan, Vien" , "Bhan, Mahesh" Subject: RE: FW: Question about the Trillium stack Date: Mon, 13 Nov 2000 20:04:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Mozilla-Status2: 00000000 Hi Isabelle, Please find the responses embedded. Regards, Mukesh. -----Original Message----- Here are some further questions we have on the stack. Could you help us with an answer? Q1. For a wild card response, what is the format of the response that the stack expects from the application and in which data structures? Answer: There is one example in H.248 implmenter's guide where it uses W- in Audit reply. The ABNF in RFC and H.248 shows W- being used in Requests only. We have not yet come to implementing all issues in implementer's guide as it is still evolving at this point. We would implement wilcard response for Audit in the released code. Q2. Does trillium support a list of termination's and a list of context ID's in the response? If so, in which data structure? Answer: Yes, we do support this complete hierarchy. Please follow structures in mgt.x. Take MgMgcoTxnReply as the root and go all the way up to MgMgcoCmdReply. MgMgcoTxnReply->MgMgcoActnReplyLst->MgMgcoActnReply (per context) ->MgMgcoCxtCmdReply->mgMgcoCmdReplyLst->MgMgcoCmdReply (per termination) Q3. In the following data structure: /**** Termination ID ****/ typedef struct mgMgcoTermId { TknU8 type; /* "ROOT", "*", "$" or other */ MgMgcoPathName name; /* If other */ } MgMgcoTermId; Questions: a. If term_id is 'ROOT', then type = MGT_TERMID_ROOT and what is the value of name? b. If term_id is partial wildcard, such 'abc*', then what are the values of type and name? Answer: a) In case of MGT_TERMID_ROOT, the "name" is not present and is not significant. b) In case of partial wildcard, "type" is MGT_TERMID_OTHER, "name" is 'abc*'. Thanks a lot! Isabelle --- Isabelle Cnudde ----------------- CID - media gateway tel: +1 408 957 6234 | A L C A T E L | 720 South Milpitas Blvd fax: +1 408 941 1818 ----------------- Milpitas, CA 95035 mailto:Isabelle.Cnudde@ind.alcatel.com USA --------------C5B1EA12C5C630BDE6E8942D-- --------------87EF07F50FD2C1F998D18DCE-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 20 13:15:05 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14936 for ; Mon, 20 Nov 2000 13:15:05 -0500 (EST) Received: from standards (47.234.32.16:2196) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB7FA3@standards.nortelnetworks.com>; Mon, 20 Nov 2000 12:55:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 119638 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Nov 2000 12:55:54 -0500 Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB7FA2@standards.nortelnetworks.com>; Mon, 20 Nov 2000 12:55:54 -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 NAA17213 for ; Mon, 20 Nov 2000 13:12:44 -0500 (EST) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id NAA17204 for ; Mon, 20 Nov 2000 13:12:44 -0500 (EST) Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA22420; Mon, 20 Nov 2000 13:12:43 -0500 Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA22417; Mon, 20 Nov 2000 13:12:43 -0500 X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A196950.E88B1C0@lucent.com> Date: Mon, 20 Nov 2000 13:11:28 -0500 Reply-To: Troy Cauble Sender: "Media Gateway Control (megaco)" From: Troy Cauble Subject: Multiple SDP "blocks" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit In the call flow example, Appendix A.1.2 of the 6/00 ITU document, item 12 shows the following: Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 a=ptime:30 v=0 c=IN IP4 $ m=audio $ RTP/AVP 0 } and states: "NOTE - The MGC its preferred parameter values as a series of sdp blocks in Local. The MGC fills in the Local Descriptor in the Reply." Is this really the way we want to present choices to the MGC? SDP already has mechanisms to support multiple suggested parameter values. For example, this is valid, and equivalent to the intent above: v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 0 a=ptime:30 SDP also has mechanisms to specify multiple media streams per session. So unless we really need to specify multiple SESSIONS, I don't see a need for multiple "blocks" delimited by v=0 lines. -troy From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 20 13:44:34 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20977 for ; Mon, 20 Nov 2000 13:44:33 -0500 (EST) Received: from standards (47.234.32.16:2196) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8003@standards.nortelnetworks.com>; Mon, 20 Nov 2000 13:24:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 119765 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Nov 2000 13:24:53 -0500 Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8002@standards.nortelnetworks.com>; Mon, 20 Nov 2000 13:24:53 -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 NAA17876 for ; Mon, 20 Nov 2000 13:41:43 -0500 (EST) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id NAA17872 for ; Mon, 20 Nov 2000 13:41:43 -0500 (EST) Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA22679; Mon, 20 Nov 2000 13:41:42 -0500 Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA22676; Mon, 20 Nov 2000 13:41:41 -0500 X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A19701B.616DE236@lucent.com> Date: Mon, 20 Nov 2000 13:40:27 -0500 Reply-To: Troy Cauble Sender: "Media Gateway Control (megaco)" From: Troy Cauble Subject: Annex C questions To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Why is there an entire Annex of properties that can only be encoded in binary form? Or can all of the properties in Annex C be encoded in SDP? (Doesn't seem likely.) If so, how? Isn't it a fundamental goal of the protocol to support all messages in a text or ASN.1 encoding? -troy From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 20 13:44:35 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20984 for ; Mon, 20 Nov 2000 13:44:34 -0500 (EST) Received: from standards (47.234.32.16:2196) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB800E@standards.nortelnetworks.com>; Mon, 20 Nov 2000 13:25:22 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 119730 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Nov 2000 13:25:21 -0500 Received: from zrchh190 (47.158.65.22:52073) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB7FE8@standards.nortelnetworks.com>; Mon, 20 Nov 2000 13:15:21 -0500 Received: from smtprch1.nortel.com (actually erchg0j) by zrchh190; Mon, 20 Nov 2000 12:28:58 -0600 Received: from zcard015.ca.nortel.com (actually zcard015) by smtprch1.nortel.com; Mon, 20 Nov 2000 12:19:07 -0600 Received: from ztcfd004.ca.nortel.com ([47.211.192.106]) by zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id W4S0XH3A; Mon, 20 Nov 2000 13:19:09 -0500 Received: from americasm10.nt.com (michael-brown.us.nortel.com [47.142.213.27]) by ztcfd004.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id T7R3C6B6; Mon, 20 Nov 2000 13:19:02 -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: <3A18ADE7.EA84BC2C@ipdialog.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Message-ID: <3A196D0D.BE562B61@americasm10.nt.com> Date: Mon, 20 Nov 2000 13:27:25 -0500 Reply-To: "Brown, Michael" Sender: "Media Gateway Control (megaco)" From: "Brown, Michael" Organization: Nortel Networks Subject: Re: Announcement Package, noc To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit The link is to the document on the IETF Megaco web site. This was up for decision last week in Geneva. Any changes made in Geneva would not be reflected in this document. http://ietf.org/internet-drafts/draft-ietf-megaco-h248k-00.txt Cheers, Michael Brown Paul Long wrote: > ...except of course, as I just noticed, a link to that particular annex. Sorry. > :-) > > Paul Long wrote: > > > Takao, > > > > Everything you need should be here: > > http://www.packetizer.com/iptel/h248/doc_status.html > > > > Paul Long > > ipDialog, Inc. > > > > -----Original Message----- > > From: Media Gateway Control (megaco) > > [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Matsuda > > Sent: Sunday, November 19, 2000 8:03 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Announcement Package, noc > > > > Hello Mr.Christian, > > > > What is the URL to get the most recent version of H.248 ANNEX K? > > > > Best regards, > > Takao From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 20 13:44:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21000 for ; Mon, 20 Nov 2000 13:44:35 -0500 (EST) Received: from standards (47.234.32.16:2196) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8023@standards.nortelnetworks.com>; Mon, 20 Nov 2000 13:26:20 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 119733 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Nov 2000 13:26:20 -0500 Received: from zrchh190 (47.158.65.22:52188) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB7FEB@standards.nortelnetworks.com>; Mon, 20 Nov 2000 13:16:20 -0500 Received: from smtprch2.nortel.com (actually erchg0k) by zrchh190; Mon, 20 Nov 2000 12:33:30 -0600 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Mon, 20 Nov 2000 12:27:50 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 20 Nov 2000 12:32:00 -0600 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD1102D9FCBF@zcard00g.ca.nortel.com> Date: Mon, 20 Nov 2000 12:31:58 -0600 Reply-To: "Taylor, Tom-PT" Sender: "Media Gateway Control (megaco)" From: "Taylor, Tom-PT" Subject: Re: Statistics X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM [Old mail, issue still open.] Agreed that we have a bug, but I'm not sure it matters in practice. The typical usage of RTP terminations will, I suspect, mean just one stream per termination. Without that assumption, it appears that the text of the package description contradicts the syntax of the statistics descriptor. One way to solve it is to specify in the I-G that each statistic is to be reported as a series of "pkgdName EQUAL VALUE" entries, one per stream (with pkgdName repeated), in increasing order of stream number active on the termination. This respects the existing syntax but gives us a workaround until we need a more permanent solution. > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > Sent: Thursday, October 19, 2000 10:20 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Statistics > > > Oh cool. I don't think we have ever talked about this, > stream specific statistics! Hmmmmm. > > So we would want to add (an optional) StreamId to Statistics > Descriptor > Statistics=1{rtp/pr=.... > and you might get more than one Statistics descriptor in the reply. > > Wow. This is a real bug in the protocol I think! > > Brian > > > > -----Original Message----- > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > Sent: Thursday, October 19, 2000 9:51 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Statistics > > > > > > Section E.12.4 states that statistics like > > jitter, packet loss,etc are described on an > > RTP stream. If only one RTP stream is > > present on a termination its straitforward > > to send statistics. But if multiple streams > > are created on a termination How this > > reporting is done? > > > > -Madhubabu > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 20 15:46:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14219 for ; Mon, 20 Nov 2000 15:46:36 -0500 (EST) Received: from standards (47.234.32.16:4607) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB80E1@standards.nortelnetworks.com>; Mon, 20 Nov 2000 15:27:59 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 120023 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Nov 2000 15:27:59 -0500 Received: from zrchh190 (47.158.65.22:64296) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB80C1@standards.nortelnetworks.com>; Mon, 20 Nov 2000 15:17:58 -0500 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by zrchh190; Mon, 20 Nov 2000 14:34:33 -0600 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Mon, 20 Nov 2000 14:01:35 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 20 Nov 2000 14:01:32 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD1102D9FD94@zcard00g.ca.nortel.com> Date: Mon, 20 Nov 2000 14:01:09 -0500 Reply-To: "Taylor, Tom-PT" Sender: "Media Gateway Control (megaco)" From: "Taylor, Tom-PT" Subject: Re: physical and ephemeral terminations X-To: njain@assuredaccess.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM [Old issue, apparently not closed.] Two cases: (1) The initial ADD does not specify enough properties to remove the ambiguity. In this case, the termination chosen is a shell, ready to receive further information. I do see a theoretical possibility that a termination is chosen according to one naming scheme, but has properties applied to it in a subsequent MODIFY which make that naming scheme inappropriate. I suppose the MG could reject the ADD request on grounds of ambiguity, or else reject the MODIFY because of the contradiction. In the latter case, the MGC would have to subtract the invalid termination and add another, this time with enough properties specified that an appropriate name is chosen. (2) The initial ADD specifies enough properties that the right termination can be assigned. I would judge this to be the preferable way of doing things. > -----Original Message----- > From: Nitin Jain [mailto:njain@ASSUREDACCESS.COM] > Sent: Thursday, October 19, 2000 1:25 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: physical and ephemeral terminations > > > Hi all, > > Sorry I am late into this discussion. From the archives, I could not > find out what the consensus was for creating an ephemeral termination > or selecting a physical termination for CHOOSE in an ADD command. > > If the physical termination can have the localDescriptor properties, > how do we distinguish between a CHOOSE for ephemeral termination or > Physical termination when "TermID=$" in an ADD command. > > Thanks. > Nitin > > > -----Orig. Message------- > > Any termination can have properties, defined by the packages > implemented on > it. > Look at the IPPhone packages for example. > > Brian > > -----Original Message----- > From: Shlomo Kabaz ECItelecom [mailto:Shlomo.Kabaz@ECITELE.COM] > Sent: Tuesday, October 10, 2000 5:21 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: physical and ephemeral terminations > > > Hi , all ! > > Does the physical termination have properties , because in > the examples > in > the Rfc all the > properties of the "connection" is given in the ephemeral > termination and > the elements that are given to > physical is events and signals . > > Thanks , Shlomo > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 20 16:13:58 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18099 for ; Mon, 20 Nov 2000 16:13:57 -0500 (EST) Received: from standards (47.234.32.16:1967) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB812E@standards.nortelnetworks.com>; Mon, 20 Nov 2000 15:55:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 120158 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Nov 2000 15:55:31 -0500 Received: from zmers013 (47.124.1.40:54921) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8129@standards.nortelnetworks.com>; Mon, 20 Nov 2000 15:45:29 -0500 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by zmers013; Mon, 20 Nov 2000 15:58:42 -0500 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Mon, 20 Nov 2000 15:46:22 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 20 Nov 2000 15:46:13 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD1102DA0021@zcard00g.ca.nortel.com> Date: Mon, 20 Nov 2000 15:45:47 -0500 Reply-To: "Taylor, Tom-PT" Sender: "Media Gateway Control (megaco)" From: "Taylor, Tom-PT" Subject: Re: Signal lists X-To: kris_albert@lycos.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM [More old business.] As per other messages in this thread: -- if the new descriptor arrives while s2 or s3 is playing, playout of the list is halted -- if the new descriptor arrives while s1 or s4 is playing, playout of the list continues. > -----Original Message----- > From: Kris Albert [mailto:kris_albert@lycos.com] > Sent: Thursday, November 02, 2000 11:02 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM; Taylor, Tom-PT > [NORSE:B901:EXCH] > Subject: Re: Signal lists > > > I will appreciate if you can give me a example for the case > > when MG is playing a signal list = (s1ka, s2, s3, s4ka) > and MG receives a replacement signal descriptor with same > signal list, > what will the processing > 1) when S1KA is playing currently > 2) when S2 is playing currently > How the keepActive status will work on the case of signal list.? > > thanks > Kris > > -- > > On Thu, 2 Nov 2000 10:23:39 > Tom-PT Taylor wrote: > >I stand corrected and apologize for my carelessness. You're > right. So the > >only thing that determines whether the signal list keeps > playing is the > >keepActive setting (or embedded SignalsDescriptor) in the > event itself. > > > >> -----Original Message----- > >> From: Sandeep Gautam [mailto:sgautam@HSS.HNS.COM] > >> Sent: Thursday, November 02, 2000 8:40 AM > >> To: MEGACO@STANDARDS.NORTELNETWORKS.COM > >> Subject: Re: Signal lists > >> > >> > >> Hi, > >> The keepactive flag that comes in the signals descriptor is > >> not remebered. The > >> fact whether the currently playing signal arrived with a > >> keepcative flag or not > >> is immaterial for subsequent processing. > >> > >> According to text > >> > >> Signals present in the replacement descriptor and > >> containing the KeepActive > >> flagshall be continued if they are currently playing and > >> have not already > >> completed. If a replacement signal descriptor contains a > >> signal that is not > >> currently playing and contains the KeepActive flag, that > >> signal SHALL be > >> ignored > >> > >> Thus the scope of keepactive flag is limited to the signal > >> descriptor processing > >> of the descriptor in which it arrived. > >> > >> When subsequently an event is detected the stopping of the > >> signal( which may > >> have arrived with a keepactive flag) is solely governed by > >> the keepactive flag > >> associated with the event that is detected. Thus point no. 2 > >> is invalid. If the > >> KA of event detected is not set then the MG should stop > >> application of all > >> active signals. > >> > >> > >> Is this understanding correct? > >> Regards, > >> Sandy G > >> > >> 1) Check for event flag. If there is one, leave signals playing. > >> 2) Otherwise check flag for each signal and keep playing or > >> terminate as > >> indicated. > >> > >> > -----Original Message----- > >> > From: Kris Albert [mailto:kris_albert@lycos.com] > >> > Sent: Thursday, November 02, 2000 7:57 AM > >> > To: Taylor, Tom-PT [NORSE:B901:EXCH] > >> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > >> > Subject: Re: Signal lists > >> > > >> > > >> > > >> > ----- > >> > > Signals can also have a KeepActive flag. > >> > > >> > That's true, but my question is different, I want to ask > >> > whether on the detection of event, do we process only the > >> > KeepActive flag associated with Events, or do we also > >> > consider the KeepActive flag associated with the active Signals. > >> > > >> > thanks > >> > Kris > >> > > >> > > > >> > > > -----Original Message----- > >> > > > From: Kris Albert [mailto:kris_albert@LYCOS.COM] > >> > > > Sent: Thursday, November 02, 2000 1:27 AM > >> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > >> > > > Subject: Re: Signal lists > >> > > > > >> > > > > >> > > > Hi Christian, > >> > > > I have few questions on your explanation. > >> > > > > >> > > > > [CHG] I guess you can view this is several ways. The > >> > > > KeepActive on ALL > >> > > > > signals certainly makes sense when you don't want any > >> > > > interruption. But > >> > > > > is it erroneous to specify Keepactive on different signals? > >> > > > Certainly > >> > > > > weird behaviour but you may want the initial part of a > >> > > > message to play > >> > > > > irrespective of what event happens and you don't care about > >> > > > the rest of > >> > > > > the signal. I would say that the Keepactive pertains to a > >> > > > moment in time > >> > > > > in the playback of a message. > >> > > > > ie. Signal list = (s1ka, s2, s3, s4ka) > >> > > > > If you receive an event when S1KA is playing the whole > >> > list plays. > >> > > > > If you receive an event when S2 is playing the whole > >> list stops. > >> > > > > >> > > > I am not able to understand your example here. > >> > > > It is specified in MEGACO that " Normally, recognition of an > >> > > > event shall cause any active signals to stop. When KeepActive > >> > > > is specified in the event, the MG shall not interrupt any > >> > > > signals active on the Termination on which the event is > >> detected." > >> > > > > >> > > > how does the 'KeepActive' status of signals matter here. Only > >> > > > KeepActive Flag associated with Event Defination should be > >> > > > considered. Otherwise Event Defination should have a embedded > >> > > > Signal Descriptor. > >> > > > > >> > > > I will appriciate if you please further explain your example > >> > > > w.r.t. the arrival of new signal descriptor with the same > >> > > > Signal list. > >> > > > > >> > > > > >> > > > Always, > >> > > > Kris > >> > > > > >> > > > > >> > > > > >> > > > Get FREE Email/Voicemail with 15MB at Lycos Communications at > >> > > http://comm.lycos.com > >> > > > >> > > > >> > > >> > > >> > Get FREE Email/Voicemail with 15MB at Lycos Communications at > >> http://comm.lycos.com > >> > > > > > Get FREE Email/Voicemail with 15MB at Lycos Communications at http://comm.lycos.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 20 16:29:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20233 for ; Mon, 20 Nov 2000 16:29:09 -0500 (EST) Received: from standards (47.234.32.16:1967) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8168@standards.nortelnetworks.com>; Mon, 20 Nov 2000 16:10:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 120216 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Nov 2000 16:10:36 -0500 Received: from zrchh190 (47.158.65.22:37101) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8153@standards.nortelnetworks.com>; Mon, 20 Nov 2000 16:00:36 -0500 Received: from zrtps06s.us.nortel.com by zrchh190; Mon, 20 Nov 2000 15:12:16 -0600 Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Mon, 20 Nov 2000 14:30:00 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 20 Nov 2000 14:25:55 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD1102D9FE21@zcard00g.ca.nortel.com> Date: Mon, 20 Nov 2000 14:25:51 -0500 Reply-To: "Taylor, Tom-PT" Sender: "Media Gateway Control (megaco)" From: "Taylor, Tom-PT" Subject: Re: Error code for Max no Term in a context exceeded X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM A bit late for me to chime in here, but I'm a little concerned about the process for describing new error codes vs. your suggestions. Specifically, we need to document the codes and register them with IANA. I wouldn't consider the Implementor's Guide a proper vehicle for documentation except on a temporary basis. Annex L is good for the first batch. What about new codes after that, if they are not documented in packages? Maybe the process is: -- document in Implementor's Guide pending incorporation into the next issue of Annex L -- register with IANA, referring to Implementor's Guide for documentation -- update documentation reference at IANA when Annex L is updated (presumably as a general update of H.248). > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > Sent: Thursday, October 19, 2000 8:31 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Error code for Max no Term in a context exceeded > > > G'Day all, > > I had a question of: > In H.248, what Error code should be used to indicate > that a context already has the max number of terminations > in it? > > e.g. MG supports a max of 2 terminations per context; > MGC performs an ADD{C1, (T3)} to context C1 which already > has T1 and T2 in it. > > I couldn't find a appropriate error code. The closest would be > "Insufficient Resources" but I'm not sure it really covers this case. > > As such I propose either an addition to H.248 Annex L or the > implementors' guide with something like the following text: > > Error Code #: 434 Name: Max number of Terminations in a Context > exceeded. > Definition: The MGC has requested that a termination be added or moved > to a context that already contains a maximum number of termination. > Package: - > > Cheers, Christian > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 20 17:11:46 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28213 for ; Mon, 20 Nov 2000 17:11:46 -0500 (EST) Received: from standards (47.234.32.16:1967) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB81C5@standards.nortelnetworks.com>; Mon, 20 Nov 2000 16:53:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 120357 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Nov 2000 16:53:20 -0500 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB81BA@standards.nortelnetworks.com>; Mon, 20 Nov 2000 16:43:20 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eAKLxv211596; Mon, 20 Nov 2000 23:00:02 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id WAA02517; Mon, 20 Nov 2000 22:59:57 +0100 (MET) Received: from ericsson.com (arael26m105.ericsson.se [130.100.249.105]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id WAA16077; Mon, 20 Nov 2000 22:59:55 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <3A19701B.616DE236@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A199EA4.21EC6B91@ericsson.com> Date: Tue, 21 Nov 2000 08:59:00 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Annex C questions X-To: Troy Cauble To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Troy, Historical. The properties were added to give the binary encoding a base of values to use as the SDP had values. Not all properties in Annex C can be encoded in SDP, although work is ongoing in SDP to align. The fundamental goal was to have the ASN1 and ABNF align. Ideally it would be nice to have SDP and Annex C completely equivalent but I don't see that as realistic. I personally would have liked to see everything that was required in H248 be added in packages, that way the text and binary would be consistent. Cheers, Christian Troy Cauble wrote: > > Why is there an entire Annex of properties that can > only be encoded in binary form? > > Or can all of the properties in Annex C be encoded > in SDP? (Doesn't seem likely.) If so, how? > > Isn't it a fundamental goal of the protocol to support > all messages in a text or ASN.1 encoding? > > -troy From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 20 17:53:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03871 for ; Mon, 20 Nov 2000 17:53:54 -0500 (EST) Received: from standards (47.234.32.16:1967) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB820E@standards.nortelnetworks.com>; Mon, 20 Nov 2000 17:35:36 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 120446 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Nov 2000 17:35:36 -0500 Received: from zmers013 (47.124.1.40:35361) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB81FB@standards.nortelnetworks.com>; Mon, 20 Nov 2000 17:25:35 -0500 Received: from zrtps06s.us.nortel.com by zmers013; Mon, 20 Nov 2000 17:42:15 -0500 Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Mon, 20 Nov 2000 11:27:02 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 20 Nov 2000 11:23:40 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD1102D511D9@zcard00g.ca.nortel.com> Date: Mon, 20 Nov 2000 11:23:37 -0500 Reply-To: "Taylor, Tom-PT" Sender: "Media Gateway Control (megaco)" From: "Taylor, Tom-PT" Subject: Re: Local / Remote for physical termination X-To: samittal@HSS.HNS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM I'm working on some old mail, as you'll gather. This question is very much on my mind as I think about a bearer capability package to go with the NAS packages. To be consistent with our present scheme, I believe we have to use Local and Remote to specify the media characteristics for circuit terminations too. Unfortunately, this will tend to redundancy, since circuit terminations are normally operated symmetrically. What I believe I have to do for the bearer capability package is to define appropriate SDP, basically in the form of a much simplified version of the ATM SDP document now in MMUSIC WG Last Call. > -----Original Message----- > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > Sent: Thursday, October 19, 2000 10:17 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Local / Remote for physical termination > > > In section 7.1.8 its mentioned that > "Local refers to the media received by the MG > and Remote refers to the media sent by the MG". > Is there any significance for the local and remote > descriptors in case of physical termination? > Local and remote seems to define the media flow > for PDN rather than SCN. > > -Madhubabu > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 20 22:23:52 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA08407 for ; Mon, 20 Nov 2000 22:23:51 -0500 (EST) Received: from standards (47.234.32.16:3106) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB833D@standards.nortelnetworks.com>; Mon, 20 Nov 2000 22:05:12 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 120903 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Nov 2000 22:05:12 -0500 Received: from zrchh190 (47.158.65.22:63536) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB833A@standards.nortelnetworks.com>; Mon, 20 Nov 2000 21:55:04 -0500 Received: from zrtps06s.us.nortel.com by zrchh190; Mon, 20 Nov 2000 21:12:54 -0600 Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Mon, 20 Nov 2000 19:17:33 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 20 Nov 2000 19:14:10 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD1102DA02B8@zcard00g.ca.nortel.com> Date: Mon, 20 Nov 2000 19:14:08 -0500 Reply-To: "Taylor, Tom-PT" Sender: "Media Gateway Control (megaco)" From: "Taylor, Tom-PT" Subject: Re: REPOST: conflicting IDs in NAS packages X-To: "Tulpule, Naren" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Yes, I hadn't thought things through. Since the extension package incorporates the properties, signals, etc. of the base package, it has to be able to refer to them unambiguously. This means the binary values for the items in the extension have to start above those in the base package. I have to fix this and (sorry to say) draft Annex M. Good catch. > -----Original Message----- > From: Tulpule, Naren [mailto:naren@TRILLIUM.COM] > Sent: Friday, November 17, 2000 5:06 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: REPOST: conflicting IDs in NAS packages > > > > -----Original Message----- > > Sent: Wednesday, November 15, 2000 6:52 PM > > > > Hi, > > apologies if this has already been pointed out. > > In > http://www.ietf.org/internet-drafts/draft-ietf-megaco-naspkg-0 > 1.txt the > > 'nasin' package extends 'nas' package. Yet they have > identical property > > IDs (for clgstat and sessid resp, both = 0x0001), event IDs > (authres = > > nasfail = 1) etc. Has this been resolved? If so, where can > I find the > > draft? > > Also, what's the name of the NAS root package? 'nasroot'? I > assume it > > doesn't extend any other package? > > > > -- Naren. > > These views and opinions are mine alone, not those of Intel > (yet ;-) > > Narendra C. Tulpule SMTS, Trillium (an Intel company) > > Ph: +1-310-442-9222 Fax: +1-310-442-1162 > > 12100 Wilshire Bl #1800 Los Angeles, CA 90025 > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 03:23:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12915 for ; Tue, 21 Nov 2000 03:23:14 -0500 (EST) Received: from standards (47.234.32.16:4237) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8520@standards.nortelnetworks.com>; Tue, 21 Nov 2000 3:04:41 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 121558 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 03:04:41 -0500 Received: from mail-in.audiocodes.com (AC-INT-LP.ser.netvision.net.il) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB851F@standards.nortelnetworks.com>; Tue, 21 Nov 2000 3:04:40 -0500 Received: by MAIL-IN with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 10:21:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <81C3E8FE6C0AD4119D49009027C3AAB25DAC1F@MAIL-IN> Date: Tue, 21 Nov 2000 10:21:00 +0200 Reply-To: Nurit Shenhar Sender: "Media Gateway Control (megaco)" From: Nurit Shenhar Subject: Re: physical and ephemeral terminations To: MEGACO@STANDARDS.NORTELNETWORKS.COM Tom and List The subject keeps coming again and again, and I fill that it because there is really a problem implemeting the current definition. The problem is, that choosing a termination according to the command parameters, means that you have to analyse all the parameters in order to decide upon the type. But the structure of the protocol being as it is, it is more natural to first pick up an existing termination, or create a new one, and then continue and assign it with the command parameters. As the MGC knows exectly which kind of termination it wants, why shouldn't he say so? one way to do it, is something that I found in John Segers answer from 14/11/2000 (RE: Use of CHOOSE): >Normally I would expect naming hierarchies where the first level in the >hierarchy identifies the class of the termination. And I would expect >that MGCs use Add commands with partially specified names, e.g. >Add=TDMC/$, or Add=RTP/$. Can't we adopt it as a rull? Thenks Nurit -----Original Message----- From: Taylor, Tom-PT [mailto:taylor@AMERICASM01.NT.COM] Sent: Monday, November 20, 2000 9:01 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: physical and ephemeral terminations [Old issue, apparently not closed.] Two cases: (1) The initial ADD does not specify enough properties to remove the ambiguity. In this case, the termination chosen is a shell, ready to receive further information. I do see a theoretical possibility that a termination is chosen according to one naming scheme, but has properties applied to it in a subsequent MODIFY which make that naming scheme inappropriate. I suppose the MG could reject the ADD request on grounds of ambiguity, or else reject the MODIFY because of the contradiction. In the latter case, the MGC would have to subtract the invalid termination and add another, this time with enough properties specified that an appropriate name is chosen. (2) The initial ADD specifies enough properties that the right termination can be assigned. I would judge this to be the preferable way of doing things. > -----Original Message----- > From: Nitin Jain [mailto:njain@ASSUREDACCESS.COM] > Sent: Thursday, October 19, 2000 1:25 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: physical and ephemeral terminations > > > Hi all, > > Sorry I am late into this discussion. From the archives, I could not > find out what the consensus was for creating an ephemeral termination > or selecting a physical termination for CHOOSE in an ADD command. > > If the physical termination can have the localDescriptor properties, > how do we distinguish between a CHOOSE for ephemeral termination or > Physical termination when "TermID=$" in an ADD command. > > Thanks. > Nitin > > > -----Orig. Message------- > > Any termination can have properties, defined by the packages > implemented on > it. > Look at the IPPhone packages for example. > > Brian > > -----Original Message----- > From: Shlomo Kabaz ECItelecom [mailto:Shlomo.Kabaz@ECITELE.COM] > Sent: Tuesday, October 10, 2000 5:21 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: physical and ephemeral terminations > > > Hi , all ! > > Does the physical termination have properties , because in > the examples > in > the Rfc all the > properties of the "connection" is given in the ephemeral > termination and > the elements that are given to > physical is events and signals . > > Thanks , Shlomo > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 06:09:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA02416 for ; Tue, 21 Nov 2000 06:09:16 -0500 (EST) Received: from standards (47.234.32.16:2162) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB860A@standards.nortelnetworks.com>; Tue, 21 Nov 2000 5:50:26 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 121857 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 05:50:26 -0500 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8603@standards.nortelnetworks.com>; Tue, 21 Nov 2000 5:40:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00825; Tue, 21 Nov 2000 05:57:15 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200011211057.FAA00825@ietf.org> Date: Tue, 21 Nov 2000 05:57:15 -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-mib-01.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Media Gateway Control Working Group of the IETF. Title : MEGACO MIB Author(s) : M. Holdrege, I. Akramovich Filename : draft-ietf-megaco-mib-01.txt Pages : 35 Date : 20-Nov-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular it defines objects for use by the MEGACO protocol operating on Media Gateways and Media Gateway Controllers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-mib-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-megaco-mib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-megaco-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001120151500.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-megaco-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-megaco-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001120151500.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 07:14:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA13090 for ; Tue, 21 Nov 2000 07:14:48 -0500 (EST) Received: from standards (47.234.32.16:4583) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8688@standards.nortelnetworks.com>; Tue, 21 Nov 2000 6:56:15 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 122031 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 06:56:14 -0500 Received: from hindon.hss.co.in (202.54.26.202:55346) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8687@standards.nortelnetworks.com>; Tue, 21 Nov 2000 6:56:11 -0500 Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id eALCEQN12419 for ; Tue, 21 Nov 2000 17:44:27 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525699E.00420FAE ; Tue, 21 Nov 2000 17:31:30 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525699E.00420DA2.00@sandesh.hss.hns.com> Date: Tue, 21 Nov 2000 17:36:37 +0530 Reply-To: chassija@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Chanchal Hassija Subject: ContextAudit + TopologyDescriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello All, If topology descriptor is specified in an action and contextaudit is also requested, should the audit-result contain the topology state of the context before applying the commands and topology-descriptor given in the action or after applying the commands and topology-descriptor given in the action. Thanks for your time Chan.... From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 07:20:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA13887 for ; Tue, 21 Nov 2000 07:20:09 -0500 (EST) Received: from standards (47.234.32.16:4583) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB86AC@standards.nortelnetworks.com>; Tue, 21 Nov 2000 7:01:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 122079 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 07:01:37 -0500 Received: from sapphire.int.ipverse.com (w067.z208037018.sjc-ca.dsl.cnc.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB86AB@standards.nortelnetworks.com>; Tue, 21 Nov 2000 7:01:37 -0500 Received: from matt.ipverse.com (tnt-9-97.easynet.co.uk [195.40.198.97]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id W8BX8L6M; Tue, 21 Nov 2000 04:18:28 -0800 X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.0.2.1.0.20001121041440.02912820@pop3.ipverse.com> Date: Tue, 21 Nov 2000 04:18:14 -0800 Reply-To: Matt Holdrege Sender: "Media Gateway Control (megaco)" From: Matt Holdrege Subject: Re: I-D ACTION:draft-ietf-megaco-mib-01.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200011211057.FAA00825@ietf.org> Regarding this document...As many of you know I've been begging for input for a long time, but I've realized that we wouldn't get good input til people started implementing the protocol. Now that that has happened, I'm flooded with input. So unfortunately this draft isn't very well organized. Even as I finalized this draft, a bunch more objects were suggested to me. So please review the objects in this draft and comment. Regardless of further input, I have a lot of work to do to organize this MIB better. At 05:57 AM 11/21/2000 -0500, Internet-Drafts@IETF.ORG wrote: >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 MIB > Author(s) : M. Holdrege, I. Akramovich > Filename : draft-ietf-megaco-mib-01.txt > Pages : 35 > Date : 20-Nov-00 > >This memo defines a portion of the Management Information Base (MIB) >for use with network management protocols in the Internet community. >In particular it defines objects for use by the MEGACO protocol >operating on Media Gateways and Media Gateway Controllers. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-megaco-mib-01.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-megaco-mib-01.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-megaco-mib-01.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20001120151500.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-megaco-mib-01.txt > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 08:45:17 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29656 for ; Tue, 21 Nov 2000 08:45:17 -0500 (EST) Received: from standards (47.234.32.16:2092) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB870C@standards.nortelnetworks.com>; Tue, 21 Nov 2000 8:26:42 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 122210 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 08:26:38 -0500 Received: from mx4.tellabs.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB870B@standards.nortelnetworks.com>; Tue, 21 Nov 2000 8:16:37 -0500 Received: from mailw02.hq.tellabs.com (mailw02.bb.tellabs.com [138.111.51.101]) by mx4.tellabs.com (Mirapoint) with ESMTP id AAH19041; Tue, 21 Nov 2000 07:33:24 -0600 (CST) Received: from bullwinkle.salix.com (salix.ash.tellabs.com [172.21.10.6]) by mailw02.hq.tellabs.com with ESMTP (8.8.6 (PHNE_17190)/8.7.1) id HAA03258; Tue, 21 Nov 2000 07:33:17 -0600 (CST) Received: by salix.ash.tellabs.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 08:32:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 21 Nov 2000 08:32:36 -0500 Reply-To: Hung Bui Sender: "Media Gateway Control (megaco)" From: Hung Bui Subject: Re: Announcement Package, noc X-To: "Brown, Michael" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA29656 Dear Michael, I suggest we should also add syntax for stringing announcement phrases together. May be a Parameter Id that indicates how many announcement phrases to be included in the request. Cheers, Hung. ________________________________________________________________________ ========= =========== Hung Bui < mailto:hbui@salix.com> ============ Senior Product Manager ============ Next Generation Switching == ==== == Tellabs Gaithersburg == 904 Wind River Lane Suite 101 TEL: (240) 686-6500 x6176 === Gaithersburg, MD 20878 FAX: (240) 631 2228 The statements contained herein are strictly those of their author, and unless otherwise specifically indicated should not be attributed to Tellabs® or its management. -----Original Message----- From: Brown, Michael [mailto:C.Michael.Brown@AMERICASM10.NT.COM] Sent: Monday, November 20, 2000 1:27 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Announcement Package, noc The link is to the document on the IETF Megaco web site. This was up for decision last week in Geneva. Any changes made in Geneva would not be reflected in this document. http://ietf.org/internet-drafts/draft-ietf-megaco-h248k-00.txt Cheers, Michael Brown Paul Long wrote: > ...except of course, as I just noticed, a link to that particular annex. Sorry. > :-) > > Paul Long wrote: > > > Takao, > > > > Everything you need should be here: > > http://www.packetizer.com/iptel/h248/doc_status.html > > > > Paul Long > > ipDialog, Inc. > > > > -----Original Message----- > > From: Media Gateway Control (megaco) > > [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Matsuda > > Sent: Sunday, November 19, 2000 8:03 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Announcement Package, noc > > > > Hello Mr.Christian, > > > > What is the URL to get the most recent version of H.248 ANNEX K? > > > > Best regards, > > Takao From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 09:12:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05202 for ; Tue, 21 Nov 2000 09:12:29 -0500 (EST) Received: from standards (47.234.32.16:2092) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB873F@standards.nortelnetworks.com>; Tue, 21 Nov 2000 8:53:59 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 122279 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 08:53:59 -0500 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB873E@standards.nortelnetworks.com>; Tue, 21 Nov 2000 8:53:58 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA18622; Tue, 21 Nov 2000 09:10:49 -0500 (EST) Received: from stl-server-01.pit.comms.marconi.com (stl-server-01.pit.comms.marconi.com [169.144.36.27]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA02435; Tue, 21 Nov 2000 09:10:49 -0500 (EST) Received: by stl-server-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 09:10: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: <4FBEA8857476D311A03300204840E1CF01A6EA33@whq-msgusr-02.pit.comms.marconi.com> Date: Tue, 21 Nov 2000 09:10:42 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: physical and ephemeral terminations X-To: Nurit Shenhar To: MEGACO@STANDARDS.NORTELNETWORKS.COM I have always been in favor of this approach. I agree that implementing it by process of elimination of termination characteristics is very hard. Brian > -----Original Message----- > From: Nurit Shenhar [mailto:nurit.shenhar@AUDIOCODES.COM] > Sent: Tuesday, November 21, 2000 3:21 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: physical and ephemeral terminations > > > Tom and List > > The subject keeps coming again and again, and I fill that it > because there > is really a problem implemeting the current definition. The > problem is, that > choosing a termination according to the command parameters, > means that you > have to analyse all the parameters in order to decide upon > the type. But the > structure of the protocol being as it is, it is more natural > to first pick > up an existing termination, or create a new one, and then continue and > assign it with the command parameters. As the MGC knows > exectly which kind > of termination it wants, why shouldn't he say so? > > one way to do it, is something that I found in John Segers answer from > 14/11/2000 (RE: Use of CHOOSE): > > >Normally I would expect naming hierarchies where the first > level in the > >hierarchy identifies the class of the termination. And I > would expect > >that MGCs use Add commands with partially specified names, e.g. > >Add=TDMC/$, or Add=RTP/$. > > Can't we adopt it as a rull? > > Thenks > > Nurit > > -----Original Message----- > From: Taylor, Tom-PT [mailto:taylor@AMERICASM01.NT.COM] > Sent: Monday, November 20, 2000 9:01 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: physical and ephemeral terminations > > > [Old issue, apparently not closed.] > Two cases: > (1) The initial ADD does not specify enough properties to remove the > ambiguity. In this case, the termination chosen is a shell, ready to > receive further information. I do see a theoretical > possibility that a > termination is chosen according to one naming scheme, but has > properties > applied to it in a subsequent MODIFY which make that naming scheme > inappropriate. I suppose the MG could reject the ADD request > on grounds of > ambiguity, or else reject the MODIFY because of the > contradiction. In the > latter case, the MGC would have to subtract the invalid > termination and add > another, this time with enough properties specified that an > appropriate name > is chosen. > > (2) The initial ADD specifies enough properties that the > right termination > can be assigned. I would judge this to be the preferable way of doing > things. > > > -----Original Message----- > > From: Nitin Jain [mailto:njain@ASSUREDACCESS.COM] > > Sent: Thursday, October 19, 2000 1:25 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: physical and ephemeral terminations > > > > > > Hi all, > > > > Sorry I am late into this discussion. From the archives, I could not > > find out what the consensus was for creating an ephemeral > termination > > or selecting a physical termination for CHOOSE in an ADD command. > > > > If the physical termination can have the localDescriptor properties, > > how do we distinguish between a CHOOSE for ephemeral termination or > > Physical termination when "TermID=$" in an ADD command. > > > > Thanks. > > Nitin > > > > > > -----Orig. Message------- > > > > Any termination can have properties, defined by the packages > > implemented on > > it. > > Look at the IPPhone packages for example. > > > > Brian > > > > -----Original Message----- > > From: Shlomo Kabaz ECItelecom [mailto:Shlomo.Kabaz@ECITELE.COM] > > Sent: Tuesday, October 10, 2000 5:21 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: physical and ephemeral terminations > > > > > > Hi , all ! > > > > Does the physical termination have properties , because in > > the examples > > in > > the Rfc all the > > properties of the "connection" is given in the ephemeral > > termination and > > the elements that are given to > > physical is events and signals . > > > > Thanks , Shlomo > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 11:01:23 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28367 for ; Tue, 21 Nov 2000 11:01:22 -0500 (EST) Received: from standards (47.234.32.16:1266) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB889F@standards.nortelnetworks.com>; Tue, 21 Nov 2000 10:39:36 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 122758 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 10:39:35 -0500 Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB889E@standards.nortelnetworks.com>; Tue, 21 Nov 2000 10:39:35 -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 KAA02219 for ; Tue, 21 Nov 2000 10:56:28 -0500 (EST) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id KAA02207 for ; Tue, 21 Nov 2000 10:56:28 -0500 (EST) Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA04244; Tue, 21 Nov 2000 10:56:26 -0500 Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA04241; Tue, 21 Nov 2000 10:56:26 -0500 X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A1A9ADF.825A4A8F@lucent.com> Date: Tue, 21 Nov 2000 10:55:11 -0500 Reply-To: Troy Cauble Sender: "Media Gateway Control (megaco)" From: Troy Cauble Subject: MEGACO: Impl. guide comments/corrections To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello all, Section 6.23 of the Implementors Guide discusses the fact that sigParameter is hard to parse because it's impossible to tell the sigStream sequence from the sigOther sequence. I find this statement confusing: "The problem lies in the fact that in the future that the introduction of a new Token for a signal Parameter may cause overlap with an existing package identity." More to the point is the fact that the opposite problem exists *NOW*. Package identities (i.e. signal parameter names) can be defined such that they conflict with nearby tokens such as DurationToken, StreamToken, SignalTypeToken, etc. These tokens are used in "Token EQUALS X" sequences that are impossible to distinguish from sigOther. While the following change to section 12.2: "The textual ParameterID of parameters to Events and Signals shall not start with "EPA" and "SPA" respectively." guards against conflicts with FUTURE tokens, it does not guard against conflicts with CURRENT tokens. There are many other things that these "textual ParameterIDs" must avoid matching. A (partial?) list for signal parameter names is: StreamToken SignalTypeToken DurationToken NotifyCompletionToken A (partial?) list for event parameter names is: ModemToken StreamToken DigitMapToken The lists are a little longer if you want to make parsing easy. These are required to make parsing possible. They should be listed in the correction to section 12.2. -troy From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 11:52:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09982 for ; Tue, 21 Nov 2000 11:52:29 -0500 (EST) Received: from standards (47.234.32.16:3025) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8961@standards.nortelnetworks.com>; Tue, 21 Nov 2000 11:34:04 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 123014 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 11:34:04 -0500 Received: from dnsmx1pya.telcordia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB895C@standards.nortelnetworks.com>; Tue, 21 Nov 2000 11:24:03 -0500 Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com [128.96.244.1]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with SMTP id LAA01995; Tue, 21 Nov 2000 11:36:03 -0500 (EST) Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 8525699E.005B305E ; Tue, 21 Nov 2000 11:36:01 -0500 X-Lotus-FromDomain: TELCORDIA Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <8525699E.005B2EEF.00@notes950.cc.telcordia.com> Date: Tue, 21 Nov 2000 11:35:35 -0500 Reply-To: Somit Ghosh Sender: "Media Gateway Control (megaco)" From: Somit Ghosh Subject: Continuity package X-To: Troy Cauble To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello: Can the basic continuity package be used to test both a TDM circuit and Network (RTP) continuity check also ? MGCP clearly allows co1/co2 to be applied as part of RTP package, I am not sure about Megaco. Please let me know, if anyone has an answer. Thanks Somit Ghosh Telcordia Technologies Troy Cauble on 11/21/2000 10:55:11 AM Please respond to Troy Cauble To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Somit Ghosh/Telcordia) Subject: MEGACO: Impl. guide comments/corrections Hello all, Section 6.23 of the Implementors Guide discusses the fact that sigParameter is hard to parse because it's impossible to tell the sigStream sequence from the sigOther sequence. I find this statement confusing: "The problem lies in the fact that in the future that the introduction of a new Token for a signal Parameter may cause overlap with an existing package identity." More to the point is the fact that the opposite problem exists *NOW*. Package identities (i.e. signal parameter names) can be defined such that they conflict with nearby tokens such as DurationToken, StreamToken, SignalTypeToken, etc. These tokens are used in "Token EQUALS X" sequences that are impossible to distinguish from sigOther. While the following change to section 12.2: "The textual ParameterID of parameters to Events and Signals shall not start with "EPA" and "SPA" respectively." guards against conflicts with FUTURE tokens, it does not guard against conflicts with CURRENT tokens. There are many other things that these "textual ParameterIDs" must avoid matching. A (partial?) list for signal parameter names is: StreamToken SignalTypeToken DurationToken NotifyCompletionToken A (partial?) list for event parameter names is: ModemToken StreamToken DigitMapToken The lists are a little longer if you want to make parsing easy. These are required to make parsing possible. They should be listed in the correction to section 12.2. -troy From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 11:58:05 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11293 for ; Tue, 21 Nov 2000 11:58:04 -0500 (EST) Received: from standards (47.234.32.16:3025) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB898D@standards.nortelnetworks.com>; Tue, 21 Nov 2000 11:39:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 123077 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 11:39:34 -0500 Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB898C@standards.nortelnetworks.com>; Tue, 21 Nov 2000 11:39:34 -0500 Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA10602 for ; Tue, 21 Nov 2000 11:56:27 -0500 (EST) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id LAA10595 for ; Tue, 21 Nov 2000 11:56:27 -0500 (EST) Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id LAA05054; Tue, 21 Nov 2000 11:56:24 -0500 Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id LAA05051; Tue, 21 Nov 2000 11:56:24 -0500 X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A1AA8EE.7D6BB007@lucent.com> Date: Tue, 21 Nov 2000 11:55:10 -0500 Reply-To: Troy Cauble Sender: "Media Gateway Control (megaco)" From: Troy Cauble Subject: MEGACO: Impl. guide SHOCKER! To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello again, Does section 6.48 of the Implementors Guide really say that the text encoding that used to be this: Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 0 a=fmtp:PCMU VAD=X-NNVAD } Is now this: Local { 763d30200a633d494e204950342024200a6d3d617564696f2024205254502f4156502030200a613d666d74703a50434d55205641443d582d4e4e5641440a } !?!?!?! Let's be reasonable. There's no reason to make this unreadable. SDP is UTF-8 conformant. octetString is overkill for the SDP encoding in localDescriptor and remoteDescriptor. localDescriptor = LocalToken LBRKT octetString RBRKT remoteDescriptor = RemoteToken LBRKT octetString RBRKT It's these definititions that should be changed. Don't make the text encoding this much uglier because someone once wrote "octetString" there. As for the argument about escaping "{" and "}"; that's a form of *encoding* just like this hex stuff. So it shouldn't cause any heartburn. If you want to talk about non-conformance with RFC 2327, let's talk about those dollar signs. octetString has already been taken out of mtpAddress. Please, take it out of these descriptors too and get rid of it all together. -troy From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 12:27:59 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16273 for ; Tue, 21 Nov 2000 12:27:59 -0500 (EST) Received: from standards (47.234.32.16:3025) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB89C5@standards.nortelnetworks.com>; Tue, 21 Nov 2000 12:09:32 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 123150 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 12:09:32 -0500 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB89C0@standards.nortelnetworks.com>; Tue, 21 Nov 2000 11:59:32 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eALHGL205897; Tue, 21 Nov 2000 18:16:21 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id SAA21093; Tue, 21 Nov 2000 18:16:16 +0100 (MET) Received: from ericsson.com (kipe2.ki.sw.ericsson.se [147.214.68.2]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id SAA19038; Tue, 21 Nov 2000 18:16:15 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <3A1AA8EE.7D6BB007@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A1AADA6.7ED641B@ericsson.com> Date: Wed, 22 Nov 2000 04:15:18 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: MEGACO: Impl. guide SHOCKER! X-To: Troy Cauble To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Troy, I think you have a GROSS misunderstanding of what was proposed. It was a suggestion from Lucent have some conformity when you wanted to code a Binary octet with the text encoding. If you wish to send a binary encoded octet string then you should use the hex format proposed. If you have SDP or text to send ofcourse you use text. Christian Troy Cauble wrote: > > Hello again, > > Does section 6.48 of the Implementors Guide really say > that the text encoding that used to be this: > > Local { > v=0 > c=IN IP4 $ > m=audio $ RTP/AVP 0 > a=fmtp:PCMU VAD=X-NNVAD > } > > Is now this: > > Local { > 763d30200a633d494e204950342024200a6d3d617564696f2024205254502f4156502030200a613d666d74703a50434d55205641443d582d4e4e5641440a > } > > !?!?!?! > > Let's be reasonable. There's no reason to make this unreadable. > > SDP is UTF-8 conformant. octetString is overkill for the SDP > encoding in localDescriptor and remoteDescriptor. > > localDescriptor = LocalToken LBRKT octetString RBRKT > > remoteDescriptor = RemoteToken LBRKT octetString RBRKT > > It's these definititions that should be changed. Don't make the > text encoding this much uglier because someone once wrote > "octetString" there. > > As for the argument about escaping "{" and "}"; that's a form > of *encoding* just like this hex stuff. So it shouldn't cause > any heartburn. If you want to talk about non-conformance with > RFC 2327, let's talk about those dollar signs. > > octetString has already been taken out of mtpAddress. Please, > take it out of these descriptors too and get rid of it all together. > > -troy From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 12:40:14 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19053 for ; Tue, 21 Nov 2000 12:40:14 -0500 (EST) Received: from standards (47.234.32.16:3025) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB89EC@standards.nortelnetworks.com>; Tue, 21 Nov 2000 12:21:50 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 123209 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 12:21:50 -0500 Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB89EB@standards.nortelnetworks.com>; Tue, 21 Nov 2000 12:21:50 -0500 Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA00742 for ; Tue, 21 Nov 2000 12:38:43 -0500 (EST) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id MAA00732 for ; Tue, 21 Nov 2000 12:38:43 -0500 (EST) Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id MAA05566; Tue, 21 Nov 2000 12:38:41 -0500 Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id MAA05559; Tue, 21 Nov 2000 12:38:40 -0500 X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Original-CC: ietf_megaco References: <3A1AA8EE.7D6BB007@lucent.com> <3A1AADA6.7ED641B@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A1AB2D4.18628D47@lucent.com> Date: Tue, 21 Nov 2000 12:37:24 -0500 Reply-To: Troy Cauble Sender: "Media Gateway Control (megaco)" From: Troy Cauble Subject: Re: MEGACO: Impl. guide SHOCKER! X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Christian, I'm happy to be wrong about the intent! But if it's not referring to the "octetString" element of the ABNF, what is it referring to? From the problem description: "Sometimes it is desirable to transfer octet strings between MG and MGC." WHEN?? This should be a clearly labled part of the ABNF spec. The solution describes how to do "hexidecimal octet coding" but doesn't tell us where or when we would. I jumped to the conclusion that you were referring to the ABNF "octetString". (It *was* mentioned in the problem description.) Can I suggest that the ANBF element "octetString" be renamed to avoid confusion? -troy Christian Groves wrote: > > Hello Troy, > > I think you have a GROSS misunderstanding of what was proposed. It was a > suggestion from Lucent have some conformity when you wanted to code a > Binary octet with the text encoding. If you wish to send a binary > encoded octet string then you should use the hex format proposed. If you > have SDP or text to send ofcourse you use text. > > Christian > > Troy Cauble wrote: > > > > Hello again, > > > > Does section 6.48 of the Implementors Guide really say > > that the text encoding that used to be this: > > > > Local { > > v=0 > > c=IN IP4 $ > > m=audio $ RTP/AVP 0 > > a=fmtp:PCMU VAD=X-NNVAD > > } > > > > Is now this: > > > > Local { > > 763d30200a633d494e204950342024200a6d3d617564696f2024205254502f4156502030200a613d666d74703a50434d55205641443d582d4e4e5641440a > > } > > > > !?!?!?! > > > > Let's be reasonable. There's no reason to make this unreadable. > > > > SDP is UTF-8 conformant. octetString is overkill for the SDP > > encoding in localDescriptor and remoteDescriptor. > > > > localDescriptor = LocalToken LBRKT octetString RBRKT > > > > remoteDescriptor = RemoteToken LBRKT octetString RBRKT > > > > It's these definititions that should be changed. Don't make the > > text encoding this much uglier because someone once wrote > > "octetString" there. > > > > As for the argument about escaping "{" and "}"; that's a form > > of *encoding* just like this hex stuff. So it shouldn't cause > > any heartburn. If you want to talk about non-conformance with > > RFC 2327, let's talk about those dollar signs. > > > > octetString has already been taken out of mtpAddress. Please, > > take it out of these descriptors too and get rid of it all together. > > > > -troy From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 13:33:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01234 for ; Tue, 21 Nov 2000 13:33:08 -0500 (EST) Received: from standards (47.234.32.16:3025) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8AD9@standards.nortelnetworks.com>; Tue, 21 Nov 2000 13:13:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 123408 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 13:13:07 -0500 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8A82@standards.nortelnetworks.com>; Tue, 21 Nov 2000 13:03:07 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eALIJxt08677 for ; Tue, 21 Nov 2000 19:20:00 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id TAA23804 for ; Tue, 21 Nov 2000 19:19:58 +0100 (MET) Received: from ericsson.com (kipe2.ki.sw.ericsson.se [147.214.68.2]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id TAA19164 for ; Tue, 21 Nov 2000 19:19:57 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01A6EA33@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A1AAFF3.B952E4D5@ericsson.com> Date: Wed, 22 Nov 2000 04:25:07 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: physical and ephemeral terminations To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I think that what we currently have should stay. CHOOSE can be both based on the termination ID and/or characteristics listed in the command. It very much depends on how you want to set up your termination ID structure. The MGC may not know or care what termination ID he wants. All it wants is a termination ID with certain properties. This to me sounds like a perfectly reasonable scenario. The MGC wants a termination from a certain range, it also wants property x sounds reasonable to me. By changing anything here it seems to me that we would be removing a moderate amount of functionality. A little more than editorial. Christian "Rosen, Brian" wrote: > > I have always been in favor of this approach. I agree that implementing > it by process of elimination of termination characteristics is very hard. > > Brian > > > -----Original Message----- > > From: Nurit Shenhar [mailto:nurit.shenhar@AUDIOCODES.COM] > > Sent: Tuesday, November 21, 2000 3:21 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: physical and ephemeral terminations > > > > > > Tom and List > > > > The subject keeps coming again and again, and I fill that it > > because there > > is really a problem implemeting the current definition. The > > problem is, that > > choosing a termination according to the command parameters, > > means that you > > have to analyse all the parameters in order to decide upon > > the type. But the > > structure of the protocol being as it is, it is more natural > > to first pick > > up an existing termination, or create a new one, and then continue and > > assign it with the command parameters. As the MGC knows > > exectly which kind > > of termination it wants, why shouldn't he say so? > > > > one way to do it, is something that I found in John Segers answer from > > 14/11/2000 (RE: Use of CHOOSE): > > > > >Normally I would expect naming hierarchies where the first > > level in the > > >hierarchy identifies the class of the termination. And I > > would expect > > >that MGCs use Add commands with partially specified names, e.g. > > >Add=TDMC/$, or Add=RTP/$. > > > > Can't we adopt it as a rull? > > > > Thenks > > > > Nurit > > > > -----Original Message----- > > From: Taylor, Tom-PT [mailto:taylor@AMERICASM01.NT.COM] > > Sent: Monday, November 20, 2000 9:01 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: physical and ephemeral terminations > > > > > > [Old issue, apparently not closed.] > > Two cases: > > (1) The initial ADD does not specify enough properties to remove the > > ambiguity. In this case, the termination chosen is a shell, ready to > > receive further information. I do see a theoretical > > possibility that a > > termination is chosen according to one naming scheme, but has > > properties > > applied to it in a subsequent MODIFY which make that naming scheme > > inappropriate. I suppose the MG could reject the ADD request > > on grounds of > > ambiguity, or else reject the MODIFY because of the > > contradiction. In the > > latter case, the MGC would have to subtract the invalid > > termination and add > > another, this time with enough properties specified that an > > appropriate name > > is chosen. > > > > (2) The initial ADD specifies enough properties that the > > right termination > > can be assigned. I would judge this to be the preferable way of doing > > things. > > > > > -----Original Message----- > > > From: Nitin Jain [mailto:njain@ASSUREDACCESS.COM] > > > Sent: Thursday, October 19, 2000 1:25 PM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: physical and ephemeral terminations > > > > > > > > > Hi all, > > > > > > Sorry I am late into this discussion. From the archives, I could not > > > find out what the consensus was for creating an ephemeral > > termination > > > or selecting a physical termination for CHOOSE in an ADD command. > > > > > > If the physical termination can have the localDescriptor properties, > > > how do we distinguish between a CHOOSE for ephemeral termination or > > > Physical termination when "TermID=$" in an ADD command. > > > > > > Thanks. > > > Nitin > > > > > > > > > -----Orig. Message------- > > > > > > Any termination can have properties, defined by the packages > > > implemented on > > > it. > > > Look at the IPPhone packages for example. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Shlomo Kabaz ECItelecom [mailto:Shlomo.Kabaz@ECITELE.COM] > > > Sent: Tuesday, October 10, 2000 5:21 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: physical and ephemeral terminations > > > > > > > > > Hi , all ! > > > > > > Does the physical termination have properties , because in > > > the examples > > > in > > > the Rfc all the > > > properties of the "connection" is given in the ephemeral > > > termination and > > > the elements that are given to > > > physical is events and signals . > > > > > > Thanks , Shlomo > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 13:33:09 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01249 for ; Tue, 21 Nov 2000 13:33:09 -0500 (EST) Received: from standards (47.234.32.16:3025) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8ADF@standards.nortelnetworks.com>; Tue, 21 Nov 2000 13:13:11 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 123409 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 13:13:11 -0500 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8A83@standards.nortelnetworks.com>; Tue, 21 Nov 2000 13:03:10 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eALIK0200838; Tue, 21 Nov 2000 19:20:00 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id TAA23801; Tue, 21 Nov 2000 19:19:57 +0100 (MET) Received: from ericsson.com (kipe2.ki.sw.ericsson.se [147.214.68.2]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id TAA19160; Tue, 21 Nov 2000 19:19:57 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <3A1A9ADF.825A4A8F@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A1AAEA3.3F217A40@ericsson.com> Date: Wed, 22 Nov 2000 04:19:31 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: MEGACO: Impl. guide comments/corrections X-To: Troy Cauble To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Troy, I'm not sure what the current problem is. Any overlap between properties and parameters have been resolved. Any new signal / event parameter must be defined according to the new rule. The other tokens you list do not overlap with the current signalOther definition. Christian Troy Cauble wrote: > > Hello all, > > Section 6.23 of the Implementors Guide discusses the > fact that sigParameter is hard to parse because it's > impossible to tell the sigStream sequence from the > sigOther sequence. > > I find this statement confusing: > "The problem lies in the fact that in the future > that the introduction of a new Token for a > signal Parameter may cause overlap with an > existing package identity." > > More to the point is the fact that the opposite problem > exists *NOW*. Package identities (i.e. signal parameter > names) can be defined such that they conflict with nearby > tokens such as DurationToken, StreamToken, SignalTypeToken, > etc. These tokens are used in "Token EQUALS X" sequences > that are impossible to distinguish from sigOther. > > While the following change to section 12.2: > "The textual ParameterID of parameters to Events > and Signals shall not start with "EPA" and "SPA" > respectively." > > guards against conflicts with FUTURE tokens, it does not > guard against conflicts with CURRENT tokens. > > There are many other things that these "textual ParameterIDs" > must avoid matching. A (partial?) list for signal parameter > names is: > StreamToken > SignalTypeToken > DurationToken > NotifyCompletionToken > > A (partial?) list for event parameter names is: > ModemToken > StreamToken > DigitMapToken > > The lists are a little longer if you want to make parsing easy. > These are required to make parsing possible. They should be > listed in the correction to section 12.2. > > -troy From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 13:33:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01264 for ; Tue, 21 Nov 2000 13:33:09 -0500 (EST) Received: from standards (47.234.32.16:3025) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8AE3@standards.nortelnetworks.com>; Tue, 21 Nov 2000 13:13:17 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 123410 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 13:13:17 -0500 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8A85@standards.nortelnetworks.com>; Tue, 21 Nov 2000 13:03:16 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eALIK3t08722; Tue, 21 Nov 2000 19:20:03 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id TAA23820; Tue, 21 Nov 2000 19:20:00 +0100 (MET) Received: from ericsson.com (kipe2.ki.sw.ericsson.se [147.214.68.2]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id TAA19180; Tue, 21 Nov 2000 19:19:59 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD1102D9FCBF@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A1AB2C1.3DBF03F4@ericsson.com> Date: Wed, 22 Nov 2000 04:37:05 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Statistics X-To: "Taylor, Tom-PT" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit What fix do you propose for the ASN1? Cheers, Christian "Taylor, Tom-PT" wrote: > > [Old mail, issue still open.] > Agreed that we have a bug, but I'm not sure it matters in practice. The > typical usage of RTP terminations will, I suspect, mean just one stream per > termination. Without that assumption, it appears that the text of the > package description contradicts the syntax of the statistics descriptor. > One way to solve it is to specify in the I-G that each statistic is to be > reported as a series of "pkgdName EQUAL VALUE" entries, one per stream (with > pkgdName repeated), in increasing order of stream number active on the > termination. This respects the existing syntax but gives us a workaround > until we need a more permanent solution. > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > Sent: Thursday, October 19, 2000 10:20 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Statistics > > > > > > Oh cool. I don't think we have ever talked about this, > > stream specific statistics! Hmmmmm. > > > > So we would want to add (an optional) StreamId to Statistics > > Descriptor > > Statistics=1{rtp/pr=.... > > and you might get more than one Statistics descriptor in the reply. > > > > Wow. This is a real bug in the protocol I think! > > > > Brian > > > > > > > -----Original Message----- > > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > > Sent: Thursday, October 19, 2000 9:51 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Statistics > > > > > > > > > Section E.12.4 states that statistics like > > > jitter, packet loss,etc are described on an > > > RTP stream. If only one RTP stream is > > > present on a termination its straitforward > > > to send statistics. But if multiple streams > > > are created on a termination How this > > > reporting is done? > > > > > > -Madhubabu > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 13:33:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01277 for ; Tue, 21 Nov 2000 13:33:11 -0500 (EST) Received: from standards (47.234.32.16:3025) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8AE7@standards.nortelnetworks.com>; Tue, 21 Nov 2000 13:13:18 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 123411 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 13:13:18 -0500 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8A84@standards.nortelnetworks.com>; Tue, 21 Nov 2000 13:03:16 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eALIK2200863; Tue, 21 Nov 2000 19:20:02 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id TAA23808; Tue, 21 Nov 2000 19:19:59 +0100 (MET) Received: from ericsson.com (kipe2.ki.sw.ericsson.se [147.214.68.2]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id TAA19172; Tue, 21 Nov 2000 19:19:58 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD1102D9FE21@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A1AB192.F3EC2558@ericsson.com> Date: Wed, 22 Nov 2000 04:32:02 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Error code for Max no Term in a context exceeded X-To: "Taylor, Tom-PT" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Tom, I agree with your concerns. I wouldn't add "error code xxx - Fred has gone home" to the implementors' guide as it application specific and should be in a package. Anything that should have been part of the core protocol which I think the one below should have been could be in the Implementors' guide and annex L. I think your proposal below is OK. Cheers, Christian "Taylor, Tom-PT" wrote: > > A bit late for me to chime in here, but I'm a little concerned about the > process for describing new error codes vs. your suggestions. Specifically, > we need to document the codes and register them with IANA. I wouldn't > consider the Implementor's Guide a proper vehicle for documentation except > on a temporary basis. Annex L is good for the first batch. What about new > codes after that, if they are not documented in packages? Maybe the process > is: > -- document in Implementor's Guide pending incorporation into the next > issue of Annex L > -- register with IANA, referring to Implementor's Guide for documentation > -- update documentation reference at IANA when Annex L is updated > (presumably as a general update of H.248). > > > -----Original Message----- > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > > Sent: Thursday, October 19, 2000 8:31 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Error code for Max no Term in a context exceeded > > > > > > G'Day all, > > > > I had a question of: > > In H.248, what Error code should be used to indicate > > that a context already has the max number of terminations > > in it? > > > > e.g. MG supports a max of 2 terminations per context; > > MGC performs an ADD{C1, (T3)} to context C1 which already > > has T1 and T2 in it. > > > > I couldn't find a appropriate error code. The closest would be > > "Insufficient Resources" but I'm not sure it really covers this case. > > > > As such I propose either an addition to H.248 Annex L or the > > implementors' guide with something like the following text: > > > > Error Code #: 434 Name: Max number of Terminations in a Context > > exceeded. > > Definition: The MGC has requested that a termination be added or moved > > to a context that already contains a maximum number of termination. > > Package: - > > > > Cheers, Christian > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 13:33:12 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01287 for ; Tue, 21 Nov 2000 13:33:12 -0500 (EST) Received: from standards (47.234.32.16:3025) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8AEB@standards.nortelnetworks.com>; Tue, 21 Nov 2000 13:13:19 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 123412 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 13:13:18 -0500 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8A87@standards.nortelnetworks.com>; Tue, 21 Nov 2000 13:03:18 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eALIK2200857; Tue, 21 Nov 2000 19:20:02 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id TAA23812; Tue, 21 Nov 2000 19:20:00 +0100 (MET) Received: from ericsson.com (kipe2.ki.sw.ericsson.se [147.214.68.2]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id TAA19176; Tue, 21 Nov 2000 19:19:59 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD1102D511D9@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A1AB260.3075FCDB@ericsson.com> Date: Wed, 22 Nov 2000 04:35:28 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Local / Remote for physical termination X-To: "Taylor, Tom-PT" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Tom, An old email, an old topic. I really think that as time goes on I think we need to investigate a means of defining things in Local and Remote via packages. Not all applications will want to go to the trouble of defining SDP extensions but want to use specific properties that should reside in Local and Remote. Cheers, Christian "Taylor, Tom-PT" wrote: > > I'm working on some old mail, as you'll gather. This question is very much > on my mind as I think about a bearer capability package to go with the NAS > packages. To be consistent with our present scheme, I believe we have to > use Local and Remote to specify the media characteristics for circuit > terminations too. Unfortunately, this will tend to redundancy, since > circuit terminations are normally operated symmetrically. > > What I believe I have to do for the bearer capability package is to define > appropriate SDP, basically in the form of a much simplified version of the > ATM SDP document now in MMUSIC WG Last Call. > > > -----Original Message----- > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > > Sent: Thursday, October 19, 2000 10:17 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Local / Remote for physical termination > > > > > > In section 7.1.8 its mentioned that > > "Local refers to the media received by the MG > > and Remote refers to the media sent by the MG". > > Is there any significance for the local and remote > > descriptors in case of physical termination? > > Local and remote seems to define the media flow > > for PDN rather than SCN. > > > > -Madhubabu > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 13:33:13 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01299 for ; Tue, 21 Nov 2000 13:33:12 -0500 (EST) Received: from standards (47.234.32.16:3025) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8AEF@standards.nortelnetworks.com>; Tue, 21 Nov 2000 13:13:19 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 123413 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 13:13:19 -0500 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8A88@standards.nortelnetworks.com>; Tue, 21 Nov 2000 13:03:18 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eALIK4t08732; Tue, 21 Nov 2000 19:20:04 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id TAA23822; Tue, 21 Nov 2000 19:20:01 +0100 (MET) Received: from ericsson.com (kipe2.ki.sw.ericsson.se [147.214.68.2]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id TAA19184; Tue, 21 Nov 2000 19:20:00 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <353093573B82D411889E0000F808216648E4DF@zcard00q.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A1AB852.BC28CD2B@ericsson.com> Date: Wed, 22 Nov 2000 05:00:50 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: H.248 Implementors' Guide at SG16 X-To: Peter Blatherwick To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Peter, It was probably removed after the meeting. For some reason I haven't been able to access the pictel server. The implementors' guide does contain the extension rules we talked about. I'll upload the approved version when I can access the site. Cheers, christian Peter Blatherwick wrote: > > Darned if I could find it. Not in any other obvious folder I could > find either... > > Did the stuff re package extension rules we were on about a while back > (wording clarifications) make it in? > > Peter Blatherwick > > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > Sent: Wednesday, November 15, 2000 12:31 > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: H.248 Implementors' Guide at SG16 > > G'Day all, > > The updated Implementors' Guide from the SG16 Meeting is now available > > at: > ftp://standard.pictel.com/avc-site/Incoming/ > > plen-xxx_H248_Implementors_guide_v7.pdf > or > plen-xxx_H248_Implementors_guide_v7.doc > > This is now going for approval. > > Cheers, Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 13:33:13 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01306 for ; Tue, 21 Nov 2000 13:33:13 -0500 (EST) Received: from standards (47.234.32.16:3025) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8AF4@standards.nortelnetworks.com>; Tue, 21 Nov 2000 13:13:22 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 123414 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 13:13:22 -0500 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8A86@standards.nortelnetworks.com>; Tue, 21 Nov 2000 13:03:22 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eALIK7t08752; Tue, 21 Nov 2000 19:20:07 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id TAA23852; Tue, 21 Nov 2000 19:20:04 +0100 (MET) Received: from ericsson.com (kipe2.ki.sw.ericsson.se [147.214.68.2]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id TAA19208; Tue, 21 Nov 2000 19:20:03 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <3A1AA8EE.7D6BB007@lucent.com> <3A1AADA6.7ED641B@ericsson.com> <3A1AB2D4.18628D47@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A1ABC7F.262A0F81@ericsson.com> Date: Wed, 22 Nov 2000 05:18:39 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: MEGACO: Impl. guide SHOCKER! X-To: Troy Cauble To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Troy, OK maybe binary octer strings should have been mentioned. The section was added as a guideline for the future and didn't intend to change any current definitions. I'll let other people reply on renaming OCTET STRING in ABNF. Christian Troy Cauble wrote: > > Christian, > > I'm happy to be wrong about the intent! > > But if it's not referring to the "octetString" element > of the ABNF, what is it referring to? > > >From the problem description: > "Sometimes it is desirable to transfer octet strings > between MG and MGC." > > WHEN?? This should be a clearly labled part of the ABNF > spec. > > The solution describes how to do "hexidecimal octet coding" > but doesn't tell us where or when we would. > > I jumped to the conclusion that you were referring to the ABNF > "octetString". (It *was* mentioned in the problem description.) > > Can I suggest that the ANBF element "octetString" be renamed to > avoid confusion? > > -troy > > Christian Groves wrote: > > > > Hello Troy, > > > > I think you have a GROSS misunderstanding of what was proposed. It was a > > suggestion from Lucent have some conformity when you wanted to code a > > Binary octet with the text encoding. If you wish to send a binary > > encoded octet string then you should use the hex format proposed. If you > > have SDP or text to send ofcourse you use text. > > > > Christian > > > > Troy Cauble wrote: > > > > > > Hello again, > > > > > > Does section 6.48 of the Implementors Guide really say > > > that the text encoding that used to be this: > > > > > > Local { > > > v=0 > > > c=IN IP4 $ > > > m=audio $ RTP/AVP 0 > > > a=fmtp:PCMU VAD=X-NNVAD > > > } > > > > > > Is now this: > > > > > > Local { > > > 763d30200a633d494e204950342024200a6d3d617564696f2024205254502f4156502030200a613d666d74703a50434d55205641443d582d4e4e5641440a > > > } > > > > > > !?!?!?! > > > > > > Let's be reasonable. There's no reason to make this unreadable. > > > > > > SDP is UTF-8 conformant. octetString is overkill for the SDP > > > encoding in localDescriptor and remoteDescriptor. > > > > > > localDescriptor = LocalToken LBRKT octetString RBRKT > > > > > > remoteDescriptor = RemoteToken LBRKT octetString RBRKT > > > > > > It's these definititions that should be changed. Don't make the > > > text encoding this much uglier because someone once wrote > > > "octetString" there. > > > > > > As for the argument about escaping "{" and "}"; that's a form > > > of *encoding* just like this hex stuff. So it shouldn't cause > > > any heartburn. If you want to talk about non-conformance with > > > RFC 2327, let's talk about those dollar signs. > > > > > > octetString has already been taken out of mtpAddress. Please, > > > take it out of these descriptors too and get rid of it all together. > > > > > > -troy From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 13:33:14 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01317 for ; Tue, 21 Nov 2000 13:33:14 -0500 (EST) Received: from standards (47.234.32.16:3025) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8B05@standards.nortelnetworks.com>; Tue, 21 Nov 2000 13:13:28 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 123421 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 13:13:27 -0500 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8A8D@standards.nortelnetworks.com>; Tue, 21 Nov 2000 13:03:27 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eALIK6t08744; Tue, 21 Nov 2000 19:20:06 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id TAA23846; Tue, 21 Nov 2000 19:20:03 +0100 (MET) Received: from ericsson.com (kipe2.ki.sw.ericsson.se [147.214.68.2]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id TAA19204; Tue, 21 Nov 2000 19:20:02 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <200011211055.FAA00160@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A1ABBA5.8D0A1BFB@ericsson.com> Date: Wed, 22 Nov 2000 05:15:01 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: I-D ACTION:draft-cutler-megaco-recvpkg-01.txt X-To: wayne.cutler@marconi.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Wayne, Could you elaborate on some use cases for this package? I read it and I have no idea what it is used for. What type of information is stored etc? Is this property per termination ? On the root termination? Does it link terminations together? What information does it store that can't be received from an auditvalue/auditcapability? Regards, Christian Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : MGC Recovery Package for Megaco/H248 > Author(s) : W. Cutler > Filename : draft-cutler-megaco-recvpkg-01.txt > Pages : 4 > Date : 20-Nov-00 > > This documents provides a proposed definition for a supplemental > package to Megaco/H.248. The proposed package addresses support of > functionality to enable a MGC to store information on a MG which can > subsequently be retrieved thereby facilitating the appropriate (MGC) > recovery action in the event of a MGC restart. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-cutler-megaco-recvpkg-01.txt > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 13:33:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01326 for ; Tue, 21 Nov 2000 13:33:14 -0500 (EST) Received: from standards (47.234.32.16:3025) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8B0A@standards.nortelnetworks.com>; Tue, 21 Nov 2000 13:13:46 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 123425 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 13:13:46 -0500 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8A90@standards.nortelnetworks.com>; Tue, 21 Nov 2000 13:03:45 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eALIK0200845; Tue, 21 Nov 2000 19:20:00 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id TAA23806; Tue, 21 Nov 2000 19:19:59 +0100 (MET) Received: from ericsson.com (kipe2.ki.sw.ericsson.se [147.214.68.2]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id TAA19168; Tue, 21 Nov 2000 19:19:58 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: multipart/mixed; boundary="------------5FCEE04064CF62B910BEA66E" Message-ID: <3A1AB0CA.432F24AC@ericsson.com> Date: Wed, 22 Nov 2000 04:28:42 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Announcement Package, noc X-To: Hung Bui To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------5FCEE04064CF62B910BEA66E Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello Hung, Annex K has now been decided so we can't add anymore parameters. The decided Annex K is attached. Sorry about the attachment but the pictel server where it should be uploaded is down. Cheers, Christian Hung Bui wrote: > > Dear Michael, > > I suggest we should also add syntax for stringing announcement phrases > together. May be a Parameter Id that indicates how many announcement > phrases to be included in the request. > > Cheers, > Hung. > > > ________________________________________________________________________ > ========= > =========== Hung Bui < mailto:hbui@salix.com> > ============ Senior Product Manager > ============ Next Generation Switching > == ==== == Tellabs Gaithersburg > == 904 Wind River Lane Suite 101 TEL: (240) 686-6500 x6176 > === Gaithersburg, MD 20878 FAX: (240) 631 2228 > > The statements contained herein are strictly those of > their author, and unless otherwise specifically indicated > should not be attributed to Tellabs® or its management. > > -----Original Message----- > From: Brown, Michael [mailto:C.Michael.Brown@AMERICASM10.NT.COM] > Sent: Monday, November 20, 2000 1:27 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Announcement Package, noc > > The link is to the document on the IETF Megaco web site. This was up for > decision > last week in Geneva. Any changes made in Geneva would not be reflected in > this > document. > > http://ietf.org/internet-drafts/draft-ietf-megaco-h248k-00.txt > > Cheers, > > Michael Brown > > Paul Long wrote: > > > ...except of course, as I just noticed, a link to that particular annex. > Sorry. > > :-) > > > > Paul Long wrote: > > > > > Takao, > > > > > > Everything you need should be here: > > > http://www.packetizer.com/iptel/h248/doc_status.html > > > > > > Paul Long > > > ipDialog, Inc. > > > > > > -----Original Message----- > > > From: Media Gateway Control (megaco) > > > [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Matsuda > > > Sent: Sunday, November 19, 2000 8:03 PM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Announcement Package, noc > > > > > > Hello Mr.Christian, > > > > > > What is the URL to get the most recent version of H.248 ANNEX K? > > > > > > Best regards, > > > Takao --------------5FCEE04064CF62B910BEA66E Content-Type: application/pdf; name="h248_annex_k_decided.PDF" Content-Disposition: inline; filename="h248_annex_k_decided.PDF" Content-Transfer-Encoding: base64 JVBERi0xLjIgDQol4uPP0w0KIA0KMTAgMCBvYmoNCjw8DQovTGVuZ3RoIDExIDAgUg0KL0Zp bHRlciAvTFpXRGVjb2RlIA0KPj4NCnN0cmVhbQ0KgBxEANGoyGouGY2EA3HMHGIyEEHGQ4EA xGIugogORlEBXEBugZCKkEg0IhUMG4uG8KEBUIgNGAgmMxORngYvI0xGIwFwwiktM0wEEtMc yoZUO4gFAxFMtNQNIsjKMhkYxhIuig3GgzlUsl1CmcamwNnAxitcHMQoEwnoyGQ5o9FngwHI 3s0tpIoJAuGQ0ihBNxuMp4EBLEBct0KI5lwRyNNFwBuN51NxjMptxh0EBQIJDJZBI5FppUp4 tG8QFoyrgwGlHIggnEQnc9n5UoItud+uNGvFKKBhMZrMJnMpJIg6EBhNwsmR4GAw1Wjp8x1I yjFe14oKxlORzNJvN3IplOBpUFVKIp4OmMMhz5BO8Bl6VC6tY11KKhoMOaOHA4TiBAOY6jgO A3jkOg5uSwLJsqy7MhAMzKDGOjvjcMI2DSOg8uSzQwhAJoyjINMPCO/YyjuMI8hclo0DSOb5 uoiy+Nq7LlMlCUHDczQxsmNgyBAMSOI3C8XRDIENjoNCORBEUSRNFENjDBMRDMMzuQeOcDQQ EA3jM+bzKUzA5jm4Y0jcM8ViNAwQMGMI2jgNgyuRDIQR4OsfSAjjlOSOsRDfBUbwazEdOZDz 1vUEExTJAEDS+84UQ9Hk3je70KPBLgzBBQ7NUU4YyjmF0YBAFoZpSG0aNgIyzKsFy0qOoK5h mGC7ioooUCWFzxtIBoZIuhLeJdVIZrPVq1NsoSiIqngbhu6CjryED5hiGgXBs1qYpa16y2JV y1twnoYhsG7d2wpDfDkN44O5ClPvnUiFNSHCEWNbQjNkubatu3La1s+DBVFUlTVRbdWW7Y9Y 1m3dbr4+depNYF62HgtjVg3bZ2ZZzehRaLyWnatrvvgi0YotlZhuGtyWe9A7MzF7yXfUYYpS 1mQ3tZTaVeBtvtZfilX8+TyOoGQbVy7FU1Xkec4RWlbVwGeG18hVy4jbmSXKouL2bY1oWlal rYho+q6UtoZ57cq8imNIzwsNmXV3mFSOtcL7rmxOFCWrldKeid57AnGJaSterhArgcJ3ralY 5XeBb9VWxcFcAc6YmVcueuGNCMNI8SMFoQMjBjLUG/g2RTgG+BnelU3vnFvX3lONbTtcLuM5 AwjhTIuBQGDnOeGIuBT0zrVQFAiU+MbHDhSzwhAJI3QzEb1wTJKOThFNMOTCHNSNG3QRyOlQ 6DUa3Ou+4UdjtgqDzdTkCeJ7mCoJ7DhQMgyjMMM7jp3+ARkify/OhcIgdQ5H7QqcgKC6A7Iu QqiF8Cu0wAoPghQMweQhhvTenF5UBoEQKPij93L9H7P4QghcOYZX9PhPq8M38AzMHrO6Do+a vz6g1aMxtz6OHREfTc0BXcMn+QqDDCwMsLnaFDPmDhkC2SlJ7dy7s56s4TtviQzEi5GYlAof S+tNgbg6mYgG8p673IcMtgaaWGT44aPlCdF1IIcnrhjDyGNOLbinw+Iu/2K8K4dxEOOUMyRR Ymu8OhFE6cVEZvliynIECZj1nEDlGU+j43hhWQuHVT7tQ3B5hivCH75ShkxRcCAOsJUfh0T+ RsOBG4So6QUoB7rol3R2kPEpwbOzdMaKHLmXJ8zdNTVG65ZLZylJJP2nU8CFIuGTDmGxDb1Q 8oJTWGwN66VQPyfbIRnRugWydiu8WEIbA6HIlSG+BJ3oOggXVG6MSgkHpmU0kpD4R5INwkk+ WG87JWSUMccoOkm5DR4WCCiPULTuRFOSHZ+UTjngzmwjGO7w5EnIDmHQxyZ5INCeE+V5qIgx omQSh4Oa6gxhpDMY+V0Y5WB2iCiOVgZk1pmomcoyz+6HvlDsG8x5HENLqS5G50iZw6qekgVE BpAQDQplbmRzdHJlYW0NCmVuZG9iag0KMTEgMCBvYmoNCjEzNzcNCmVuZG9iag0KNCAwIG9i ag0KPDwNCi9UeXBlIC9QYWdlDQovUGFyZW50IDUgMCBSDQovUmVzb3VyY2VzIDw8DQovRm9u dCA8PA0KL0YwIDYgMCBSIA0KL0YxIDcgMCBSIA0KL0YyIDggMCBSIA0KL0YzIDkgMCBSIA0K Pj4NCi9Qcm9jU2V0IDIgMCBSDQo+Pg0KL0NvbnRlbnRzIDEwIDAgUg0KPj4NCmVuZG9iag0K MTMgMCBvYmoNCjw8DQovTGVuZ3RoIDE0IDAgUg0KL0ZpbHRlciAvTFpXRGVjb2RlIA0KPj4N CnN0cmVhbQ0KgBxEANGoyGouGY2EA3HMHGIyEEHGQ4EAxGIugogORlEBXEBugZCKkEg0IhUM G4uG8KEBUIgNGAgmMxORngYvI0xGIwFwwiktM0wEEtMcyoZUO4gFAyFMtNQNIsjKMhkYxhIu ikri8ZlsvmdGms3I0Qnc9n5UoItngwGlnosxltJFBBNxuN51NxjMptMpuOggIhpjZjOhpN5u ppUp8JEAtiwuidHIlKKBhORhvh0MpyJJEHVDMhpEBcFAwPAw1A0LgpxNPmOOrcQrtKKh5OBl z4gvp1NutoWwyFnyYoKxhNh1Mpzz++G8QuEupRFPGaORu4wg5nOyVKMvT0el04x1Ys3wt5uN x+R2YoJN+zfWNnZo3rNN+0mmGAy8fl8/A9ToBQIQ3joND5Oe4YxQGND7tOGbVvKGIaBo9CLv +4YiDKMwwjqNg6M+7o6QgnzGhmlIbOEECcBiioZhcHLZLQmCehkGSWCoooUCXFqmKcBqJoQ7 TZpwGcWRdGCgueosWhwncYLk7EexMikDxSI0VqtIyjrStYZhpGC3hcGIay8o65OKOQ0jCMQ2 I4FoQLouy8L0vi/BAOA2DCPLfNfH4ZxgyacLItazy2nq2qOt8yqUKY0jO+DOs+MI4Ds778NQ /TWR7PgZKw7YUQwOYxzQODCsOz72jSwows0OYQQIjk7zyEA3jMEAwhAOzLTTNaODCuq7ryva +joF09sbGiMRs4dGUc4zatuz4nieFiWie74yQzDcOwfTUKODT1mPgIg6svUo3M+KA5DeOw0j mww3DKMli264CuQAJ0BjSMw8iGN42zuMtzXRdV2Xcw942vbMOL/DQ2DmMtuMU39kBrZTKMsz GAs25TfMYFuKYsFE31/OVhTq6y+Y6hV6z/i7LsyzdIKG3wcQnKgUV9SrTtQ8VM4kFua29Cza Ns3DdDc3jN1Xd9Z1rX042DOg6Dneef48Gclwm9YnN4MTN6aEAxjyMc2DnlVvXs4bK5fjTOM8 oa7KLBjUPziLXaFFAUWfoz6s0M7N6ru+P05itPOK47k0iN09R7jz07yoaY3aEA64eMlXDejQ yjgjeHzrnOn2BOdhvLxzYu3JLGrXQ64qUofX9e31DyotVDLc+akKVAlV7Cw7C6Qu45jYPM7T wPNWjeOQQDYN43jhqjv2luwGhbQ7/bzDENYWz/OXXdt34Q2/ldDkupBA+tXDQjgmiPwPqY9k FPTh0WTL/M80r9s/r09teMuozJWylG5moQcz5wRj20u6aKZ8OYdE0BuDO+5TayVPHtNCGNVZ yVbAgDmbcMa+g0lFfI1FYauFdK+YY8l84boGq+L0sZ/Z6w7BvhCRwOjRVZvKTxBAOoYW/vuB a/BTjeWuBta8HJ/Tj3+MYZg243LSA2s6boaqAxv4lHrb2blvoZW/xIR6FQFRSnDnIOUUNXzj GrMrWQ3kKcHoQFFDhExtqrYthyc4wFpZh4koVby/2JsAIOmigGDAGr0zXxXQBFkoZuy+LlXe b6MEYjjRkcVGgp8QY1RDXBG4M0IU7RyOo2ZxrK5ENqlAzFt6UGJNBZvB2KRqAbPTaAhOGMiY FlDgbA8M8MJSyScRGWM8kIwqfYUh186rXusFfA5cM0Kgyh2M28SEboy/RAiEp09b83ywlMCY Nc0e1vnrj822ABoZXgwBu9MqIDSAgA0KZW5kc3RyZWFtDQplbmRvYmoNCjE0IDAgb2JqDQox MjU1DQplbmRvYmoNCjEyIDAgb2JqDQo8PA0KL1R5cGUgL1BhZ2UNCi9QYXJlbnQgNSAwIFIN Ci9SZXNvdXJjZXMgPDwNCi9Gb250IDw8DQovRjAgNiAwIFIgDQovRjEgNyAwIFIgDQovRjIg OCAwIFIgDQovRjMgOSAwIFIgDQo+Pg0KL1Byb2NTZXQgMiAwIFINCj4+DQovQ29udGVudHMg MTMgMCBSDQo+Pg0KZW5kb2JqDQoxNiAwIG9iag0KPDwNCi9MZW5ndGggMTcgMCBSDQovRmls dGVyIC9MWldEZWNvZGUgDQo+Pg0Kc3RyZWFtDQqAHEQA0ajIai4ZjYQDccwcYjIQQcZDgQDE Yi6CiA5GUQFcQG6BkIqQSDQiFQwbi4bwoQFQiA0YCCYzE5GeBi8jTEYjAXDCKS0zTAQS0xzK hlQ7iAUDMUy01A0iyMoyGRjEbjIXRSVxeMy2XzOjTWbkaITuez8qUEWzwYDS0UWYy2kigqHk 4GUdUMym46m2mlSnzEWxYXROjkSlFYwmw6mU53m/0+r0avUoing6GU5G7FiDIg3J3GXUoy5g QFwUDA8DAYlwUizPi3J4OuRDKigkm7M5vF5/Q4elGndajVDAZa7YU4G7KIbTC2jECghG86Gj fRDRdExdQ0cTVjPXbEYjQaCDnYbbkQymYwnU2HS86U6eKfeYZykbdAQTgYxUZhcHLbLSmCeh m1ijqKFAlhcGjPhki6Eso0acBm/0AQEoLRKKswbhu4yjrmzzlPGFwbPK7L9iM/oYv/AKjwyn oYhsGsEQkuYpjoMI6DSOcdjGObYwiFqJoRATEJwsq2LQtS2LdGoUCcN43DKz7BPvBjysq/kL RcoECBhAz+qIpUFhrB0IIVFEKS5DChTHDkPQFELPxJE0JSPFU2Re5a2TDGrRLmKA5DeMYyjI OqNyA5QWyEqznuBJCKyVPa1p7J03oREClCMN45BAMowjGNAQDCNw3DeOo3UKNq9jpUgQDI9b 2vfWFER0NMpVINwyI+voxM0EA3jMEAxjyMY2McEEeVg9bhUNZQ3Sq8zCPQ0dAKU6qOCaI4XW lIasBqljRhQIKQW2IYQDaMI8hAOa914MIQDMNI8WeOA2XXETAAaq0TuAFFS1PVNV1aOd2jSM 7ODYEA6Dfhg0W1bjxBu8tvqy4CLhoGIcTkpQghBbaNDLQo0js4SbDmOtRVeOeEYUEF73Xg1s 2gMg0jHHVn4DVFVDLVjdNOFDhZtnDM14MQ829aj9IutC55ozlWZgMI5DDVjdtdeVO4ejlD6r Hdcjmu4xjTedn6RriP0Jqeq6vYGt2yz4qBUisABtCK5KVluEs7r1bykFyW4hYMp4fHVPjwOA 00TeXFx6EA7jSNmFx6N44bTneB59VvAiSM25bonjJ7yFFTqKOGqasMrd10MgX63v2wJBOmOK yikUJ4HNxLnZdT1c4VjjrWIyBZtOQjrd2Z8GMdO0SOEpZsNwzvF2ocIo879WvgFTZ5gjdYNW L2PcOg5265TBBkrD9P+GoYQ7TTcWHmm95f2NcJBZYYeL+eXM7ZbMQ8rPbEyNsoaWzrsagoRp RF1qmIJ4hV0jqG2urbeG4Ni7Gth3YgSB3y0HgvDWg2l+hnW0M0cyz1n75FehtV+HJ0CNilLC WIsZZCzHxHvW8+li5lWMsbY6XRhwcFBsmViqQMjNnZP+DcGZTq6nZOQg2rpXTAoUKtWUzNhy v2YL4gC8RrkC1HmVP/BApBSlzrtXewZeMAAQB2aoGkMIYoawne8q6EbC2GvGW4UMJBhUnBkD eY4NwXH0gyPmcpuZESVPwDOHV1JugykcOFGgOJjWeswUGoUObLXpLBfk1UNwc1QuyfKS1hxe 2UkbkpJZHZvZEN0Iu7pvEZQUQAZPJ6KUdHNm6eKvEOkoJRBjieRte67ImKeXi8wNq6lduGVc GEMwZmRvkheVhGT8ITPcc1Clg7fHKBoVQGxo5HCNskDtAd4yho4AgCOzkO6+QhpSl+G9yZmo wFdWs/BX8x5JR2jS5iI4aYksLjcHKOEciOS6m4GRHQYXzL7ME0tjCDIfPwY+yGcoZWSy3ZSy teMd4tsybS0Nm7OV4Taiq0A1FJGiwHhe02bDg2okcgk6prBTZjtpfs2FscBZ0QJdO6ltynm4 MQpe3aWZc6QU7Dc4EKjg0pEcOq4c0rinGLzDk49yLk12sNcvNmKkdXOufleTJIoN4yFzdM2y mywFSuudgraJ7VCOQdeAYx4b+3BvHeS2l5gcnnPQZPPdI0MHt1hl2q58Ks3yUPMCeaHS4TgP sfcDd+DnoRP9YXUyK5Mq9EcpA/+LkAqetmaPAimUCnzrTgY9lTMEahQUqJBaDCnoNF7bU79V VeFnyTf5N4EEJXB0KYLCuFsL3tQyWKsdrqsnxw5fUcCB4Mq0WXfk4OQgMgZhTtKzetlQw53Z PLTWodna7vCUNZ9kARwQPIWSzS7N27uhjjBA2swNEaWwgmbtgxwjdxCdW3+Qb6bx2xdZHkNK sTdNlXZW9aF/yNquZpBJHx7mqXItfLQOhdiOQyOFMeJz92GRZklbu9CvJJkbXxE+PNYHu2Jc CCAy7Vl7mOhef8GANb8PwhkzTDZd2DQyu5ARedQb9mav7iaIsvgyrIDhOBwpfIWGaeLQwzLx VO2EulNgNKrLHFCYtZIyoNAXHjBrfmWlT2uuLmniK8lsliKluCRy9yvMEK7pKZmnWbJhYiqn hKo1q3sHABwgx+FxGgLLjzFpdxunAmXN2y81Fi3xtZpYzl5Th241lXADAHKYpaaId+wbRqrg zKDDbHrEcUj5GaZe8+/znZIG8YXpczKiqIWsIxYXMmZs0NPDRpq4dKI62dgBb03TDmaMhxbV BbKnjdhtOFgJ8t9XsvwOmdWd67NbLJv9q4zuDtW60znsFkyqA5ZfKiA0gIANCmVuZHN0cmVh bQ0KZW5kb2JqDQoxNyAwIG9iag0KMTk1OQ0KZW5kb2JqDQoxNSAwIG9iag0KPDwNCi9UeXBl IC9QYWdlDQovUGFyZW50IDUgMCBSDQovUmVzb3VyY2VzIDw8DQovRm9udCA8PA0KL0YwIDYg MCBSIA0KL0YxIDcgMCBSIA0KL0YyIDggMCBSIA0KL0YzIDkgMCBSIA0KPj4NCi9Qcm9jU2V0 IDIgMCBSDQo+Pg0KL0NvbnRlbnRzIDE2IDAgUg0KPj4NCmVuZG9iag0KNiAwIG9iag0KPDwN Ci9UeXBlIC9Gb250DQovU3VidHlwZSAvVHJ1ZVR5cGUNCi9OYW1lIC9GMA0KL0Jhc2VGb250 IC9UaW1lc05ld1JvbWFuDQovRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZw0KPj4NCmVuZG9i ag0KNyAwIG9iag0KPDwNCi9UeXBlIC9Gb250DQovU3VidHlwZSAvVHJ1ZVR5cGUNCi9OYW1l IC9GMQ0KL0Jhc2VGb250IC9UaW1lc05ld1JvbWFuLEJvbGQNCi9FbmNvZGluZyAvV2luQW5z aUVuY29kaW5nDQo+Pg0KZW5kb2JqDQo4IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnQNCi9TdWJ0 eXBlIC9UcnVlVHlwZQ0KL05hbWUgL0YyDQovQmFzZUZvbnQgL0NvdXJpZXJOZXcNCi9FbmNv ZGluZyAvV2luQW5zaUVuY29kaW5nDQo+Pg0KZW5kb2JqDQo5IDAgb2JqDQo8PA0KL1R5cGUg L0ZvbnQNCi9TdWJ0eXBlIC9UcnVlVHlwZQ0KL05hbWUgL0YzDQovQmFzZUZvbnQgL0FyaWFs LEJvbGQNCi9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nDQo+Pg0KZW5kb2JqDQoyIDAgb2Jq DQpbIC9QREYgL1RleHQgIF0NCmVuZG9iag0KNSAwIG9iag0KPDwNCi9LaWRzIFs0IDAgUiAx MiAwIFIgMTUgMCBSIF0NCi9Db3VudCAzDQovVHlwZSAvUGFnZXMNCi9NZWRpYUJveCBbIDAg MCA1OTUgODQyIF0NCj4+DQplbmRvYmoNCjEgMCBvYmoNCjw8DQovQ3JlYXRvciAoTWljcm9z b2Z0IFdvcmQgKQ0KL0NyZWF0aW9uRGF0ZSAoVHVlc2RheSwgMjEgTm92ZW1iZXIgMjAwMCAw ODoyMCkNCi9UaXRsZSAoaDI0OF9hbm5leF9rX2RlY2lkZWQpDQovQXV0aG9yIChDaHJpc3Rp YW4gR3JvdmVzKQ0KL1Byb2R1Y2VyIChBY3JvYmF0IFBERldyaXRlciAzLjAyIGZvciBXaW5k b3dzKQ0KL0tleXdvcmRzICgpDQovU3ViamVjdCAoKQ0KPj4NCmVuZG9iag0KMyAwIG9iag0K PDwNCi9QYWdlcyA1IDAgUg0KL1R5cGUgL0NhdGFsb2cNCi9EZWZhdWx0R3JheSAxOCAwIFIN Ci9EZWZhdWx0UkdCICAxOSAwIFINCj4+DQplbmRvYmoNCjE4IDAgb2JqDQpbL0NhbEdyYXkN Cjw8DQovV2hpdGVQb2ludCBbMC45NTA1IDEgMS4wODkxIF0NCi9HYW1tYSAwLjI0NjggDQo+ Pg0KXQ0KZW5kb2JqDQoxOSAwIG9iag0KWy9DYWxSR0INCjw8DQovV2hpdGVQb2ludCBbMC45 NTA1IDEgMS4wODkxIF0NCi9HYW1tYSBbMC4yNDY4IDAuMjQ2OCAwLjI0NjggXQ0KL01hdHJp eCBbMC40MzYxIDAuMjIyNSAwLjAxMzkgMC4zODUxIDAuNzE2OSAwLjA5NzEgMC4xNDMxIDAu MDYwNiAwLjcxNDEgXQ0KPj4NCl0NCmVuZG9iag0KeHJlZg0KMCAyMA0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDA2MDczIDAwMDAwIG4NCjAwMDAwMDU5MzMgMDAwMDAgbg0KMDAwMDAw NjMwOSAwMDAwMCBuDQowMDAwMDAxNTA2IDAwMDAwIG4NCjAwMDAwMDU5NjcgMDAwMDAgbg0K MDAwMDAwNTQ0MiAwMDAwMCBuDQowMDAwMDA1NTY1IDAwMDAwIG4NCjAwMDAwMDU2OTMgMDAw MDAgbg0KMDAwMDAwNTgxMyAwMDAwMCBuDQowMDAwMDAwMDIxIDAwMDAwIG4NCjAwMDAwMDE0 ODIgMDAwMDAgbg0KMDAwMDAwMzAzNyAwMDAwMCBuDQowMDAwMDAxNjc0IDAwMDAwIG4NCjAw MDAwMDMwMTMgMDAwMDAgbg0KMDAwMDAwNTI3MyAwMDAwMCBuDQowMDAwMDAzMjA2IDAwMDAw IG4NCjAwMDAwMDUyNDkgMDAwMDAgbg0KMDAwMDAwNjQwNiAwMDAwMCBuDQowMDAwMDA2NDk0 IDAwMDAwIG4NCnRyYWlsZXINCjw8DQovU2l6ZSAyMA0KL1Jvb3QgMyAwIFINCi9JbmZvIDEg MCBSDQovSUQgWzw3Y2E0M2JkYWI3NTA1YzRlZTE3Y2UwYjU0ZmVkMjYyYj48N2NhNDNiZGFi NzUwNWM0ZWUxN2NlMGI1NGZlZDI2MmI+XQ0KPj4NCnN0YXJ0eHJlZg0KNjY3Mg0KJSVFT0YN Cg== --------------5FCEE04064CF62B910BEA66E-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 13:48:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03560 for ; Tue, 21 Nov 2000 13:48:53 -0500 (EST) Received: from standards (47.234.32.16:3025) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8C29@standards.nortelnetworks.com>; Tue, 21 Nov 2000 13:25:15 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 123984 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 13:25:15 -0500 Received: from auemail2.firewall.lucent.com (auemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8C28@standards.nortelnetworks.com>; Tue, 21 Nov 2000 13:25:15 -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 NAA25751 for ; Tue, 21 Nov 2000 13:42:08 -0500 (EST) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id NAA25745 for ; Tue, 21 Nov 2000 13:42:08 -0500 (EST) Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA06364; Tue, 21 Nov 2000 13:42:06 -0500 Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA06357; Tue, 21 Nov 2000 13:42:05 -0500 X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Original-CC: MEGACO@STANDARDS.NORTELNETWORKS.COM References: <3A1A9ADF.825A4A8F@lucent.com> <3A1AAEA3.3F217A40@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A1AC1B3.2B32688D@lucent.com> Date: Tue, 21 Nov 2000 13:40:51 -0500 Reply-To: Troy Cauble Sender: "Media Gateway Control (megaco)" From: Troy Cauble Subject: Re: MEGACO: Impl. guide comments/corrections X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit If I define a package with a signal parameter "dr" you can't tell it from a DurationToken. Signals { foo/bar { dr=100, dr=200 }} The "new rule" doesn't address this. It only says that my signal parameter name cannot start with "SPA". -troy Christian Groves wrote: > > Hello Troy, > > I'm not sure what the current problem is. Any overlap between properties > and parameters have been resolved. Any new signal / event parameter must > be defined according to the new rule. The other tokens you list do not > overlap with the current signalOther definition. > > Christian > > Troy Cauble wrote: > > > > Hello all, > > > > Section 6.23 of the Implementors Guide discusses the > > fact that sigParameter is hard to parse because it's > > impossible to tell the sigStream sequence from the > > sigOther sequence. > > > > I find this statement confusing: > > "The problem lies in the fact that in the future > > that the introduction of a new Token for a > > signal Parameter may cause overlap with an > > existing package identity." > > > > More to the point is the fact that the opposite problem > > exists *NOW*. Package identities (i.e. signal parameter > > names) can be defined such that they conflict with nearby > > tokens such as DurationToken, StreamToken, SignalTypeToken, > > etc. These tokens are used in "Token EQUALS X" sequences > > that are impossible to distinguish from sigOther. > > > > While the following change to section 12.2: > > "The textual ParameterID of parameters to Events > > and Signals shall not start with "EPA" and "SPA" > > respectively." > > > > guards against conflicts with FUTURE tokens, it does not > > guard against conflicts with CURRENT tokens. > > > > There are many other things that these "textual ParameterIDs" > > must avoid matching. A (partial?) list for signal parameter > > names is: > > StreamToken > > SignalTypeToken > > DurationToken > > NotifyCompletionToken > > > > A (partial?) list for event parameter names is: > > ModemToken > > StreamToken > > DigitMapToken > > > > The lists are a little longer if you want to make parsing easy. > > These are required to make parsing possible. They should be > > listed in the correction to section 12.2. > > > > -troy From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 16:51:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10998 for ; Tue, 21 Nov 2000 16:51:55 -0500 (EST) Received: from standards (47.234.32.16:1205) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8DAB@standards.nortelnetworks.com>; Tue, 21 Nov 2000 16:33:13 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 124497 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 16:33:13 -0500 Received: from zrchh190 (47.158.65.22:54015) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8DA2@standards.nortelnetworks.com>; Tue, 21 Nov 2000 16:23:12 -0500 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by zrchh190; Tue, 21 Nov 2000 15:40:34 -0600 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Tue, 21 Nov 2000 16:33:07 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 21 Nov 2000 16:33:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05402.9C4AA7E0" X-Orig: Message-ID: <353093573B82D411889E0000F808216648E4F5@zcard00q.ca.nortel.com> Date: Tue, 21 Nov 2000 16:32:55 -0500 Reply-To: "Blatherwick, Peter [CAR:AT14:EXCHANGE]" Sender: "Media Gateway Control (megaco)" From: "Blatherwick, Peter [CAR:AT14:EXCHANGE]" Subject: Re: I-D ACTION:draft-ietf-megaco-mib-01.txt X-To: Matt Holdrege 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_01C05402.9C4AA7E0 Content-Type: text/plain; charset="iso-8859-1" Hi Matt, I'd definitely like to have a look, but am unable to retrieve the I-D. Link below comes back with "no longer available .. deleted on July 17, 2000" (and same URL with 02 on the end also fails Not Found). Any idea what's up with that? Is there another place to access? -- Peter Blatherwick -----Original Message----- From: Matt Holdrege [mailto:matt@IPVERSE.COM] Sent: Tuesday, November 21, 2000 07:18 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: I-D ACTION:draft-ietf-megaco-mib-01.txt Regarding this document...As many of you know I've been begging for input for a long time, but I've realized that we wouldn't get good input til people started implementing the protocol. Now that that has happened, I'm flooded with input. So unfortunately this draft isn't very well organized. Even as I finalized this draft, a bunch more objects were suggested to me. So please review the objects in this draft and comment. Regardless of further input, I have a lot of work to do to organize this MIB better. At 05:57 AM 11/21/2000 -0500, Internet-Drafts@IETF.ORG wrote: >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 MIB > Author(s) : M. Holdrege, I. Akramovich > Filename : draft-ietf-megaco-mib-01.txt > Pages : 35 > Date : 20-Nov-00 > >This memo defines a portion of the Management Information Base (MIB) >for use with network management protocols in the Internet community. >In particular it defines objects for use by the MEGACO protocol >operating on Media Gateways and Media Gateway Controllers. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-megaco-mib-01.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-megaco-mib-01.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-megaco-mib-01.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20001120151500.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-megaco-mib-01.txt > > ------_=_NextPart_001_01C05402.9C4AA7E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-megaco-mib-01.txt

Hi Matt,

I'd definitely like to have a look, but am unable to = retrieve the I-D.  Link below comes back with "no longer = available ..  deleted on July 17, 2000" (and same URL with 02 = on the end also fails Not Found).  Any idea what's up with = that?  Is there another place to access? 

-- Peter Blatherwick 



-----Original Message-----
From: Matt Holdrege [mailto:matt@IPVERSE.COM]
Sent: Tuesday, November 21, 2000 07:18
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: I-D = ACTION:draft-ietf-megaco-mib-01.txt


Regarding this document...As many of you know I've = been begging for input
for a long time, but I've realized that we wouldn't = get good input til
people started implementing the protocol. Now that = that has happened, I'm
flooded with input. So unfortunately this draft = isn't very well organized.
Even as I finalized this draft, a bunch more objects = were suggested to me.

So please review the objects in this draft and = comment. Regardless of
further input, I have a lot of work to do to = organize this MIB better.


At 05:57 AM 11/21/2000 -0500, = Internet-Drafts@IETF.ORG wrote:
>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 MIB
>         = Author(s)       : M. Holdrege, I. = Akramovich
>         = Filename        : = draft-ietf-megaco-mib-01.txt
>         = Pages           : = 35
>         = Date            = : 20-Nov-00
>
>This memo defines a portion of the Management = Information Base (MIB)
>for use with network management protocols in the = Internet community.
>In particular it defines objects for use by the = MEGACO protocol
>operating on Media Gateways and Media Gateway = Controllers.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-megaco-= mib-01.txt
>
>Internet-Drafts are also available by anonymous = FTP. Login with the username
>"anonymous" and a password of your = e-mail address. After logging in,
>type "cd internet-drafts" and = then
>         = "get draft-ietf-megaco-mib-01.txt".
>
>A list of Internet-Drafts directories can be = found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by = e-mail.
>
>Send a message to:
>         = mailserv@ietf.org.
>In the body type:
>         = "FILE /internet-drafts/draft-ietf-megaco-mib-01.txt".
>
>NOTE:   The mail server at ietf.org = can return the document in
>         = MIME-encoded form by using the "mpack" utility.  To use = this
>         = feature, insert the command "ENCODING mime" before the = "FILE"
>         = command.  To decode the response(s), you will need = "munpack" or
>         = a MIME-compliant mail reader.  Different MIME-compliant mail = readers
>         = exhibit different behavior, especially when dealing with
>         = "multipart" MIME messages (i.e. documents which have been = split
>         = up into multiple messages), so check your local documentation on
>         = how to manipulate these messages.
>
>
>Below is the data which will enable a MIME = compliant mail reader
>implementation to automatically retrieve the = ASCII version of the
>Internet-Draft.
>Content-Type: text/plain
>Content-ID:     = <20001120151500.I-D@ietf.org>
>
>ENCODING mime
>FILE = /internet-drafts/draft-ietf-megaco-mib-01.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-megaco-m= ib-01.txt>

------_=_NextPart_001_01C05402.9C4AA7E0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 17:00:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12230 for ; Tue, 21 Nov 2000 17:00:38 -0500 (EST) Received: from standards (47.234.32.16:1205) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8DCA@standards.nortelnetworks.com>; Tue, 21 Nov 2000 16:41:53 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 124548 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 16:41:53 -0500 Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8DC9@standards.nortelnetworks.com>; Tue, 21 Nov 2000 16:41:52 -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 QAA02587 for ; Tue, 21 Nov 2000 16:58:46 -0500 (EST) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA02583 for ; Tue, 21 Nov 2000 16:58:46 -0500 (EST) Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id QAA20669 for ; Tue, 21 Nov 2000 16:57:09 -0500 (EST) X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------330289FF7007DD5AED62D6B1" Message-ID: <3A1AF005.DC8C5F29@lucent.com> Date: Tue, 21 Nov 2000 16:58:30 -0500 Reply-To: Terry L Anderson Sender: "Media Gateway Control (megaco)" From: Terry L Anderson Organization: Lucent Technologies Subject: ServiceChangeMethod = failover To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------330289FF7007DD5AED62D6B1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The use of ServiceChangeMethod = failover is not clear in H.248. The definition says that it is "sent from the MG to MGC to indicate the primary MG is out of service and a secondary MG is taking over." 1) If the primary is "out of service" presumably the message is sent by the "secondary", but how does the message indicate what primary MG it is taking over for? or must the secondary use the same IPAddr/port as the primary? 2) what properties of the primary does the MGC assume are shared by the secondary? Should the MGC assume that calls that were in progress are continued by the "secondary" MG or should it audit the MG? I am interested in a case where the H.248 signaling part of an MG has failed, say a NIC, but it has a second NIC and can continue all calls, but must receive future transactions from the MGC on this new address. Should it send ServiceChange with ServiceChangeMethod = failover from the new NIC (new ipaddr/port)? Or is failover intended for something different? -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572@skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------330289FF7007DD5AED62D6B1 Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;pager:800.759.8352 pin 1704572 tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks / Applications Group version:2.1 email;internet:tla@lucent.com title:DMTS adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA note;quoted-printable:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal)=0D=0A18E343126 / 10034134 x-mozilla-cpt:;-23792 fn:Terry L Anderson end:vcard --------------330289FF7007DD5AED62D6B1-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 18:33:37 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25008 for ; Tue, 21 Nov 2000 18:33:37 -0500 (EST) Received: from standards (47.234.32.16:4705) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8EC0@standards.nortelnetworks.com>; Tue, 21 Nov 2000 18:15:12 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 124887 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 18:15:12 -0500 Received: from sapphire.int.ipverse.com (w067.z208037018.sjc-ca.dsl.cnc.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB8EBF@standards.nortelnetworks.com>; Tue, 21 Nov 2000 18:15:12 -0500 Received: from matt.ipverse.com (dial-02-52.community.co.uk [195.72.167.244]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id W8BX8MM0; Tue, 21 Nov 2000 15:32:04 -0800 X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.0.2.1.0.20001121153112.023f3580@pop3.ipverse.com> Date: Tue, 21 Nov 2000 15:32:00 -0800 Reply-To: Matt Holdrege Sender: "Media Gateway Control (megaco)" From: Matt Holdrege Subject: Re: I-D ACTION:draft-ietf-megaco-mib-01.txt X-To: Peter Blatherwick To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <353093573B82D411889E0000F808216648E4F5@zcard00q.ca.nortel. com> It works for me. Try again or go to a different ISP perhaps. At 04:32 PM 11/21/2000 -0500, Peter Blatherwick wrote: >Hi Matt, > >I'd definitely like to have a look, but am unable to retrieve the >I-D. Link below comes back with "no longer available .. deleted on July >17, 2000" (and same URL with 02 on the end also fails Not Found). Any >idea what's up with that? Is there another place to access? > >-- Peter Blatherwick > > >-----Original Message----- >From: Matt Holdrege [mailto:matt@IPVERSE.COM] >Sent: Tuesday, November 21, 2000 07:18 >To: MEGACO@STANDARDS.NORTELNETWORKS.COM >Subject: Re: I-D ACTION:draft-ietf-megaco-mib-01.txt > >Regarding this document...As many of you know I've been begging for input >for a long time, but I've realized that we wouldn't get good input til >people started implementing the protocol. Now that that has happened, I'm >flooded with input. So unfortunately this draft isn't very well organized. >Even as I finalized this draft, a bunch more objects were suggested to me. > >So please review the objects in this draft and comment. Regardless of >further input, I have a lot of work to do to organize this MIB better. > >At 05:57 AM 11/21/2000 -0500, Internet-Drafts@IETF.ORG wrote: > >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 MIB > > Author(s) : M. Holdrege, I. Akramovich > > Filename : draft-ietf-megaco-mib-01.txt > > Pages : 35 > > Date : 20-Nov-00 > > > >This memo defines a portion of the Management Information Base (MIB) > >for use with network management protocols in the Internet community. > >In particular it defines objects for use by the MEGACO protocol > >operating on Media Gateways and Media Gateway Controllers. > > > >A URL for this Internet-Draft is: > >http:// > www.ietf.org/internet-drafts/draft-ietf-megaco-mib-01.txt > > > >Internet-Drafts are also available by anonymous FTP. Login with the > username > >"anonymous" and a password of your e-mail address. After logging in, > >type "cd internet-drafts" and then > > "get draft-ietf-megaco-mib-01.txt". > > > >A list of Internet-Drafts directories can be found in > >http://www.ietf.org/shadow.html > >or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > >Internet-Drafts can also be obtained by e-mail. > > > >Send a message to: > > mailserv@ietf.org. > >In the body type: > > "FILE /internet-drafts/draft-ietf-megaco-mib-01.txt". > > > >NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail > readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > >Below is the data which will enable a MIME compliant mail reader > >implementation to automatically retrieve the ASCII version of the > >Internet-Draft. > >Content-Type: text/plain > >Content-ID: <20001120151500.I-D@ietf.org> > > > >ENCODING mime > >FILE /internet-drafts/draft-ietf-megaco-mib-01.txt > > > ><ftp://f > tp.ietf.org/internet-drafts/draft-ietf-megaco-mib-01.txt> From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 22:44:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29632 for ; Tue, 21 Nov 2000 22:44:54 -0500 (EST) Received: from standards (47.234.32.16:4348) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB90B6@standards.nortelnetworks.com>; Tue, 21 Nov 2000 22:26:29 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 125555 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 22:26:29 -0500 Received: from extmx.itri.org.tw by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB90A1@standards.nortelnetworks.com>; Tue, 21 Nov 2000 22:16:27 -0500 Received: from mail3.itri.org.tw (mail3.itri.org.tw [140.96.157.3]) by extmx.itri.org.tw (8.8.8/8.8.8) with ESMTP id LAA21836 for ; Wed, 22 Nov 2000 11:36:17 +0800 (CST) Received: from nti.itri.org.tw (nti.itri.org.tw [140.96.157.2]) by mail3.itri.org.tw (8.9.3+Sun/8.9.1) with ESMTP id LAA15596 for ; Wed, 22 Nov 2000 11:26:32 +0800 (CST) Received: from cclmail.ccl.itri.org.tw (cclmail.ccl.itri.org.tw [140.96.90.193]) by nti.itri.org.tw (8.8.8/8.8.8) with ESMTP id LAA07880 for ; Wed, 22 Nov 2000 11:33:29 +0800 (CST) Received: from Exsior ([140.96.102.175]) by cclmail.ccl.itri.org.tw (Lotus Domino Release 5.0.2a (Intl)) with SMTP id 2000112211324727:4217 ; Wed, 22 Nov 2000 11:32:47 +0800 References: <5.0.2.1.0.20001121153112.023f3580@pop3.ipverse.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MIMETrack: Itemize by SMTP Server on CCLMAIL/ITRI(Release 5.0.2a (Intl)|23 November 1999) at 2000/11/22 11:32:47 AM, Serialize by Router on CCLMAIL/ITRI(Release 5.0.2a (Intl)|23 November 1999) at 2000/11/22 11:33:45 AM, Serialize complete at 2000/11/22 11:33:45 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Message-ID: <00d601c05435$115ad820$af66608c@Exsior> Date: Wed, 22 Nov 2000 11:34:05 +0800 Reply-To: ??? Sender: "Media Gateway Control (megaco)" From: ??? Subject: Definiation of Name in ASN.1 and ABNF To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit In ABNF NAME = ALPHA * 63(ALPHA/ DIGIT/ "_") In ASN.1 Name ::= OCTET STRING(SIZE(2)) How can I translate a 64 bytes text string to a 2 bytes octets? In my case, I have a digitmap name in text mode like : DigitMap = Dialplan0{ ....} How can I encode the text "Dialplan0" to ASN ? Thanks From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 22:58:52 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02483 for ; Tue, 21 Nov 2000 22:58:52 -0500 (EST) Received: from standards (47.234.32.16:4348) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB90DD@standards.nortelnetworks.com>; Tue, 21 Nov 2000 22:40:14 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 125627 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 22:40:14 -0500 Received: from zrchh190 (47.158.65.22:44001) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB90D3@standards.nortelnetworks.com>; Tue, 21 Nov 2000 22:30:14 -0500 Received: from zrtps06s.us.nortel.com by zrchh190; Tue, 21 Nov 2000 21:48:05 -0600 Received: from zrtpd00y.us.nortel.com by zrtps06s.us.nortel.com; Tue, 21 Nov 2000 16:10:11 -0500 Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 21 Nov 2000 16:06:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C053FE.F0575DF0" X-Orig: X-Orig: Message-ID: <5F68FAE98163D21193750000F81AC9BE01E88936@zrtpd00x.us.nortel.com> Date: Tue, 21 Nov 2000 16:06:38 -0500 Reply-To: "Cromwell, David [NCRTP:B933:EXCHANGE]" Sender: "Media Gateway Control (megaco)" From: "Cromwell, David [NCRTP:B933:EXCHANGE]" Subject: Re: Multiple SDP "blocks" X-To: Troy Cauble 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_01C053FE.F0575DF0 Content-Type: text/plain Troy, My guess is that the problem was that you couldn't associate a separate packetization with each payload type. David -- cromwell@nortelnetworks.com Nortel Networks Cable Telephony Solutions, Inc. Tel: 919-991-8870 (esn 351) 35 Davis Dr Fax: 919-991-4088 RTP, NC 27709 > -----Original Message----- > From: Troy Cauble [SMTP:troy@LUCENT.COM] > Sent: Monday, November 20, 2000 1:11 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Multiple SDP "blocks" > > In the call flow example, Appendix A.1.2 of the 6/00 ITU document, > item 12 shows the following: > > Local { > v=0 > c=IN IP4 $ > m=audio $ RTP/AVP 4 > a=ptime:30 > v=0 > c=IN IP4 $ > m=audio $ RTP/AVP 0 > } > > and states: > "NOTE - The MGC its preferred parameter values as a series of sdp > blocks in Local. The MGC fills in the Local Descriptor in the Reply." > > > Is this really the way we want to present choices to the MGC? > > SDP already has mechanisms to support multiple suggested parameter > values. For example, this is valid, and equivalent to the intent > above: > > v=0 > c=IN IP4 $ > m=audio $ RTP/AVP 4 0 > a=ptime:30 > > SDP also has mechanisms to specify multiple media streams per session. > So unless we really need to specify multiple SESSIONS, I don't see > a need for multiple "blocks" delimited by v=0 lines. > > -troy ------_=_NextPart_001_01C053FE.F0575DF0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Multiple SDP "blocks"

Troy,

My guess is that the = problem was that you couldn't associate a separate packetization with = each payload type.

David
--
cromwell@nortelnetworks.com     =             =   Nortel Networks Cable Telephony Solutions, Inc.
Tel:   = 919-991-8870  (esn = 351)           &n= bsp;         35 Davis Dr
Fax:  = 919-991-4088          =             =             =   RTP, NC 27709



    -----Original Message-----
    From:   Troy Cauble [SMTP:troy@LUCENT.COM]
    Sent:   Monday, November 20, 2000 1:11 PM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Multiple SDP = "blocks"

    In the call flow example, Appendix = A.1.2 of the 6/00 ITU document,
    item 12 shows the following:

             &nb= sp;           Local = {
       v=3D0
       c=3DIN IP4 $
       m=3Daudio $ RTP/AVP = 4
       a=3Dptime:30
       v=3D0
       c=3DIN IP4 $
       m=3Daudio $ RTP/AVP = 0
             &nb= sp;           = }

    and states:
       "NOTE - The MGC its = preferred parameter values as a series of sdp
        blocks in = Local.  The MGC fills in the Local Descriptor in the = Reply."


    Is this really the way we want to = present choices to the MGC?

    SDP already has mechanisms to support = multiple suggested parameter
    values.  For example, this is = valid, and equivalent to the intent
    above:

       v=3D0
       c=3DIN IP4 $
       m=3Daudio $ RTP/AVP 4 = 0
       a=3Dptime:30

    SDP also has mechanisms to specify mult= iple media streams per session.
    So unless we really need to specify = multiple SESSIONS, I don't see
    a need for multiple = "blocks" delimited by v=3D0 lines.

    -troy

------_=_NextPart_001_01C053FE.F0575DF0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 22:58:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02499 for ; Tue, 21 Nov 2000 22:58:52 -0500 (EST) Received: from standards (47.234.32.16:4348) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB90EB@standards.nortelnetworks.com>; Tue, 21 Nov 2000 22:41:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 125630 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 22:41:07 -0500 Received: from zrchh190 (47.158.65.22:44053) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB90D6@standards.nortelnetworks.com>; Tue, 21 Nov 2000 22:31:07 -0500 Received: from zrtps06s.us.nortel.com by zrchh190; Tue, 21 Nov 2000 21:48:59 -0600 Received: from zrtpd00y.us.nortel.com by zrtps06s.us.nortel.com; Tue, 21 Nov 2000 15:11:34 -0500 Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 21 Nov 2000 15:00:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C053F5.9126DCB0" X-Orig: X-Orig: Message-ID: <5F68FAE98163D21193750000F81AC9BE01E88935@zrtpd00x.us.nortel.com> Date: Tue, 21 Nov 2000 14:59:33 -0500 Reply-To: "Cromwell, David [NCRTP:B933:EXCHANGE]" Sender: "Media Gateway Control (megaco)" From: "Cromwell, David [NCRTP:B933:EXCHANGE]" Subject: Re: Announcement Package, noc X-To: Hung Bui 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_01C053F5.9126DCB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hung, =20 The Base Audio (bau) and Advanced Audio (aau) packages which are = currently being determined as Annex M have this capability. Regards, David -- cromwell@nortelnetworks.com Nortel Networks Cable Telephony Solutions, Inc.=20 Tel: 919-991-8870 (esn 351) 35 Davis Dr Fax: 919-991-4088 RTP, NC 27709 > -----Original Message----- > From: Hung Bui [SMTP:Hbui@SALIX.COM] > Sent: Tuesday, November 21, 2000 8:33 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Announcement Package, noc >=20 > Dear Michael, >=20 > I suggest we should also add syntax for stringing announcement = phrases > together. May be a Parameter Id that indicates how many announcement > phrases to be included in the request. >=20 > Cheers, > Hung. > =20 >=20 > = ________________________________________________________________________= > =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Hung Bui = < mailto:hbui@salix.com> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Senior Product Manager = > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Next Generation Switching > =3D=3D =3D=3D=3D=3D =3D=3D Tellabs Gaithersburg > =3D=3D 904 Wind River Lane Suite 101 TEL: (240) = 686-6500 x6176 > =3D=3D=3D Gaithersburg, MD 20878 FAX: (240) 631 = 2228 >=20 > The statements contained herein are strictly those of > their author, and unless otherwise specifically indicated > should not be attributed to Tellabs=AE or its management. >=20 >=20 >=20 >=20 > -----Original Message----- > From: Brown, Michael [mailto:C.Michael.Brown@AMERICASM10.NT.COM] > Sent: Monday, November 20, 2000 1:27 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Announcement Package, noc >=20 >=20 > The link is to the document on the IETF Megaco web site. This was up = for > decision > last week in Geneva. Any changes made in Geneva would not be = reflected in > this > document. >=20 > http://ietf.org/internet-drafts/draft-ietf-megaco-h248k-00.txt >=20 > Cheers, >=20 > Michael Brown >=20 > Paul Long wrote: >=20 > > ...except of course, as I just noticed, a link to that particular = annex. > Sorry. > > :-) > > > > Paul Long wrote: > > > > > Takao, > > > > > > Everything you need should be here: > > > http://www.packetizer.com/iptel/h248/doc_status.html > > > > > > Paul Long > > > ipDialog, Inc. > > > > > > -----Original Message----- > > > From: Media Gateway Control (megaco) > > > [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Matsuda > > > Sent: Sunday, November 19, 2000 8:03 PM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Announcement Package, noc > > > > > > Hello Mr.Christian, > > > > > > What is the URL to get the most recent version of H.248 ANNEX K? > > > > > > Best regards, > > > Takao ------_=_NextPart_001_01C053F5.9126DCB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Announcement Package, noc

Hung,
 
The Base Audio = (bau) and Advanced Audio (aau)  packages which are currently being = determined as Annex M have this capability.

Regards,
David
--
cromwell@nortelnetworks.com     =             =   Nortel Networks Cable Telephony Solutions, Inc.
Tel:   = 919-991-8870  (esn = 351)           &n= bsp;         35 Davis Dr
Fax:  = 919-991-4088          =             =             =   RTP, NC 27709



    -----Original Message-----
    From:   Hung Bui [SMTP:Hbui@SALIX.COM]
    Sent:   Tuesday, November 21, 2000 8:33 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: Announcement Package, noc

    Dear Michael,

    I suggest we should also add syntax = for stringing announcement phrases
    together.  May be a Parameter Id = that indicates how many announcement
    phrases to be included in the = request.

    Cheers,
    Hung.
     

    _________________________________________________________= _______________
       = =3D=3D=3D=3D=3D=3D=3D=3D=3D 
      = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D   Hung = Bui           &nb= sp;           &nb= sp; < mailto:hbui@salix.com>
     =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D   = Senior Product = Manager           = ; <http://www.salix.com>
     =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D   = Next Generation Switching
     =3D=3D  =3D=3D=3D=3D = =3D=3D    Tellabs Gaithersburg
          = =3D=3D        904 Wind River Lane = Suite 101  TEL:  (240) 686-6500 x6176
          = =3D=3D=3D       Gaithersburg, MD  = 20878        FAX:  (240) 631 = 2228

       The statements contained = herein are strictly those of
       their author, and unless = otherwise specifically indicated
       should not be attributed = to Tellabs=AE or its management.




    -----Original Message-----
    From: Brown, Michael [mailto:C.Michael.Brow= n@AMERICASM10.NT.COM]
    Sent: Monday, November 20, 2000 1:27 = PM
    To: = MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject: Re: Announcement Package, = noc


    The link is to the document on the = IETF Megaco web site. This was up for
    decision
    last week in Geneva. Any changes made = in Geneva would not be reflected in
    this
    document.

     http://ietf.org/internet-drafts/draft-ietf-megaco-h248= k-00.txt

    Cheers,

    Michael Brown

    Paul Long wrote:

    > ...except of course, as I just = noticed, a link to that particular annex.
    Sorry.
    > :-)
    >
    > Paul Long wrote:
    >
    > > Takao,
    > >
    > > Everything you need should = be here:
    > > http://www.packetizer.com/iptel/h248/doc_status.html
    > >
    > > Paul Long
    > > ipDialog, Inc.
    > >
    > > -----Original = Message-----
    > > From: Media Gateway Control = (megaco)
    > > [    mailto:MEGACO@STANDA= RDS.NORTELNETWORKS.COM]On Behalf Of Matsuda
    > > Sent: Sunday, November 19, = 2000 8:03 PM
    > > To: = MEGACO@STANDARDS.NORTELNETWORKS.COM
    > > Subject: Re: Announcement = Package, noc
    > >
    > > Hello Mr.Christian,
    > >
    > > What is the URL to get the = most recent version of H.248 ANNEX K?
    > >
    > > Best regards,
    > > Takao

------_=_NextPart_001_01C053F5.9126DCB0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 21 23:17:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04630 for ; Tue, 21 Nov 2000 23:17:31 -0500 (EST) Received: from standards (47.234.32.16:4348) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB9158@standards.nortelnetworks.com>; Tue, 21 Nov 2000 22:59:08 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 125739 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Nov 2000 22:59:08 -0500 Received: from zmers013 (47.124.1.40:33552) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB9123@standards.nortelnetworks.com>; Tue, 21 Nov 2000 22:48:44 -0500 Received: from zrtps06s.us.nortel.com by zmers013; Tue, 21 Nov 2000 23:05:16 -0500 Received: from zrtpd00y.us.nortel.com by zrtps06s.us.nortel.com; Tue, 21 Nov 2000 17:02:06 -0500 Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 21 Nov 2000 16:58:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05406.3448FF30" X-Orig: Message-ID: <5F68FAE98163D21193750000F81AC9BE01E88938@zrtpd00x.us.nortel.com> Date: Tue, 21 Nov 2000 16:58:39 -0500 Reply-To: "Cromwell, David [NCRTP:B933:EXCHANGE]" Sender: "Media Gateway Control (megaco)" From: "Cromwell, David [NCRTP:B933:EXCHANGE]" Subject: Representation of multiple packetizations in SDP 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_01C05406.3448FF30 Content-Type: text/plain Section 7.1.8, Local and Remote Descriptors, of RFC 2885 (August 2000), describes multiple session descriptions being provided in a descriptor. It's clear from the examples that a session description per codec is the standard. However, in the case where you have multiple packetizations per codec would you have one packetization per v= block or multiple attribute lines on one v= block? Would it depend on whether or not one packetization was preferred over another? I haven't looked at the Implementation Guide recently, but if we don't already have a section on SDP conventions for H.248 I'd like to see one. The lack of specification of SDP and LCO conventions in MGCP has, in my experience, resulted in interoperability problems. David -- cromwell@nortelnetworks.com Nortel Networks Cable Telephony Solutions, Inc. Tel: 919-991-8870 (esn 351) 35 Davis Dr Fax: 919-991-4088 RTP, NC 27709 ------_=_NextPart_001_01C05406.3448FF30 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Representation of multiple packetizations in SDP

Section 7.1.8, Local and Remote = Descriptors, of RFC 2885 (August 2000), describes multiple session = descriptions being provided in a descriptor.  It's clear from the = examples that a session description per codec is the standard.  = However, in the case where you have multiple packetizations per codec = would you have one packetization per v=3D block or multiple attribute = lines on one v=3D block?  Would it depend on whether or not one = packetization was preferred over another?

I haven't looked at the Implementation = Guide recently, but if we don't already have a section on SDP = conventions for H.248 I'd like to see one.  The lack of = specification of SDP and LCO conventions in MGCP has, in my experience, = resulted in interoperability problems.

David
--
cromwell@nortelnetworks.com     =             =   Nortel Networks Cable Telephony Solutions, Inc.
Tel:   = 919-991-8870  (esn = 351)           &n= bsp;         35 Davis Dr
Fax:  = 919-991-4088          =             =             =   RTP, NC 27709



------_=_NextPart_001_01C05406.3448FF30-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 22 04:20:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08040 for ; Wed, 22 Nov 2000 04:20:42 -0500 (EST) Received: from standards (47.234.32.16:2536) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB924A@standards.nortelnetworks.com>; Wed, 22 Nov 2000 4:01:45 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 126116 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 22 Nov 2000 04:01:45 -0500 Received: from mel.alcatel.fr (mail2.alcatel.fr) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB9249@standards.nortelnetworks.com>; Wed, 22 Nov 2000 4:01:44 -0500 Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id KAA10092 for ; Wed, 22 Nov 2000 10:18:09 +0100 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id KAA06728 for ; Wed, 22 Nov 2000 10:15:05 +0100 (MET) Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id KAA03157 for ; Wed, 22 Nov 2000 10:18:29 +0100 (MET) Received: from ms.alcatel.fr ([188.9.247.87]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id KAA05850 for ; Wed, 22 Nov 2000 10:18:29 +0100 (MET) X-Mailer: Mozilla 4.71 [en] (WinNT; I) X-Accept-Language: en,fr MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------7BB6B637B350AA6EC808502D" Message-ID: <3A1B8F73.538CEECA@ms.alcatel.fr> Date: Wed, 22 Nov 2000 10:18:43 +0100 Reply-To: Thomas LEVY Sender: "Media Gateway Control (megaco)" From: Thomas LEVY Organization: Alcatel Subject: [Fwd: I-D ACTION:draft-levy-megaco-mgdiscovery-01.txt] To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------7BB6B637B350AA6EC808502D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry, The I-D editor forgot to forward the draft to Megaco. Thomas, --------------7BB6B637B350AA6EC808502D Content-Type: message/rfc822 Content-Disposition: inline Received: from mayer.dinsunnet (mayer [188.9.32.147]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id JAA02862 for ; Wed, 22 Nov 2000 09:53:32 +0100 (MET) Received: from alcatel.fr by mayer.dinsunnet (8.9.1b+Sun/SMI-SVR4) id JAA23505; Wed, 22 Nov 2000 09:52:09 +0100 (MET) Sender: galand@mayer.dinsunnet Message-ID: <3A1B8939.B37D1331@alcatel.fr> Date: Wed, 22 Nov 2000 09:52:09 +0100 From: Damien Galand X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: thomas.levy@ms Subject: [Fwd: I-D ACTION:draft-levy-megaco-mgdiscovery-01.txt] Content-Type: multipart/mixed; boundary="------------5AA75006CCDD5A5D0829628E" X-Mozilla-Status2: 00000000 This is a multi-part message in MIME format. --------------5AA75006CCDD5A5D0829628E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- ---------------------------------------------------------------- Damien Galand * Alcatel * Etablissement de Marcoussis R & I * Route de Nozay Software Department * 91461 Marcoussis Cedex Damien.Galand@alcatel.fr * FRANCE Tel: +33 (0)1 69 63 41 84 * Fax: +33 (0)1 69 63 11 69 ---------------------------------------------------------------- --------------5AA75006CCDD5A5D0829628E Content-Type: message/rfc822 Content-Disposition: inline Received: from medine.ms.alcatel.fr (medine [193.105.117.1]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id SAA07401; Tue, 21 Nov 2000 18:13:04 +0100 (MET) Received: from aifhs10.alcatel.fr (aifhs10.alcatel.fr [155.132.188.80]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id SAA01874; Tue, 21 Nov 2000 18:12:33 +0100 (MET) Received: from mel.alcatel.fr (mailgate2.alcatel.fr [155.132.188.92]) by aifhs10.alcatel.fr (ALCANET/SMTP2) with ESMTP id SAA18404; Tue, 21 Nov 2000 18:04:48 +0100 (MET) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id SAA17156; Tue, 21 Nov 2000 18:12:12 +0100 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id LAA27565 for ietf-123-outbound.07@ietf.org; Tue, 21 Nov 2000 11:55:02 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id FAA24671 for ; Tue, 21 Nov 2000 05:55:40 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00247 for ; Tue, 21 Nov 2000 05:55:39 -0500 (EST) Message-Id: <200011211055.FAA00247@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-levy-megaco-mgdiscovery-01.txt Date: Tue, 21 Nov 2000 05:55:39 -0500 Sender: nsyracus@cnri.reston.va.us X-Mozilla-Status2: 00000000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Megaco/H.248 Media Gateway Resources Discovery Author(s) : T. Levy, L. Anquetil Filename : draft-levy-megaco-mgdiscovery-01.txt Pages : 8 Date : 20-Nov-00 This document addresses the need for a Media Gateway Controller (MGC) to be informed from the media resources of its Media Gateways (MG) in the context of the Megaco/H.248 protocol. The draft discusses alternative solutions for an effective media gateway resources discovery mechanism. The document is provided as an informational draft for discussion within the Megaco Working Group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-levy-megaco-mgdiscovery-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-levy-megaco-mgdiscovery-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-levy-megaco-mgdiscovery-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001120151156.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-levy-megaco-mgdiscovery-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-levy-megaco-mgdiscovery-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001120151156.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------5AA75006CCDD5A5D0829628E-- --------------7BB6B637B350AA6EC808502D-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 22 04:37:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09926 for ; Wed, 22 Nov 2000 04:37:31 -0500 (EST) Received: from standards (47.234.32.16:4013) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB9264@standards.nortelnetworks.com>; Wed, 22 Nov 2000 4:18:57 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 126149 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 22 Nov 2000 04:18:57 -0500 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB9262@standards.nortelnetworks.com>; Wed, 22 Nov 2000 4:08:57 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eAM9Ppt14386; Wed, 22 Nov 2000 10:25:51 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id KAA16961; Wed, 22 Nov 2000 10:25:50 +0100 (MET) Received: from ericsson.com (arael26m12.ericsson.se [130.100.249.12]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id KAA20804; Wed, 22 Nov 2000 10:25:47 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <3A192CBE.2B5B24B1@ms.alcatel.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <3A1B8008.6727CED7@ericsson.com> Date: Wed, 22 Nov 2000 19:12:56 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: draft-levy-megaco-mgdiscovery-01.txt, X-To: Thomas LEVY To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hello Thomas, Finally have have had a chance to read the draft and have a think about it. I have a fundamental question to this draft. Does the MGC really need such indepth knowledge of the internal capabilities of the MG? Megaco I believe was intended to be agonostic with regards to the internals of an MG. I'm also not sure that a mechanism to discover this needs to be highly available. Once the internals of a MG have been found they don't typically change configuration frequently. Thus I feel a SNMP interface would be appropriate as its something not happening all the time, only during maintenance procedures. Cheers, Christian Thomas LEVY wrote: > > All, > > You will find enclosed the revision of the internet draft "Megaco/H.248 > Media Gateway Resources Discovery". > It has been enhanced in accordance to comments received on the initial > version. > It also shortly raises the issue of the relationship between the draft > and the SDP-ng activities on Capability Description. > > The impacted points in the document are : > -Addition from "7.4 Implementation considerations" and "8. Conclusion" > parts. > -Very minor editorial corrections. > > Please let me know, if you have any comment, > > Thomas, > > ------------------------------------------------------------------------ > > Megaco Working Group T.Levy > L-P.Anquetil > Internet Draft Alcatel > Document: draft-levy-megaco-mgdiscovery-01.txt November 2000 > Category: Informational > > Megaco/H.248 Media Gateway Resources Discovery > > Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026 [1]. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. Internet-Drafts are draft documents valid for a maximum of > six months and may be updated, replaced, or obsoleted by other > documents at any time. It is inappropriate to use Internet- Drafts > as reference material or to cite them other than as "work in > progress." > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > 1. Abstract > > This document addresses the need for a Media Gateway Controller > (MGC) to be informed from the media resources of its Media Gateways > (MG) in the context of the Megaco/H.248 protocol. The draft > discusses alternative solutions for an effective media gateway > resources discovery mechanism. > The document is provided as an informational draft for discussion > within the Megaco Working Group. > > 2. Conventions used in this document > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > this document are to be interpreted as described in RFC-2119 [2]. > > 3. Abbreviations > > MG: Media Gateway > MGC: Media Gateway Controller > SNMP: Simple Network Management Protocol > SDP: Session Description Protocol > > Levy, Anquetil Informational - Expires May 2001 1 > > Media Gateway Discovery November 2000 > > 4. Introduction > > Megaco/H.248 protocol [3] stands as a Media Gateway Control Protocol > between MGC and MG. Each MG owns a limited amount of resources > (hardware and software) potentially realizing media processing. As > an MGC may control a set of MGs, an efficient control requires a > precise knowledge (qualitatively and quantitatively) of the MG’s > resources. > > The draft firstly justifies why Megaco/H.248 is the candidate for a > media gateway resources discovery mechanism. It then compares > alternative mechanisms to solve this issue. > > 5. Justifications > > The RFC 2805 [4] describes requirements for the Megaco/H.248 > protocol. Section 6.1 deals with Resource Status Management. A > requirement of the protocol is to "Provide an MG Resource Discovery > mechanism which must allow an MGC to discover what resources the MG > has". > > A solution could rely on SNMP between MGC and MG to exchange > resources values with MGC acting as a manager and MG acting as an > agent. However, MGC requires a high availability protocol because of > its link with call processing. As SNMP doesn’t fulfill this needs, > Megaco/H.248 protocol must not require an MGC to implement an SNMP > manager function in order to discover capabilities of an MG. Thus, > resources discovery is not under the scope of SNMP. > > 6. Solution using ServiceChange command > > Megaco/H.248 protocol currently offers the ServiceChange command. > This command allows a MG to notify a MGC that a Termination, group > of Terminations or a whole MG has just been returned to service. The > ServiceChangeProfile parameter specifies what features of the > Megaco/H.248 protocol is implemented by the MG. > > This solution proposes to extend the meaning of the > ServiceChangeProfile parameter in order to express the media > functions supported by the MG. Thus, when it starts up, the MG > announces its media functions with a ServiceChangeProfile value > issued in a ServiceChange command. > > The main drawback of this solution is its lack of flexibility. > A profile value must reflect each potential set of media functions > possessed by a MG. > > Levy, Anquetil Informational - Expires May 2001 2 > > Media Gateway Discovery November 2000 > > Furthermore, the failure of an hardware resource in an MG may cause > the alteration of its media resources. This change should be > reflected by a new profile value. > > 7. Solution using AuditValue command. > > Megaco/H.248 protocol currently offers the AuditValue commands. The > command returns the current values of the properties, events, > signals and statistics associated with terminations. The knowledge > of terminations gives an external vision of the MG but it does not > inform how a context of the MG is able to associate the > terminations. The solution proposes to make use of the AuditValue > command to discover the internal media functions of the MG. > > 7.1 Atomic model > > The solution relies on an atomic model of the media functions to be > performed by the MG. It is based on the four logically separated > basic functions: > 1. Modify the transport without modifying the media encoding > (application part) (e.g. moving from PCMU/RTP to G711 mu-law/TDM). > 2. Modify the media encoding using the same transport (e.g. moving > from PCMU/RTP to GSM/RTP). > 3. Mix media streams using the same transport and the same media > encoding (e.g. mix three PCMA/RTP flows for conferencing purposes). > 4. Terminate (or initiate) a media stream (e.g. terminate PCMU/RTP > acting as an Interactive Voice Response unit). > > The functions may be : > . oneway or bothway for functions 1 and 2. > . send, receive or bothway for function 4. > > Any context realized by the MG should result in a combination of the > previous basic functions. For instance, a context associating a > termination with a stream G723 over RTP and a termination with a > PCMU over a TDM channel makes use of the transport modification and > the encoding modification functions. > > 7.2 Extension Description > > The extension introduces MediaResources and MediaFunctions > descriptors. General knowledge of the descriptors semantics provides > interoperability between MG and MGC. An MGC issues an AuditValue > command with a MediaResources Descriptor as parameter to an MG which > answers with its available media resources in the value of the > descriptor. > > 7.2.1 MediaFunctions Descriptor > > Levy, Anquetil Informational - Expires May 2001 3 > > Media Gateway Discovery November 2000 > > The Media Functions descriptor defines a set of identical functions > such as those detailed in section 7.1. The descriptor includes the > following properties: > > . FunctionID > . Type > . Cardinality > . Description > . Condition > . Direction > > The FunctionID identifies the MediaFunctions. > > The possible values for the Type property are: > Transportmodification, Encodingmodification, Mixstream and > Terminatestream. > > The Cardinality value defines the number of identical functions that > may be realized by the MG. > > The Description value describes the core of the function. The syntax > of this value is not completely defined in this version of the > draft. In general, the value shall be a string with the input value > followed by the output value (if any) separated by a "-" character. > The input and output value may be multiple: "|" character separates > alternative values, "*" character describes a factorization, "/" > describes an ordered succession. > For Transportmodification, the input and output values define the > transport protocol before and after the modification. "/" character > is used to separate multiple successive protocol layer. It begins > with the upper layer and terminates with the lower specified layer. > For Encodingmodification, the input and output values describe the > media format before and after the modification. For audio media, it > means the audio format. Eventual additional encoding parameters such > as the sampling rate may be added after a "/" character. > For Mixstream, the input and output values describe the media > encoding before and after the mixing. An integer value followed by > "*" character is used to express the maximum number of input streams > that may be mixed. > For Terminatestream, the input value describes the media encoding > getting in or out the MG. > > The Condition value defines the necessary conditions to realize the > function. For Transportmodification, it describes the media encoding > required for the modification. As for the other functions, it > describes the transport protocol required for the modification. The > Condition may have the ALL value. > > The Direction property can have the following values : Bothway, > Oneway, Send, Receive. > Bothway means that the transformation is bi-directional and > symmetrical. > > Levy, Anquetil Informational - Expires May 2001 4 > > Media Gateway Discovery November 2000 > > Oneway means that the modification only operates from input stream > to output stream. > Send and receive are only for Terminatestream type function. It > means that the function initiates (and respectively ends) the media > stream. > > It is noted that properties corresponding to other transformation > (such as echo cancellation) should be added to the descriptor > through packages. > > 7.2.2 MediaRessources Descriptor > > The Media Resources descriptor groups MediaFunctions which forms the > simultaneous media resources of an MG. > > 7.2.3 Audit Descriptor > > The Audit Descriptor specifies the list of descriptors to be > returned by the reply. In addition to possible items defined in [3], > MediaResources is provided in order to audit the media resources of > an MG. > > 7.3 Call Flow Example > > This example illustrates the uses of the presented mechanism to > discover the media resources of a Media Gateway. We assume that a > Media Gateway Controller (MGC1) controls a Media Gateway (MG1). The > registration of MG1 is not shown with these call flows but it is > supposed that it has been previously performed. > > 1. The MGC1 decides to audit the MG1 media resources. It issues an > AuditValue command to MG1 > From MGC1 to MG1: > MEGACO/1 MGC1 > Transaction = 10001 { > Context = Null { AuditValue = Root { > Audit{MediaResources } > } } > } > > 2. The MG1 replies. In this example, MG1 is able to handle 16 > simultaneous bi-directional transport modifications from RTP to TDM > with any media encoding AND to handle 8 simultaneous bi-directional > media encoding conversions from PCMU to G723 or GSM using RTP > transport. > From MG1 to MGC1: > MEGACO/1 MG1 > Reply = 10001 { > Context = Null { AuditValue = Root { > MediaResources { > > Levy, Anquetil Informational - Expires May 2001 5 > > Media Gateway Discovery November 2000 > > MediaFunctions = 1 { > Type = Transportmodification, > Cardinality = 16, > Description = RTP/UDP/IPv4 - TDM, > Condition = *, > Direction = Bothway > }, > MediaFunctions = 2 { > Type = Encodingmodification, > Cardinality = 8, > Description = PCMU-G723|GSM, > Condition = RTP, > Direction = Bothway > } > } > } } > } > > 7.4 Implementation considerations > > An audit of the available media resources of an MG should be > performed by the MGC, immediately after the MG has restarted. The > MGC detects the restart, because it receives a ServiceChange command > with ServiceChangeMethod corresponding to "Restart". After this > audit, the MGC is able to control the resources of the MG in order > to realize media connections. > > Under normal utilization, at any time, the MGC may ask the MG to > return its available media resources. However, due to > synchronization problems, some MG may fail in computing available > resources, while resources are being allocated. In case of failure, > the MG reports a "502-Not ready" error code. > > Therefore, it is highly recommended, that once knowing the initial > media resources of the MG, the MGC performs its own accountancy of > the available resources of the MG. Thus, the MGC does not need to > audit the available resources anymore, until the MG stops. > > 8. Conclusion > > Experiment demonstrates, that it is an error to oppose the 2 > previously described solutions. While the ServiceChangeProfile > allows to get the high level characteristics of a MG, the > MediaResources descriptor gives precise knowledge of its media > resources. Thus, authors are convinced of the interest of both > solutions. > > Furthermore, SDP-ng initiative [5] aims at developing a successor of > SDP [6] allowing to describe capabilities of a system. Therefore, > > Levy, Anquetil Informational - Expires May 2001 6 > > Media Gateway Discovery November 2000 > > future works would carry on integrating the MediaResources and > MediaDescription descriptor into SDP-ng. > > 9. Security Considerations > > Already covered by [3]. No specific extension needed for the > proposed solutions. > > 10. References > > 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP > 9, RFC 2026, October 1996. > > 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement > Levels", BCP 14, RFC 2119, March 1997. > > 3 ITU-T Recommendation H.248, "Gateway Control Protocol", Geneva, > June 2000. See also RFC 2885, August 2000. > > 4 Greene, Ramalho, Rosen, "Media Gateway Control Protocol > Architecture and Requirements", RFC 2805, April 1999. > > 5 Kutscher, Ott, Bormann, "Requirements for Session Description and > Capability Negotiation", draft-kutscher-mmusic-sdpng-req-00.txt, > July 2000. > > 6 Handley, Jacobson, "SDP: Session Description Protocol", RFC 2327, > April 1998. > > 11. Author's Addresses > > Thomas Levy > Alcatel > Route de Nozay > 91461 Marcoussis > France > Phone: + 33 (0)1 69 63 41 02 > Email: thomas.levy@ms.alcatel.fr > > Laurent-Philippe Anquetil > Alcatel > Route de Nozay > 91461 Marcoussis > France > Phone: + 33 (0)1 69 63 17 03 > Email: laurent.anquetil@ms.alcatel.fr > > Levy, Anquetil Informational - Expires May 2001 7 > > Media Gateway Discovery November 2000 > > Full Copyright Statement > > "Copyright (C) The Internet Society (date). All Rights Reserved. > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > or assist in its implmentation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this paragraph > are included on all such copies and derivative works. However, this > document itself may not be modified in any way, such as by removing > the copyright notice or references to the Internet Society or other > Internet organizations, except as needed for the purpose of > developing Internet standards in which case the procedures for > copyrights defined in the Internet Standards process must be > followed, or as required to translate it into > > Levy, Anquetil Informational - Expires May 2001 8 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 22 04:37:32 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09941 for ; Wed, 22 Nov 2000 04:37:31 -0500 (EST) Received: from standards (47.234.32.16:4013) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB926E@standards.nortelnetworks.com>; Wed, 22 Nov 2000 4:19:22 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 126150 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 22 Nov 2000 04:19:21 -0500 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB9263@standards.nortelnetworks.com>; Wed, 22 Nov 2000 4:09:21 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eAM9Q7217798; Wed, 22 Nov 2000 10:26:12 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id KAA16992; Wed, 22 Nov 2000 10:26:05 +0100 (MET) Received: from ericsson.com (arael26m12.ericsson.se [130.100.249.12]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id KAA20828; Wed, 22 Nov 2000 10:26:04 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A1B90C9.1C2EC843@ericsson.com> Date: Wed, 22 Nov 2000 20:24:25 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Uploaded H.248 documents X-To: SG16 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day all, I've uploaded the outputs of the Geneva SG16 meeting: H248_Annex_L.zip H248_Implementors_guide_approved.zip h248_annex_H_decided.zip h248_annex_i_decided.zip h248_annex_k_decided.zip H248_annex_n_draft.zip These are available as both as doc & pdf in the following directory: ftp://standard.pictel.com/avc-site/Incoming/ Cheers, Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 22 07:30:25 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01857 for ; Wed, 22 Nov 2000 07:30:25 -0500 (EST) Received: from standards (47.234.32.16:3114) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB93D3@standards.nortelnetworks.com>; Wed, 22 Nov 2000 7:11:48 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 126616 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 22 Nov 2000 07:11:48 -0500 Received: from mel.alcatel.fr (mail2.alcatel.fr) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB93D2@standards.nortelnetworks.com>; Wed, 22 Nov 2000 7:11:47 -0500 Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id NAA13559; Wed, 22 Nov 2000 13:28:14 +0100 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id NAA25933; Wed, 22 Nov 2000 13:25:12 +0100 (MET) Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id NAA14983; Wed, 22 Nov 2000 13:28:36 +0100 (MET) Received: from ms.alcatel.fr ([188.9.247.87]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id NAA24923; Wed, 22 Nov 2000 13:28:34 +0100 (MET) X-Mailer: Mozilla 4.71 [en] (WinNT; I) X-Accept-Language: en,fr MIME-Version: 1.0 References: <3A192CBE.2B5B24B1@ms.alcatel.fr> <3A1B8008.6727CED7@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A1BBC00.F56AB877@ms.alcatel.fr> Date: Wed, 22 Nov 2000 13:28:48 +0100 Reply-To: Thomas LEVY Sender: "Media Gateway Control (megaco)" From: Thomas LEVY Organization: Alcatel Subject: Re: draft-levy-megaco-mgdiscovery-01.txt, X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Christian, -Concerning the need for a MGC to know the internal capabilities of the MG: Let's consider this basic example: Imagine a MGC controlling 100 heterogeneous MGs. Only 1 MG is able to perform encoding modification from PCMU to GSM payload type upon ephemeral terminations. When the MGC will need to realize this media function, it should "allocate" a Megaco Context in the corresponding MG. If the MGC doesn't have the knowledge, it could potentially attempt (without success) to ADD Terminations in a new context for 99 MGs, before getting the right MG. What a waste!!! -Concerning the best way to get the available internal capabilities(Management:SNMP or High Availability:Megaco): In any the cases, the MGC needs to know the internal capabilities of a MG on start up. This could be done through Management interface. But, those available internal capabilities evolves due to : -normal consumption of resources -"on fly" configuration changes (faillure/recovery of an hardware/software resources) Thus, I am convinced that a high availability mechanism is needed for internal capabilities discovery. Thomas, Christian Groves wrote: > Hello Thomas, > > Finally have have had a chance to read the draft and have a think about > it. > > I have a fundamental question to this draft. Does the MGC really need > such indepth knowledge of the internal capabilities of the MG? Megaco I > believe was intended to be agonostic with regards to the internals of an > MG. I'm also not sure that a mechanism to discover this needs to be > highly available. Once the internals of a MG have been found they don't > typically change configuration frequently. Thus I feel a SNMP interface > would be appropriate as its something not happening all the time, only > during maintenance procedures. > > Cheers, Christian > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 22 08:25:03 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13283 for ; Wed, 22 Nov 2000 08:25:02 -0500 (EST) Received: from standards (47.234.32.16:3114) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB941C@standards.nortelnetworks.com>; Wed, 22 Nov 2000 8:06:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 126678 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 22 Nov 2000 08:06:38 -0500 Received: from relay2.alcatel.be (alc239.alcatel.be) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB9400@standards.nortelnetworks.com>; Wed, 22 Nov 2000 7:56:38 -0500 Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay2.alcatel.be (8.10.1/8.10.1) with SMTP id eAMDAn102203 for ; Wed, 22 Nov 2000 14:10:50 +0100 (MET) Received: from alcatel.be ([138.203.67.37]) by bemail04.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C125699F.0048A201; Wed, 22 Nov 2000 14:13:20 +0100 X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A1BC61D.3E125835@alcatel.be> Date: Wed, 22 Nov 2000 14:11:57 +0100 Reply-To: Bouwen Jan Sender: "Media Gateway Control (megaco)" From: Bouwen Jan Subject: Megaco & ISDN drafts To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit All, I submitted three internet drafts related to the support of ISDN Access Gateways in Megaco. You'll find the announcements below. The three drafts are an update of the earlier draft on the same subject (draft-bouwen-megaco-isdn-01.txt). Main difference is that the old draft contained a lot of options, while in the current proposals only one solution for every issue is described. And there is of the course the fact that I split the old draft into three new ones, each with a more clearly defined scope. A short overview: * draft-bouwen-megaco-isdn-package-00.txt This one defines a Megaco package for ISDN terminations (some properties and events/signals for layer 1 activation) * draft-bouwen-megaco-isdn-bcp-00.txt Best Current Practice for ISDN access gateways. Proposes guidelines for interaction between Megaco and Sigtran in ISDN access gateways. * draft-bouwen-megaco-isdn-data-00.txt Proposes extensions for Megaco (to be included in Megaco v2) to support non-Q.931 data in the D-channel (ephemeral terminations on top of the D-channel, and ISDN DLCI addressing scheme in SDP). Jan A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ISDN Package for Megaco Author(s) : J. Bouwen Filename : draft-bouwen-megaco-isdn-pack-00.txt Pages : 5 Date : 20-Nov-00 This draft introduces a Megaco package to support voip access gateways with ISDN terminations. The package defines TerminationState properties for ISDN terminations, and events/signals that are to be used for the layer 1 activation/deactivation procedure for ISDN basic interfaces. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bouwen-megaco-isdn-pack-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Best Current Practice for Megaco-Sigtran Interaction in ISDN Access Gateways Author(s) : J. Bouwen Filename : draft-bouwen-megaco-isdn-bcp-00.txt Pages : 10 Date : 20-Nov-00 A Media Gateway with ISDN terminations will use both Megaco [1] and Sigtran protocols for communication with the Media Gateway Controller. In an ISDN Access Gateway the media carrying B-channels are controlled by the Media Gateway Controller using Megaco, while the User-to-Network signalling running over the D-channels will be relayed to the Media Gateway Controller using Sigtran protocols (IUA [3] over SCTP [2]). At the moment, in the absence of appropriate specifications, the Megaco and Sigtran protocols may interact in different ways in the Access Gateway, leaving room for non-interoperable solutions. This draft proposes a set of guidelines for the Megaco-Sigtran interworking, documenting a best current practice for ISDN Access Gateways. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bouwen-megaco-isdn-bcp-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions to Megaco to support Data in an ISDN D-channel Author(s) : J. Bouwen Filename : draft-bouwen-megaco-isdn-data-00.txt Pages : Date : 20-Nov-00 In ISDN interfaces the D-channel is used to transport the Q.931 signalling messages. In addition, the D-channel can transport packet data for user-to-user communication. The Megaco protocol specification has to be extended to support data in an ISDN D- channel. More specifically, ephemeral terminations on top of physical ISDN terminations have to be allowed, and support for the ISDN addressing scheme has to be added to refer to the data streams in the D-channel. This draft defines the required additional functionality, that could be part of the second version of the Megaco protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bouwen-megaco-isdn-data-00.txt From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 22 08:36:34 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15647 for ; Wed, 22 Nov 2000 08:36:34 -0500 (EST) Received: from standards (47.234.32.16:3114) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB9465@standards.nortelnetworks.com>; Wed, 22 Nov 2000 8:18:02 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 126813 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 22 Nov 2000 08:18:01 -0500 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB9464@standards.nortelnetworks.com>; Wed, 22 Nov 2000 8:18:01 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA12364; Wed, 22 Nov 2000 08:34:55 -0500 (EST) Received: from stl-server-01.pit.comms.marconi.com (stl-server-01.pit.comms.marconi.com [169.144.36.27]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA07034; Wed, 22 Nov 2000 08:34:56 -0500 (EST) Received: by stl-server-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 08:34:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6EA49@whq-msgusr-02.pit.comms.marconi.com> Date: Wed, 22 Nov 2000 08:34:50 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: ServiceChangeMethod = failover X-To: Terry L Anderson To: MEGACO@STANDARDS.NORTELNETWORKS.COM > The use of ServiceChangeMethod = failover is not clear in H.248. The > definition says that it is "sent from the MG to MGC to indicate the > primary MG is out of service and a secondary MG is taking over." > > 1) If the primary is "out of service" presumably the message > is sent by > the "secondary", but how does the message indicate what > primary MG it is > taking over for? or must the secondary use the same > IPAddr/port as the > primary? The intention is that it is an handover, and the message comes from the primary > 2) what properties of the primary does the MGC assume are > shared by the > secondary? Should the MGC assume that calls that were in progress are > continued by the "secondary" MG or should it audit the MG? It should assume that the state remains the same, and no audit is necessary > > I am interested in a case where the H.248 signaling part of an MG has > failed, say a NIC, but it has a second NIC and can continue all calls, > but must receive future transactions from the MGC on this new address. > Should it send ServiceChange with ServiceChangeMethod = failover from > the new NIC (new ipaddr/port)? Or is failover intended for something > different? We don't cover this case, because the message formats all assume the header has the "from" = old and the ServiceChangeAddress has the new. I think we SHOULD cover this case, but it's a change to the protocol. Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 22 08:43:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17185 for ; Wed, 22 Nov 2000 08:43:10 -0500 (EST) Received: from standards (47.234.32.16:3114) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB948B@standards.nortelnetworks.com>; Wed, 22 Nov 2000 8:24:41 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 126865 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 22 Nov 2000 08:24:40 -0500 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB948A@standards.nortelnetworks.com>; Wed, 22 Nov 2000 8:24:40 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA12893; Wed, 22 Nov 2000 08:41:33 -0500 (EST) Received: from stl-server-01.pit.comms.marconi.com (stl-server-01.pit.comms.marconi.com [169.144.36.27]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA08495; Wed, 22 Nov 2000 08:41:33 -0500 (EST) Received: by stl-server-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 08:41:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6EA4A@whq-msgusr-02.pit.comms.marconi.com> Date: Wed, 22 Nov 2000 08:41:31 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Definiation of Name in ASN.1 and ABNF X-To: ??? To: MEGACO@STANDARDS.NORTELNETWORKS.COM You don't. A binary name is a number (although you could have "structure" to the bit pattern). A text name is a string-like ASCII name. You don't ever translate one to the other. The syntax of DigitMap in ASN.1 is: DigitMapDescriptor ::= SEQUENCE { digitMapName DigitMapName OPTIONAL, digitMapValue DigitMapValue OPTIONAL } DigitMapName ::= Name DigitMapValue ::= SEQUENCE { startTimer INTEGER(0..99) OPTIONAL, shortTimer INTEGER(0..99) OPTIONAL, longTimer INTEGER(0..99) OPTIONAL, digitMapBody IA5String, -- See Section A.3 for explanation of digit map syntax ... } So you don't have to put a text name in the digitMapBody Brian > -----Original Message----- > From: ??? [mailto:yjliao@itri.org.tw] > Sent: Tuesday, November 21, 2000 10:34 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Definiation of Name in ASN.1 and ABNF > > > In ABNF > NAME = ALPHA * 63(ALPHA/ DIGIT/ "_") > > In ASN.1 > Name ::= OCTET STRING(SIZE(2)) > > How can I translate a 64 bytes text string to a 2 bytes octets? > > In my case, I have a digitmap name in text mode like : > DigitMap = Dialplan0{ ....} > How can I encode the text "Dialplan0" to ASN ? > > Thanks > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 22 09:48:45 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01905 for ; Wed, 22 Nov 2000 09:48:44 -0500 (EST) Received: from standards (47.234.32.16:3114) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB9578@standards.nortelnetworks.com>; Wed, 22 Nov 2000 9:29:58 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 127186 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 22 Nov 2000 09:29:58 -0500 Received: from hindon.hss.co.in (202.54.26.202:46530) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB9577@standards.nortelnetworks.com>; Wed, 22 Nov 2000 9:29:56 -0500 Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id eAMEmIs05536 for ; Wed, 22 Nov 2000 20:18:18 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525699F.0050268F ; Wed, 22 Nov 2000 20:05:27 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525699F.00502249.00@sandesh.hss.hns.com> Date: Wed, 22 Nov 2000 20:10:44 +0530 Reply-To: samittal@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sachin Mittal Subject: Property values due to new descriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM In section 6.2.4 "..........Properties not mentioned in the command retain their prior values. Similarly, a property of a Termination in a Context may have its value changed by the Modify command. Properties not mentioned in the Modify command retain their prior values............." But in section 7.1.7 "..................A new setting of the LocalControl Descriptor completely replaces the previous setting of that descriptor in the MG." Is it that the intension is to replace items other than properties ? From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 22 12:36:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03726 for ; Wed, 22 Nov 2000 12:36:42 -0500 (EST) Received: from standards (47.234.32.16:2111) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB971F@standards.nortelnetworks.com>; Wed, 22 Nov 2000 12:18:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 127724 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 22 Nov 2000 12:18:03 -0500 Received: from zrchh190 (47.158.65.22:36841) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB9716@standards.nortelnetworks.com>; Wed, 22 Nov 2000 12:08:03 -0500 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by zrchh190; Wed, 22 Nov 2000 11:25:58 -0600 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Wed, 22 Nov 2000 10:29:48 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 22 Nov 2000 10:29:47 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD1102DE6813@zcard00g.ca.nortel.com> Date: Wed, 22 Nov 2000 10:29:36 -0500 Reply-To: "Taylor, Tom-PT [NORSE:B901:EXCH]" Sender: "Media Gateway Control (megaco)" From: "Taylor, Tom-PT [NORSE:B901:EXCH]" Subject: Re: ServiceChangeMethod = failover X-To: Terry L Anderson To: MEGACO@STANDARDS.NORTELNETWORKS.COM You have managed to place yourself into a debate some of my colleagues have been having on the list, regarding the Megaco/H.248 control session management model. The intent of the failover method is that it be issued by the failing party BEFORE cessation of communications, to indicate that a new control session has to be established to replace the old one. It is then up to the MG to initiate this new session. The case you describe, involving failure of a NIC, would most simply be solved by allowing the MGC to indicate that it is still available, but with a new address. This is not allowed in the current Megaco model. Instead, it is up to the MG to detect the communications failure and find the alternate address, either through provisioning or through other means such as DNS. This situation actually seems made to order for the use of SCTP, as permitted by the newly approved H.248 Annex H. > -----Original Message----- > From: Terry L Anderson [mailto:tla@LUCENT.COM] > Sent: Tuesday, November 21, 2000 4:59 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: ServiceChangeMethod = failover > > > The use of ServiceChangeMethod = failover is not clear in H.248. The > definition says that it is "sent from the MG to MGC to indicate the > primary MG is out of service and a secondary MG is taking over." > > 1) If the primary is "out of service" presumably the message > is sent by > the "secondary", but how does the message indicate what > primary MG it is > taking over for? or must the secondary use the same > IPAddr/port as the > primary? > > 2) what properties of the primary does the MGC assume are > shared by the > secondary? Should the MGC assume that calls that were in progress are > continued by the "secondary" MG or should it audit the MG? > > I am interested in a case where the H.248 signaling part of an MG has > failed, say a NIC, but it has a second NIC and can continue all calls, > but must receive future transactions from the MGC on this new address. > Should it send ServiceChange with ServiceChangeMethod = failover from > the new NIC (new ipaddr/port)? Or is failover intended for something > different? > > -- > ------------------------------------------------------------ > Terry L Anderson mailto:tla@lucent.com > Tel:908.582.7013 Fax:908.582.6729 > Pager:800.759.8352 pin 1704572 1704572@skytel.com > Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 22 14:59:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17804 for ; Wed, 22 Nov 2000 14:59:06 -0500 (EST) Received: from standards (47.234.32.16:3244) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB981C@standards.nortelnetworks.com>; Wed, 22 Nov 2000 14:40:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 128062 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 22 Nov 2000 14:40:34 -0500 Received: from auemail2.firewall.lucent.com (auemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB981B@standards.nortelnetworks.com>; Wed, 22 Nov 2000 14:40:34 -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 OAA01154 for ; Wed, 22 Nov 2000 14:57:30 -0500 (EST) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA01146 for ; Wed, 22 Nov 2000 14:57:30 -0500 (EST) Received: from lucent.com (pctla2 [135.3.130.26]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id OAA06745 for ; Wed, 22 Nov 2000 14:55:55 -0500 (EST) X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD1102DE6813@zcard00g.ca.nortel.com> Content-Type: multipart/mixed; boundary="------------F51C38B5D4751BC9D6F5ADE7" Message-ID: <3A1C2500.359DA45A@lucent.com> Date: Wed, 22 Nov 2000 14:56:48 -0500 Reply-To: Terry L Anderson Sender: "Media Gateway Control (megaco)" From: Terry L Anderson Organization: Lucent Technologies Subject: Re: ServiceChangeMethod = failover To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------F51C38B5D4751BC9D6F5ADE7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks Tom and Brian I now see that "failover" is similar to "handoff" but initiated from the MG end. I guess I find the name confusing in that this procedure seems more gentle than a "failure" - "handoff" is better but used for the MGC initiated case. If the MG can anticipate its need to "fail" this works but I think of "failover" as recovery from an unanticipated failure. But I now understand the intent. Perhaps this should be clarified/explained in the Implementors Guide. And I agree with Tom that SCTP could handle this without any support from H.248, but it could also handle the "failover" and "handoff" cases. Not all of use may be able to use STCP immediately. I would still like to see mechanisms to handle unanticipated failures of either MGC or MG, although I realize that allowing a message from an entity that it is taking over for some other entity can have security concerns. "Taylor, Tom-PT [NORSE:B901:EXCH]" wrote: > You have managed to place yourself into a debate some of my colleagues have > been having on the list, regarding the Megaco/H.248 control session > management model. The intent of the failover method is that it be issued by > the failing party BEFORE cessation of communications, to indicate that a new > control session has to be established to replace the old one. It is then up > to the MG to initiate this new session. > > The case you describe, involving failure of a NIC, would most simply be > solved by allowing the MGC to indicate that it is still available, but with > a new address. This is not allowed in the current Megaco model. Instead, > it is up to the MG to detect the communications failure and find the > alternate address, either through provisioning or through other means such > as DNS. > > This situation actually seems made to order for the use of SCTP, as > permitted by the newly approved H.248 Annex H. > > > -----Original Message----- > > From: Terry L Anderson [mailto:tla@LUCENT.COM] > > Sent: Tuesday, November 21, 2000 4:59 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: ServiceChangeMethod = failover > > > > > > The use of ServiceChangeMethod = failover is not clear in H.248. The > > definition says that it is "sent from the MG to MGC to indicate the > > primary MG is out of service and a secondary MG is taking over." > > > > 1) If the primary is "out of service" presumably the message > > is sent by > > the "secondary", but how does the message indicate what > > primary MG it is > > taking over for? or must the secondary use the same > > IPAddr/port as the > > primary? > > > > 2) what properties of the primary does the MGC assume are > > shared by the > > secondary? Should the MGC assume that calls that were in progress are > > continued by the "secondary" MG or should it audit the MG? > > > > I am interested in a case where the H.248 signaling part of an MG has > > failed, say a NIC, but it has a second NIC and can continue all calls, > > but must receive future transactions from the MGC on this new address. > > Should it send ServiceChange with ServiceChangeMethod = failover from > > the new NIC (new ipaddr/port)? Or is failover intended for something > > different? > > > > -- > > ------------------------------------------------------------ > > Terry L Anderson mailto:tla@lucent.com > > Tel:908.582.7013 Fax:908.582.6729 > > Pager:800.759.8352 pin 1704572 1704572@skytel.com > > Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > > > -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572@skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------F51C38B5D4751BC9D6F5ADE7 Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;pager:800.759.8352 pin 1704572 tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks / Applications Group version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;Rm 2B-121=0D=0A600 Mountain Ave;Murray Hill;NJ;07974;USA x-mozilla-cpt:;20896 fn:Terry L Anderson end:vcard --------------F51C38B5D4751BC9D6F5ADE7-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 22 15:59:09 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05757 for ; Wed, 22 Nov 2000 15:59:09 -0500 (EST) Received: from standards (47.234.32.16:1247) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB9867@standards.nortelnetworks.com>; Wed, 22 Nov 2000 15:40:40 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 128149 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 22 Nov 2000 15:40:40 -0500 Received: from zrchh190 (47.158.65.22:55373) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB985C@standards.nortelnetworks.com>; Wed, 22 Nov 2000 15:30:35 -0500 Received: from smtprch1.nortel.com (actually erchg0j) by zrchh190; Wed, 22 Nov 2000 14:48:03 -0600 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Wed, 22 Nov 2000 09:40:26 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 22 Nov 2000 09:37:00 -0600 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD1102DE6843@zcard00g.ca.nortel.com> Date: Wed, 22 Nov 2000 09:36:50 -0600 Reply-To: "Taylor, Tom-PT [NORSE:B901:EXCH]" Sender: "Media Gateway Control (megaco)" From: "Taylor, Tom-PT [NORSE:B901:EXCH]" Subject: Re: I-D ACTION:draft-ietf-megaco-mib-01.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM The Internet-Drafts search engine pulled it up this morning. > -----Original Message----- > From: Matt Holdrege [mailto:matt@IPVERSE.COM] > Sent: Tuesday, November 21, 2000 6:32 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: I-D ACTION:draft-ietf-megaco-mib-01.txt > > > It works for me. Try again or go to a different ISP perhaps. > > > At 04:32 PM 11/21/2000 -0500, Peter Blatherwick wrote: > > >Hi Matt, > > > >I'd definitely like to have a look, but am unable to retrieve the > >I-D. Link below comes back with "no longer available .. > deleted on July > >17, 2000" (and same URL with 02 on the end also fails Not > Found). Any > >idea what's up with that? Is there another place to access? > > > >-- Peter Blatherwick > > > > > >-----Original Message----- > >From: Matt Holdrege > [mailto:matt@IPVERSE.COM] > >Sent: Tuesday, November 21, 2000 07:18 > >To: MEGACO@STANDARDS.NORTELNETWORKS.COM > >Subject: Re: I-D ACTION:draft-ietf-megaco-mib-01.txt > > > >Regarding this document...As many of you know I've been > begging for input > >for a long time, but I've realized that we wouldn't get good > input til > >people started implementing the protocol. Now that that has > happened, I'm > >flooded with input. So unfortunately this draft isn't very > well organized. > >Even as I finalized this draft, a bunch more objects were > suggested to me. > > > >So please review the objects in this draft and comment. Regardless of > >further input, I have a lot of work to do to organize this > MIB better. > > > >At 05:57 AM 11/21/2000 -0500, Internet-Drafts@IETF.ORG wrote: > > >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 MIB > > > Author(s) : M. Holdrege, I. Akramovich > > > Filename : draft-ietf-megaco-mib-01.txt > > > Pages : 35 > > > Date : 20-Nov-00 > > > > > >This memo defines a portion of the Management Information > Base (MIB) > > >for use with network management protocols in the Internet > community. > > >In particular it defines objects for use by the MEGACO protocol > > >operating on Media Gateways and Media Gateway Controllers. > > > > > >A URL for this Internet-Draft is: > > >http:// > www.ietf.org/internet-drafts/draft-ietf-megaco-mib-01.txt > > > >Internet-Drafts are also available by anonymous FTP. Login with the > username > >"anonymous" and a password of your e-mail address. After logging in, > >type "cd internet-drafts" and then > > "get draft-ietf-megaco-mib-01.txt". > > > >A list of Internet-Drafts directories can be found in > >http://www.ietf.org/shadow.html > >or > ftp://ftp.ietf.org/ietf/1shadow-s ites.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-mib-01.txt". > > > >NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail > readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > >Below is the data which will enable a MIME compliant mail reader > >implementation to automatically retrieve the ASCII version of the > >Internet-Draft. > >Content-Type: text/plain > >Content-ID: <20001120151500.I-D@ietf.org> > > > >ENCODING mime > >FILE /internet-drafts/draft-ietf-megaco-mib-01.txt > > > ><ftp://f > tp.ietf.org/internet-drafts/draft-ietf-megaco-mib-01.txt> From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 22 19:41:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05402 for ; Wed, 22 Nov 2000 19:41:46 -0500 (EST) Received: from standards (47.234.32.16:2287) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB998C@standards.nortelnetworks.com>; Wed, 22 Nov 2000 19:23:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 128564 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 22 Nov 2000 19:23:21 -0500 Received: from ganymede.or.intel.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB998B@standards.nortelnetworks.com>; Wed, 22 Nov 2000 19:23:21 -0500 Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id QAA12941 for ; Wed, 22 Nov 2000 16:40:18 -0800 (PST) Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 23 Nov 2000 00:40:17 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 16:40:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 22 Nov 2000 16:40:15 -0800 Reply-To: "Tulpule, Naren" Sender: "Media Gateway Control (megaco)" From: "Tulpule, Naren" Subject: Implementation guide issues To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, I have a couple of questions about the implementation guide. Any clarification is appreciated. 1. In 6.46 allowing pkgdName syntax for modem properties. What package names are we expecting here? If they are one of annex E packages or other publicly available packages such as NAS shouldn't the package definitions include "property parameters for modems" section? What syntactic/semantic convenience does it offer to have pkgdName instead of a plain NAME here? 2. In 7.3 the last example shows a wildcard response for Audit. Presumably this also applies to Subtract reply. But the current ABNF does not show that "commandReplys" maybe preceded by "W-". (Or do you want to split ammsReply into ammReply and subReply, and allow W- only for subReply and auditReply?) -- Naren. These views and opinions are mine alone, not those of Intel (yet ;-) Narendra C. Tulpule SMTS, Trillium (an Intel company) Ph: +1-310-442-9222 Fax: +1-310-442-1162 12100 Wilshire Bl #1800 Los Angeles, CA 90025 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 23 04:59:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11184 for ; Thu, 23 Nov 2000 04:59:39 -0500 (EST) Received: from standards (47.234.32.16:2039) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB9AF2@standards.nortelnetworks.com>; Thu, 23 Nov 2000 4:39:40 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 128994 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 23 Nov 2000 04:39:40 -0500 Received: from gorilla.mchh.siemens.de by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB9AD7@standards.nortelnetworks.com>; Thu, 23 Nov 2000 4:29:40 -0500 Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA23284 for ; Thu, 23 Nov 2000 10:46:09 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA21594 for ; Thu, 23 Nov 2000 10:46:37 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Nov 2000 10:46:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <115FD6FDE682D311A9500008C791E2698D2814@MCHH262E> Date: Thu, 23 Nov 2000 10:46:28 +0100 Reply-To: Pauls Markus Sender: "Media Gateway Control (megaco)" From: Pauls Markus Subject: H.248 - Annexes H & I To: MEGACO@STANDARDS.NORTELNETWORKS.COM G'day List Members, I'm relatively new to MEGACO/H.248. Over the last couple of weeks I tried to get some basic understandings about the protocol. I also followed the extensive discussions on this list with great interest. I think, now the time has come that I would like to ask some questions too. To start with: In the newly approved Annexes H & I, when a reliable transport protocol is used (e.g. SCTP and MTP3B), it is recommended to provide the At-Most-Once functionality as in Annex D, but the LONG-TIMER and the TransactionResponseAck parameter shall not be used. Looking at Annex D, it is stated that, for the purpose of the At-Most-Once functionality, the "Peer control entities are expected to keep in memory a list of the responses that they sent to recent transactions ....". Furthermore, it is stated that "the copy of the responses may be destroyed either LONG-TIMER seconds after the response is issued, or when the entity receives a confirmation that the response has been received, through the 'Response Acknowledgement parameter' [which seems to be the TransactionResponseAck parameter]". My questions now: * When are the copies of the responses deleted, when there is no timer and no Response Acknowledgment parameter? * Or is there no list? But how to provide the At-Most-Once functionality then? I hope someone can clarify these issues. Best regards and many thanks for your answers in advance Markus Pauls ________________________________________________________ Markus Pauls SIEMENS Information and Communication Networks ICN WN CC EK B13 Tel.: +49 89 722 62937 Hofmannstr. 51 Fax: +49 89 722 44176 81359 Munich Email: markus.pauls@icn.siemens.de Germany From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 23 11:26:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12363 for ; Thu, 23 Nov 2000 11:26:40 -0500 (EST) Received: from standards (47.234.32.16:4304) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB9CE7@standards.nortelnetworks.com>; Thu, 23 Nov 2000 11:07:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 129660 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 23 Nov 2000 11:07:54 -0500 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB9CE3@standards.nortelnetworks.com>; Thu, 23 Nov 2000 10:57:54 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eANGEp228703; Thu, 23 Nov 2000 17:14:51 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id RAA21116; Thu, 23 Nov 2000 17:14:50 +0100 (MET) Received: from ericsson.com ([130.100.249.232]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id RAA26102; Thu, 23 Nov 2000 17:14:47 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A1D2C79.E6C986BA@ericsson.com> Date: Fri, 24 Nov 2000 01:40:57 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Implementation guide issues X-To: "Tulpule, Naren" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day, Please see my response [CHG] below. Cheers, Christian "Tulpule, Naren" wrote: > > Hi, > I have a couple of questions about the implementation guide. Any > clarification is appreciated. > 1. In 6.46 allowing pkgdName syntax for modem properties. What package names > are we expecting here? If they are one of annex E packages or other publicly > available packages such as NAS shouldn't the package definitions include > "property parameters for modems" section? What syntactic/semantic > convenience does it offer to have pkgdName instead of a plain NAME here? [CHG] This correction aligned the ABNF and the ASN1. Packages could define property parameters for modems. There's nothing stopping them. The convenience is that the NAME is qualified by a package ID making it unique. If you didn't have this you run into name space problems. > 2. In 7.3 the last example shows a wildcard response for Audit. Presumably > this also applies to Subtract reply. But the current ABNF does not show that > "commandReplys" maybe preceded by "W-". (Or do you want to split ammsReply > into ammReply and subReply, and allow W- only for subReply and auditReply?) [CHG] There is a correction in the implementors' guide which fixes this inconsistency between the ASN1 and the ABNF. > > -- Naren. > These views and opinions are mine alone, not those of Intel (yet ;-) > Narendra C. Tulpule SMTS, Trillium (an Intel company) > Ph: +1-310-442-9222 Fax: +1-310-442-1162 > 12100 Wilshire Bl #1800 Los Angeles, CA 90025 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 23 11:26:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12378 for ; Thu, 23 Nov 2000 11:26:41 -0500 (EST) Received: from standards (47.234.32.16:4304) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB9CEB@standards.nortelnetworks.com>; Thu, 23 Nov 2000 11:07:59 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 129661 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 23 Nov 2000 11:07:59 -0500 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB9CE4@standards.nortelnetworks.com>; Thu, 23 Nov 2000 10:57:58 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eANGEu228743; Thu, 23 Nov 2000 17:14:56 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id RAA21120; Thu, 23 Nov 2000 17:14:56 +0100 (MET) Received: from ericsson.com ([130.100.249.232]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id RAA26109; Thu, 23 Nov 2000 17:14:52 +0100 (MET) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <3A192CBE.2B5B24B1@ms.alcatel.fr> <3A1B8008.6727CED7@ericsson.com> <3A1BBC00.F56AB877@ms.alcatel.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A1D2DE3.20B94C0E@ericsson.com> Date: Fri, 24 Nov 2000 01:46:59 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: draft-levy-megaco-mgdiscovery-01.txt, X-To: Thomas LEVY To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Tomas, Please see my answers below marked [CHG] Cheers, Christian Thomas LEVY wrote: > > Hello Christian, > > -Concerning the need for a MGC to know the internal capabilities of the MG: > Let's consider this basic example: > Imagine a MGC controlling 100 heterogeneous MGs. Only 1 MG is able to perform > encoding modification from PCMU to GSM payload type upon ephemeral terminations. > When the MGC will need to realize this media function, it should "allocate" a > Megaco Context in the corresponding MG. > If the MGC doesn't have the knowledge, it could potentially attempt (without > success) to ADD Terminations in a new context for 99 MGs, before getting the > right MG. > What a waste!!! [CHG] Seems to me that the MGC would audit these MGs at start up to get a picture of what they do. If 99 MGs say PCMU only and the 100th it comes back and gives GSM, PCMU that you choose that one. > > -Concerning the best way to get the available internal > capabilities(Management:SNMP or High Availability:Megaco): > In any the cases, the MGC needs to know the internal capabilities of a MG on > start up. This could be done through Management interface. > But, those available internal capabilities evolves due to : > -normal consumption of resources > -"on fly" configuration changes (faillure/recovery of an hardware/software > resources) > Thus, I am convinced that a high availability mechanism is needed for internal > capabilities discovery. [CHG] Normal consumption of resources should be handled by some sort of congestion indication mechanism. It should be up to the MG to monitor its own resources. The MGC shouldn't have to worry about resource allocation in the MG as the MG might have its own schema. The new H248AnnexN proposes a load control mechanism. With regards to "on fly" configuration changes this is why we have ServiceChange "Capability Change" see annex L. It indicates when something has changed. The MGC can then audit to see the change. > > Thomas, > > Christian Groves wrote: > > > Hello Thomas, > > > > Finally have have had a chance to read the draft and have a think about > > it. > > > > I have a fundamental question to this draft. Does the MGC really need > > such indepth knowledge of the internal capabilities of the MG? Megaco I > > believe was intended to be agonostic with regards to the internals of an > > MG. I'm also not sure that a mechanism to discover this needs to be > > highly available. Once the internals of a MG have been found they don't > > typically change configuration frequently. Thus I feel a SNMP interface > > would be appropriate as its something not happening all the time, only > > during maintenance procedures. > > > > Cheers, Christian > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 23 16:40:56 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09505 for ; Thu, 23 Nov 2000 16:40:55 -0500 (EST) Received: from standards (47.234.32.16:4942) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB9D7B@standards.nortelnetworks.com>; Thu, 23 Nov 2000 16:22:25 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 129860 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 23 Nov 2000 16:22:24 -0500 Received: from ish7.ericsson.com.au (203.61.155.111:50038) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB9D7A@standards.nortelnetworks.com>; Thu, 23 Nov 2000 16:12:23 -0500 Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id IAA20584; Fri, 24 Nov 2000 08:26:10 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id IAA12857; Fri, 24 Nov 2000 08:29:01 +1100 (EST) Received: from ericsson.com.au (7-119.epa.ericsson.se [146.11.7.119]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WRBDYS0P; Fri, 24 Nov 2000 08:29:16 +1100 X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <3A192CBE.2B5B24B1@ms.alcatel.fr> <3A1B8008.6727CED7@ericsson.com> <3A1BBC00.F56AB877@ms.alcatel.fr> Content-Type: multipart/mixed; boundary="------------706FE304F3FA07044C6D5594" Message-ID: <3A1D8C17.3A17888E@ericsson.com.au> Date: Fri, 24 Nov 2000 08:28:55 +1100 Reply-To: Paul Hollis Sender: "Media Gateway Control (megaco)" From: Paul Hollis Organization: Ericsson Australia Subject: Re: draft-levy-megaco-mgdiscovery-01.txt, X-To: Thomas LEVY To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------706FE304F3FA07044C6D5594 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Thomas/Christian, I thought that if a MG supports terminations for PCMU and terminations for GSM then it should also support the encoding/decoding between them. If there are only limited resources to do such encoding/decoding, then this would have to be found out via rejection of commands with error codes. Otherwise I guess you would have to audit every time before trying to use a MG to check its got enough resources or the MG could send the ServiceChange or an event when all of a particular resource is used. You would then need a ServiceChange or event to tell when the resource is available again. Sounds pretty much like congestion control, which I guess is on the agenda for the new work anyway. Regards Paul. Thomas LEVY wrote: > Hello Christian, > > -Concerning the need for a MGC to know the internal capabilities of the MG: > Let's consider this basic example: > Imagine a MGC controlling 100 heterogeneous MGs. Only 1 MG is able to perform > encoding modification from PCMU to GSM payload type upon ephemeral terminations. > When the MGC will need to realize this media function, it should "allocate" a > Megaco Context in the corresponding MG. > If the MGC doesn't have the knowledge, it could potentially attempt (without > success) to ADD Terminations in a new context for 99 MGs, before getting the > right MG. > What a waste!!! > > -Concerning the best way to get the available internal > capabilities(Management:SNMP or High Availability:Megaco): > In any the cases, the MGC needs to know the internal capabilities of a MG on > start up. This could be done through Management interface. > But, those available internal capabilities evolves due to : > -normal consumption of resources > -"on fly" configuration changes (faillure/recovery of an hardware/software > resources) > Thus, I am convinced that a high availability mechanism is needed for internal > capabilities discovery. > > Thomas, > > Christian Groves wrote: > > > Hello Thomas, > > > > Finally have have had a chance to read the draft and have a think about > > it. > > > > I have a fundamental question to this draft. Does the MGC really need > > such indepth knowledge of the internal capabilities of the MG? Megaco I > > believe was intended to be agonostic with regards to the internals of an > > MG. I'm also not sure that a mechanism to discover this needs to be > > highly available. Once the internals of a MG have been found they don't > > typically change configuration frequently. Thus I feel a SNMP interface > > would be appropriate as its something not happening all the time, only > > during maintenance procedures. > > > > Cheers, Christian > > --------------706FE304F3FA07044C6D5594 Content-Type: text/x-vcard; charset=us-ascii; name="paul.hollis.vcf" Content-Description: Card for Paul Hollis Content-Disposition: attachment; filename="paul.hollis.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Hollis;Paul tel;fax:9301 1139 tel;work:9301 6831 x-mozilla-html:FALSE org:Ericsson Australia. adr:;;;Melbourne;Victoria;;Australia version:2.1 email;internet:Paul.Hollis@ericsson.com.au title:Software Designer (Signalling) x-mozilla-cpt:;-25040 fn:Paul Hollis end:vcard --------------706FE304F3FA07044C6D5594-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 24 07:21:56 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16748 for ; Fri, 24 Nov 2000 07:21:55 -0500 (EST) Received: from standards (47.234.32.16:3936) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB9FEC@standards.nortelnetworks.com>; Fri, 24 Nov 2000 7:03:02 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 130637 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 24 Nov 2000 07:03:01 -0500 Received: from mel.alcatel.fr (mail2.alcatel.fr) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBB9FEB@standards.nortelnetworks.com>; Fri, 24 Nov 2000 7:03:00 -0500 Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id NAA03814; Fri, 24 Nov 2000 13:19:12 +0100 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id NAA20631; Fri, 24 Nov 2000 13:16:25 +0100 (MET) Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id NAA15495; Fri, 24 Nov 2000 13:19:51 +0100 (MET) Received: from ms.alcatel.fr ([188.9.247.87]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id NAA27681; Fri, 24 Nov 2000 13:19:49 +0100 (MET) X-Mailer: Mozilla 4.71 [en] (WinNT; I) X-Accept-Language: en,fr MIME-Version: 1.0 References: <3A192CBE.2B5B24B1@ms.alcatel.fr> <3A1B8008.6727CED7@ericsson.com> <3A1BBC00.F56AB877@ms.alcatel.fr> <3A1D2DE3.20B94C0E@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A1E5CF7.EE5C8DCC@ms.alcatel.fr> Date: Fri, 24 Nov 2000 13:20:07 +0100 Reply-To: Thomas LEVY Sender: "Media Gateway Control (megaco)" From: Thomas LEVY Organization: Alcatel Subject: Re: draft-levy-megaco-mgdiscovery-01.txt, X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Christian, See my answers below marked [THL] Christian Groves wrote: > G'Day Tomas, > > Please see my answers below marked [CHG] > > Cheers, Christian > > Thomas LEVY wrote: > > > > Hello Christian, > > > > -Concerning the need for a MGC to know the internal capabilities of the MG: > > Let's consider this basic example: > > Imagine a MGC controlling 100 heterogeneous MGs. Only 1 MG is able to perform > > encoding modification from PCMU to GSM payload type upon ephemeral terminations. > > When the MGC will need to realize this media function, it should "allocate" a > > Megaco Context in the corresponding MG. > > If the MGC doesn't have the knowledge, it could potentially attempt (without > > success) to ADD Terminations in a new context for 99 MGs, before getting the > > right MG. > > What a waste!!! > [CHG] Seems to me that the MGC would audit these MGs at start up to get > a picture of what they do. If 99 MGs say PCMU only and the 100th it > comes back and gives GSM, PCMU that you choose that one. [THL] The previous example was not the best one to justify my ideas. But, I don't think that the current audit command provide you all information, you could need. For ephemeral terminations (let's consider RTP streams), providing alternative codecs (for inst: GSM, PCMU, PCMA, G729) doesn't inform about whole the media capacities: 1)-It doesn't mean that all the encoding combinations for the codec are supported by the MG. (It can support encoding modification from PCMU to GSM and from PCMA to G729 but not from GSM to G729 (or PCMA to PCMU). 2)-It doesn't tell you if the MG is able to mix several (more than 2) RTP streams (for conferencing purpose) 3)-It doesn't tell the cardinality (number of available media resources for encoding/mixing...) of the MG. > > > > > > -Concerning the best way to get the available internal > > capabilities(Management:SNMP or High Availability:Megaco): > > In any the cases, the MGC needs to know the internal capabilities of a MG on > > start up. This could be done through Management interface. > > But, those available internal capabilities evolves due to : > > -normal consumption of resources > > -"on fly" configuration changes (faillure/recovery of an hardware/software > > resources) > > Thus, I am convinced that a high availability mechanism is needed for internal > > capabilities discovery. > [CHG] Normal consumption of resources should be handled by some sort of > congestion indication mechanism. It should be up to the MG to monitor > its own resources. The MGC shouldn't have to worry about resource > allocation in the MG as the MG might have its own schema. The new > H248AnnexN proposes a load control mechanism. [THL] Sorry, but I can't get: "H248_Annex_L and H248_annex_n_draft" on ftp site from Pictel, could you please give the new URL. However, I am not sure to follow you concerning the "congestion indication mechanism". With "normal consumption of resources", I was meaning that the cardinality of the available media ressources of a MG may evolve due to the normal use of the MG. Thus, the MGC may requires to "realign" its view of the MG by auditing the MediaResources. > > With regards to "on fly" configuration changes this is why we have > ServiceChange "Capability Change" see annex L. It indicates when > something has changed. The MGC can then audit to see the change. [THL] I agree for the ServiceChange "Capability Change" to indicate that something has changed.. But still the same pb to get the new capabilities with audit. > > > > > > Thomas, > > > > Christian Groves wrote: > > > > > Hello Thomas, > > > > > > Finally have have had a chance to read the draft and have a think about > > > it. > > > > > > I have a fundamental question to this draft. Does the MGC really need > > > such indepth knowledge of the internal capabilities of the MG? Megaco I > > > believe was intended to be agonostic with regards to the internals of an > > > MG. I'm also not sure that a mechanism to discover this needs to be > > > highly available. Once the internals of a MG have been found they don't > > > typically change configuration frequently. Thus I feel a SNMP interface > > > would be appropriate as its something not happening all the time, only > > > during maintenance procedures. > > > > > > Cheers, Christian > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 24 08:05:56 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01015 for ; Fri, 24 Nov 2000 08:05:55 -0500 (EST) Received: from standards (47.234.32.16:2631) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBA032@standards.nortelnetworks.com>; Fri, 24 Nov 2000 7:47:22 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 130726 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 24 Nov 2000 07:47:22 -0500 Received: from mel.alcatel.fr (mail2.alcatel.fr) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBA031@standards.nortelnetworks.com>; Fri, 24 Nov 2000 7:47:21 -0500 Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id OAA18767; Fri, 24 Nov 2000 14:03:36 +0100 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id OAA07449; Fri, 24 Nov 2000 14:00:38 +0100 (MET) Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id OAA18296; Fri, 24 Nov 2000 14:04:05 +0100 (MET) Received: from ms.alcatel.fr ([188.9.247.87]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id OAA03235; Fri, 24 Nov 2000 14:04:06 +0100 (MET) X-Mailer: Mozilla 4.71 [en] (WinNT; I) X-Accept-Language: en,fr MIME-Version: 1.0 References: <3A192CBE.2B5B24B1@ms.alcatel.fr> <3A1B8008.6727CED7@ericsson.com> <3A1BBC00.F56AB877@ms.alcatel.fr> <3A1D8C17.3A17888E@ericsson.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A1E6755.E1282C94@ms.alcatel.fr> Date: Fri, 24 Nov 2000 14:04:21 +0100 Reply-To: Thomas LEVY Sender: "Media Gateway Control (megaco)" From: Thomas LEVY Organization: Alcatel Subject: Re: draft-levy-megaco-mgdiscovery-01.txt, X-To: Paul Hollis To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Paul, See my answers below marked [THL] Paul Hollis wrote: > Hi Thomas/Christian, > > I thought that if a MG supports terminations for PCMU and terminations for GSM then > it should also support the encoding/decoding between them. [THL] On my opinion: When an MG owns several heterogeneous terminations, it does not automatically means that it is able to perform ALL the combinations of terminations associations (encoding or decoding) within a context. > > > If there are only limited resources to do such encoding/decoding, then this would > have to be found out via rejection of commands with error codes. Otherwise I guess > you would have to audit every time before trying to use a MG to check its got enough > > resources or the MG could send the ServiceChange or an event when all of a > particular resource is used. [THL] I agree that having a ServiceChange to inform that some kind of resources is not available anymore, provides a best solution in terms of congestion than auditing each time you need to perform a media transformation. But, how does the MGC knows what is unavailable the media resources (in case of several functions performed by the MG)? I think, there is something missing if you use the audit such as it is. The draft "megaco-mgdiscovery" proposes (see part 7) to: -to provide a "quantitative" knowledge of the media resources with the audit command. It could allow the MGC to know that the MG named mg1 will be able to perform only 16 media encoding from PCMA to GSM. -to provide a better "qualitative" knowledge of the media resources. It could allow the MGC to know that the MG named mg1 will be able to perform media encoding only from PCMA to GSM but not for other audio codec type. > You would then need a ServiceChange or event to tell > when the resource is available again. Sounds pretty much like congestion control, > which I guess is on the agenda for the new work anyway. [THL] Yes, it could be interresting to talk specifically about Congestion Control during next meeting. Hope, we will talk about the "megaco-mgdiscovery" draft as well ;-) > > > Regards Paul. > > Thomas LEVY wrote: > > > Hello Christian, > > > > -Concerning the need for a MGC to know the internal capabilities of the MG: > > Let's consider this basic example: > > Imagine a MGC controlling 100 heterogeneous MGs. Only 1 MG is able to perform > > encoding modification from PCMU to GSM payload type upon ephemeral terminations. > > When the MGC will need to realize this media function, it should "allocate" a > > Megaco Context in the corresponding MG. > > If the MGC doesn't have the knowledge, it could potentially attempt (without > > success) to ADD Terminations in a new context for 99 MGs, before getting the > > right MG. > > What a waste!!! > > > > -Concerning the best way to get the available internal > > capabilities(Management:SNMP or High Availability:Megaco): > > In any the cases, the MGC needs to know the internal capabilities of a MG on > > start up. This could be done through Management interface. > > But, those available internal capabilities evolves due to : > > -normal consumption of resources > > -"on fly" configuration changes (faillure/recovery of an hardware/software > > resources) > > Thus, I am convinced that a high availability mechanism is needed for internal > > capabilities discovery. > > > > Thomas, > > > > Christian Groves wrote: > > > > > Hello Thomas, > > > > > > Finally have have had a chance to read the draft and have a think about > > > it. > > > > > > I have a fundamental question to this draft. Does the MGC really need > > > such indepth knowledge of the internal capabilities of the MG? Megaco I > > > believe was intended to be agonostic with regards to the internals of an > > > MG. I'm also not sure that a mechanism to discover this needs to be > > > highly available. Once the internals of a MG have been found they don't > > > typically change configuration frequently. Thus I feel a SNMP interface > > > would be appropriate as its something not happening all the time, only > > > during maintenance procedures. > > > > > > Cheers, Christian > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Nov 24 11:45:06 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26085 for ; Fri, 24 Nov 2000 11:45:05 -0500 (EST) Received: from standards (47.234.32.16:2188) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBA242@standards.nortelnetworks.com>; Fri, 24 Nov 2000 11:26:28 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 131425 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 24 Nov 2000 11:26:28 -0500 Received: from mel.alcatel.fr (mail2.alcatel.fr) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBA240@standards.nortelnetworks.com>; Fri, 24 Nov 2000 11:26:27 -0500 Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id RAA01058; Fri, 24 Nov 2000 17:42:39 +0100 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id RAA11342; Fri, 24 Nov 2000 17:39:56 +0100 (MET) Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id RAA03078; Fri, 24 Nov 2000 17:43:22 +0100 (MET) Received: from ms.alcatel.fr ([188.9.247.87]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id RAA29654; Fri, 24 Nov 2000 17:43:21 +0100 (MET) X-Mailer: Mozilla 4.71 [en] (WinNT; I) X-Accept-Language: en,fr MIME-Version: 1.0 References: <3A192CBE.2B5B24B1@ms.alcatel.fr> <3A1B8008.6727CED7@ericsson.com> <3A1BBC00.F56AB877@ms.alcatel.fr> <3A1D2DE3.20B94C0E@ericsson.com> <3A1E5CF7.EE5C8DCC@ms.alcatel.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A1E9ABE.4848790@ms.alcatel.fr> Date: Fri, 24 Nov 2000 17:43:42 +0100 Reply-To: Thomas LEVY Sender: "Media Gateway Control (megaco)" From: Thomas LEVY Organization: Alcatel Subject: Re: draft-levy-megaco-mgdiscovery-01.txt, X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Christian, I finally got the H248_annexN draft!! I think that in case of congestion, the use of an audit of the MediaRessources descriptor is complementary with the reception of an event indicating a congestion in the MG. Thomas, Thomas LEVY wrote: > Christian, > > See my answers below marked [THL] > > Christian Groves wrote: > > > G'Day Tomas, > > > > Please see my answers below marked [CHG] > > > > Cheers, Christian > > > > Thomas LEVY wrote: > > > > > > Hello Christian, > > > > > > -Concerning the need for a MGC to know the internal capabilities of the MG: > > > Let's consider this basic example: > > > Imagine a MGC controlling 100 heterogeneous MGs. Only 1 MG is able to perform > > > encoding modification from PCMU to GSM payload type upon ephemeral terminations. > > > When the MGC will need to realize this media function, it should "allocate" a > > > Megaco Context in the corresponding MG. > > > If the MGC doesn't have the knowledge, it could potentially attempt (without > > > success) to ADD Terminations in a new context for 99 MGs, before getting the > > > right MG. > > > What a waste!!! > > [CHG] Seems to me that the MGC would audit these MGs at start up to get > > a picture of what they do. If 99 MGs say PCMU only and the 100th it > > comes back and gives GSM, PCMU that you choose that one. > > [THL] The previous example was not the best one to justify my ideas. > But, I don't think that the current audit command provide you all information, you > could need. > > For ephemeral terminations (let's consider RTP streams), providing alternative codecs > (for inst: GSM, PCMU, PCMA, G729) doesn't inform about whole the media capacities: > 1)-It doesn't mean that all the encoding combinations for the codec are supported by > the MG. (It can support encoding modification from PCMU to GSM and from PCMA to G729 > but not from GSM to G729 (or PCMA to PCMU). > 2)-It doesn't tell you if the MG is able to mix several (more than 2) RTP streams (for > conferencing purpose) > 3)-It doesn't tell the cardinality (number of available media resources for > encoding/mixing...) of the MG. > > > > > > > > > > > -Concerning the best way to get the available internal > > > capabilities(Management:SNMP or High Availability:Megaco): > > > In any the cases, the MGC needs to know the internal capabilities of a MG on > > > start up. This could be done through Management interface. > > > But, those available internal capabilities evolves due to : > > > -normal consumption of resources > > > -"on fly" configuration changes (faillure/recovery of an hardware/software > > > resources) > > > Thus, I am convinced that a high availability mechanism is needed for internal > > > capabilities discovery. > > [CHG] Normal consumption of resources should be handled by some sort of > > congestion indication mechanism. It should be up to the MG to monitor > > its own resources. The MGC shouldn't have to worry about resource > > allocation in the MG as the MG might have its own schema. The new > > H248AnnexN proposes a load control mechanism. > > [THL] Sorry, but I can't get: "H248_Annex_L and H248_annex_n_draft" on ftp site from > Pictel, could you please give the new URL. > However, I am not sure to follow you concerning the "congestion indication mechanism". > > With "normal consumption of resources", I was meaning that the cardinality of the > available media ressources of a MG may evolve due to the normal use of the MG. Thus, > the MGC may requires to "realign" its view of the MG by auditing the MediaResources. > > > > > With regards to "on fly" configuration changes this is why we have > > ServiceChange "Capability Change" see annex L. It indicates when > > something has changed. The MGC can then audit to see the change. > > [THL] I agree for the ServiceChange "Capability Change" to indicate that something has > changed.. > But still the same pb to get the new capabilities with audit. > > > > > > > > > > > Thomas, > > > > > > Christian Groves wrote: > > > > > > > Hello Thomas, > > > > > > > > Finally have have had a chance to read the draft and have a think about > > > > it. > > > > > > > > I have a fundamental question to this draft. Does the MGC really need > > > > such indepth knowledge of the internal capabilities of the MG? Megaco I > > > > believe was intended to be agonostic with regards to the internals of an > > > > MG. I'm also not sure that a mechanism to discover this needs to be > > > > highly available. Once the internals of a MG have been found they don't > > > > typically change configuration frequently. Thus I feel a SNMP interface > > > > would be appropriate as its something not happening all the time, only > > > > during maintenance procedures. > > > > > > > > Cheers, Christian > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Nov 25 07:22:35 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18137 for ; Sat, 25 Nov 2000 07:22:34 -0500 (EST) Received: from standards (47.234.32.16:4403) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBA696@standards.nortelnetworks.com>; Sat, 25 Nov 2000 7:04:00 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 132898 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 25 Nov 2000 07:04:00 -0500 Received: from ns.vivanet.co.kr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBA685@standards.nortelnetworks.com>; Sat, 25 Nov 2000 6:53:59 -0500 Received: from yguswsr45 (cranston-ip-1-85.dynamic.ziplink.net [209.206.4.85]) by ns.vivanet.co.kr (8.9.3/8.9.3) with ESMTP id VAA30086; Sat, 25 Nov 2000 21:36:25 +0900 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: <200011251236.VAA30086@ns.vivanet.co.kr> Date: Sat, 25 Nov 2000 05:41:56 -0500 Reply-To: Darren Nason <81gjj@DESERETMAIL.COM> Sender: "Media Gateway Control (megaco)" From: Darren Nason <81gjj@DESERETMAIL.COM> Subject: AMAZING OVERNIGHT FAT-LOSS NEWS #1E3A X-To: over92e@ns.vivanet.co.kr To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA18137 JUST IN TIME FOR THE HOLIDAYS!!!!!! It only takes an hour of your time to gently rub in our miracle gel and .. LOSE 4-6 INCHES OF STUBBORN FAT OVERNIGHT! ****FLATTEN your stomach. ****RE-SHAPE your butt. ****TRIM your thighs. ****REDUCE cellulite everywhere! ^^^WITHOUT strict diets ^^^WITHOUT strenuous exercise ^^^WITHOUT harmful metabolism boosters ^^^WITHOUT expensive surgery Do you want to... [ ] GET SLIM for the Holidays & STAY SLIM? [ ] EAT WHAT YOU WANT at Holiday feasts and festivities but GET RID OF those extra inches FAST? [ ] BEGIN THE NEW YEAR without having to go on ANOTHER DIET? YOU CAN DO IT ALL!!!!! with the safe and reliable overnight results of our MIRACLE GEL. It's safe to use as often as once a week to help you lose more and more inches OR... to lose the added inches of too much Holiday celebrating! GUARANTEED RESULTS! "My wife was scheduled for $6,000 liposuction surgery. We saw your ad and decided your product was worth trying first. Words can't express our delight! My wife lost four inches in her midriff and three inches in her waist, much more than the 'average results' in your ad. Needless to say, we cancelled the surgery." Eric Larsen, Lacrosse, WI "I'm a professional singer, and I'm on the road a lot. I lost almost two inches in my waistline in the first 24 hours. I am very proud of the fact that I have lost this waistline and obliques fat." David Hutchins, Hickory, NC "I lost one inch in my waist, one inch in my hips, and two inches in my thighs. The overnight results with your product are really great! Thank you!" Susan Meir, New York, NY FOR MORE FREE INFORMATION, lots of testimonials, and a step-by-step description of how this product safely creates such amazing overnight results Reply To: mailto:hnm25@verizonmail.com?subject=more_info CALL US: 520-203-4572 (9am-6pm, MST Mon-Sun) You'll talk to people who have used our miracle gels. /////////////////////////////////////////////////////// Please remove at: mailto:81gjj@usa.net?subject=remove /////////////////////////////////////////////////////// From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Nov 25 11:40:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29359 for ; Sat, 25 Nov 2000 11:40:41 -0500 (EST) Received: from standards (47.234.32.16:3792) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBA7D1@standards.nortelnetworks.com>; Sat, 25 Nov 2000 11:21:53 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 133345 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 25 Nov 2000 11:21:52 -0500 Received: from enduser (ts001d04.sun-fl.concentric.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBA7C8@standards.nortelnetworks.com>; Sat, 25 Nov 2000 11:11:50 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Sat, 25 Nov 2000 11:21:52 -0500 Reply-To: Purchasing Sender: "Media Gateway Control (megaco)" From: Purchasing Subject: Your advertising rates To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello megaco@standards.nortelnetworks.com, We saw you listed at http://www.ietf.org/html.charters/megaco-charter.h. We would appreciate you letting us know if you accept advertising on your website and your rates. Any information you could supply about your traffic and demographics would be helpful as well. You can email us your proposal at: inquire8@freeautobot.com You are also invited to place your link on our site for free at: http://63.82.144.35/inquire8/index.html If you are not accepting advertising at this time we would appreciate you forwarding this email to anyone you know who has a high traffic website which accepts paid advertising Thank you for your consideration. If you have no interest in ever accepting advertising please just click this link then click send. mailto:removeadinquire@mail.ru?Subject=remove ########################################################### Please report any internet abuse to: abusealert@hongkong.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 27 05:49:32 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16878 for ; Mon, 27 Nov 2000 05:49:31 -0500 (EST) Received: from standards (47.234.32.16:1275) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBAEDF@standards.nortelnetworks.com>; Mon, 27 Nov 2000 5:30:45 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 135812 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Nov 2000 05:30:45 -0500 Received: from mailcity.com (fes-qout.whowhere.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBAEDE@standards.nortelnetworks.com>; Mon, 27 Nov 2000 5:30:44 -0500 Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Mon Nov 27 02:47:44 2000 Mime-Version: 1.0 X-Sent-Mail: off X-Mailer: MailCity Service X-Sender-Ip: 12.40.232.2 Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Message-ID: Date: Mon, 27 Nov 2000 02:47:44 -0800 Reply-To: kris_albert@lycos.com Sender: "Media Gateway Control (megaco)" From: Kris Albert Organization: Lycos Communications (http://comm.lycos.com:80) Subject: Basic Question on Audit To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi all, In case of Add command, In general the MG applies the desciptor present in the command to the termination after adding it into context. The audit descriptor if present in Add command should be processed. 1. As it comes in the descriptor order. 2. Before adding the termination into the context. 3. After adding the termination into context and after applying all other descriptors. Please tell me which option is valid. Thanks, Kris Get FREE Email/Voicemail with 15MB at Lycos Communications at http://comm.lycos.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 27 09:47:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00907 for ; Mon, 27 Nov 2000 09:47:10 -0500 (EST) Received: from standards (47.234.32.16:3940) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBAFE7@standards.nortelnetworks.com>; Mon, 27 Nov 2000 9:28:25 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 136172 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Nov 2000 09:28:25 -0500 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBAFE6@standards.nortelnetworks.com>; Mon, 27 Nov 2000 9:28:24 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA06916; Mon, 27 Nov 2000 09:45:34 -0500 (EST) Received: from stl-server-01.pit.comms.marconi.com (stl-server-01.pit.comms.marconi.com [169.144.36.27]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA19055; Mon, 27 Nov 2000 09:45:34 -0500 (EST) Received: by stl-server-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 09:45:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6EA64@whq-msgusr-02.pit.comms.marconi.com> Date: Mon, 27 Nov 2000 09:45:16 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Basic Question on Audit X-To: "kris_albert@lycos.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM I believe that specific behavior is undefined (there is no implied order of descriptor processing). I would, if I were implementing an MG, do it in descriptor order, which I believe would be AFTER the actual Add was done. On the other hand, I wouldn't expect this behavior if I was implementing an MGC, and thus would do the audit either before, or after the Add, depending on what I wanted. Brian > -----Original Message----- > From: Kris Albert [mailto:kris_albert@lycos.com] > Sent: Monday, November 27, 2000 5:48 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Basic Question on Audit > > > Hi all, > In case of Add command, In general the MG applies the > desciptor present in the command to the termination after > adding it into context. > The audit descriptor if present in Add command should > be processed. > 1. As it comes in the descriptor order. > 2. Before adding the termination into the context. > 3. After adding the termination into context and after > applying all other descriptors. > > Please tell me which option is valid. > > Thanks, > Kris > > > Get FREE Email/Voicemail with 15MB at Lycos Communications at > http://comm.lycos.com > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 27 11:40:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06565 for ; Mon, 27 Nov 2000 11:40:55 -0500 (EST) Received: from standards (47.234.32.16:1851) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB072@standards.nortelnetworks.com>; Mon, 27 Nov 2000 11:21:48 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 136351 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Nov 2000 11:21:48 -0500 Received: from tesla.comm.toronto.edu (tesla.comm.utoronto.ca) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB06F@standards.nortelnetworks.com>; Mon, 27 Nov 2000 11:11:47 -0500 Received: from localhost (rchen@localhost) by tesla.comm.toronto.edu (8.9.0/8.9.0) with SMTP id LAA03093 for ; Mon, 27 Nov 2000 11:21:31 -0500 (EST) X-Sender: rchen@tesla.comm MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Mon, 27 Nov 2000 11:21:31 -0500 Reply-To: Richard Chen Sender: "Media Gateway Control (megaco)" From: Richard Chen Subject: Megaco/H.248 Implementors guide To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, Can anyone please let me know where can i find the latest Implementors guide for Megaco/H.248. Thanks ==== Richard From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 27 16:03:51 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04956 for ; Mon, 27 Nov 2000 16:03:51 -0500 (EST) Received: from standards (47.234.32.16:1461) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB1C4@standards.nortelnetworks.com>; Mon, 27 Nov 2000 15:45:04 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 136802 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Nov 2000 15:45:03 -0500 Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB1C3@standards.nortelnetworks.com>; Mon, 27 Nov 2000 15:45:03 -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 QAA23769 for ; Mon, 27 Nov 2000 16:02:11 -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 QAA23761 for ; Mon, 27 Nov 2000 16:02:10 -0500 (EST) Received: by ihgp2.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA06760; Mon, 27 Nov 2000 15:02:10 -0600 (CST) Received: from lucent.com by ihgp2.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA06687; Mon, 27 Nov 2000 15:02:05 -0600 (CST) X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD1102DE6813@zcard00g.ca.nortel.com> <3A1C2500.359DA45A@lucent.com> Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit Message-ID: <3A22CB4D.6BCC7AA1@lucent.com> Date: Mon, 27 Nov 2000 14:59:57 -0600 Reply-To: Hsien-Chuen Yu Sender: "Media Gateway Control (megaco)" From: Hsien-Chuen Yu Organization: Lucent Technologies Subject: ServiceChangeMethod and serviceState To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit All, I have several comments and questions: 1. The description of Failover in Item 6, Section 7.2.8 needs to be expanded to include the case described in the 1st paragraph of Section 11.5: "If the MG detects a failure of its controlling MGC, it attempts to.... It sends a ServiceChange message with a "Failover" method and a "MGC Impending Failure" reason". 2. The description of "notifyCompletion" in Section 7.1.11 is confusing. It appears that if notifyCompletion is included in the signalsDescriptor, MGC will be notified even if it does not specify an eventsDescriptor. It also appears that if notifyCompletion is not included in the signalDescriptor, notification is generated only via eventsDescriptor. However, the description of Signal Completion event in Annex E.1.2 says this event is for the case where the notifyCompletion parameter is set to "ON". If this description is correct, then why duplicate the same mechanism in notifyCompletion? 3. The returned parameter in Section 7.2.8 should be ServiceChangeReplyDescriptor instead of ServiceChangeDescriptor. 4. The description in Section 7.2.8 allows a MGC to send a ServiceChange message to MG to put a Termination out of service (with ServcieChangeMethod = graceful or forced) or to put a Termination in service (with ServiceChangeMethod = Restart). This obviously is one way that the MGC can affect the value of serviceStates in the terminationStateDescriptor. My question: Is this the only mechanism allowed for MGC to modify serviceStates of a Termination? If so, should it be clearly stated that serviceStates is read-only by MGC? 5. The Mux Properties in Annex C.2 are already covered in Annex A and Annex B. Why are they repeated here? In any case, they are not part of MediaDescriptors and therefore should not belong to Annex C. Regards, Hsien Yu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Nov 27 18:23:19 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16617 for ; Mon, 27 Nov 2000 18:23:18 -0500 (EST) Received: from standards (47.234.32.16:1107) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB31B@standards.nortelnetworks.com>; Mon, 27 Nov 2000 17:17:06 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 137268 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Nov 2000 17:17:06 -0500 Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB31A@standards.nortelnetworks.com>; Mon, 27 Nov 2000 17:17:05 -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 RAA04271 for ; Mon, 27 Nov 2000 17:34:18 -0500 (EST) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id RAA04256 for ; Mon, 27 Nov 2000 17:34:17 -0500 (EST) Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id RAA19417; Mon, 27 Nov 2000 17:34:14 -0500 Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id RAA19414; Mon, 27 Nov 2000 17:34:14 -0500 X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A22E11A.8E03EB8B@lucent.com> Date: Mon, 27 Nov 2000 17:32:58 -0500 Reply-To: Troy Cauble Sender: "Media Gateway Control (megaco)" From: Troy Cauble Subject: ServiceChangeReason - OPTIONAL? To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit In the text encoding spec., ServiceChangeReason is optional. In the ASN.1 encoding spec., it is not. Which is correct? If it is not optional, the first to messages in Appendix A should be fixed. -troy From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 28 06:21:06 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14435 for ; Tue, 28 Nov 2000 06:21:05 -0500 (EST) Received: from standards (47.234.32.16:3184) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB8CA@standards.nortelnetworks.com>; Tue, 28 Nov 2000 6:02:32 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 139151 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 06:02:31 -0500 Received: from blaze1.hcltech.com (202.9.161.211:4943) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBB89B@standards.nortelnetworks.com>; Tue, 28 Nov 2000 5:52:30 -0500 Received: from blaze.hcltech.com ([192.168.201.1]) by blaze1.hcltech.com with Microsoft SMTPSVC(5.5.1877.197.19); Tue, 28 Nov 2000 16:40:43 +0530 Received: from avinash ([192.168.201.59]) by blaze.hcltech.com (8.9.3/8.8.7) with SMTP id QAA12657 for ; Tue, 28 Nov 2000 16:47:31 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0062_01C0595A.69E64040" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <006501c0592c$666063c0$3bc9a8c0@avinash> Date: Tue, 28 Nov 2000 16:44:02 +0530 Reply-To: Avinash Prakash Sender: "Media Gateway Control (megaco)" From: Avinash Prakash Subject: Definition of media Descriptor in ABNF & ASN.1 To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0062_01C0595A.69E64040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, According to ABNF, a media Descriptor can have a sequence of media = Parameter. In ASN.1, however, it is not so. Is there a discrepancy in the two or I am missing something? Can we be more claer as to what is intended? Regards, Avinash. ------=_NextPart_000_0062_01C0595A.69E64040 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
According to ABNF, a media Descriptor = can=20 have a sequence of  media Parameter. In ASN.1, however, it is = not=20 so.
Is there a discrepancy in the two or I = am missing=20 something?
Can we be more claer as to what is=20 intended?
 
Regards,
Avinash.
 
------=_NextPart_000_0062_01C0595A.69E64040-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 28 10:56:54 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02788 for ; Tue, 28 Nov 2000 10:56:53 -0500 (EST) Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBBCAF@standards.nortelnetworks.com>; Tue, 28 Nov 2000 10:36:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 140506 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 10:36:10 -0500 Received: from auemail2.firewall.lucent.com (auemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBBCAE@standards.nortelnetworks.com>; Tue, 28 Nov 2000 10:36:09 -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 KAA13826 for ; Tue, 28 Nov 2000 10:53:24 -0500 (EST) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id KAA13818 for ; Tue, 28 Nov 2000 10:53:23 -0500 (EST) Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA28458; Tue, 28 Nov 2000 10:53:21 -0500 Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA28455; Tue, 28 Nov 2000 10:53:20 -0500 X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A23D4A4.B397EBD@lucent.com> Date: Tue, 28 Nov 2000 10:52:04 -0500 Reply-To: Troy Cauble Sender: "Media Gateway Control (megaco)" From: Troy Cauble Subject: MEGACO: Lists and Enums To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Section 12.1.2 and 12.2 specify data types for Properties and Parameters. The specifications include: "Enumeration: One of a list of possible unique values. (See 12.3)" "Sub-list: A list of several values from a list." Section 12.3, "Lists" states: Possible values for parameters include enumerations. Enumerations may be defined in a list. Questions: Does this imply that "Sub-list" means "list of enums"? That is, can a package define Properties or Parameters whose values are lists of strings or lists of integers? -troy From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 28 11:57:33 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00107 for ; Tue, 28 Nov 2000 11:57:32 -0500 (EST) Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBBE9F@standards.nortelnetworks.com>; Tue, 28 Nov 2000 11:38:47 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 141174 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 11:38:47 -0500 Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBBE9E@standards.nortelnetworks.com>; Tue, 28 Nov 2000 11:38:46 -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 LAA11526 for ; Tue, 28 Nov 2000 11:56:01 -0500 (EST) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id LAA11517 for ; Tue, 28 Nov 2000 11:56:01 -0500 (EST) Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id LAA29389; Tue, 28 Nov 2000 11:55:59 -0500 Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id LAA29386; Tue, 28 Nov 2000 11:55:58 -0500 X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A23E353.17C4A8CB@lucent.com> Date: Tue, 28 Nov 2000 11:54:43 -0500 Reply-To: Troy Cauble Sender: "Media Gateway Control (megaco)" From: Troy Cauble Subject: MEGACO: Generic Package parameter SigID To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, hello again, In section E.1.2 (Events for the Generic package), under the "Signal Completion" event, "Signal Identity" parameter... Firstly, I find it objectionable that this parameter defines encoding syntax. Shouldn't that be defined in section 12 with the allowed types and referenced by type in the package elements? Can a package element really define it's own syntax? As someone writing a stack with a extensible package mechanism, I can say that this would be a major pain in the butt. Secondly, and I may be reading too much into things again, but this SEEMS to IMPLY that ANY signal may be returned, without being an extension of this package. Only because the Call Progress Tones Generator Package EXTENDS the Tone Generator Package, the former's values can be used with the latter's signals. But all of the Call Progress Tones and any others can be used with "Signal Completion" without extending the Generic package?!?!? -troy From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 28 15:33:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04687 for ; Tue, 28 Nov 2000 15:33:00 -0500 (EST) Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC45D@standards.nortelnetworks.com>; Tue, 28 Nov 2000 15:09:50 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 143150 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 15:09:50 -0500 Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC45C@standards.nortelnetworks.com>; Tue, 28 Nov 2000 15:09:50 -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 PAA29708 for ; Tue, 28 Nov 2000 15:27:04 -0500 (EST) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id PAA29685 for ; Tue, 28 Nov 2000 15:27:04 -0500 (EST) Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA01792; Tue, 28 Nov 2000 15:27:03 -0500 Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA01789; Tue, 28 Nov 2000 15:27:03 -0500 X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <3A23D4A4.B397EBD@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A2414C9.7710BD9E@lucent.com> Date: Tue, 28 Nov 2000 15:25:45 -0500 Reply-To: Troy Cauble Sender: "Media Gateway Control (megaco)" From: Troy Cauble Subject: Re: MEGACO: Lists and Enums To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Troy Cauble wrote: > > Section 12.1.2 and 12.2 specify data types for Properties > and Parameters. The specifications include: > > "Enumeration: One of a list of possible unique values. (See 12.3)" > "Sub-list: A list of several values from a list." > > Section 12.3, "Lists" states: > Possible values for parameters include enumerations. > Enumerations may be defined in a list. > > Questions: > Does this imply that "Sub-list" means "list of enums"? > That is, can a package define Properties or Parameters > whose values are lists of strings or lists of integers? (Answering myself.) In E.9.3, "cadence" specifies a list of integers. So I guess a lists of any more basic type can be specified. -troy From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 28 15:36:19 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05547 for ; Tue, 28 Nov 2000 15:36:19 -0500 (EST) Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC4B6@standards.nortelnetworks.com>; Tue, 28 Nov 2000 15:17:06 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 143271 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 15:17:06 -0500 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC4B5@standards.nortelnetworks.com>; Tue, 28 Nov 2000 15:17:06 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA08624 for ; Tue, 28 Nov 2000 15:34:18 -0500 (EST) Received: from stl-server-01.pit.comms.marconi.com (stl-server-01.pit.comms.marconi.com [169.144.36.27]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA27441 for ; Tue, 28 Nov 2000 15:34:18 -0500 (EST) Received: by stl-server-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Nov 2000 15:34: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: <4FBEA8857476D311A03300204840E1CF01A6EA89@whq-msgusr-02.pit.comms.marconi.com> Date: Tue, 28 Nov 2000 15:34:18 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: 2nd Megaco Interop Event X-To: "megaco-interop@fore.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM I am very pleased to announce that the second Megaco Interop Event will be held February 19-21 at the University of New Hampshire's Interoperability Lab. The Event is co-sponsored by the IOL and the Multiservice Switching Forum, further co-sponsors may be announced. Ericsson will be the host for this event. There will be at least 3 full days of testing. A new version of the test profile document will be released when the IETF freeze is lifted following the San Diego meeting. We will have more extensive test scenarios, there will be IP and ATM networks, and we will support additional profile testing. If you have a Megaco/H.248 implementation, please plan to bring it to this event. Block out the time in your calendars, make your travel plans. Be there! As a reminder, details of interop events are carried on the megaco-interop mail list. To subscribe, send an email to majordomo@fore.com and specify "subscribe megaco-interop" in the BODY of the message. Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Nov 28 20:09:35 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22512 for ; Tue, 28 Nov 2000 20:09:35 -0500 (EST) Received: from standards (47.234.32.16:3887) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC7B6@standards.nortelnetworks.com>; Tue, 28 Nov 2000 19:50:46 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 144262 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Nov 2000 19:50:46 -0500 Received: from ganymede.or.intel.com (134.134.248.3:1671) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC7B5@standards.nortelnetworks.com>; Tue, 28 Nov 2000 19:50:45 -0500 Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id RAA14821; Tue, 28 Nov 2000 17:07:58 -0800 (PST) Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 29 Nov 2000 01:07:57 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Nov 2000 17:07:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: Date: Tue, 28 Nov 2000 10:59:47 -0800 Reply-To: "Tulpule, Naren" Sender: "Media Gateway Control (megaco)" From: "Tulpule, Naren" Subject: Re: MEGACO: Generic Package parameter SigID X-To: Troy Cauble To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi Troy, list, please see comments below. -- Naren. These views and opinions are mine alone, not those of Intel (yet ;-) Narendra C. Tulpule SMTS, Trillium (an Intel company) Ph: +1-310-442-9222 Fax: +1-310-442-1162 12100 Wilshire Bl #1800 Los Angeles, CA 90025 -----Original Message----- From: Troy Cauble [mailto:troy@LUCENT.COM] Section 12.1.2 and 12.2 specify data types for Properties and Parameters. The specifications include: "Enumeration: One of a list of possible unique values. (See 12.3)" "Sub-list: A list of several values from a list." Section 12.3, "Lists" states: Possible values for parameters include enumerations. Enumerations may be defined in a list. Questions: Does this imply that "Sub-list" means "list of enums"? That is, can a package define Properties or Parameters whose values are lists of strings or lists of integers? [[ NAREN ]] I think so. A parmValue can contain a list of enums, each of which is a VALUE. It'd serve no purpose IMHO to have VALUE itself as a list-of-enums (and then parmValue can be a list-of-lists). One such parameter is tl for tonedet/etd whose value (parmValue) is a list of toneIDs. In section E.1.2 (Events for the Generic package), under the "Signal Completion" event, "Signal Identity" parameter... Firstly, I find it objectionable that this parameter defines encoding syntax. Shouldn't that be defined in section 12 with the allowed types and referenced by type in the package elements? Can a package element really define it's own syntax? As someone writing a stack with a extensible package mechanism, I can say that this would be a major pain in the butt. [[ NAREN ]] Glad I am not the only guy who thinks so. It _is_ a pain in the neck. We could have had an sc event parameter in each package (or its related package) which has that signal, so e.g. for al/ri signal, we could have an al/ri event with parameter sc taking no values. (Insert better example here :-) Plus the syntax is too complicated for g/sc. Secondly, and I may be reading too much into things again, but this SEEMS to IMPLY that ANY signal may be returned, without being an extension of this package. Only because the Call Progress Tones Generator Package EXTENDS the Tone Generator Package, the former's values can be used with the latter's signals. But all of the Call Progress Tones and any others can be used with "Signal Completion" without extending the Generic package?!?!? [[ NAREN ]] Yes - essentially everytime you add a package you add a possible parameter to g/sc! can anyone give a practical example where g/sc will be _needed_? if "end tone detected" (etd) could take method (Meth) as a parameter we don't need g/sc for toneIDs. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 29 00:20:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27015 for ; Wed, 29 Nov 2000 00:20:24 -0500 (EST) Received: from standards (47.234.32.16:3175) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC919@standards.nortelnetworks.com>; Wed, 29 Nov 2000 0:01:36 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 144664 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Nov 2000 00:01:35 -0500 Received: from srv_linz_www.pcd.at (195.82.225.19:1093) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBC902@standards.nortelnetworks.com>; Tue, 28 Nov 2000 23:51:33 -0500 Received: from mindspring (user-3qt5hn.dialup.mindspring.com[99.174.150.55]) by smtp6.mindspring.com (8.9.3/8.8.5) with SMTP id OAA06398 from 110140321worldnet.att.net ([102.70.21.32]) by mtiwmhc98.worldnet.att.net (InterMail v03.02.07.07 118-134) with SMTP id<20090116Ô`ö[ 6 ([216.214.107.29]) by srv_linz_www.pcd.at (Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) with SMTP id C12569A6.001BD986; Sun, 29 Nov 1970 06:05:21 +0100 X-Priority: 3 X-MSMail-Priority: Normal Errors-To: dren6421@concentric.net X-Mailer: Mozilla 4.72 [en] (Win98; U) Message-ID: <00004b616bf0$0000269b$00000bbf@mcpeely.concentric.net (mcfeely.concentric.net [217.15.198.83])by darius.concentric.net (8.9.1a/(98/12/15 5.12)) id PAA04003from default (m202.2-25.warwick.net [218.242.202.80]) byhost.warwick.net (8.10.0.Beta10/8.10.0.Beta10) with SMTP id e0GKEKk19201 > Date: Tue, 28 Nov 2000 20:13:41 -0800 Reply-To: wjeske@CORP22-98.SONERA-XS.NL Sender: "Media Gateway Control (megaco)" From: wjeske@CORP22-98.SONERA-XS.NL Subject: Be Happier.. X-To: christy@mail.dige.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM Only from Shambhala Botanicals... Greetings & Blessings To You! Offering for your "Sensitive" Delight: "Seventh Heaven" Kathmandu Temple Kiff (tm); a viripotent cannabis alternative for blissful regressions of vexatious depressions... "Seventh Heaven" Prosaka Tablets (tm); a botanical alternative to pharmaceutical medications for calm, balance, serenity and joyful living... "Seventh Heaven" Gentle Ferocity Tablets (tm); a most efficacious, non-caffeine, non-ephedrine, non-MaHuang botanical energizer... Kathmandu Temple Kiff is a proprietary; Nepalese, sensitive, pipe-smoking/stoking substance. Kathmandu Temple Kiff is indeed the most substantial marijuana/cannabis alternative on the planet. Absolutely Legal! Marvelously Potent! Kathmandu Temple Kiff possesses all of the positive virtues fine ganja/cannabis without any of the negatives. An amalgamation of high concentrates of rare euphoric herbas, Kathmandu is offered in a solid jigget/bar format and is actually more UPLIFTING & POISED than cannabis / marijuana while rendering Euphoria, Happiness, Mood- Enhancement, Stress/Depression Relief and promoting contemplativeness, creativity, better sleep, lucid dreaming ... and enhancing the sexual experience!!! Kathmandu Temple Kiff is simply the best and just a little pinch/snippet of the Kathmandu goes a long "sensitive" way. Just 4 or 5 draws of the pipe ... (an herb pipe included with each package of Kathmandu Temple Kiff). PLEASE NOTE: Although no botanical factor in Kathmandu Temple Kiff is illegal or considered to be harmful by regulatory agencies and no tobacco is included therein, it is the policy of our company that Kathmandu Temple Kiff may not be offered or sold to any person that has not attained at least 21 years of age. Ingredients: Kathmandu Temple Kiff is both a euphoriant and an uplifting, calmative relaxant that offers scintillating physical and cerebral ambiance enhancement. Kathmandu Temple Kiff is a proprietary, prescribed amalgamation which includes the following synergistically, synesthesia conglomerated, uncommon herbs, resins, essences, flower-tops and oils in extreme ratio extractment ranging from 8.5 to to 60 to 1, viripotent concentrations: Drachasha, Chavana Prash, Trikatu, Black Seed Herb, Capillaris Herba, Angelica Root, Wild Dagga, Haritaki, Shatavari, Labdunum, Neroli, Unicorn Root, Papaver Rhoes, Dendrobian, Calea Zacalechichi, Rue, Amla, Salvia Divinorum, Crocus Sativa, Lotus and Gokshura. Also for your sensitive mellowness... "Seventh Heaven" Prosaka Tablets are an entirely natural, proprietary, botanical prescription comprised of uncommon Asian Herbs for Calm, Balance, Serenity and Joyful Living. "Seventh Heaven" Prosaka is indeed a most extraordinary, viripotent, calming, centering, mood-enhancing, holistically- formulated, exotic herbaceous alternative to pharmaceutical medications for depression, anxiety, stress, insomnia, etc. NO side effects! NO dependency! Vivaciously Mellow! There is ABSOLUTELY nothing else quite like "Seventh Heaven" Prosaka (tm). Ingredients: Seventh Heaven Prosaka tablets contain the following herbal factors in precise prescription: Tadix Salviae, Sensitive Mimosa Bark, Arullus Euphoriae, Shizandra, Frutcus Mori, Caulis, Polygoni Multiflori, Zizphus, Tang Kuei, Cedar Seed, weetflag Rhizome, Cuscutae, Amber, Radix Scutellariae, Evodia, Longan, Arizisaema, Cistanches, Radix Polygalae, Red Sage Root and Eucommia. Recommended dosage: 1-2 tablets; 2-3 times per day. Also... for your "Sensitive" "Pure Energy" Energization... "Seventh Heaven" Gentle Ferocity Tablets (tm). A "Seventh Heaven" non-caffeine, non-ephedrine, non-ephedra, non-MaHuang; viripotent, herbaceous prescription for the dynamic energization of body, mind and spirit. This Gentle Ferocity Formulation is amalgamated in accordance with the fundamental Taoist herbal principle of botanical interactiveness and precursorship which in essence is a molecular equation of the relevant botanical/ herbal alkaloids and glycosides interacting with one another to prolificate molecular communion and thereby to achieve demonstrative herbal efficaciousness without negative implication to any aspect of human composition. These Gentle Ferocity Cordial Tablets are incredulously and thoroughly effective. Enjoy! Contents: Each Gentle Ferocity Tablet contains 500 mg. of the following proprietary formulated, high-ratio concentrated botanical factors... Cortex Eucommiae, Radex Polygoni Multiflori, Zizyphus Seed, Fructus Schisandrae, Radix Panax Ginseng, Radix Astragali, Atractylode, Sclerotium, Porial Cocos, Saussurea Tang Kuei, Longan, Radix Paeoniae, Biota Seeds, Glehnia, Radix Salviae, Ligusticum, Lycu Berry, Radix Dioscoreae, Cortex Mouton, Frutcus Corni, Radix Polygalae, Cistanches, Radix Pseudoslellariae and Cortex Aranthopanacis. PRICING INFORMATION: 1. SEVENTH HEAVEN KATHMANDU TEMPLE KIFF (tm) One .75 oz. jigget/bar $65.00 One 2 oz. jigget/bar $115.00 (Free Capillaris Herba with 1.5 oz. bar Refer to Capillaris paragraph at end of text) 2. SEVENTH HEAVEN PROSAKA (tm) One 100 tablet tin $40.00 Three 100 tablet tins $105.00 Six 100 tablet tins $185.00 3. SEVENTH HEAVEN GENTLE FEROCITY (tm) One 300 tablet jar $130.00 4. BODY, MIND, SPIRIT "HEAVENLY" INTRO COMBINATION OFFER Includes one, 2 oz. jigget/bar of Kathmandu Temple Kiff & 1 tin (100 tablets) of Seventh Heaven Prosaka for...$125.00 (Reg. $155.00 Save $30) (Free Capillaris Herba with this intro offer. Refer to Capillaris paragraph at end of text) 5. "PURE ENERGY" INTRO COMBINATION OFFER Includes one, 2 oz. jigget/bar of Kathmandu Temple Kiff & 1 jar (300 tablets) of Seventh Heaven Gentle Ferocity for...$170.00 (Reg. $245.00 Save $75) (Free Capillaris Herba with this intro offer Refer to Capillaris paragraph at end of text) 6. "SENSITIVE" PREFERENTIAL INTRO COMBINATION OFFER Includes one, 2 oz. jigget/bar of Kathmandu Temple Kiff & 1 tin (100 tablets) of Seventh Heaven Prosaka & 1 jar (300 tablets) of Seventh Heaven Gentle Ferocity for $200.00 (Reg. $285.00 Save $85) (Free Capillaris Herba with this intro offer Refer to Capillaris paragraph at end of this text.) =============================== ORDERING INFORMATION: For your convenience, you can call us direct with your orders or questions. Call 1 (719) 686-9919 =============================== SPECIAL DISCOUNT & GIFT Call now and receive a FREE botanical gift! With every order for a 2 oz. jigget / bar of Kathmandu Temple Kiff or an order for our "Heavenly" Intro Combination Offer or our "Pure Energy" Intro Combination Offer, we will include as our free gift to you ... a 2 oz. package of our ever so sedate, sensitive Asian import, loose-leaf Capillaris Herba for "happy" smoking or brewing ... (a $40.00 retail value). =============================== Remove Instructions We comply with proposed federal legislation regarding unsolicited commercial email by providing you with a method for you to opt-out of future mailings from our company. To remove your address, click on the following link and follow the simple instructions: MAILTO:peterpan@egyptsun.com?subject=removeplease From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 29 12:37:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25300 for ; Wed, 29 Nov 2000 12:37:29 -0500 (EST) Received: from standards (47.234.32.16:4854) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBCE13@standards.nortelnetworks.com>; Wed, 29 Nov 2000 12:18:14 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 146370 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Nov 2000 12:18:14 -0500 Received: from k21c.co.kr (210.183.227.238:2441) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBCDF7@standards.nortelnetworks.com>; Wed, 29 Nov 2000 12:08:12 -0500 Received: from 210.183.227.237 ([206.217.206.23]) by k21c.co.kr (8.10.1/8.8.7) with SMTP id eATH51W20370; Thu, 30 Nov 2000 02:05:03 +0900 Message-ID: <7490321574.swr92301@rly-d58943.comnet11.co.jp> Date: Wed, 29 Nov 2000 07:16:04 EST Reply-To: sallysue2@comnet11.co.jp Sender: "Media Gateway Control (megaco)" From: sallysue2@comnet11.co.jp Subject: MORE Holiday Sales + NO Set Up Fee E-Commerce Solution!! X-To: courtney34@swbell.net To: MEGACO@STANDARDS.NORTELNETWORKS.COM Complete E-COMMERCE solutions to accept VISA, MasterCard, American Express, Discover and Checks for your website, online store, traditional storefront or home based business. WE OFFER -Bank-approved merchant accounts -Real-time, online payment transactions -Shopping carts -Terminals & printers -95% approval rate -Fast 5 - 7 day setup A TURNKEY E-COMMERCE SOLUTION FOR -Internet Storefront Businesses -Mail Order and Phone Order -Start-up Businesses -Traditional Retail Stores -Home based Businesses Good Credit / Bad Credit / No Credit **** NO PROBLEM **** ------FREE SET-UP------FREE SET-UP------FREE SET-UP---------- While OTHERS Charge You From $200 TO $350 To Get Set Up WE CHARGE ZERO FOR SETUP FEES!!! Limited Time Offer So Take Advantage NOW!!! Secure transactions are authorized in true real-time immediately upon submitting orders right on your website. You can process transactions right over the Internet without the need for separate transaction terminal or processing software. Dedicated data line for fast, 3-5 second transactions. No installation required! Quick and easy account setup: 5 - 7 days. _____________________________________________ Full Service E-Commerce Provider who offers complete e-commerce solutions for thousands of businesses. FREE CONSULTATION WITH AN INDUSTRY EXPERT, NO OBLIGATION -LOWEST MONTHLY SERVICE FEES as low as 1.59% Banks can charge up to 5% or higher ------FREE SET-UP------FREE SET-UP------FREE SET-UP-------- The Time Is Right!!! Call Now!!! ------------------------------------------------------------- 1-888-480-9950 In order to have one of our CONSULTANTS contact you, we MUST have all of the following information: First & Last Name________________________________________ Phone Number with Area Code______________________________ Company Name_____________________________________________ Type of Product and or Service________________________ ** Please note: USA Only, No Adult or Travel A merchant account CONSULTANT will contact you soon. ============================================== 1-888-480-9950 Here's what our customers say... Testimonial # 1 - I knew having a merchant account would increase my sales, But never thought it would be so great. In addition in being able to take major credit cards, I can also do real time credit card processing on the internet and receive orders while I am Sleeping. It's awesome! I encourage every serious business owner to get one. Thanks. M.B./MI Testimonial # 2 - " Being a home based business owner, no one would approve me, until this came my way. I am more than grateful. Within 10 days I had my merchant account set up. I am more than pleased with the 24 hr. customer service. My business has sky rocketed because I now can accept credit card orders. " Oscar/FL =================================================== This message was sent by an independent advertising company. To be removed from future promotions please send an email to: glitchie@cutey.com with REMOVE in the subject line. We apologize for any inconvenience. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 29 15:13:57 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16987 for ; Wed, 29 Nov 2000 15:13:56 -0500 (EST) Received: from standards (47.234.32.16:1042) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBCED5@standards.nortelnetworks.com>; Wed, 29 Nov 2000 14:55:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 146661 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Nov 2000 14:55:03 -0500 Received: from standards (47.234.32.16:1042) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBCED4@standards.nortelnetworks.com>; Wed, 29 Nov 2000 14:55:03 -0500 Message-ID: Date: Wed, 29 Nov 2000 14:55:03 -0500 Reply-To: Tom Taylor Sender: "Media Gateway Control (megaco)" From: Tom Taylor Subject: Re: Megaco/H.248 Implementors guide X-To: Richard Chen To: MEGACO@STANDARDS.NORTELNETWORKS.COM On Mon, 27 Nov 2000 11:21:31 -0500, Richard Chen wrote: > >Hi, > >Can anyone please let me know where can i find the latest Implementors guide >for Megaco/H.248. > > >Thanks > > >==== >Richard You can find it at ftp://standard.pictel.com/avc-site/0011_Gen/H248_Implementors_guide_approved.zip From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 29 15:28:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21466 for ; Wed, 29 Nov 2000 15:28:30 -0500 (EST) Received: from standards (47.234.32.16:1042) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBCF0D@standards.nortelnetworks.com>; Wed, 29 Nov 2000 15:09:35 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 146740 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Nov 2000 15:09:35 -0500 Received: from standards (47.234.32.16:1042) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBCF0C@standards.nortelnetworks.com>; Wed, 29 Nov 2000 15:09:34 -0500 Message-ID: Date: Wed, 29 Nov 2000 15:09:34 -0500 Reply-To: Tom Taylor Sender: "Media Gateway Control (megaco)" From: Tom Taylor Subject: Re: Basic Question on Audit To: MEGACO@STANDARDS.NORTELNETWORKS.COM On Mon, 27 Nov 2000 09:45:16 -0500, Rosen, Brian wrote: >I believe that specific behavior is undefined (there is no >implied order of descriptor processing). I would, if I were >implementing an MG, do it in descriptor order, which I believe >would be AFTER the actual Add was done. [PTT] Actually, section 7.2 says that descriptors are processed in the order they are encountered. > >On the other hand, I wouldn't expect this behavior if I was >implementing an MGC, and thus would do the audit either before, >or after the Add, depending on what I wanted. > >Brian > >> -----Original Message----- >> From: Kris Albert [mailto:kris_albert@lycos.com] >> Sent: Monday, November 27, 2000 5:48 AM >> To: MEGACO@STANDARDS.NORTELNETWORKS.COM >> Subject: Basic Question on Audit >> >> >> Hi all, >> In case of Add command, In general the MG applies the >> desciptor present in the command to the termination after >> adding it into context. >> The audit descriptor if present in Add command should >> be processed. >> 1. As it comes in the descriptor order. >> 2. Before adding the termination into the context. >> 3. After adding the termination into context and after >> applying all other descriptors. >> >> Please tell me which option is valid. >> >> Thanks, >> Kris >> >> >> Get FREE Email/Voicemail with 15MB at Lycos Communications at >> http://comm.lycos.com >> From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 29 17:01:13 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26625 for ; Wed, 29 Nov 2000 17:01:12 -0500 (EST) Received: from standards (47.234.32.16:2919) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBCF81@standards.nortelnetworks.com>; Wed, 29 Nov 2000 16:42:18 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 146876 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Nov 2000 16:42:18 -0500 Received: from web_server.szpb.gov.cn (210.74.122.148:4443) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBCF74@standards.nortelnetworks.com>; Wed, 29 Nov 2000 16:32:16 -0500 Received: from h809 (1Cust82.tnt1.mia5.da.uu.net [63.30.194.82]) by web_server.szpb.gov.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id XW7A6QNZ; Thu, 30 Nov 2000 05:45:52 +0800 Message-ID: Date: Wed, 29 Nov 2000 16:42:18 -0500 Reply-To: V@TZW.DE Sender: "Media Gateway Control (megaco)" From: V@TZW.DE Subject: Lady V: The Pleasure Pill for Women! To: MEGACO@STANDARDS.NORTELNETWORKS.COM LADY V: The Pleasure Pill for Women! Men Have Their Viagra®! Finally, A Pill for Women! It's Here! The Revolutionary Woman's Sexual Sensation is Now Available. Researchers are calling Lady V the greatest breakthrough for women since the Birth Control Pill. And you don't even need a prescription to get it! Welcome to the New Sexual Revolution! It's no secret that men have been having the time of their lives since the wonder pill Viagra® was made available. But, women were left out in the cold with no pill... nothing! Well now thanks to an all-star team of medical researchers who have been working around the clock, those days are finally over. The perfect female "pleasure pill" has been created and you don't even need a prescription. You can now get it from Lion Sciences! Lady V is the world's first pleasure pill scientifically designed for women. Lady V is an all-natural proprietary herbal blend of prosexual nutrients from around the world synergistically blended to naturally stimulate neurotransmitter endorphin signals. This magical combination increases targeted blood flow, unleashes natural stimulator for maximum stimulation, triggering pleasure responses quickly. Lady V is safe, natural and doctor-recommended. Since its introduction Lady V has been taking the world by storm! From Malibu to Miami women are enjoying the most intense pleasure of their lives! • 100% Natural • Safe • The Highest Quality Pharmaceutical Pure Nutraceuticals • Guaranteed Potency • Certified Purity Lady V is Sweeping the Nation! Women are going crazy over Lady V. Suddenly couples are falling in love all over again. The passion and pleasure that women are reporting is off the charts! Lady V has an incredible 88% success rate. Best of all, while Viagra costs $10 a pill, Lady V costs less than $1 a pill! It's not just a man's world anymore! Just look at what a few women have to say: "I thought my love life was good before, but now it is out of this world! Lady V is remarkable." — Mary J., Interior Designer "I haven't smiled like this in a long time. My husband and I feel like a couple of 19 year olds again!" — Debra T, Assistant Buyer "Imagine what it would feel like to have incredible passion and pleasure anytime you want." — Jennifer C., Film Editor "Suddenly my husband and I are spending more time in the bedroom instead of the TV room." — Angie R., Realtor Ingredients: Vitamin D, Niacin, Vitamin B6, Folic Acid, Vitamin B12, Avena Sativa, Kava Kava, Guarana, White Willow Extract, Mura Puama, St. John's Wort, Siberian Ginseng, Cordyceps, Damiana, and L-Taurine. Each bottle of Lady V contains 30 tablets. Take three capsules one hour before romantic activity as a dietary supplement. Risk Free: Double Your Money Back Guarantee If Lady V does not give the desired results as stated above, simply return the unused portion for a double-your money back refund. No questions asked! Order Now: Safe, Fast, Secure, Private Lady V with its DOUBLE YOUR MONEY BACK GUARANTEE is available only through this special promotional offer. Herbal V arrives in plain packaging for your privacy. Any and all information is kept strictly confidential. Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express.payments. Money Orders are accepted only by Postal Mail. Each bottle of Lady V contains 30 tablets. Step 1: Place a check by your desired quanity. ______ 1 Bottle of Lady V $24 ______ 2 Bottles of Lady V $44 ______ 3 Bottles of Lady V $59 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$30, 2 bottles=$50, 3 bottles=$65 ] International Orders Please add $18 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$42, 2 bottles=$62, 3 bottles=$77 ] We cannot accept foreign checks. International money orders or credit cards only. Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: LSN 273 S. State Rd. 7, #193 Margate, FL 33068-5727 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: Lady V is not intended to diagnose, treat, cure or prevent any disease. As individuals differ, so will results. Lady V helps provide herbal and nutritional support for female sexual performance. The FDA has not evaluated these statements. For details about our double your money back guarantee, please write to the above address, attention consumer affairs department; enclose a self addressed stamped envelope for this and any requested contact information. Thank You. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 29 21:11:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15597 for ; Wed, 29 Nov 2000 21:11:52 -0500 (EST) Received: from standards (47.234.32.16:2102) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD0B7@standards.nortelnetworks.com>; Wed, 29 Nov 2000 20:53:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 147319 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Nov 2000 20:53:07 -0500 Received: from thalia.fm.intel.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD0B6@standards.nortelnetworks.com>; Wed, 29 Nov 2000 20:53:06 -0500 Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id CAA01768 for ; Thu, 30 Nov 2000 02:11:43 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 30 Nov 2000 02:10:24 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Nov 2000 18:10:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 29 Nov 2000 18:10:22 -0800 Reply-To: "Tulpule, Naren" Sender: "Media Gateway Control (megaco)" From: "Tulpule, Naren" Subject: Simple Q on TDM circuit package - gain format To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi list, in the TDM circuit package (tdmc), gain control (propertyID gain) has type "enumeration (integer)". It also says the parameter value can be "automatic" (0xFFFFFFFF) or any other integer value. Now when I encode/decode the message, if gain = automatic, what appears after the string "tdmc/gain = "? Is it the token "automatic" or is it the integer "4294967295" or is it the integer "0xFFFFFFFF"? -- Naren. These views and opinions are mine alone, not those of Intel (yet ;-) Narendra C. Tulpule SMTS, Trillium (an Intel company) Ph: +1-310-442-9222 Fax: +1-310-442-1162 12100 Wilshire Bl #1800 Los Angeles, CA 90025 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 29 23:36:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA08342 for ; Wed, 29 Nov 2000 23:36:29 -0500 (EST) Received: from standards (47.234.32.16:4293) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD107@standards.nortelnetworks.com>; Wed, 29 Nov 2000 23:17:45 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 147412 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Nov 2000 23:17:44 -0500 Received: from drawbridge.ascend.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD102@standards.nortelnetworks.com>; Wed, 29 Nov 2000 23:07:44 -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 UAA19348 for ; Wed, 29 Nov 2000 20:16: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; 30 Nov 2000 04:24:58 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id UAA04244 for ; Wed, 29 Nov 2000 20:24:57 -0800 (PST) Received: from lucent.com (pitbull.eng.ascend.com [135.140.26.36]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id UAA07325 for ; Wed, 29 Nov 2000 20:24:57 -0800 (PST) X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 i86pc) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A25D699.451E580D@lucent.com> Date: Wed, 29 Nov 2000 20:24:57 -0800 Reply-To: Ilya Akramovich Sender: "Media Gateway Control (megaco)" From: Ilya Akramovich Organization: Lucent Technologies, Inc. Subject: ANSI 102- 108-, etc-type tests with H.248 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi All, I remember that there was a discussion a while ago between (mostly) Brian and Tom about how to support ANSI test lines with H.248. To refresh everybody's memory, I'm talking about 102- (milliwatt), 108- (digital noninverting loopback) and, most importantly, 105-type (automatic transmission measuring system) tests. If my memory serves me, the options that were discussed were: 1. To add more states to the Termination State descriptor. 2. To create the new Termination Class "Test" that could be programmed for various tests. Then a test can be initiated by placing a DS0 termination into the "Test" state and adding it to a context with this special "Test" termination. 3. To create a separate "Test" package(s) with their own signals and events, which can then be applied to the termination under test. While #2 appeared to be the most intuitive and the closest to the way it is usually implemented, it looked like several people inclined towards #3. Then, as far as I remember, the subject was dropped "for further study" due to the lack of interest and lack of time at that time. I'd like to get back to that subject and see if there has been any progress and/or resolution on that. Is anybody still interested in support for those kinds of tests? Sincerely, -- Ilya Akramovich Tel: +1 (510) 747-2926 Sr. Software Engineer mailto:iakramov@lucent.com Lucent InterNetworking Systems http://www.lucent.com/ins From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Nov 29 23:48:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA12321 for ; Wed, 29 Nov 2000 23:48:35 -0500 (EST) Received: from standards (47.234.32.16:4293) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD131@standards.nortelnetworks.com>; Wed, 29 Nov 2000 23:29:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 147453 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Nov 2000 23:29:54 -0500 Received: from drawbridge.ascend.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD122@standards.nortelnetworks.com>; Wed, 29 Nov 2000 23:19:54 -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 UAA19762 for ; Wed, 29 Nov 2000 20:29:10 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 30 Nov 2000 04:37:13 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id UAA05667 for ; Wed, 29 Nov 2000 20:37:12 -0800 (PST) Received: from lucent.com (pitbull.eng.ascend.com [135.140.26.36]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id UAA07501 for ; Wed, 29 Nov 2000 20:37:12 -0800 (PST) X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 i86pc) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD1102DE6843@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A25D978.E6062FCE@lucent.com> Date: Wed, 29 Nov 2000 20:37:12 -0800 Reply-To: Ilya Akramovich Sender: "Media Gateway Control (megaco)" From: Ilya Akramovich Organization: Lucent Technologies, Inc. Subject: Re: I-D ACTION:draft-ietf-megaco-mib-01.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Ugh. Yes. I see that as more stuff got added, the objects in the MIB may actually need some more refinement now. Matt, I'm preparing some notes on that new draft. Should I send them to you or to the list for further follow-up? Ilya -- Ilya Akramovich Tel: (510) 747-2926 Sr. Software Engineer mailto:iakramov@lucent.com Lucent InterNetworking Systems http://www.lucent.com/ins "Taylor, Tom-PT [NORSE:B901:EXCH]" wrote: > > The Internet-Drafts search engine pulled it up this morning. > > > -----Original Message----- > > From: Matt Holdrege [mailto:matt@IPVERSE.COM] > > Sent: Tuesday, November 21, 2000 6:32 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: I-D ACTION:draft-ietf-megaco-mib-01.txt > > > > > > It works for me. Try again or go to a different ISP perhaps. > > > > > > At 04:32 PM 11/21/2000 -0500, Peter Blatherwick wrote: > > > > >Hi Matt, > > > > > >I'd definitely like to have a look, but am unable to retrieve the > > >I-D. Link below comes back with "no longer available .. > > deleted on July > > >17, 2000" (and same URL with 02 on the end also fails Not > > Found). Any > > >idea what's up with that? Is there another place to access? > > > > > >-- Peter Blatherwick > > > > > > > > >-----Original Message----- > > >From: Matt Holdrege > > [mailto:matt@IPVERSE.COM] > > >Sent: Tuesday, November 21, 2000 07:18 > > >To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > >Subject: Re: I-D ACTION:draft-ietf-megaco-mib-01.txt > > > > > >Regarding this document...As many of you know I've been > > begging for input > > >for a long time, but I've realized that we wouldn't get good > > input til > > >people started implementing the protocol. Now that that has > > happened, I'm > > >flooded with input. So unfortunately this draft isn't very > > well organized. > > >Even as I finalized this draft, a bunch more objects were > > suggested to me. > > > > > >So please review the objects in this draft and comment. Regardless of > > >further input, I have a lot of work to do to organize this > > MIB better. > > > > > >At 05:57 AM 11/21/2000 -0500, Internet-Drafts@IETF.ORG wrote: > > > >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 MIB > > > > Author(s) : M. Holdrege, I. Akramovich > > > > Filename : draft-ietf-megaco-mib-01.txt > > > > Pages : 35 > > > > Date : 20-Nov-00 > > > > > > > >This memo defines a portion of the Management Information > > Base (MIB) > > > >for use with network management protocols in the Internet > > community. > > > >In particular it defines objects for use by the MEGACO protocol > > > >operating on Media Gateways and Media Gateway Controllers. > > > > > > > >A URL for this Internet-Draft is: > > > > >http:// > > www.ietf.org/internet-drafts/draft-ietf-megaco-mib-01.txt > > > > > >Internet-Drafts are also available by anonymous FTP. Login with the > > username > > >"anonymous" and a password of your e-mail address. After logging in, > > >type "cd internet-drafts" and then > > > "get draft-ietf-megaco-mib-01.txt". > > > > > >A list of Internet-Drafts directories can be found in > > >http://www.ietf.org/shadow.html > > >or > > > ftp://ftp.ietf.org/ietf/1shadow-s > ites.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-mib-01.txt". > > > > > >NOTE: The mail server at ietf.org can return the document in > > > MIME-encoded form by using the "mpack" utility. To use this > > > feature, insert the command "ENCODING mime" before the "FILE" > > > command. To decode the response(s), you will need "munpack" or > > > a MIME-compliant mail reader. Different MIME-compliant mail > > readers > > > exhibit different behavior, especially when dealing with > > > "multipart" MIME messages (i.e. documents which have been split > > > up into multiple messages), so check your local documentation on > > > how to manipulate these messages. > > > > > > > > >Below is the data which will enable a MIME compliant mail reader > > >implementation to automatically retrieve the ASCII version of the > > >Internet-Draft. > > >Content-Type: text/plain > > >Content-ID: <20001120151500.I-D@ietf.org> > > > > > >ENCODING mime > > >FILE /internet-drafts/draft-ietf-megaco-mib-01.txt > > > > > ><ftp://f > > tp.ietf.org/internet-drafts/draft-ietf-megaco-mib-01.txt> From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 30 06:08:26 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04267 for ; Thu, 30 Nov 2000 06:08:26 -0500 (EST) Received: from standards (47.234.32.16:3770) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD214@standards.nortelnetworks.com>; Thu, 30 Nov 2000 5:49:42 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 147749 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Nov 2000 05:49:42 -0500 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD20E@standards.nortelnetworks.com>; Thu, 30 Nov 2000 5:39:42 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27889; Thu, 30 Nov 2000 05:56:59 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200011301056.FAA27889@ietf.org> Date: Thu, 30 Nov 2000 05:56:59 -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-naspkg-02.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Media Gateway Control Working Group of the IETF. Title : Megaco/H.248 NAS Package Author(s) : J. Mitchell, T. Taylor, A. Whitton, R. Subramaniam Filename : draft-ietf-megaco-naspkg-02.txt Pages : 17 Date : 29-Nov-00 This document is work in progress, intended to satisfy the requirements in section 11.2.5 of the Megaco/H.248 requirements document [5]. It defines five packages: - the base NAS package contains properties and events supported by all NAS terminations; - the NAS Incoming package contains properties and events supported by NAS terminations involved in calls initiated by the circuit network; - the NAS Outgoing package contains properties supported by NAS terminations involved in calls outgoing to the circuit network; - the NAS Control package contains an event supported by a NAS Control termination, which allows the MG to indicate a request to initiate a data connection to a terminal served by the switched circuit network; - the NAS ROOT package contains properties supported by an MG which is also capable of supporting at least the NAS and NAS Incoming packages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-naspkg-02.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-naspkg-02.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-naspkg-02.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: <20001129114519.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-megaco-naspkg-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-megaco-naspkg-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001129114519.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 30 07:11:26 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01917 for ; Thu, 30 Nov 2000 07:11:25 -0500 (EST) Received: from standards (47.234.32.16:2163) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD290@standards.nortelnetworks.com>; Thu, 30 Nov 2000 6:52:26 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 147909 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Nov 2000 06:52:26 -0500 Received: from zmers013 (47.124.1.40:48779) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD28F@standards.nortelnetworks.com>; Thu, 30 Nov 2000 6:52:16 -0500 Received: from tlhuph12.elex.co.il (actually ertpg1e0.us.nortel.com) by zmers013; Thu, 30 Nov 2000 07:09:07 -0500 Received: from tmx100.elex.co.il (tmx100.elex.co.il [141.226.8.254]) by tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA26312 for ; Thu, 30 Nov 2000 13:57:29 +0200 (IST) Received: from tl100h0c.elex.co.il by tmx100.elex.co.il (8.8.8+Sun/SMI-SVR4) id NAA10655; Thu, 30 Nov 2000 13:57:28 +0200 (IST) Received: from tmx100.elex.co.il (rakefet@localhost [127.0.0.1]) by tl100h0c.elex.co.il with ESMTP (8.8.6 (PHNE_14041)/8.7.3) id NAA12013 for ; Thu, 30 Nov 2000 13:57:27 +0200 (IST) X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A2640A1.2C638386@tmx100.elex.co.il> Date: Thu, 30 Nov 2000 13:57:21 +0200 Reply-To: "Prozan, Rakefet [LOD:Telrad:SMTPPART]" Sender: "Media Gateway Control (megaco)" From: "Prozan, Rakefet [LOD:Telrad:SMTPPART]" Organization: Telrad Ltd. Subject: Empty Signals Descriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi all, In APPENDIX A of the standard (the example) in step 17, after MG2 sends the notification of off hook to the MGC, the MGC answers with event, in which it asks the MG to monitor on hook event (and to stop the ringing). From MGC to MG2: MEGACO/1 [123.123.123.4]:55555 Transaction = 50006 { Context = 5000 { Modify = A5555 { Events = 1235 {al/on}, Signals { } ; to turn off ringing } } } My question is :why does the MGC need to send an empty signal descriptor in order to stop ringing, if according to the standard - if no keepActive param is sent on the signal, the signal stops automatically when an event happens. many thanks in advance, -- Rakefet Prozan, Team Manager, S/W Development ATS SBU Telrad Networks ESN 828-3043 Email:rakefet.prozan@telrad.co.il """ -(o o)- +---------------------------------oOO--(_)--OOo--------------+ .oooO Oooo. -------------------------------( )---------( )------------ \ ( ) / \_) (_/ Have fun !!! From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 30 17:26:33 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21298 for ; Thu, 30 Nov 2000 17:26:32 -0500 (EST) Received: from standards (47.234.32.16:2349) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD733@standards.nortelnetworks.com>; Thu, 30 Nov 2000 17:07:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 149497 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Nov 2000 17:07:34 -0500 Received: from mail.cn.prospectful.com (szptt103-148.szptt.net.cn) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD730@standards.nortelnetworks.com>; Thu, 30 Nov 2000 16:57:30 -0500 Received: from 1Cust54.tnt1.mia5.da.uu.net by mail.cn.prospectful.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id XR676HGN; Fri, 1 Dec 2000 06:14:45 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Message-ID: Date: Thu, 30 Nov 2000 17:07:34 -0500 Reply-To: Younger@BDSM.AT Sender: "Media Gateway Control (megaco)" From: Younger@BDSM.AT Subject: REVERSE the AGING PROCESS 10-20 Years! To: MEGACO@STANDARDS.NORTELNETWORKS.COM HAVE YOU HEARD OF HUMAN GROWTH HORMONE (HGH)??? Released by your own pituitary gland, HGH starts declining in your 20s, even more in your 30s and 40s, eventually resulting in the shrinkage of major organs-plus all other symptoms related to old age. THIS CAN NOW BE REVERSED!!! IN THOUSANDS OF CLINICAL STUDIES, HGH HAS BEEN SHOWN TO ACCOMPLISH THE FOLLOWING: * Reduce Body Fat Without Dieting Build Lean Muscle WITHOUT EXERCISE! * Enhance Sexual Performance * Remove Wrinkles and Cellulite * Lower Blood Pressure and improve Cholesterol Profile * Improve Sleep, Vision and Memory * Restore Hair Color and Growth * Strengthen the Immune System * Increase Energy and Cardiac Output * Turn back your body's Biological Time Clock 10-20 years in 6 months of usage !!! You don't have to spend thousands of dollars on shots. You don't have to spend the $139.00 per bottle that HGH is selling for at some Clinics in the United States. For the next 30 Days, you can obtain a complete one-month supply of our HGH releaser for our special "New Customers" price of just $69.95 plus $6.00 shipping and handling. To ensure a constant supply and to SAVE EVEN MORE, you can order with confidence 3 bottles of HGH and GET 1 FREE - that's just $209.85 for 4 bottles, plus $6.00 shipping and handling. You SAVE $69.95! ORDER TODAY! Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express payments. Money Orders are accepted only by Postal Mail. Step 1: Place a check by your desired quanity. ______ 1 Bottle of HGH $69.95 ______ 2 Bottles of HGH $131.90 ($65.95 a bottle) ______ 4 Bottles of HGH (Buy 3 get 1 FREE. SAVE $69.95) $209.85 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$75.95, 2 bottles=$137.90, 4 bottles=$215.85 ] International shipping, please add $35 for any size order [ Total cost including shipping & handling, 1 bottle=$104.95, 2 bottles=$166.90, 4 bottles=$244.85 ] Foreign checks are not accepted. Credit cards & international money orders only. Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: Lion Sciences National 273 S. State Rd. 7 #193 Margate, FL 33068-5727 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: HGH is not intended to diagnose, treat, cure or prevent any disease. The FDA has not evaluated these statements. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Nov 30 19:21:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18822 for ; Thu, 30 Nov 2000 19:21:11 -0500 (EST) Received: from standards (47.234.32.16:1396) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD91F@standards.nortelnetworks.com>; Thu, 30 Nov 2000 19:02:11 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 150139 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Nov 2000 19:02:11 -0500 Received: from thalia.fm.intel.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBD91E@standards.nortelnetworks.com>; Thu, 30 Nov 2000 19:02:11 -0500 Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id AAA19470 for ; Fri, 1 Dec 2000 00:20:50 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 01 Dec 2000 00:19:30 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 16:19:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 30 Nov 2000 16:14:25 -0800 Reply-To: "Tulpule, Naren" Sender: "Media Gateway Control (megaco)" From: "Tulpule, Naren" Subject: NAS root package 'nampat' To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi list, Tom, Section 9.1.1 of naspkg-02.txt draft defines nampat with type 'terminationIDlist'. Is this for each VALUE or for "parmValue"? In other words, can we expect nasroot/nampat followed by a list of a list of termination IDs? Something like nasroot/nampat = { {ROOT, *}, {abc*, def*} } or will it be a single list of termination IDs? If latter, type should be renamed to 'terminationID' and not 'terminationIDlist'. -- Naren. These views and opinions are mine alone, not those of Intel (yet ;-) Narendra C. Tulpule SMTS, Trillium (an Intel company) Ph: +1-310-442-9222 Fax: +1-310-442-1162 12100 Wilshire Bl #1800 Los Angeles, CA 90025