From mailman-admin@ietf.org Sat Feb 1 10:33:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08642 for ; Sat, 1 Feb 2003 10:33:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h11FbPJ09938 for ; Sat, 1 Feb 2003 10:37:25 -0500 Date: Sat, 01 Feb 2003 10:37:25 -0500 Message-ID: <20030201153725.8821.23549.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: megaco-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, megaco-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for megaco-archive@lists.ietf.org: List Password // URL ---- -------- megaco@ietf.org rFKd https://www1.ietf.org/mailman/options/megaco/megaco-archive%40lists.ietf.org From megaco-admin@ietf.org Mon Feb 3 04:52:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01700 for ; Mon, 3 Feb 2003 04:52:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h139trJ06692; Mon, 3 Feb 2003 04:55:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h139qRJ06585 for ; Mon, 3 Feb 2003 04:52:27 -0500 Received: from spf1.us.outblaze.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01639 for ; Mon, 3 Feb 2003 04:47:00 -0500 (EST) Received: (qmail 15038 invoked from network); 3 Feb 2003 09:50:37 -0000 Received: from unknown (205.158.62.146) by spf1.us.outblaze.com with QMQP; 3 Feb 2003 09:50:37 -0000 Received: (qmail 3928 invoked from network); 3 Feb 2003 09:49:00 -0000 Received: from unknown (HELO ws3-3.us4.outblaze.com) (205.158.62.93) by 205-158-62-146.outblaze.com with SMTP; 3 Feb 2003 09:49:00 -0000 Received: (qmail 11713 invoked by uid 1001); 3 Feb 2003 09:50:32 -0000 Message-ID: <20030203095032.11712.qmail@email.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [202.134.200.4] by ws3-3.us4.outblaze.com with http for harry_suede@email.com; Mon, 03 Feb 2003 04:50:32 -0500 From: "Harry Suede" To: megaco@ietf.org, taylor@nortelnetworks.com Date: Mon, 03 Feb 2003 04:50:32 -0500 X-Originating-Ip: 202.134.200.4 X-Originating-Server: ws3-3.us4.outblaze.com Content-Transfer-Encoding: 7bit Subject: [Megaco] Descriptor state after out of service Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi list, Tom What is the state of descriptor of a termination in a non-null context when termination is put “out of service” by MGC or MG? Does the descriptor remain on termination database but inactivated or does they are total flushed. Thus if this termination is put “out of service” by MGC or MG then what will be the state of descriptor i.e. they are reapply/reactivated on the termination or not. regards harry -- _______________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Meet Singles http://corp.mail.com/lavalife _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Feb 3 04:53:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01722 for ; Mon, 3 Feb 2003 04:53:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h139vvI06837 for megaco-archive@odin.ietf.org; Mon, 3 Feb 2003 04:57:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h139vvJ06834 for ; Mon, 3 Feb 2003 04:57:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01709 for ; Mon, 3 Feb 2003 04:52:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h139trJ06692; Mon, 3 Feb 2003 04:55:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h139qRJ06585 for ; Mon, 3 Feb 2003 04:52:27 -0500 Received: from spf1.us.outblaze.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01639 for ; Mon, 3 Feb 2003 04:47:00 -0500 (EST) Received: (qmail 15038 invoked from network); 3 Feb 2003 09:50:37 -0000 Received: from unknown (205.158.62.146) by spf1.us.outblaze.com with QMQP; 3 Feb 2003 09:50:37 -0000 Received: (qmail 3928 invoked from network); 3 Feb 2003 09:49:00 -0000 Received: from unknown (HELO ws3-3.us4.outblaze.com) (205.158.62.93) by 205-158-62-146.outblaze.com with SMTP; 3 Feb 2003 09:49:00 -0000 Received: (qmail 11713 invoked by uid 1001); 3 Feb 2003 09:50:32 -0000 Message-ID: <20030203095032.11712.qmail@email.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [202.134.200.4] by ws3-3.us4.outblaze.com with http for harry_suede@email.com; Mon, 03 Feb 2003 04:50:32 -0500 From: "Harry Suede" To: megaco@ietf.org, taylor@nortelnetworks.com Date: Mon, 03 Feb 2003 04:50:32 -0500 X-Originating-Ip: 202.134.200.4 X-Originating-Server: ws3-3.us4.outblaze.com Content-Transfer-Encoding: 7bit Subject: [Megaco] Descriptor state after out of service Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi list, Tom What is the state of descriptor of a termination in a non-null context when termination is put “out of service” by MGC or MG? Does the descriptor remain on termination database but inactivated or does they are total flushed. Thus if this termination is put “out of service” by MGC or MG then what will be the state of descriptor i.e. they are reapply/reactivated on the termination or not. regards harry -- _______________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Meet Singles http://corp.mail.com/lavalife _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Feb 3 05:41:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02288 for ; Mon, 3 Feb 2003 05:41:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13AiSJ10261; Mon, 3 Feb 2003 05:44:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13AhlJ10234 for ; Mon, 3 Feb 2003 05:43:47 -0500 Received: from spf1.us.outblaze.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02263 for ; Mon, 3 Feb 2003 05:38:21 -0500 (EST) Received: (qmail 7196 invoked from network); 3 Feb 2003 10:41:56 -0000 Received: from unknown (205.158.62.146) by spf1.us.outblaze.com with QMQP; 3 Feb 2003 10:41:56 -0000 Received: (qmail 26145 invoked from network); 3 Feb 2003 10:40:23 -0000 Received: from unknown (HELO ws3-4.us4.outblaze.com) (205.158.62.94) by 205-158-62-146.outblaze.com with SMTP; 3 Feb 2003 10:40:23 -0000 Received: (qmail 5721 invoked by uid 1001); 3 Feb 2003 10:41:56 -0000 Message-ID: <20030203104156.5720.qmail@email.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [202.134.200.4] by ws3-4.us4.outblaze.com with http for harry_suede@email.com; Mon, 03 Feb 2003 05:41:56 -0500 From: "Harry Suede" To: megaco@ietf.org, taylor@nortelnetworks.com Date: Mon, 03 Feb 2003 05:41:56 -0500 X-Originating-Ip: 202.134.200.4 X-Originating-Server: ws3-4.us4.outblaze.com Content-Transfer-Encoding: 7bit Subject: [Megaco] Descriptor state after out of service Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi list, Tom PL ignore my previous mail. By mistake I have written "out of service" in place of "in service" in the last line. What is the state of descriptor of a termination in a non-null context when termination is put "out of service" by MGC or MG? Does the descriptor remain on termination database but inactivated or does they are total flushed. Thus if this termination is put "in service" by MGC or MG then what will be the state of descriptor i.e. they are reapply/reactivated on the termination or not. regards harry -- _______________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Meet Singles http://corp.mail.com/lavalife _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Feb 3 05:41:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02308 for ; Mon, 3 Feb 2003 05:41:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13AkWi10342 for megaco-archive@odin.ietf.org; Mon, 3 Feb 2003 05:46:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13AkWJ10339 for ; Mon, 3 Feb 2003 05:46:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02293 for ; Mon, 3 Feb 2003 05:41:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13AiSJ10261; Mon, 3 Feb 2003 05:44:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13AhlJ10234 for ; Mon, 3 Feb 2003 05:43:47 -0500 Received: from spf1.us.outblaze.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02263 for ; Mon, 3 Feb 2003 05:38:21 -0500 (EST) Received: (qmail 7196 invoked from network); 3 Feb 2003 10:41:56 -0000 Received: from unknown (205.158.62.146) by spf1.us.outblaze.com with QMQP; 3 Feb 2003 10:41:56 -0000 Received: (qmail 26145 invoked from network); 3 Feb 2003 10:40:23 -0000 Received: from unknown (HELO ws3-4.us4.outblaze.com) (205.158.62.94) by 205-158-62-146.outblaze.com with SMTP; 3 Feb 2003 10:40:23 -0000 Received: (qmail 5721 invoked by uid 1001); 3 Feb 2003 10:41:56 -0000 Message-ID: <20030203104156.5720.qmail@email.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [202.134.200.4] by ws3-4.us4.outblaze.com with http for harry_suede@email.com; Mon, 03 Feb 2003 05:41:56 -0500 From: "Harry Suede" To: megaco@ietf.org, taylor@nortelnetworks.com Date: Mon, 03 Feb 2003 05:41:56 -0500 X-Originating-Ip: 202.134.200.4 X-Originating-Server: ws3-4.us4.outblaze.com Content-Transfer-Encoding: 7bit Subject: [Megaco] Descriptor state after out of service Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi list, Tom PL ignore my previous mail. By mistake I have written "out of service" in place of "in service" in the last line. What is the state of descriptor of a termination in a non-null context when termination is put "out of service" by MGC or MG? Does the descriptor remain on termination database but inactivated or does they are total flushed. Thus if this termination is put "in service" by MGC or MG then what will be the state of descriptor i.e. they are reapply/reactivated on the termination or not. regards harry -- _______________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Meet Singles http://corp.mail.com/lavalife _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Feb 3 05:52:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02443 for ; Mon, 3 Feb 2003 05:52:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13AthJ10752; Mon, 3 Feb 2003 05:55:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13AsiJ10694 for ; Mon, 3 Feb 2003 05:54:44 -0500 Received: from ish7.ericsson.com.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02418 for ; Mon, 3 Feb 2003 05:49:16 -0500 (EST) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id h13Aobx15946; Mon, 3 Feb 2003 21:50:37 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h135Ipj29344; Mon, 3 Feb 2003 16:18:51 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.194]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DZ358V5Y; Mon, 3 Feb 2003 16:18:51 +1100 Message-ID: <3E3DE32C.CD8275BB@ericsson.com.au> Date: Mon, 03 Feb 2003 14:34:04 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: shbansal@hss.hns.com CC: megaco@ietf.org References: <65256CBE.0047CB86.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] Re: Topology Descriptor Processing Logic Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Shobhit, As everything is fully specified I believe it is your first description. Christian shbansal@hss.hns.com wrote: > > Hi Chris, > > I have gone through the mailing list discussions > But I still have some doubts in topology descriptor procressing > I will be really very thankful and obliged if you help in resolving them > > Assuming that we have a context C1 with terminations T1, T2 and T3 > and command comes like > > Action C1 Topolgy ( T1, T3, Isolate) > Command Modify T1 > Command Modify T2 > > In this case: > > Will the topology (T1, T3, Isolate) be applied before the > command execution starts i.e. tuples of specified terminations > will get applied before any command execution starts. > If this understanding is correct, topology will get applied > before execution of MODIFY T1 > > OR > > Will the topology application be deffered till the command > execution starts for the respective terminations that are present in tuples. > If this understanding is correct, after MODIFY T1 gets executed, > topology would be applied in conjunction thereof. > Further after that, MODIFY T2 will get executed. > > Thanking you in advance > Shobhit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Feb 3 05:52:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02465 for ; Mon, 3 Feb 2003 05:52:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13AvlH10837 for megaco-archive@odin.ietf.org; Mon, 3 Feb 2003 05:57:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13AvkJ10834 for ; Mon, 3 Feb 2003 05:57:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02453 for ; Mon, 3 Feb 2003 05:52:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13AthJ10752; Mon, 3 Feb 2003 05:55:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13AsiJ10694 for ; Mon, 3 Feb 2003 05:54:44 -0500 Received: from ish7.ericsson.com.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02418 for ; Mon, 3 Feb 2003 05:49:16 -0500 (EST) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id h13Aobx15946; Mon, 3 Feb 2003 21:50:37 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h135Ipj29344; Mon, 3 Feb 2003 16:18:51 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.194]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DZ358V5Y; Mon, 3 Feb 2003 16:18:51 +1100 Message-ID: <3E3DE32C.CD8275BB@ericsson.com.au> Date: Mon, 03 Feb 2003 14:34:04 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: shbansal@hss.hns.com CC: megaco@ietf.org References: <65256CBE.0047CB86.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] Re: Topology Descriptor Processing Logic Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Shobhit, As everything is fully specified I believe it is your first description. Christian shbansal@hss.hns.com wrote: > > Hi Chris, > > I have gone through the mailing list discussions > But I still have some doubts in topology descriptor procressing > I will be really very thankful and obliged if you help in resolving them > > Assuming that we have a context C1 with terminations T1, T2 and T3 > and command comes like > > Action C1 Topolgy ( T1, T3, Isolate) > Command Modify T1 > Command Modify T2 > > In this case: > > Will the topology (T1, T3, Isolate) be applied before the > command execution starts i.e. tuples of specified terminations > will get applied before any command execution starts. > If this understanding is correct, topology will get applied > before execution of MODIFY T1 > > OR > > Will the topology application be deffered till the command > execution starts for the respective terminations that are present in tuples. > If this understanding is correct, after MODIFY T1 gets executed, > topology would be applied in conjunction thereof. > Further after that, MODIFY T2 will get executed. > > Thanking you in advance > Shobhit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Feb 3 07:22:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05622 for ; Mon, 3 Feb 2003 07:22:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13CQ2J16955; Mon, 3 Feb 2003 07:26:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13CNnJ16814 for ; Mon, 3 Feb 2003 07:23:49 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05228 for ; Mon, 3 Feb 2003 07:18:18 -0500 (EST) From: knayar@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h13CKUj03443 for ; Mon, 3 Feb 2003 17:50:30 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h13CKSM03433 for ; Mon, 3 Feb 2003 17:50:28 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h13CMo929667 for ; Mon, 3 Feb 2003 17:52:50 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CC2.00433A81 ; Mon, 3 Feb 2003 17:44:18 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CC2.0043394B.00@sandesh.hss.hns.com> Date: Mon, 3 Feb 2003 17:49:10 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Cancel Service Change (method=Graceful) mechanism Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi It seems the protocol doesnot define any procedure for cancelling an earlier Service Change (method=Graceful) on a non-root termination. Taking a practical case: MG sends a Service Change (method=Graceful) on a termination with delay= 2 hours. After 1 hour, MG realizes that it doesn't want to put the termination out-of-service (after remaining 1 hour) as was earlier intended. How to inform the MGC of the new intentions - cancel graceful..? Sending Service Change (method =Restart) would mean that termination just came InService and doesnot have any active descriptors, whereas this is not the case. Solution: MG sends Service Change (method = Graceful) delay =2 hours to inform MGC only about the intentions. MG sends Service Change (method = Forced) when the termination actually goes out-of-service after 2 hours. This ensures that if Service Change (method = Forced) never came, the intentions of MG never got materialised. Does any body have an alternative solution? Please suggest. thanks, kapil nayar www.hssworld.com DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Feb 3 07:23:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05641 for ; Mon, 3 Feb 2003 07:23:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13CSJ317066 for megaco-archive@odin.ietf.org; Mon, 3 Feb 2003 07:28:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13CSJJ17063 for ; Mon, 3 Feb 2003 07:28:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05626 for ; Mon, 3 Feb 2003 07:22:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13CQ2J16955; Mon, 3 Feb 2003 07:26:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13CNnJ16814 for ; Mon, 3 Feb 2003 07:23:49 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05228 for ; Mon, 3 Feb 2003 07:18:18 -0500 (EST) From: knayar@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h13CKUj03443 for ; Mon, 3 Feb 2003 17:50:30 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h13CKSM03433 for ; Mon, 3 Feb 2003 17:50:28 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h13CMo929667 for ; Mon, 3 Feb 2003 17:52:50 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CC2.00433A81 ; Mon, 3 Feb 2003 17:44:18 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CC2.0043394B.00@sandesh.hss.hns.com> Date: Mon, 3 Feb 2003 17:49:10 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Cancel Service Change (method=Graceful) mechanism Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi It seems the protocol doesnot define any procedure for cancelling an earlier Service Change (method=Graceful) on a non-root termination. Taking a practical case: MG sends a Service Change (method=Graceful) on a termination with delay= 2 hours. After 1 hour, MG realizes that it doesn't want to put the termination out-of-service (after remaining 1 hour) as was earlier intended. How to inform the MGC of the new intentions - cancel graceful..? Sending Service Change (method =Restart) would mean that termination just came InService and doesnot have any active descriptors, whereas this is not the case. Solution: MG sends Service Change (method = Graceful) delay =2 hours to inform MGC only about the intentions. MG sends Service Change (method = Forced) when the termination actually goes out-of-service after 2 hours. This ensures that if Service Change (method = Forced) never came, the intentions of MG never got materialised. Does any body have an alternative solution? Please suggest. thanks, kapil nayar www.hssworld.com DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Feb 3 09:47:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08882 for ; Mon, 3 Feb 2003 09:47:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13EoEJ26784; Mon, 3 Feb 2003 09:50:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13EmGJ26668 for ; Mon, 3 Feb 2003 09:48:16 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08824 for ; Mon, 3 Feb 2003 09:42:39 -0500 (EST) From: prjain@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h13Eiqj20314 for ; Mon, 3 Feb 2003 20:14:52 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h13EipM20310; Mon, 3 Feb 2003 20:14:51 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h13ElBX06428; Mon, 3 Feb 2003 20:17:12 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CC2.0050715F ; Mon, 3 Feb 2003 20:08:39 +0530 X-Lotus-FromDomain: HSS To: Christian Groves cc: shbansal@hss.hns.com, megaco@ietf.org Message-ID: <65256CC2.00506FA5.00@sandesh.hss.hns.com> Date: Mon, 3 Feb 2003 20:13:29 +0530 Subject: Re: [Megaco] Re: Topology Descriptor Processing Logic Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Christian/list, Thanks a lot for clarifying all the doubts. In addition to what you have said, I have two more questions as asked below. I beg your pardon in case these questions have already been discussed or asked on the list before. <> You have told that in case the topology tuple happens to be fully specified (except $), the topology descriptor would be executed first (at the action level befoe any command processing starts, even though the protocol command like ADD or MODIFY with fully-specified terminations were there in the context further, for the corresponding terminations in the topology tuples). If the above statement holds true, does it imply that the topology descriptor would always be first descriptor in the entire descriptor processing sequence that would get executed, taking into account the other descriptors processing like events, signals, stream descriptors (for all descriptors except topology, the processing sequence can be specified by MGC) etc. ?? Is this implication about the "sequence of processing" valid whether MG executes topology descriptor at the action level or at the command level (in case of ADD $) ?? <> Thanks and Regards, Prashant Jain Christian Groves on 02/03/2003 08:34:04 AM To: Shobhit Bansal/HSS@HSS cc: megaco@ietf.org (bcc: Prashant Jain/HSS) Subject: [Megaco] Re: Topology Descriptor Processing Logic Hello Shobhit, As everything is fully specified I believe it is your first description. Christian shbansal@hss.hns.com wrote: > > Hi Chris, > > I have gone through the mailing list discussions > But I still have some doubts in topology descriptor procressing > I will be really very thankful and obliged if you help in resolving them > > Assuming that we have a context C1 with terminations T1, T2 and T3 > and command comes like > > Action C1 Topolgy ( T1, T3, Isolate) > Command Modify T1 > Command Modify T2 > > In this case: > > Will the topology (T1, T3, Isolate) be applied before the > command execution starts i.e. tuples of specified terminations > will get applied before any command execution starts. > If this understanding is correct, topology will get applied > before execution of MODIFY T1 > > OR > > Will the topology application be deffered till the command > execution starts for the respective terminations that are present in tuples. > If this understanding is correct, after MODIFY T1 gets executed, > topology would be applied in conjunction thereof. > Further after that, MODIFY T2 will get executed. > > Thanking you in advance > Shobhit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Feb 3 09:48:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08906 for ; Mon, 3 Feb 2003 09:48:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13Er1j26878 for megaco-archive@odin.ietf.org; Mon, 3 Feb 2003 09:53:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13Er0J26875 for ; Mon, 3 Feb 2003 09:53:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08893 for ; Mon, 3 Feb 2003 09:47:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13EoEJ26784; Mon, 3 Feb 2003 09:50:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13EmGJ26668 for ; Mon, 3 Feb 2003 09:48:16 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08824 for ; Mon, 3 Feb 2003 09:42:39 -0500 (EST) From: prjain@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h13Eiqj20314 for ; Mon, 3 Feb 2003 20:14:52 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h13EipM20310; Mon, 3 Feb 2003 20:14:51 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h13ElBX06428; Mon, 3 Feb 2003 20:17:12 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CC2.0050715F ; Mon, 3 Feb 2003 20:08:39 +0530 X-Lotus-FromDomain: HSS To: Christian Groves cc: shbansal@hss.hns.com, megaco@ietf.org Message-ID: <65256CC2.00506FA5.00@sandesh.hss.hns.com> Date: Mon, 3 Feb 2003 20:13:29 +0530 Subject: Re: [Megaco] Re: Topology Descriptor Processing Logic Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Christian/list, Thanks a lot for clarifying all the doubts. In addition to what you have said, I have two more questions as asked below. I beg your pardon in case these questions have already been discussed or asked on the list before. <> You have told that in case the topology tuple happens to be fully specified (except $), the topology descriptor would be executed first (at the action level befoe any command processing starts, even though the protocol command like ADD or MODIFY with fully-specified terminations were there in the context further, for the corresponding terminations in the topology tuples). If the above statement holds true, does it imply that the topology descriptor would always be first descriptor in the entire descriptor processing sequence that would get executed, taking into account the other descriptors processing like events, signals, stream descriptors (for all descriptors except topology, the processing sequence can be specified by MGC) etc. ?? Is this implication about the "sequence of processing" valid whether MG executes topology descriptor at the action level or at the command level (in case of ADD $) ?? <> Thanks and Regards, Prashant Jain Christian Groves on 02/03/2003 08:34:04 AM To: Shobhit Bansal/HSS@HSS cc: megaco@ietf.org (bcc: Prashant Jain/HSS) Subject: [Megaco] Re: Topology Descriptor Processing Logic Hello Shobhit, As everything is fully specified I believe it is your first description. Christian shbansal@hss.hns.com wrote: > > Hi Chris, > > I have gone through the mailing list discussions > But I still have some doubts in topology descriptor procressing > I will be really very thankful and obliged if you help in resolving them > > Assuming that we have a context C1 with terminations T1, T2 and T3 > and command comes like > > Action C1 Topolgy ( T1, T3, Isolate) > Command Modify T1 > Command Modify T2 > > In this case: > > Will the topology (T1, T3, Isolate) be applied before the > command execution starts i.e. tuples of specified terminations > will get applied before any command execution starts. > If this understanding is correct, topology will get applied > before execution of MODIFY T1 > > OR > > Will the topology application be deffered till the command > execution starts for the respective terminations that are present in tuples. > If this understanding is correct, after MODIFY T1 gets executed, > topology would be applied in conjunction thereof. > Further after that, MODIFY T2 will get executed. > > Thanking you in advance > Shobhit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Feb 3 09:59:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09295 for ; Mon, 3 Feb 2003 09:59:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13F2QJ27352; Mon, 3 Feb 2003 10:02:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13F1OJ27297 for ; Mon, 3 Feb 2003 10:01:24 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09112 for ; Mon, 3 Feb 2003 09:55:51 -0500 (EST) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h13EwYs23298; Mon, 3 Feb 2003 09:58:34 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1DG5HLFL; Mon, 3 Feb 2003 09:58:34 -0500 Received: from nortelnetworks.com (acart1d1.ca.nortel.com [47.129.129.77]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1NC1L4; Mon, 3 Feb 2003 09:58:35 -0500 Message-ID: <3E3E8398.8020105@nortelnetworks.com> Date: Mon, 03 Feb 2003 09:58:32 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Harry Suede CC: megaco@ietf.org References: <20030203104156.5720.qmail@email.com> In-Reply-To: <20030203104156.5720.qmail@email.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] Re: Descriptor state after out of service Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I don't believe the ServiceChange action does anything to the descriptors on its own. It is up to the MGC to reset them if necessary. I do have the feeling that we might want to analyze the situation and possibly refine it. Harry Suede wrote: > Hi list, Tom > > PL ignore my previous mail. By mistake I have written "out of service" in place of "in service" in the last line. > > What is the state of descriptor of a termination in a non-null context when termination is put "out of service" by MGC or MG? Does the descriptor remain on termination database but inactivated or does they are total flushed. Thus if this termination is put "in service" by MGC or MG then what will be the state of descriptor i.e. they are reapply/reactivated on the termination or not. > > regards > harry _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Feb 3 09:59:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09384 for ; Mon, 3 Feb 2003 09:59:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13F50T27496 for megaco-archive@odin.ietf.org; Mon, 3 Feb 2003 10:05:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13F50J27492 for ; Mon, 3 Feb 2003 10:05:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09312 for ; Mon, 3 Feb 2003 09:59:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13F2QJ27352; Mon, 3 Feb 2003 10:02:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13F1OJ27297 for ; Mon, 3 Feb 2003 10:01:24 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09112 for ; Mon, 3 Feb 2003 09:55:51 -0500 (EST) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h13EwYs23298; Mon, 3 Feb 2003 09:58:34 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1DG5HLFL; Mon, 3 Feb 2003 09:58:34 -0500 Received: from nortelnetworks.com (acart1d1.ca.nortel.com [47.129.129.77]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1NC1L4; Mon, 3 Feb 2003 09:58:35 -0500 Message-ID: <3E3E8398.8020105@nortelnetworks.com> Date: Mon, 03 Feb 2003 09:58:32 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Harry Suede CC: megaco@ietf.org References: <20030203104156.5720.qmail@email.com> In-Reply-To: <20030203104156.5720.qmail@email.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] Re: Descriptor state after out of service Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I don't believe the ServiceChange action does anything to the descriptors on its own. It is up to the MGC to reset them if necessary. I do have the feeling that we might want to analyze the situation and possibly refine it. Harry Suede wrote: > Hi list, Tom > > PL ignore my previous mail. By mistake I have written "out of service" in place of "in service" in the last line. > > What is the state of descriptor of a termination in a non-null context when termination is put "out of service" by MGC or MG? Does the descriptor remain on termination database but inactivated or does they are total flushed. Thus if this termination is put "in service" by MGC or MG then what will be the state of descriptor i.e. they are reapply/reactivated on the termination or not. > > regards > harry _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Feb 3 10:24:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10284 for ; Mon, 3 Feb 2003 10:24:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13FRmJ29388; Mon, 3 Feb 2003 10:27:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13FQ3J29298 for ; Mon, 3 Feb 2003 10:26:03 -0500 Received: from genius.empirix.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10001 for ; Mon, 3 Feb 2003 10:20:30 -0500 (EST) Received: from kappa.midnight.com (kappa.empirix.com [10.4.0.10]) by genius.empirix.com (Postfix) with ESMTP id 3BD7E11091C for ; Mon, 3 Feb 2003 10:24:07 -0500 (EST) Received: by kappa.empirix.com with Internet Mail Service (5.5.2655.55) id <11C15A3L>; Mon, 3 Feb 2003 10:21:25 -0500 Message-ID: <5CB426A04E141C499676B19B6CF3DE571D0D2E@kappa.empirix.com> From: "Garber, Zeev" To: megaco@ietf.org Date: Mon, 3 Feb 2003 10:21:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain Subject: [Megaco] Binary Term ID format Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi All, Termination Id in binary encoding has a wildcard field separated from termination id itself. The wildcard field is not an optional parameter. What should be the value of this field in case of fixed Termination Id? Or should it disappear in this case? Thanks, Ze'ev Garber Software Engineer Communications Infrastructure Test Group p| 978.661.1211 f| 978.988.0148 m| 978.661.4800 email | zgarber@empirix.com 205 Lowell Street | Wilmington, MA | 01887 E M P I R I X www.empirix.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Feb 3 10:25:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10304 for ; Mon, 3 Feb 2003 10:25:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13FUAD29494 for megaco-archive@odin.ietf.org; Mon, 3 Feb 2003 10:30:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13FUAJ29491 for ; Mon, 3 Feb 2003 10:30:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10298 for ; Mon, 3 Feb 2003 10:24:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13FRmJ29388; Mon, 3 Feb 2003 10:27:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13FQ3J29298 for ; Mon, 3 Feb 2003 10:26:03 -0500 Received: from genius.empirix.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10001 for ; Mon, 3 Feb 2003 10:20:30 -0500 (EST) Received: from kappa.midnight.com (kappa.empirix.com [10.4.0.10]) by genius.empirix.com (Postfix) with ESMTP id 3BD7E11091C for ; Mon, 3 Feb 2003 10:24:07 -0500 (EST) Received: by kappa.empirix.com with Internet Mail Service (5.5.2655.55) id <11C15A3L>; Mon, 3 Feb 2003 10:21:25 -0500 Message-ID: <5CB426A04E141C499676B19B6CF3DE571D0D2E@kappa.empirix.com> From: "Garber, Zeev" To: megaco@ietf.org Date: Mon, 3 Feb 2003 10:21:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain Subject: [Megaco] Binary Term ID format Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi All, Termination Id in binary encoding has a wildcard field separated from termination id itself. The wildcard field is not an optional parameter. What should be the value of this field in case of fixed Termination Id? Or should it disappear in this case? Thanks, Ze'ev Garber Software Engineer Communications Infrastructure Test Group p| 978.661.1211 f| 978.988.0148 m| 978.661.4800 email | zgarber@empirix.com 205 Lowell Street | Wilmington, MA | 01887 E M P I R I X www.empirix.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Feb 3 14:20:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18125 for ; Mon, 3 Feb 2003 14:20:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13JOlJ18049; Mon, 3 Feb 2003 14:24:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13JMOJ17868 for ; Mon, 3 Feb 2003 14:22:24 -0500 Received: from zrtps0kn.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17969 for ; Mon, 3 Feb 2003 14:16:47 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h13JKMt21182 for ; Mon, 3 Feb 2003 14:20:22 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1DC5YTSL>; Mon, 3 Feb 2003 14:20:23 -0500 Message-ID: From: "Kevin Boyle" To: knayar@hss.hns.com, megaco@ietf.org Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Date: Mon, 3 Feb 2003 14:20:20 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Comments inline. [KJBII] Kevin -----Original Message----- From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] Sent: Monday, February 03, 2003 7:19 AM To: megaco@ietf.org Subject: [Megaco] Cancel Service Change (method=Graceful) mechanism Hi It seems the protocol doesnot define any procedure for cancelling an earlier Service Change (method=Graceful) on a non-root termination. Taking a practical case: MG sends a Service Change (method=Graceful) on a termination with delay= 2 hours. After 1 hour, MG realizes that it doesn't want to put the termination out-of-service (after remaining 1 hour) as was earlier intended. How to inform the MGC of the new intentions - cancel graceful..? Sending Service Change (method =Restart) would mean that termination just came InService and doesnot have any active descriptors, whereas this is not the case. [KJBII] Why can't you use SC Restart? The Warm Boot SC Reason indicates that there was NO loss of state. Solution: MG sends Service Change (method = Graceful) delay =2 hours to inform MGC only about the intentions. MG sends Service Change (method = Forced) when the termination actually goes out-of-service after 2 hours. This ensures that if Service Change (method = Forced) never came, the intentions of MG never got materialised. [KJBII] Ick. So we will be required to send TWO SCs instead of one if we use SC Graceful? I really don't like that idea. Does any body have an alternative solution? Please suggest. thanks, kapil nayar www.hssworld.com DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Feb 3 14:21:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18170 for ; Mon, 3 Feb 2003 14:21:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13JQb318201 for megaco-archive@odin.ietf.org; Mon, 3 Feb 2003 14:26:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13JQbJ18198 for ; Mon, 3 Feb 2003 14:26:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18134 for ; Mon, 3 Feb 2003 14:21:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13JOlJ18049; Mon, 3 Feb 2003 14:24:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13JMOJ17868 for ; Mon, 3 Feb 2003 14:22:24 -0500 Received: from zrtps0kn.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17969 for ; Mon, 3 Feb 2003 14:16:47 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h13JKMt21182 for ; Mon, 3 Feb 2003 14:20:22 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1DC5YTSL>; Mon, 3 Feb 2003 14:20:23 -0500 Message-ID: From: "Kevin Boyle" To: knayar@hss.hns.com, megaco@ietf.org Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Date: Mon, 3 Feb 2003 14:20:20 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Comments inline. [KJBII] Kevin -----Original Message----- From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] Sent: Monday, February 03, 2003 7:19 AM To: megaco@ietf.org Subject: [Megaco] Cancel Service Change (method=Graceful) mechanism Hi It seems the protocol doesnot define any procedure for cancelling an earlier Service Change (method=Graceful) on a non-root termination. Taking a practical case: MG sends a Service Change (method=Graceful) on a termination with delay= 2 hours. After 1 hour, MG realizes that it doesn't want to put the termination out-of-service (after remaining 1 hour) as was earlier intended. How to inform the MGC of the new intentions - cancel graceful..? Sending Service Change (method =Restart) would mean that termination just came InService and doesnot have any active descriptors, whereas this is not the case. [KJBII] Why can't you use SC Restart? The Warm Boot SC Reason indicates that there was NO loss of state. Solution: MG sends Service Change (method = Graceful) delay =2 hours to inform MGC only about the intentions. MG sends Service Change (method = Forced) when the termination actually goes out-of-service after 2 hours. This ensures that if Service Change (method = Forced) never came, the intentions of MG never got materialised. [KJBII] Ick. So we will be required to send TWO SCs instead of one if we use SC Graceful? I really don't like that idea. Does any body have an alternative solution? Please suggest. thanks, kapil nayar www.hssworld.com DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Feb 3 16:38:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22592 for ; Mon, 3 Feb 2003 16:38:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13LfjJ27932; Mon, 3 Feb 2003 16:41:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13LexJ27890 for ; Mon, 3 Feb 2003 16:40:59 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22538 for ; Mon, 3 Feb 2003 16:35:17 -0500 (EST) From: svkumar@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h13LbUj26254 for ; Tue, 4 Feb 2003 03:07:30 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h13LbSM26247; Tue, 4 Feb 2003 03:07:28 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h13LdnY29262; Tue, 4 Feb 2003 03:09:49 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CC2.007636EE ; Tue, 4 Feb 2003 03:01:13 +0530 X-Lotus-FromDomain: HSS To: "Garber, Zeev" cc: megaco@ietf.org Message-ID: <65256CC2.00763481.00@sandesh.hss.hns.com> Date: Tue, 4 Feb 2003 03:11:00 +0530 Subject: Re: [Megaco] Binary Term ID format Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Ze'ev For a fixed Termination Id, none of the bits in the wildcard field will be set. So the value is 0. But since it is not optional, it will be encoded in ASN with length 0 and no value field. Regards Shiv "Garber, Zeev" on 02/03/2003 08:51:24 PM To: megaco@ietf.org cc: (bcc: Shiv Kumar/HSS) Subject: [Megaco] Binary Term ID format Hi All, Termination Id in binary encoding has a wildcard field separated from termination id itself. The wildcard field is not an optional parameter. What should be the value of this field in case of fixed Termination Id? Or should it disappear in this case? Thanks, Ze'ev Garber Software Engineer Communications Infrastructure Test Group p| 978.661.1211 f| 978.988.0148 m| 978.661.4800 email | zgarber@empirix.com 205 Lowell Street | Wilmington, MA | 01887 E M P I R I X www.empirix.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Feb 3 16:39:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22635 for ; Mon, 3 Feb 2003 16:39:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13LiCD28017 for megaco-archive@odin.ietf.org; Mon, 3 Feb 2003 16:44:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13LiCJ28014 for ; Mon, 3 Feb 2003 16:44:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22601 for ; Mon, 3 Feb 2003 16:38:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13LfjJ27932; Mon, 3 Feb 2003 16:41:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13LexJ27890 for ; Mon, 3 Feb 2003 16:40:59 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22538 for ; Mon, 3 Feb 2003 16:35:17 -0500 (EST) From: svkumar@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h13LbUj26254 for ; Tue, 4 Feb 2003 03:07:30 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h13LbSM26247; Tue, 4 Feb 2003 03:07:28 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h13LdnY29262; Tue, 4 Feb 2003 03:09:49 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CC2.007636EE ; Tue, 4 Feb 2003 03:01:13 +0530 X-Lotus-FromDomain: HSS To: "Garber, Zeev" cc: megaco@ietf.org Message-ID: <65256CC2.00763481.00@sandesh.hss.hns.com> Date: Tue, 4 Feb 2003 03:11:00 +0530 Subject: Re: [Megaco] Binary Term ID format Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Ze'ev For a fixed Termination Id, none of the bits in the wildcard field will be set. So the value is 0. But since it is not optional, it will be encoded in ASN with length 0 and no value field. Regards Shiv "Garber, Zeev" on 02/03/2003 08:51:24 PM To: megaco@ietf.org cc: (bcc: Shiv Kumar/HSS) Subject: [Megaco] Binary Term ID format Hi All, Termination Id in binary encoding has a wildcard field separated from termination id itself. The wildcard field is not an optional parameter. What should be the value of this field in case of fixed Termination Id? Or should it disappear in this case? Thanks, Ze'ev Garber Software Engineer Communications Infrastructure Test Group p| 978.661.1211 f| 978.988.0148 m| 978.661.4800 email | zgarber@empirix.com 205 Lowell Street | Wilmington, MA | 01887 E M P I R I X www.empirix.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Feb 3 16:50:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22854 for ; Mon, 3 Feb 2003 16:50:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13LrIJ28352; Mon, 3 Feb 2003 16:53:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13LqaJ28311 for ; Mon, 3 Feb 2003 16:52:36 -0500 Received: from pop018.verizon.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22804 for ; Mon, 3 Feb 2003 16:46:55 -0500 (EST) Received: from verizon.net ([138.89.124.43]) by pop018.verizon.net (InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP id <20030203215032.PZYI1680.pop018.verizon.net@verizon.net>; Mon, 3 Feb 2003 15:50:32 -0600 Message-ID: <3E3EE41F.30303@verizon.net> Date: Mon, 03 Feb 2003 16:50:23 -0500 From: Terry L Anderson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Garber, Zeev" CC: megaco@ietf.org Subject: Re: [Megaco] Binary Term ID format References: <5CB426A04E141C499676B19B6CF3DE571D0D2E@kappa.empirix.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop018.verizon.net from [138.89.124.43] at Mon, 3 Feb 2003 15:50:31 -0600 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "SEQUENCE OF" in ASN.1 always permits sequences of zero length, so the wildcard field can be empty and would be when the the termination id is fixed. Garber, Zeev wrote: >Hi All, > >Termination Id in binary encoding has a wildcard field separated >from termination id itself. The wildcard field is not an optional parameter. > >What should be the value of this field in case of fixed Termination Id? >Or should it disappear in this case? > >Thanks, >Ze'ev Garber >Software Engineer >Communications Infrastructure Test Group > >p| 978.661.1211 f| 978.988.0148 m| 978.661.4800 >email | zgarber@empirix.com >205 Lowell Street | Wilmington, MA | 01887 > >E M P I R I X >www.empirix.com > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco > > > -- ------------------------------------------------------- Terry L Anderson tlatla@verizon.net Voice: +1 908.766.4463 Mobile: +1 908.342.9595 http://www.gti.net/tla ------------------------------------------------------- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Feb 3 16:50:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22876 for ; Mon, 3 Feb 2003 16:50:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13Ltkg28429 for megaco-archive@odin.ietf.org; Mon, 3 Feb 2003 16:55:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13LtkJ28426 for ; Mon, 3 Feb 2003 16:55:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22863 for ; Mon, 3 Feb 2003 16:50:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13LrIJ28352; Mon, 3 Feb 2003 16:53:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13LqaJ28311 for ; Mon, 3 Feb 2003 16:52:36 -0500 Received: from pop018.verizon.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22804 for ; Mon, 3 Feb 2003 16:46:55 -0500 (EST) Received: from verizon.net ([138.89.124.43]) by pop018.verizon.net (InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP id <20030203215032.PZYI1680.pop018.verizon.net@verizon.net>; Mon, 3 Feb 2003 15:50:32 -0600 Message-ID: <3E3EE41F.30303@verizon.net> Date: Mon, 03 Feb 2003 16:50:23 -0500 From: Terry L Anderson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Garber, Zeev" CC: megaco@ietf.org Subject: Re: [Megaco] Binary Term ID format References: <5CB426A04E141C499676B19B6CF3DE571D0D2E@kappa.empirix.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop018.verizon.net from [138.89.124.43] at Mon, 3 Feb 2003 15:50:31 -0600 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "SEQUENCE OF" in ASN.1 always permits sequences of zero length, so the wildcard field can be empty and would be when the the termination id is fixed. Garber, Zeev wrote: >Hi All, > >Termination Id in binary encoding has a wildcard field separated >from termination id itself. The wildcard field is not an optional parameter. > >What should be the value of this field in case of fixed Termination Id? >Or should it disappear in this case? > >Thanks, >Ze'ev Garber >Software Engineer >Communications Infrastructure Test Group > >p| 978.661.1211 f| 978.988.0148 m| 978.661.4800 >email | zgarber@empirix.com >205 Lowell Street | Wilmington, MA | 01887 > >E M P I R I X >www.empirix.com > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco > > > -- ------------------------------------------------------- Terry L Anderson tlatla@verizon.net Voice: +1 908.766.4463 Mobile: +1 908.342.9595 http://www.gti.net/tla ------------------------------------------------------- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Feb 3 23:02:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29339 for ; Mon, 3 Feb 2003 23:02:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1445gJ14850; Mon, 3 Feb 2003 23:05:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1443TJ14777 for ; Mon, 3 Feb 2003 23:03:29 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29269 for ; Mon, 3 Feb 2003 22:57:39 -0500 (EST) From: assingh@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h143xrj29308 for ; Tue, 4 Feb 2003 09:29:53 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h143xqM29303; Tue, 4 Feb 2003 09:29:52 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h1442BM10107; Tue, 4 Feb 2003 09:32:13 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CC3.00156154 ; Tue, 4 Feb 2003 09:23:31 +0530 X-Lotus-FromDomain: HSS To: Christian Groves cc: megaco@ietf.org Message-ID: <65256CC3.00156048.00@sandesh.hss.hns.com> Date: Tue, 4 Feb 2003 09:33:16 +0530 Subject: Re: [Megaco] Sequential Signal List Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Christian, Thanks for the clarifications. Suppose MGC is interested in getting Signal Completion notification in following 4 conditions: i) Complete signal list is played out (After last signal completes) ii) If Signal list is interrupted by event indication iii) If Signal list is interrupted by new signal descriptor iv) If Signal list is aborted abnormally 1st case will be solved by having "notify completion" flag with the last signal. Since it is not known when new signal descriptor will arrive or when event will be detected, so for other cases we have to attach "notify completion" with each and every signal. To avoid this, Can we use the convention that "notify completion" in any signal in the list causes "notify completion" for the list. So if signal list have "notify completion" with the last signal only, all 4 conditions will be satisfied. Pls. clarify.... Thanks in advance. Ashish Christian Groves on 01/30/2003 06:35:49 AM To: Ashish Singh/HSS@HSS cc: megaco@ietf.org Subject: Re: [Megaco] Sequential Signal List Hello, Please see my comments below. Regards, Christian assingh@hss.hns.com wrote: > > Hi List, > > A sequential signal list consists of a signal list identifier and a sequence of > signals to be played sequentially. > Each Signal of this list consists of signal name along with optional parameters > like Stream id, Signal type, Signal duration, Notify Completion reasons and > Keep Active flag. > > I am listing down my queries below. > > 1) Protocol Grammar allows the use of Notify Completion reasons with the signals > in Sequential signal list. Is there any practical scenario, in which MGC is > interested in getting Signal Completion notification after completion of each > signal of sequential list. [CHG] I don't know of a practical reason to do so, but in the development of the protocol a signal list was seen as a list of individual signals with all the capabilities of stand alone signals. > > Rather MGC will be interested in getting Signal Completion notification after > completion of whole sequential list. Since Notify Completion reason is attached > with indivisual signals and not with sequential list, so how will MGC indicate > MG to do so. [CHG] Just put notify completion on the last signal in the list. > > 2) Protocol Grammar allows the use of different stream ids with the signals in > Sequential signal list. But is there any practical scenario, in which a > sequential signal list contains signals to be played on different streams. or > All signals in sequential signal list shall refer to the same stream. [CHG] I don't know of any practical usage in PSTN/ISDN telephony that would need this but for multimedia I could see a case where you would synchronise between video and voice streams. > > 3) What is significance of Keep active flag with each signal of sequential list? [CHG] None, as a replacement with the same SignalListID ensures that the signals continue to play. > > Thanks in advance. > > Thanks N Regards > Ashish Singh > Hughes Software Systems > > DISCLAIMER: This message is proprietary to Hughes Software Systems > Limited (HSS) and is intended solely for the use of the individual > to whom it is addressed. It may contain privileged or confidential > information and should not be circulated or used for any purpose other > than for what it is intended. If you have received this message in error, > please notify the originator immediately. If you are not the intended > recipient, you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. HSS accepts > no responsibility for loss or damage arising from the use of the information > transmitted by this email including damage from virus. > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Feb 3 23:03:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29361 for ; Mon, 3 Feb 2003 23:03:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1448UX15578 for megaco-archive@odin.ietf.org; Mon, 3 Feb 2003 23:08:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1448TJ15575 for ; Mon, 3 Feb 2003 23:08:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29346 for ; Mon, 3 Feb 2003 23:02:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1445gJ14850; Mon, 3 Feb 2003 23:05:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1443TJ14777 for ; Mon, 3 Feb 2003 23:03:29 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29269 for ; Mon, 3 Feb 2003 22:57:39 -0500 (EST) From: assingh@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h143xrj29308 for ; Tue, 4 Feb 2003 09:29:53 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h143xqM29303; Tue, 4 Feb 2003 09:29:52 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h1442BM10107; Tue, 4 Feb 2003 09:32:13 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CC3.00156154 ; Tue, 4 Feb 2003 09:23:31 +0530 X-Lotus-FromDomain: HSS To: Christian Groves cc: megaco@ietf.org Message-ID: <65256CC3.00156048.00@sandesh.hss.hns.com> Date: Tue, 4 Feb 2003 09:33:16 +0530 Subject: Re: [Megaco] Sequential Signal List Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Christian, Thanks for the clarifications. Suppose MGC is interested in getting Signal Completion notification in following 4 conditions: i) Complete signal list is played out (After last signal completes) ii) If Signal list is interrupted by event indication iii) If Signal list is interrupted by new signal descriptor iv) If Signal list is aborted abnormally 1st case will be solved by having "notify completion" flag with the last signal. Since it is not known when new signal descriptor will arrive or when event will be detected, so for other cases we have to attach "notify completion" with each and every signal. To avoid this, Can we use the convention that "notify completion" in any signal in the list causes "notify completion" for the list. So if signal list have "notify completion" with the last signal only, all 4 conditions will be satisfied. Pls. clarify.... Thanks in advance. Ashish Christian Groves on 01/30/2003 06:35:49 AM To: Ashish Singh/HSS@HSS cc: megaco@ietf.org Subject: Re: [Megaco] Sequential Signal List Hello, Please see my comments below. Regards, Christian assingh@hss.hns.com wrote: > > Hi List, > > A sequential signal list consists of a signal list identifier and a sequence of > signals to be played sequentially. > Each Signal of this list consists of signal name along with optional parameters > like Stream id, Signal type, Signal duration, Notify Completion reasons and > Keep Active flag. > > I am listing down my queries below. > > 1) Protocol Grammar allows the use of Notify Completion reasons with the signals > in Sequential signal list. Is there any practical scenario, in which MGC is > interested in getting Signal Completion notification after completion of each > signal of sequential list. [CHG] I don't know of a practical reason to do so, but in the development of the protocol a signal list was seen as a list of individual signals with all the capabilities of stand alone signals. > > Rather MGC will be interested in getting Signal Completion notification after > completion of whole sequential list. Since Notify Completion reason is attached > with indivisual signals and not with sequential list, so how will MGC indicate > MG to do so. [CHG] Just put notify completion on the last signal in the list. > > 2) Protocol Grammar allows the use of different stream ids with the signals in > Sequential signal list. But is there any practical scenario, in which a > sequential signal list contains signals to be played on different streams. or > All signals in sequential signal list shall refer to the same stream. [CHG] I don't know of any practical usage in PSTN/ISDN telephony that would need this but for multimedia I could see a case where you would synchronise between video and voice streams. > > 3) What is significance of Keep active flag with each signal of sequential list? [CHG] None, as a replacement with the same SignalListID ensures that the signals continue to play. > > Thanks in advance. > > Thanks N Regards > Ashish Singh > Hughes Software Systems > > DISCLAIMER: This message is proprietary to Hughes Software Systems > Limited (HSS) and is intended solely for the use of the individual > to whom it is addressed. It may contain privileged or confidential > information and should not be circulated or used for any purpose other > than for what it is intended. If you have received this message in error, > please notify the originator immediately. If you are not the intended > recipient, you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. HSS accepts > no responsibility for loss or damage arising from the use of the information > transmitted by this email including damage from virus. > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 4 00:14:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00440 for ; Tue, 4 Feb 2003 00:14:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h145HpJ18884; Tue, 4 Feb 2003 00:17:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h145FBJ18789 for ; Tue, 4 Feb 2003 00:15:11 -0500 Received: from ish7.ericsson.com.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00324 for ; Tue, 4 Feb 2003 00:09:19 -0500 (EST) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id h145Afx24100; Tue, 4 Feb 2003 16:10:41 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h145CqV01540; Tue, 4 Feb 2003 16:12:53 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.194]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DZ359MSQ; Tue, 4 Feb 2003 16:12:52 +1100 Message-ID: <3E3F01EC.F4D8014B@ericsson.com.au> Date: Tue, 04 Feb 2003 10:57:32 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom Taylor CC: Harry Suede , megaco@ietf.org Subject: Re: [Megaco] Re: Descriptor state after out of service References: <20030203104156.5720.qmail@email.com> <3E3E8398.8020105@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit G'Day, I think you should concentrate more on the method associated with the service change that put the termination into the Out of Service state. The result of Forced or Graceful will be that terminations are subtracted - thus if subtracted the descriptors will be affected according to H.248.1 sect 7.2.3. Christian Tom Taylor wrote: > > I don't believe the ServiceChange action does anything to the descriptors on its > own. It is up to the MGC to reset them if necessary. I do have the feeling that we > might want to analyze the situation and possibly refine it. > > Harry Suede wrote: > > Hi list, Tom > > > > PL ignore my previous mail. By mistake I have written "out of service" in place of "in service" in the last line. > > > > What is the state of descriptor of a termination in a non-null context when termination is put "out of service" by MGC or MG? Does the descriptor remain on termination database but inactivated or does they are total flushed. Thus if this termination is put "in service" by MGC or MG then what will be the state of descriptor i.e. they are reapply/reactivated on the termination or not. > > > > regards > > harry > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 4 00:14:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00484 for ; Tue, 4 Feb 2003 00:14:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h145I4J18925; Tue, 4 Feb 2003 00:18:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h145HTJ18850 for ; Tue, 4 Feb 2003 00:17:29 -0500 Received: from rediffmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00356 for ; Tue, 4 Feb 2003 00:11:38 -0500 (EST) Received: (qmail 14304 invoked by uid 510); 4 Feb 2003 05:21:56 -0000 Date: 4 Feb 2003 05:21:56 -0000 Message-ID: <20030204052156.14303.qmail@webmail28.rediffmail.com> Received: from unknown (202.144.91.188) by rediffmail.com via HTTP; 04 feb 2003 05:21:56 -0000 MIME-Version: 1.0 From: "Simran Chadha" Reply-To: "Simran Chadha" To: megaco@ietf.org Content-type: text/plain; format=flowed Content-Disposition: inline Subject: [Megaco] Re: Usage of LocalControl,Local and Remote Descriptors ! Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi List, Can someone please help me at the earliest on the issues raised earlier by me - particularly, usage of LocalControl,Local and Remote Descriptors ? Thanks in advance. Simran Chadha On Thu, 30 Jan 2003 Simran Chadha wrote : >Hi List, > >Can you please help me with clarifications in my understanding of >sections 7.1.7 and 7.1.8 on the use of LocalControl,Local and >Remote Descriptors. > >As per draft-ietf-megaco-3015corr-03, in section 7.1.7, >If the value of a Reserve property is True, the MG SHALL reserve >resources for all alternatives specified in the Local and/or >Remote descriptors for which it currently has resources >available. It SHALL respond with the alternatives for which it >reserves resources. If it cannot not support any of the >alternatives, it SHALL respond with a reply to the MGC that >contains empty Local and/or Remote descriptors. >The use of two negations - "cannot not" in the last statement >will imply that - If it can support any of the alternatives, it >SHALL respond with a reply to the MGC that contains empty Local >and/or Remote descriptors. >I don't think this is what is meant to be conveyed here. > >Also in section 7.1.7 the first para starts - If the value of a >Reserve property is True, ..... >while the second para starts - If the value of a Reserve property >is False, .... >Now as there are two Reserve properties - one Reserve Group and >the other Reserve Value, One could be False and the other could >be True. Then in this case what will be the inference - Should >para 1 apply or para 2 ? Both the paras would seem to be mutually >exclusive in what is needed to be done. > >Also statements like "if it cannot support any of the >alternatives ... " - will have two meanings. >1. Any - Not even one - NONE of the alternatives is supported. >2. Any - Atleast one - While a few alternatives can be >supported, a few might not be. > >The protocol needs to be more clear on such aspects in the >documents henceforth. The English language is understood in >different parts of the world. Variations to agreed usage of the >language terms will make it difficult for new users of Megaco >protocol, like me. > >Can someone please educate me on the exact usage and meaning of >LocalControl,Local and Remote Descriptors ? > >Thanks and awaiting comments and clarifications > >Simran Chadha _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 4 00:14:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00505 for ; Tue, 4 Feb 2003 00:14:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h145HQJ18848; Tue, 4 Feb 2003 00:17:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h145FBJ18785 for ; Tue, 4 Feb 2003 00:15:11 -0500 Received: from ish7.ericsson.com.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00323 for ; Tue, 4 Feb 2003 00:09:19 -0500 (EST) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id h145Afx24102; Tue, 4 Feb 2003 16:10:41 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h145CsV01545; Tue, 4 Feb 2003 16:12:54 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.194]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DZ359MSS; Tue, 4 Feb 2003 16:12:53 +1100 Message-ID: <3E3F039C.87E1061D@ericsson.com.au> Date: Tue, 04 Feb 2003 11:04:44 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: knayar@hss.hns.com CC: megaco@ietf.org Subject: Re: [Megaco] Cancel Service Change (method=Graceful) mechanism References: <65256CC2.0043394B.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Kapil, Please see my comments below. Christian knayar@hss.hns.com wrote: > > Hi > > It seems the protocol doesnot define any procedure for cancelling an earlier > Service Change (method=Graceful) on a non-root termination. > > Taking a practical case: > MG sends a Service Change (method=Graceful) on a termination with delay= 2 > hours. > After 1 hour, MG realizes that it doesn't want to put the termination > out-of-service (after remaining 1 hour) as was earlier intended. > How to inform the MGC of the new intentions - cancel graceful..? > Sending Service Change (method =Restart) would mean that termination just came > InService and doesnot have any active descriptors, whereas this is not the case. [CHG] Method = Restart, Reason Warm Boot would work as Kevin mentions. > > Solution: > MG sends Service Change (method = Graceful) delay =2 hours to inform MGC only > about the intentions. > MG sends Service Change (method = Forced) when the termination actually goes > out-of-service after 2 hours. > This ensures that if Service Change (method = Forced) never came, the intentions > of MG never got materialised. > > Does any body have an alternative solution? Please suggest. [CHG] Why do you need to do this? The MGC should have a timer of 2 hours associated with that termination. So the MGC knows when to subtract the termination from the context. The MGC should not use this termination for traffic after it has subtracted it. > > thanks, > kapil nayar > www.hssworld.com > > DISCLAIMER: This message is proprietary to Hughes Software Systems > Limited (HSS) and is intended solely for the use of the individual > to whom it is addressed. It may contain privileged or confidential > information and should not be circulated or used for any purpose other > than for what it is intended. If you have received this message in error, > please notify the originator immediately. If you are not the intended > recipient, you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. HSS accepts > no responsibility for loss or damage arising from the use of the information > transmitted by this email including damage from virus. > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 4 00:15:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00534 for ; Tue, 4 Feb 2003 00:15:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h145KV019114 for megaco-archive@odin.ietf.org; Tue, 4 Feb 2003 00:20:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h145KUJ19111 for ; Tue, 4 Feb 2003 00:20:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00455 for ; Tue, 4 Feb 2003 00:14:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h145HpJ18884; Tue, 4 Feb 2003 00:17:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h145FBJ18789 for ; Tue, 4 Feb 2003 00:15:11 -0500 Received: from ish7.ericsson.com.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00324 for ; Tue, 4 Feb 2003 00:09:19 -0500 (EST) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id h145Afx24100; Tue, 4 Feb 2003 16:10:41 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h145CqV01540; Tue, 4 Feb 2003 16:12:53 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.194]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DZ359MSQ; Tue, 4 Feb 2003 16:12:52 +1100 Message-ID: <3E3F01EC.F4D8014B@ericsson.com.au> Date: Tue, 04 Feb 2003 10:57:32 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom Taylor CC: Harry Suede , megaco@ietf.org Subject: Re: [Megaco] Re: Descriptor state after out of service References: <20030203104156.5720.qmail@email.com> <3E3E8398.8020105@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit G'Day, I think you should concentrate more on the method associated with the service change that put the termination into the Out of Service state. The result of Forced or Graceful will be that terminations are subtracted - thus if subtracted the descriptors will be affected according to H.248.1 sect 7.2.3. Christian Tom Taylor wrote: > > I don't believe the ServiceChange action does anything to the descriptors on its > own. It is up to the MGC to reset them if necessary. I do have the feeling that we > might want to analyze the situation and possibly refine it. > > Harry Suede wrote: > > Hi list, Tom > > > > PL ignore my previous mail. By mistake I have written "out of service" in place of "in service" in the last line. > > > > What is the state of descriptor of a termination in a non-null context when termination is put "out of service" by MGC or MG? Does the descriptor remain on termination database but inactivated or does they are total flushed. Thus if this termination is put "in service" by MGC or MG then what will be the state of descriptor i.e. they are reapply/reactivated on the termination or not. > > > > regards > > harry > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 4 00:15:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00549 for ; Tue, 4 Feb 2003 00:15:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h145Keq19148 for megaco-archive@odin.ietf.org; Tue, 4 Feb 2003 00:20:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h145KeJ19145 for ; Tue, 4 Feb 2003 00:20:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00488 for ; Tue, 4 Feb 2003 00:14:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h145I4J18925; Tue, 4 Feb 2003 00:18:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h145HTJ18850 for ; Tue, 4 Feb 2003 00:17:29 -0500 Received: from rediffmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00356 for ; Tue, 4 Feb 2003 00:11:38 -0500 (EST) Received: (qmail 14304 invoked by uid 510); 4 Feb 2003 05:21:56 -0000 Date: 4 Feb 2003 05:21:56 -0000 Message-ID: <20030204052156.14303.qmail@webmail28.rediffmail.com> Received: from unknown (202.144.91.188) by rediffmail.com via HTTP; 04 feb 2003 05:21:56 -0000 MIME-Version: 1.0 From: "Simran Chadha" Reply-To: "Simran Chadha" To: megaco@ietf.org Content-type: text/plain; format=flowed Content-Disposition: inline Subject: [Megaco] Re: Usage of LocalControl,Local and Remote Descriptors ! Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi List, Can someone please help me at the earliest on the issues raised earlier by me - particularly, usage of LocalControl,Local and Remote Descriptors ? Thanks in advance. Simran Chadha On Thu, 30 Jan 2003 Simran Chadha wrote : >Hi List, > >Can you please help me with clarifications in my understanding of >sections 7.1.7 and 7.1.8 on the use of LocalControl,Local and >Remote Descriptors. > >As per draft-ietf-megaco-3015corr-03, in section 7.1.7, >If the value of a Reserve property is True, the MG SHALL reserve >resources for all alternatives specified in the Local and/or >Remote descriptors for which it currently has resources >available. It SHALL respond with the alternatives for which it >reserves resources. If it cannot not support any of the >alternatives, it SHALL respond with a reply to the MGC that >contains empty Local and/or Remote descriptors. >The use of two negations - "cannot not" in the last statement >will imply that - If it can support any of the alternatives, it >SHALL respond with a reply to the MGC that contains empty Local >and/or Remote descriptors. >I don't think this is what is meant to be conveyed here. > >Also in section 7.1.7 the first para starts - If the value of a >Reserve property is True, ..... >while the second para starts - If the value of a Reserve property >is False, .... >Now as there are two Reserve properties - one Reserve Group and >the other Reserve Value, One could be False and the other could >be True. Then in this case what will be the inference - Should >para 1 apply or para 2 ? Both the paras would seem to be mutually >exclusive in what is needed to be done. > >Also statements like "if it cannot support any of the >alternatives ... " - will have two meanings. >1. Any - Not even one - NONE of the alternatives is supported. >2. Any - Atleast one - While a few alternatives can be >supported, a few might not be. > >The protocol needs to be more clear on such aspects in the >documents henceforth. The English language is understood in >different parts of the world. Variations to agreed usage of the >language terms will make it difficult for new users of Megaco >protocol, like me. > >Can someone please educate me on the exact usage and meaning of >LocalControl,Local and Remote Descriptors ? > >Thanks and awaiting comments and clarifications > >Simran Chadha _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 4 00:15:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00562 for ; Tue, 4 Feb 2003 00:15:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h145Klp19178 for megaco-archive@odin.ietf.org; Tue, 4 Feb 2003 00:20:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h145KlJ19175 for ; Tue, 4 Feb 2003 00:20:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00509 for ; Tue, 4 Feb 2003 00:14:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h145HQJ18848; Tue, 4 Feb 2003 00:17:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h145FBJ18785 for ; Tue, 4 Feb 2003 00:15:11 -0500 Received: from ish7.ericsson.com.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00323 for ; Tue, 4 Feb 2003 00:09:19 -0500 (EST) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id h145Afx24102; Tue, 4 Feb 2003 16:10:41 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h145CsV01545; Tue, 4 Feb 2003 16:12:54 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.194]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DZ359MSS; Tue, 4 Feb 2003 16:12:53 +1100 Message-ID: <3E3F039C.87E1061D@ericsson.com.au> Date: Tue, 04 Feb 2003 11:04:44 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: knayar@hss.hns.com CC: megaco@ietf.org Subject: Re: [Megaco] Cancel Service Change (method=Graceful) mechanism References: <65256CC2.0043394B.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Kapil, Please see my comments below. Christian knayar@hss.hns.com wrote: > > Hi > > It seems the protocol doesnot define any procedure for cancelling an earlier > Service Change (method=Graceful) on a non-root termination. > > Taking a practical case: > MG sends a Service Change (method=Graceful) on a termination with delay= 2 > hours. > After 1 hour, MG realizes that it doesn't want to put the termination > out-of-service (after remaining 1 hour) as was earlier intended. > How to inform the MGC of the new intentions - cancel graceful..? > Sending Service Change (method =Restart) would mean that termination just came > InService and doesnot have any active descriptors, whereas this is not the case. [CHG] Method = Restart, Reason Warm Boot would work as Kevin mentions. > > Solution: > MG sends Service Change (method = Graceful) delay =2 hours to inform MGC only > about the intentions. > MG sends Service Change (method = Forced) when the termination actually goes > out-of-service after 2 hours. > This ensures that if Service Change (method = Forced) never came, the intentions > of MG never got materialised. > > Does any body have an alternative solution? Please suggest. [CHG] Why do you need to do this? The MGC should have a timer of 2 hours associated with that termination. So the MGC knows when to subtract the termination from the context. The MGC should not use this termination for traffic after it has subtracted it. > > thanks, > kapil nayar > www.hssworld.com > > DISCLAIMER: This message is proprietary to Hughes Software Systems > Limited (HSS) and is intended solely for the use of the individual > to whom it is addressed. It may contain privileged or confidential > information and should not be circulated or used for any purpose other > than for what it is intended. If you have received this message in error, > please notify the originator immediately. If you are not the intended > recipient, you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. HSS accepts > no responsibility for loss or damage arising from the use of the information > transmitted by this email including damage from virus. > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 4 00:24:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00972 for ; Tue, 4 Feb 2003 00:24:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h145S9J19446; Tue, 4 Feb 2003 00:28:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h145RdJ19421 for ; Tue, 4 Feb 2003 00:27:39 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00740 for ; Tue, 4 Feb 2003 00:21:46 -0500 (EST) From: knayar@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h145Nwj14774 for ; Tue, 4 Feb 2003 10:53:58 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h145NtM14766; Tue, 4 Feb 2003 10:53:55 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h145QGj16300; Tue, 4 Feb 2003 10:56:16 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CC3.001D15C3 ; Tue, 4 Feb 2003 10:47:41 +0530 X-Lotus-FromDomain: HSS To: "Kevin Boyle" cc: megaco@ietf.org Message-ID: <65256CC3.001D134D.00@sandesh.hss.hns.com> Date: Tue, 4 Feb 2003 10:52:28 +0530 Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=ipTScN13gXHWx3WpoddzMglAye5hmqEaThZ7pZjT2UrrlCDP9B6BSrIC" Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --0__=ipTScN13gXHWx3WpoddzMglAye5hmqEaThZ7pZjT2UrrlCDP9B6BSrIC Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi Kevin Thanks for your reply... But, as per H.248.8 the definition of Service Change reason "WarmBoot" is: "This indicates that the entity indicated with the TerminationID is in ServiceState "In-Service", and that it has gone through a start, or recovery, action. All transactions in process may be lost, but otherwise all states are preserved on the termination." with a special comment: "This reason code only applies for TerminationID root" The protocol defines the usage of "WarmBoot" only for root termination. Alternatives? thanks, -kapil "Kevin Boyle" on 02/04/2003 12:50:20 AM To: Kapil Nayar/HSS@HSS, megaco@ietf.org cc: Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Comments inline. [KJBII] Kevin -----Original Message----- From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] Sent: Monday, February 03, 2003 7:19 AM To: megaco@ietf.org Subject: [Megaco] Cancel Service Change (method=Graceful) mechanism Hi It seems the protocol doesnot define any procedure for cancelling an earlier Service Change (method=Graceful) on a non-root termination. Taking a practical case: MG sends a Service Change (method=Graceful) on a termination with delay= 2 hours. After 1 hour, MG realizes that it doesn't want to put the termination out-of-service (after remaining 1 hour) as was earlier intended. How to inform the MGC of the new intentions - cancel graceful..? Sending Service Change (method =Restart) would mean that termination just came InService and doesnot have any active descriptors, whereas this is not the case. [KJBII] Why can't you use SC Restart? The Warm Boot SC Reason indicates that there was NO loss of state. Solution: MG sends Service Change (method = Graceful) delay =2 hours to inform MGC only about the intentions. MG sends Service Change (method = Forced) when the termination actually goes out-of-service after 2 hours. This ensures that if Service Change (method = Forced) never came, the intentions of MG never got materialised. [KJBII] Ick. So we will be required to send TWO SCs instead of one if we use SC Graceful? I really don't like that idea. Does any body have an alternative solution? Please suggest. thanks, kapil nayar www.hssworld.com DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --0__=ipTScN13gXHWx3WpoddzMglAye5hmqEaThZ7pZjT2UrrlCDP9B6BSrIC Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTQuODkiPg0KPFRJVExFPlJFOiBbTWVn YWNvXSBDYW5jZWwgU2VydmljZSBDaGFuZ2UgKG1ldGhvZD1HcmFjZWZ1bCkgbWVjaGFuaXNtPC9U SVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KDQo8UD48Rk9OVCBTSVpFPTI+Q29tbWVudHMgaW5saW5l LiBbS0pCSUldPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+S2V2aW48L0ZPTlQ+DQo8 L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+RnJvbToga25heWFyQGhzcy5obnMuY29tIFs8QSBIUkVGPSJtYWls dG86a25heWFyQGhzcy5obnMuY29tIj5tYWlsdG86a25heWFyQGhzcy5obnMuY29tPC9BPl0gPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj5TZW50OiBNb25kYXksIEZlYnJ1YXJ5IDAzLCAyMDAzIDc6 MTkgQU08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlRvOiBtZWdhY29AaWV0Zi5vcmc8L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPlN1YmplY3Q6IFtNZWdhY29dIENhbmNlbCBTZXJ2aWNlIENoYW5n ZSAobWV0aG9kPUdyYWNlZnVsKSBtZWNoYW5pc208L0ZPTlQ+DQo8L1A+DQo8QlI+DQo8QlI+DQo8 QlI+DQoNCjxQPjxGT05UIFNJWkU9Mj5IaTwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y Pkl0IHNlZW1zIHRoZSBwcm90b2NvbCBkb2Vzbm90IGRlZmluZSBhbnkgcHJvY2VkdXJlIGZvciBj YW5jZWxsaW5nIGFuIGVhcmxpZXIgU2VydmljZSBDaGFuZ2UgKG1ldGhvZD1HcmFjZWZ1bCkgb24g YSBub24tcm9vdCB0ZXJtaW5hdGlvbi48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+VGFr aW5nIGEgcHJhY3RpY2FsIGNhc2U6PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5NRyBzZW5kcyBh IFNlcnZpY2UgQ2hhbmdlIChtZXRob2Q9R3JhY2VmdWwpIG9uIGEgdGVybWluYXRpb24gd2l0aCBk ZWxheT0gMiBob3Vycy4gQWZ0ZXIgMSBob3VyLCBNRyByZWFsaXplcyB0aGF0IGl0IGRvZXNuJ3Qg d2FudCB0byBwdXQgdGhlIHRlcm1pbmF0aW9uIG91dC1vZi1zZXJ2aWNlIChhZnRlciByZW1haW5p bmcgMSBob3VyKSBhcyB3YXMgZWFybGllciBpbnRlbmRlZC4gSG93IHRvIGluZm9ybSB0aGUgTUdD IG9mIHRoZSBuZXcgaW50ZW50aW9ucyAtIGNhbmNlbCBncmFjZWZ1bC4uPyBTZW5kaW5nIFNlcnZp Y2UgQ2hhbmdlIChtZXRob2QgPVJlc3RhcnQpIHdvdWxkIG1lYW4gdGhhdCB0ZXJtaW5hdGlvbiBq dXN0IGNhbWUgSW5TZXJ2aWNlIGFuZCBkb2Vzbm90IGhhdmUgYW55IGFjdGl2ZSBkZXNjcmlwdG9y cywgd2hlcmVhcyB0aGlzIGlzIG5vdCB0aGUgY2FzZS48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBT SVpFPTI+W0tKQklJXSBXaHkgY2FuJ3QgeW91IHVzZSBTQyBSZXN0YXJ0PyZuYnNwOyBUaGUgV2Fy bSBCb290IFNDIFJlYXNvbiBpbmRpY2F0ZXMgdGhhdCB0aGVyZSB3YXMgTk8gbG9zcyBvZiBzdGF0 ZS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5Tb2x1dGlvbjo8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPk1HIHNlbmRzIFNlcnZpY2UgQ2hhbmdlIChtZXRob2QgPSBHcmFjZWZ1bCkg ZGVsYXkgPTIgaG91cnMgdG8gaW5mb3JtIE1HQyBvbmx5IGFib3V0IHRoZSBpbnRlbnRpb25zLiBN RyBzZW5kcyBTZXJ2aWNlIENoYW5nZSAobWV0aG9kID0gRm9yY2VkKSB3aGVuIHRoZSB0ZXJtaW5h dGlvbiBhY3R1YWxseSBnb2VzIG91dC1vZi1zZXJ2aWNlIGFmdGVyIDIgaG91cnMuIFRoaXMgZW5z dXJlcyB0aGF0IGlmIFNlcnZpY2UgQ2hhbmdlIChtZXRob2QgPSBGb3JjZWQpIG5ldmVyIGNhbWUs IHRoZSBpbnRlbnRpb25zIG9mIE1HIG5ldmVyIGdvdCBtYXRlcmlhbGlzZWQuPC9GT05UPjwvUD4N Cg0KPFA+PEZPTlQgU0laRT0yPltLSkJJSV0gSWNrLiZuYnNwOyBTbyB3ZSB3aWxsIGJlIHJlcXVp cmVkIHRvIHNlbmQgVFdPIFNDcyBpbnN0ZWFkIG9mIG9uZSBpZiB3ZSB1c2UgU0MgR3JhY2VmdWw/ Jm5ic3A7IEkgcmVhbGx5IGRvbid0IGxpa2UgdGhhdCBpZGVhLjwvRk9OVD48L1A+DQoNCjxQPjxG T05UIFNJWkU9Mj5Eb2VzIGFueSBib2R5IGhhdmUgYW4gYWx0ZXJuYXRpdmUgc29sdXRpb24/IFBs ZWFzZSBzdWdnZXN0LjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPnRoYW5rcyw8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPmthcGlsIG5heWFyPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj53d3cuaHNzd29ybGQuY29tPC9GT05UPg0KPC9QPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTI+ RElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHByb3ByaWV0YXJ5IHRvIEh1Z2hlcyBTb2Z0d2Fy ZSBTeXN0ZW1zIExpbWl0ZWQgKEhTUykgYW5kIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVz ZSBvZiB0aGUgaW5kaXZpZHVhbCB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSXQgbWF5IGNvbnRh aW4mbmJzcDsgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24mbmJzcDsgYW5k IHNob3VsZCBub3QgYmUgY2lyY3VsYXRlZCBvciB1c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0 aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1l c3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3IgaW1tZWRpYXRlbHku IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgbm90aWZpZWQg dGhhdCB5b3UgYXJlIHN0cmljdGx5IHByb2hpYml0ZWQgZnJvbSB1c2luZywgY29weWluZywgYWx0 ZXJpbmcsIG9yIGRpc2Nsb3NpbmcgdGhlIGNvbnRlbnRzIG9mIHRoaXMgbWVzc2FnZS4gSFNTIGFj Y2VwdHMgbm8gcmVzcG9uc2liaWxpdHkgZm9yIGxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0 aGUgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1 ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy48L0ZPTlQ+PC9QPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpF PTI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPk1lZ2FjbyBtYWlsaW5nIGxpc3Q8L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPk1lZ2Fjb0BpZXRmLm9yZzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+PEEgSFJFRj0i aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWVnYWNvIiBUQVJHRVQ9Il9i bGFuayI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWVnYWNvPC9BPjwv Rk9OVD4NCjwvUD4NCg0KPC9CT0RZPg0KPC9IVE1MPg0K --0__=ipTScN13gXHWx3WpoddzMglAye5hmqEaThZ7pZjT2UrrlCDP9B6BSrIC-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 4 00:24:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00993 for ; Tue, 4 Feb 2003 00:24:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h145U8d19540 for megaco-archive@odin.ietf.org; Tue, 4 Feb 2003 00:30:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h145U8J19537 for ; Tue, 4 Feb 2003 00:30:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00976 for ; Tue, 4 Feb 2003 00:24:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h145S9J19446; Tue, 4 Feb 2003 00:28:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h145RdJ19421 for ; Tue, 4 Feb 2003 00:27:39 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00740 for ; Tue, 4 Feb 2003 00:21:46 -0500 (EST) From: knayar@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h145Nwj14774 for ; Tue, 4 Feb 2003 10:53:58 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h145NtM14766; Tue, 4 Feb 2003 10:53:55 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h145QGj16300; Tue, 4 Feb 2003 10:56:16 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CC3.001D15C3 ; Tue, 4 Feb 2003 10:47:41 +0530 X-Lotus-FromDomain: HSS To: "Kevin Boyle" cc: megaco@ietf.org Message-ID: <65256CC3.001D134D.00@sandesh.hss.hns.com> Date: Tue, 4 Feb 2003 10:52:28 +0530 Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=ipTScN13gXHWx3WpoddzMglAye5hmqEaThZ7pZjT2UrrlCDP9B6BSrIC" Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --0__=ipTScN13gXHWx3WpoddzMglAye5hmqEaThZ7pZjT2UrrlCDP9B6BSrIC Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi Kevin Thanks for your reply... But, as per H.248.8 the definition of Service Change reason "WarmBoot" is: "This indicates that the entity indicated with the TerminationID is in ServiceState "In-Service", and that it has gone through a start, or recovery, action. All transactions in process may be lost, but otherwise all states are preserved on the termination." with a special comment: "This reason code only applies for TerminationID root" The protocol defines the usage of "WarmBoot" only for root termination. Alternatives? thanks, -kapil "Kevin Boyle" on 02/04/2003 12:50:20 AM To: Kapil Nayar/HSS@HSS, megaco@ietf.org cc: Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Comments inline. [KJBII] Kevin -----Original Message----- From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] Sent: Monday, February 03, 2003 7:19 AM To: megaco@ietf.org Subject: [Megaco] Cancel Service Change (method=Graceful) mechanism Hi It seems the protocol doesnot define any procedure for cancelling an earlier Service Change (method=Graceful) on a non-root termination. Taking a practical case: MG sends a Service Change (method=Graceful) on a termination with delay= 2 hours. After 1 hour, MG realizes that it doesn't want to put the termination out-of-service (after remaining 1 hour) as was earlier intended. How to inform the MGC of the new intentions - cancel graceful..? Sending Service Change (method =Restart) would mean that termination just came InService and doesnot have any active descriptors, whereas this is not the case. [KJBII] Why can't you use SC Restart? The Warm Boot SC Reason indicates that there was NO loss of state. Solution: MG sends Service Change (method = Graceful) delay =2 hours to inform MGC only about the intentions. MG sends Service Change (method = Forced) when the termination actually goes out-of-service after 2 hours. This ensures that if Service Change (method = Forced) never came, the intentions of MG never got materialised. [KJBII] Ick. So we will be required to send TWO SCs instead of one if we use SC Graceful? I really don't like that idea. Does any body have an alternative solution? Please suggest. thanks, kapil nayar www.hssworld.com DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --0__=ipTScN13gXHWx3WpoddzMglAye5hmqEaThZ7pZjT2UrrlCDP9B6BSrIC Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTQuODkiPg0KPFRJVExFPlJFOiBbTWVn YWNvXSBDYW5jZWwgU2VydmljZSBDaGFuZ2UgKG1ldGhvZD1HcmFjZWZ1bCkgbWVjaGFuaXNtPC9U SVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KDQo8UD48Rk9OVCBTSVpFPTI+Q29tbWVudHMgaW5saW5l LiBbS0pCSUldPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+S2V2aW48L0ZPTlQ+DQo8 L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+RnJvbToga25heWFyQGhzcy5obnMuY29tIFs8QSBIUkVGPSJtYWls dG86a25heWFyQGhzcy5obnMuY29tIj5tYWlsdG86a25heWFyQGhzcy5obnMuY29tPC9BPl0gPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj5TZW50OiBNb25kYXksIEZlYnJ1YXJ5IDAzLCAyMDAzIDc6 MTkgQU08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlRvOiBtZWdhY29AaWV0Zi5vcmc8L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPlN1YmplY3Q6IFtNZWdhY29dIENhbmNlbCBTZXJ2aWNlIENoYW5n ZSAobWV0aG9kPUdyYWNlZnVsKSBtZWNoYW5pc208L0ZPTlQ+DQo8L1A+DQo8QlI+DQo8QlI+DQo8 QlI+DQoNCjxQPjxGT05UIFNJWkU9Mj5IaTwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y Pkl0IHNlZW1zIHRoZSBwcm90b2NvbCBkb2Vzbm90IGRlZmluZSBhbnkgcHJvY2VkdXJlIGZvciBj YW5jZWxsaW5nIGFuIGVhcmxpZXIgU2VydmljZSBDaGFuZ2UgKG1ldGhvZD1HcmFjZWZ1bCkgb24g YSBub24tcm9vdCB0ZXJtaW5hdGlvbi48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+VGFr aW5nIGEgcHJhY3RpY2FsIGNhc2U6PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5NRyBzZW5kcyBh IFNlcnZpY2UgQ2hhbmdlIChtZXRob2Q9R3JhY2VmdWwpIG9uIGEgdGVybWluYXRpb24gd2l0aCBk ZWxheT0gMiBob3Vycy4gQWZ0ZXIgMSBob3VyLCBNRyByZWFsaXplcyB0aGF0IGl0IGRvZXNuJ3Qg d2FudCB0byBwdXQgdGhlIHRlcm1pbmF0aW9uIG91dC1vZi1zZXJ2aWNlIChhZnRlciByZW1haW5p bmcgMSBob3VyKSBhcyB3YXMgZWFybGllciBpbnRlbmRlZC4gSG93IHRvIGluZm9ybSB0aGUgTUdD IG9mIHRoZSBuZXcgaW50ZW50aW9ucyAtIGNhbmNlbCBncmFjZWZ1bC4uPyBTZW5kaW5nIFNlcnZp Y2UgQ2hhbmdlIChtZXRob2QgPVJlc3RhcnQpIHdvdWxkIG1lYW4gdGhhdCB0ZXJtaW5hdGlvbiBq dXN0IGNhbWUgSW5TZXJ2aWNlIGFuZCBkb2Vzbm90IGhhdmUgYW55IGFjdGl2ZSBkZXNjcmlwdG9y cywgd2hlcmVhcyB0aGlzIGlzIG5vdCB0aGUgY2FzZS48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBT SVpFPTI+W0tKQklJXSBXaHkgY2FuJ3QgeW91IHVzZSBTQyBSZXN0YXJ0PyZuYnNwOyBUaGUgV2Fy bSBCb290IFNDIFJlYXNvbiBpbmRpY2F0ZXMgdGhhdCB0aGVyZSB3YXMgTk8gbG9zcyBvZiBzdGF0 ZS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5Tb2x1dGlvbjo8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPk1HIHNlbmRzIFNlcnZpY2UgQ2hhbmdlIChtZXRob2QgPSBHcmFjZWZ1bCkg ZGVsYXkgPTIgaG91cnMgdG8gaW5mb3JtIE1HQyBvbmx5IGFib3V0IHRoZSBpbnRlbnRpb25zLiBN RyBzZW5kcyBTZXJ2aWNlIENoYW5nZSAobWV0aG9kID0gRm9yY2VkKSB3aGVuIHRoZSB0ZXJtaW5h dGlvbiBhY3R1YWxseSBnb2VzIG91dC1vZi1zZXJ2aWNlIGFmdGVyIDIgaG91cnMuIFRoaXMgZW5z dXJlcyB0aGF0IGlmIFNlcnZpY2UgQ2hhbmdlIChtZXRob2QgPSBGb3JjZWQpIG5ldmVyIGNhbWUs IHRoZSBpbnRlbnRpb25zIG9mIE1HIG5ldmVyIGdvdCBtYXRlcmlhbGlzZWQuPC9GT05UPjwvUD4N Cg0KPFA+PEZPTlQgU0laRT0yPltLSkJJSV0gSWNrLiZuYnNwOyBTbyB3ZSB3aWxsIGJlIHJlcXVp cmVkIHRvIHNlbmQgVFdPIFNDcyBpbnN0ZWFkIG9mIG9uZSBpZiB3ZSB1c2UgU0MgR3JhY2VmdWw/ Jm5ic3A7IEkgcmVhbGx5IGRvbid0IGxpa2UgdGhhdCBpZGVhLjwvRk9OVD48L1A+DQoNCjxQPjxG T05UIFNJWkU9Mj5Eb2VzIGFueSBib2R5IGhhdmUgYW4gYWx0ZXJuYXRpdmUgc29sdXRpb24/IFBs ZWFzZSBzdWdnZXN0LjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPnRoYW5rcyw8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPmthcGlsIG5heWFyPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj53d3cuaHNzd29ybGQuY29tPC9GT05UPg0KPC9QPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTI+ RElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHByb3ByaWV0YXJ5IHRvIEh1Z2hlcyBTb2Z0d2Fy ZSBTeXN0ZW1zIExpbWl0ZWQgKEhTUykgYW5kIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVz ZSBvZiB0aGUgaW5kaXZpZHVhbCB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSXQgbWF5IGNvbnRh aW4mbmJzcDsgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24mbmJzcDsgYW5k IHNob3VsZCBub3QgYmUgY2lyY3VsYXRlZCBvciB1c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0 aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1l c3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3IgaW1tZWRpYXRlbHku IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgbm90aWZpZWQg dGhhdCB5b3UgYXJlIHN0cmljdGx5IHByb2hpYml0ZWQgZnJvbSB1c2luZywgY29weWluZywgYWx0 ZXJpbmcsIG9yIGRpc2Nsb3NpbmcgdGhlIGNvbnRlbnRzIG9mIHRoaXMgbWVzc2FnZS4gSFNTIGFj Y2VwdHMgbm8gcmVzcG9uc2liaWxpdHkgZm9yIGxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0 aGUgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1 ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy48L0ZPTlQ+PC9QPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpF PTI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPk1lZ2FjbyBtYWlsaW5nIGxpc3Q8L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPk1lZ2Fjb0BpZXRmLm9yZzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+PEEgSFJFRj0i aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWVnYWNvIiBUQVJHRVQ9Il9i bGFuayI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWVnYWNvPC9BPjwv Rk9OVD4NCjwvUD4NCg0KPC9CT0RZPg0KPC9IVE1MPg0K --0__=ipTScN13gXHWx3WpoddzMglAye5hmqEaThZ7pZjT2UrrlCDP9B6BSrIC-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 4 01:00:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01501 for ; Tue, 4 Feb 2003 01:00:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1464FJ21211; Tue, 4 Feb 2003 01:04:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1463CJ21183 for ; Tue, 4 Feb 2003 01:03:12 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01389 for ; Tue, 4 Feb 2003 00:57:20 -0500 (EST) From: knayar@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h145xWj21484 for ; Tue, 4 Feb 2003 11:29:32 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h145xWM21480; Tue, 4 Feb 2003 11:29:32 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h1461rO19120; Tue, 4 Feb 2003 11:31:53 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CC3.002059E4 ; Tue, 4 Feb 2003 11:23:21 +0530 X-Lotus-FromDomain: HSS To: Christian Groves cc: megaco@ietf.org Message-ID: <65256CC3.0020566D.00@sandesh.hss.hns.com> Date: Tue, 4 Feb 2003 11:28:06 +0530 Subject: Re: [Megaco] Cancel Service Change (method=Graceful) mechanism Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Christian Thanks for your replies in line... You would have read my comments to Kevin's response. We would need some changes to the following if no other alternative is acceptable/ available: 1). Definition of reason "WarmBoot". 2). Definition of method "Restart" which currently states only "service will be restored on the specified Terminations" BTW, I am inquisitive - if an MG would typically send a Service Change (method=Graceful) with finite delay for a termination in Null context. Any comments? thanks, kapil nayar www.hssworld.com Christian Groves on 02/04/2003 05:34:44 AM To: Kapil Nayar/HSS@HSS cc: megaco@ietf.org Subject: Re: [Megaco] Cancel Service Change (method=Graceful) mechanism Hello Kapil, Please see my comments below. Christian knayar@hss.hns.com wrote: > > Hi > > It seems the protocol doesnot define any procedure for cancelling an earlier > Service Change (method=Graceful) on a non-root termination. > > Taking a practical case: > MG sends a Service Change (method=Graceful) on a termination with delay= 2 > hours. > After 1 hour, MG realizes that it doesn't want to put the termination > out-of-service (after remaining 1 hour) as was earlier intended. > How to inform the MGC of the new intentions - cancel graceful..? > Sending Service Change (method =Restart) would mean that termination just came > InService and doesnot have any active descriptors, whereas this is not the case. [CHG] Method = Restart, Reason Warm Boot would work as Kevin mentions. > > Solution: > MG sends Service Change (method = Graceful) delay =2 hours to inform MGC only > about the intentions. > MG sends Service Change (method = Forced) when the termination actually goes > out-of-service after 2 hours. > This ensures that if Service Change (method = Forced) never came, the intentions > of MG never got materialised. > > Does any body have an alternative solution? Please suggest. [CHG] Why do you need to do this? The MGC should have a timer of 2 hours associated with that termination. So the MGC knows when to subtract the termination from the context. The MGC should not use this termination for traffic after it has subtracted it. > > thanks, > kapil nayar > www.hssworld.com > > DISCLAIMER: This message is proprietary to Hughes Software Systems > Limited (HSS) and is intended solely for the use of the individual > to whom it is addressed. It may contain privileged or confidential > information and should not be circulated or used for any purpose other > than for what it is intended. If you have received this message in error, > please notify the originator immediately. If you are not the intended > recipient, you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. HSS accepts > no responsibility for loss or damage arising from the use of the information > transmitted by this email including damage from virus. > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 4 01:00:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01522 for ; Tue, 4 Feb 2003 01:00:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14666w21324 for megaco-archive@odin.ietf.org; Tue, 4 Feb 2003 01:06:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14665J21321 for ; Tue, 4 Feb 2003 01:06:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01506 for ; Tue, 4 Feb 2003 01:00:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1464FJ21211; Tue, 4 Feb 2003 01:04:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1463CJ21183 for ; Tue, 4 Feb 2003 01:03:12 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01389 for ; Tue, 4 Feb 2003 00:57:20 -0500 (EST) From: knayar@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h145xWj21484 for ; Tue, 4 Feb 2003 11:29:32 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h145xWM21480; Tue, 4 Feb 2003 11:29:32 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h1461rO19120; Tue, 4 Feb 2003 11:31:53 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CC3.002059E4 ; Tue, 4 Feb 2003 11:23:21 +0530 X-Lotus-FromDomain: HSS To: Christian Groves cc: megaco@ietf.org Message-ID: <65256CC3.0020566D.00@sandesh.hss.hns.com> Date: Tue, 4 Feb 2003 11:28:06 +0530 Subject: Re: [Megaco] Cancel Service Change (method=Graceful) mechanism Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Christian Thanks for your replies in line... You would have read my comments to Kevin's response. We would need some changes to the following if no other alternative is acceptable/ available: 1). Definition of reason "WarmBoot". 2). Definition of method "Restart" which currently states only "service will be restored on the specified Terminations" BTW, I am inquisitive - if an MG would typically send a Service Change (method=Graceful) with finite delay for a termination in Null context. Any comments? thanks, kapil nayar www.hssworld.com Christian Groves on 02/04/2003 05:34:44 AM To: Kapil Nayar/HSS@HSS cc: megaco@ietf.org Subject: Re: [Megaco] Cancel Service Change (method=Graceful) mechanism Hello Kapil, Please see my comments below. Christian knayar@hss.hns.com wrote: > > Hi > > It seems the protocol doesnot define any procedure for cancelling an earlier > Service Change (method=Graceful) on a non-root termination. > > Taking a practical case: > MG sends a Service Change (method=Graceful) on a termination with delay= 2 > hours. > After 1 hour, MG realizes that it doesn't want to put the termination > out-of-service (after remaining 1 hour) as was earlier intended. > How to inform the MGC of the new intentions - cancel graceful..? > Sending Service Change (method =Restart) would mean that termination just came > InService and doesnot have any active descriptors, whereas this is not the case. [CHG] Method = Restart, Reason Warm Boot would work as Kevin mentions. > > Solution: > MG sends Service Change (method = Graceful) delay =2 hours to inform MGC only > about the intentions. > MG sends Service Change (method = Forced) when the termination actually goes > out-of-service after 2 hours. > This ensures that if Service Change (method = Forced) never came, the intentions > of MG never got materialised. > > Does any body have an alternative solution? Please suggest. [CHG] Why do you need to do this? The MGC should have a timer of 2 hours associated with that termination. So the MGC knows when to subtract the termination from the context. The MGC should not use this termination for traffic after it has subtracted it. > > thanks, > kapil nayar > www.hssworld.com > > DISCLAIMER: This message is proprietary to Hughes Software Systems > Limited (HSS) and is intended solely for the use of the individual > to whom it is addressed. It may contain privileged or confidential > information and should not be circulated or used for any purpose other > than for what it is intended. If you have received this message in error, > please notify the originator immediately. If you are not the intended > recipient, you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. HSS accepts > no responsibility for loss or damage arising from the use of the information > transmitted by this email including damage from virus. > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 4 04:21:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14323 for ; Tue, 4 Feb 2003 04:21:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h149PcJ11171; Tue, 4 Feb 2003 04:25:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h149ObJ11121 for ; Tue, 4 Feb 2003 04:24:37 -0500 Received: from spf1.us.outblaze.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14311 for ; Tue, 4 Feb 2003 04:18:41 -0500 (EST) Received: (qmail 29178 invoked from network); 4 Feb 2003 09:22:17 -0000 Received: from unknown (205.158.62.146) by spf1.us.outblaze.com with QMQP; 4 Feb 2003 09:22:17 -0000 Received: (qmail 11791 invoked from network); 4 Feb 2003 09:20:42 -0000 Received: from unknown (HELO ws3-1.us4.outblaze.com) (205.158.62.91) by 205-158-62-146.outblaze.com with SMTP; 4 Feb 2003 09:20:42 -0000 Received: (qmail 9037 invoked by uid 1001); 4 Feb 2003 09:22:17 -0000 Message-ID: <20030204092217.9036.qmail@email.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [202.134.200.4] by ws3-1.us4.outblaze.com with http for harry_suede@email.com; Tue, 04 Feb 2003 04:22:17 -0500 From: "Harry Suede" To: taylor@nortelnetworks.com Cc: megaco@ietf.org Date: Tue, 04 Feb 2003 04:22:17 -0500 X-Originating-Ip: 202.134.200.4 X-Originating-Server: ws3-1.us4.outblaze.com Content-Transfer-Encoding: 7bit Subject: [Megaco] Re: Descriptor state after out of service Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This means that ServiceChange does not change the descriptor of the termination and its upto MGC to change the descriptor. But consider this case that termination in non-null context is put to "out of service". Thus according to protocol all connections is lost. So at h/w level there is change but not in the database. Now if MG/MGC put termination back to "in service" does this mean that connection is to be re-established i.e. descriptors are to be reapply. ----- Original Message ----- From: Tom Taylor Date: Mon, 03 Feb 2003 09:58:32 -0500 To: Harry Suede Subject: Re: Descriptor state after out of service > I don't believe the ServiceChange action does anything to the descriptors on its > own. It is up to the MGC to reset them if necessary. I do have the feeling that we > might want to analyze the situation and possibly refine it. > > Harry Suede wrote: > > Hi list, Tom > > > > PL ignore my previous mail. By mistake I have written "out of service" in place of "in service" in the last line. > > > > What is the state of descriptor of a termination in a non-null context when termination is put "out of service" by MGC or MG? Does the descriptor remain on termination database but inactivated or does they are total flushed. Thus if this termination is put "in service" by MGC or MG then what will be the state of descriptor i.e. they are reapply/reactivated on the termination or not. > > > > regards > > harry > -- _______________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Meet Singles http://corp.mail.com/lavalife _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 4 04:21:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14349 for ; Tue, 4 Feb 2003 04:21:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h149R3p11214 for megaco-archive@odin.ietf.org; Tue, 4 Feb 2003 04:27:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h149R2J11211 for ; Tue, 4 Feb 2003 04:27:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14338 for ; Tue, 4 Feb 2003 04:21:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h149PcJ11171; Tue, 4 Feb 2003 04:25:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h149ObJ11121 for ; Tue, 4 Feb 2003 04:24:37 -0500 Received: from spf1.us.outblaze.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14311 for ; Tue, 4 Feb 2003 04:18:41 -0500 (EST) Received: (qmail 29178 invoked from network); 4 Feb 2003 09:22:17 -0000 Received: from unknown (205.158.62.146) by spf1.us.outblaze.com with QMQP; 4 Feb 2003 09:22:17 -0000 Received: (qmail 11791 invoked from network); 4 Feb 2003 09:20:42 -0000 Received: from unknown (HELO ws3-1.us4.outblaze.com) (205.158.62.91) by 205-158-62-146.outblaze.com with SMTP; 4 Feb 2003 09:20:42 -0000 Received: (qmail 9037 invoked by uid 1001); 4 Feb 2003 09:22:17 -0000 Message-ID: <20030204092217.9036.qmail@email.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [202.134.200.4] by ws3-1.us4.outblaze.com with http for harry_suede@email.com; Tue, 04 Feb 2003 04:22:17 -0500 From: "Harry Suede" To: taylor@nortelnetworks.com Cc: megaco@ietf.org Date: Tue, 04 Feb 2003 04:22:17 -0500 X-Originating-Ip: 202.134.200.4 X-Originating-Server: ws3-1.us4.outblaze.com Content-Transfer-Encoding: 7bit Subject: [Megaco] Re: Descriptor state after out of service Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This means that ServiceChange does not change the descriptor of the termination and its upto MGC to change the descriptor. But consider this case that termination in non-null context is put to "out of service". Thus according to protocol all connections is lost. So at h/w level there is change but not in the database. Now if MG/MGC put termination back to "in service" does this mean that connection is to be re-established i.e. descriptors are to be reapply. ----- Original Message ----- From: Tom Taylor Date: Mon, 03 Feb 2003 09:58:32 -0500 To: Harry Suede Subject: Re: Descriptor state after out of service > I don't believe the ServiceChange action does anything to the descriptors on its > own. It is up to the MGC to reset them if necessary. I do have the feeling that we > might want to analyze the situation and possibly refine it. > > Harry Suede wrote: > > Hi list, Tom > > > > PL ignore my previous mail. By mistake I have written "out of service" in place of "in service" in the last line. > > > > What is the state of descriptor of a termination in a non-null context when termination is put "out of service" by MGC or MG? Does the descriptor remain on termination database but inactivated or does they are total flushed. Thus if this termination is put "in service" by MGC or MG then what will be the state of descriptor i.e. they are reapply/reactivated on the termination or not. > > > > regards > > harry > -- _______________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Meet Singles http://corp.mail.com/lavalife _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 4 04:40:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14585 for ; Tue, 4 Feb 2003 04:40:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h149jCJ12438; Tue, 4 Feb 2003 04:45:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h149iRJ12390 for ; Tue, 4 Feb 2003 04:44:27 -0500 Received: from spf1.us.outblaze.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14544 for ; Tue, 4 Feb 2003 04:38:32 -0500 (EST) Received: (qmail 17736 invoked from network); 4 Feb 2003 09:42:09 -0000 Received: from unknown (205.158.62.146) by spf1.us.outblaze.com with QMQP; 4 Feb 2003 09:42:09 -0000 Received: (qmail 11297 invoked from network); 4 Feb 2003 09:40:34 -0000 Received: from unknown (HELO ws3-2.us4.outblaze.com) (205.158.62.92) by 205-158-62-146.outblaze.com with SMTP; 4 Feb 2003 09:40:34 -0000 Received: (qmail 10171 invoked by uid 1001); 4 Feb 2003 09:42:09 -0000 Message-ID: <20030204094209.10170.qmail@email.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [202.134.200.4] by ws3-2.us4.outblaze.com with http for harry_suede@email.com; Tue, 04 Feb 2003 04:42:09 -0500 From: "Harry Suede" To: Christian.Groves@ericsson.com.au, taylor@nortelnetworks.com Cc: harry_suede@email.com, megaco@ietf.org Date: Tue, 04 Feb 2003 04:42:09 -0500 Subject: Re: [Megaco] Re: Descriptor state after out of service X-Originating-Ip: 202.134.200.4 X-Originating-Server: ws3-2.us4.outblaze.com Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit That means that "out of service" termination shall be subtracted by MGC. But how MGC shall reset the descriptor of "out of service" termination in null context. ----- Original Message ----- From: Christian Groves Date: Tue, 04 Feb 2003 10:57:32 +1100 To: Tom Taylor Subject: Re: [Megaco] Re: Descriptor state after out of service > G'Day, > > I think you should concentrate more on the method associated with the service > change that put the termination into the Out of Service state. The result of > Forced or Graceful will be that terminations are subtracted - thus if subtracted > the descriptors will be affected according to H.248.1 sect 7.2.3. > > Christian > > Tom Taylor wrote: > > > > I don't believe the ServiceChange action does anything to the descriptors on its > > own. It is up to the MGC to reset them if necessary. I do have the feeling that we > > might want to analyze the situation and possibly refine it. > > > > Harry Suede wrote: > > > Hi list, Tom > > > > > > PL ignore my previous mail. By mistake I have written "out of service" in place of "in service" in the last line. > > > > > > What is the state of descriptor of a termination in a non-null context when termination is put "out of service" by MGC or MG? Does the descriptor remain on termination database but inactivated or does they are total flushed. Thus if this termination is put "in service" by MGC or MG then what will be the state of descriptor i.e. they are reapply/reactivated on the termination or not. > > > > > > regards > > > harry > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > -- _______________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Meet Singles http://corp.mail.com/lavalife _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 4 04:41:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14609 for ; Tue, 4 Feb 2003 04:41:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h149kQf12495 for megaco-archive@odin.ietf.org; Tue, 4 Feb 2003 04:46:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h149kQJ12492 for ; Tue, 4 Feb 2003 04:46:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14591 for ; Tue, 4 Feb 2003 04:40:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h149jCJ12438; Tue, 4 Feb 2003 04:45:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h149iRJ12390 for ; Tue, 4 Feb 2003 04:44:27 -0500 Received: from spf1.us.outblaze.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14544 for ; Tue, 4 Feb 2003 04:38:32 -0500 (EST) Received: (qmail 17736 invoked from network); 4 Feb 2003 09:42:09 -0000 Received: from unknown (205.158.62.146) by spf1.us.outblaze.com with QMQP; 4 Feb 2003 09:42:09 -0000 Received: (qmail 11297 invoked from network); 4 Feb 2003 09:40:34 -0000 Received: from unknown (HELO ws3-2.us4.outblaze.com) (205.158.62.92) by 205-158-62-146.outblaze.com with SMTP; 4 Feb 2003 09:40:34 -0000 Received: (qmail 10171 invoked by uid 1001); 4 Feb 2003 09:42:09 -0000 Message-ID: <20030204094209.10170.qmail@email.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [202.134.200.4] by ws3-2.us4.outblaze.com with http for harry_suede@email.com; Tue, 04 Feb 2003 04:42:09 -0500 From: "Harry Suede" To: Christian.Groves@ericsson.com.au, taylor@nortelnetworks.com Cc: harry_suede@email.com, megaco@ietf.org Date: Tue, 04 Feb 2003 04:42:09 -0500 Subject: Re: [Megaco] Re: Descriptor state after out of service X-Originating-Ip: 202.134.200.4 X-Originating-Server: ws3-2.us4.outblaze.com Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit That means that "out of service" termination shall be subtracted by MGC. But how MGC shall reset the descriptor of "out of service" termination in null context. ----- Original Message ----- From: Christian Groves Date: Tue, 04 Feb 2003 10:57:32 +1100 To: Tom Taylor Subject: Re: [Megaco] Re: Descriptor state after out of service > G'Day, > > I think you should concentrate more on the method associated with the service > change that put the termination into the Out of Service state. The result of > Forced or Graceful will be that terminations are subtracted - thus if subtracted > the descriptors will be affected according to H.248.1 sect 7.2.3. > > Christian > > Tom Taylor wrote: > > > > I don't believe the ServiceChange action does anything to the descriptors on its > > own. It is up to the MGC to reset them if necessary. I do have the feeling that we > > might want to analyze the situation and possibly refine it. > > > > Harry Suede wrote: > > > Hi list, Tom > > > > > > PL ignore my previous mail. By mistake I have written "out of service" in place of "in service" in the last line. > > > > > > What is the state of descriptor of a termination in a non-null context when termination is put "out of service" by MGC or MG? Does the descriptor remain on termination database but inactivated or does they are total flushed. Thus if this termination is put "in service" by MGC or MG then what will be the state of descriptor i.e. they are reapply/reactivated on the termination or not. > > > > > > regards > > > harry > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > -- _______________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Meet Singles http://corp.mail.com/lavalife _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 4 05:29:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15315 for ; Tue, 4 Feb 2003 05:29:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14AXsJ14588; Tue, 4 Feb 2003 05:33:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14AV3J14539 for ; Tue, 4 Feb 2003 05:31:03 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15206 for ; Tue, 4 Feb 2003 05:25:05 -0500 (EST) From: knayar@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h14ARDj05790 for ; Tue, 4 Feb 2003 15:57:14 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h14ARCM05783 for ; Tue, 4 Feb 2003 15:57:13 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h14ATUn06290 for ; Tue, 4 Feb 2003 15:59:30 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CC3.0038D9A2 ; Tue, 4 Feb 2003 15:50:57 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CC3.0038D878.00@sandesh.hss.hns.com> Date: Tue, 4 Feb 2003 15:55:49 +0530 Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=NZ6nC3yyPtl5gIvZJCXObQBfXc06Lx42DqOzsWQdK6xeRpjTRztTGkBS" Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --0__=NZ6nC3yyPtl5gIvZJCXObQBfXc06Lx42DqOzsWQdK6xeRpjTRztTGkBS Content-type: text/plain; charset=us-ascii Content-Disposition: inline Repeating the mail. Didn't see it on the list... ---------------------- Forwarded by Kapil Nayar/HSS on 02/04/2003 04:01 PM --------------------------- Kapil Nayar 02/04/2003 10:52 AM To: "Kevin Boyle" cc: megaco@ietf.org Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism (Document link not converted) Hi Kevin Thanks for your reply... But, as per H.248.8 the definition of Service Change reason "WarmBoot" is: "This indicates that the entity indicated with the TerminationID is in ServiceState "In-Service", and that it has gone through a start, or recovery, action. All transactions in process may be lost, but otherwise all states are preserved on the termination." with a special comment: "This reason code only applies for TerminationID root" The protocol defines the usage of "WarmBoot" only for root termination. Alternatives? thanks, -kapil "Kevin Boyle" on 02/04/2003 12:50:20 AM To: Kapil Nayar/HSS@HSS, megaco@ietf.org cc: Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Comments inline. [KJBII] Kevin -----Original Message----- From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] Sent: Monday, February 03, 2003 7:19 AM To: megaco@ietf.org Subject: [Megaco] Cancel Service Change (method=Graceful) mechanism Hi It seems the protocol doesnot define any procedure for cancelling an earlier Service Change (method=Graceful) on a non-root termination. Taking a practical case: MG sends a Service Change (method=Graceful) on a termination with delay= 2 hours. After 1 hour, MG realizes that it doesn't want to put the termination out-of-service (after remaining 1 hour) as was earlier intended. How to inform the MGC of the new intentions - cancel graceful..? Sending Service Change (method =Restart) would mean that termination just came InService and doesnot have any active descriptors, whereas this is not the case. [KJBII] Why can't you use SC Restart? The Warm Boot SC Reason indicates that there was NO loss of state. Solution: MG sends Service Change (method = Graceful) delay =2 hours to inform MGC only about the intentions. MG sends Service Change (method = Forced) when the termination actually goes out-of-service after 2 hours. This ensures that if Service Change (method = Forced) never came, the intentions of MG never got materialised. [KJBII] Ick. So we will be required to send TWO SCs instead of one if we use SC Graceful? I really don't like that idea. Does any body have an alternative solution? Please suggest. thanks, kapil nayar www.hssworld.com DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --0__=NZ6nC3yyPtl5gIvZJCXObQBfXc06Lx42DqOzsWQdK6xeRpjTRztTGkBS Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTQuODkiPg0KPFRJVExFPlJFOiBbTWVn YWNvXSBDYW5jZWwgU2VydmljZSBDaGFuZ2UgKG1ldGhvZD1HcmFjZWZ1bCkgbWVjaGFuaXNtPC9U SVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KDQo8UD48Rk9OVCBTSVpFPTI+Q29tbWVudHMgaW5saW5l LiBbS0pCSUldPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+S2V2aW48L0ZPTlQ+DQo8 L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+RnJvbToga25heWFyQGhzcy5obnMuY29tIFs8QSBIUkVGPSJtYWls dG86a25heWFyQGhzcy5obnMuY29tIj5tYWlsdG86a25heWFyQGhzcy5obnMuY29tPC9BPl0gPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj5TZW50OiBNb25kYXksIEZlYnJ1YXJ5IDAzLCAyMDAzIDc6 MTkgQU08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlRvOiBtZWdhY29AaWV0Zi5vcmc8L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPlN1YmplY3Q6IFtNZWdhY29dIENhbmNlbCBTZXJ2aWNlIENoYW5n ZSAobWV0aG9kPUdyYWNlZnVsKSBtZWNoYW5pc208L0ZPTlQ+DQo8L1A+DQo8QlI+DQo8QlI+DQo8 QlI+DQoNCjxQPjxGT05UIFNJWkU9Mj5IaTwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y Pkl0IHNlZW1zIHRoZSBwcm90b2NvbCBkb2Vzbm90IGRlZmluZSBhbnkgcHJvY2VkdXJlIGZvciBj YW5jZWxsaW5nIGFuIGVhcmxpZXIgU2VydmljZSBDaGFuZ2UgKG1ldGhvZD1HcmFjZWZ1bCkgb24g YSBub24tcm9vdCB0ZXJtaW5hdGlvbi48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+VGFr aW5nIGEgcHJhY3RpY2FsIGNhc2U6PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5NRyBzZW5kcyBh IFNlcnZpY2UgQ2hhbmdlIChtZXRob2Q9R3JhY2VmdWwpIG9uIGEgdGVybWluYXRpb24gd2l0aCBk ZWxheT0gMiBob3Vycy4gQWZ0ZXIgMSBob3VyLCBNRyByZWFsaXplcyB0aGF0IGl0IGRvZXNuJ3Qg d2FudCB0byBwdXQgdGhlIHRlcm1pbmF0aW9uIG91dC1vZi1zZXJ2aWNlIChhZnRlciByZW1haW5p bmcgMSBob3VyKSBhcyB3YXMgZWFybGllciBpbnRlbmRlZC4gSG93IHRvIGluZm9ybSB0aGUgTUdD IG9mIHRoZSBuZXcgaW50ZW50aW9ucyAtIGNhbmNlbCBncmFjZWZ1bC4uPyBTZW5kaW5nIFNlcnZp Y2UgQ2hhbmdlIChtZXRob2QgPVJlc3RhcnQpIHdvdWxkIG1lYW4gdGhhdCB0ZXJtaW5hdGlvbiBq dXN0IGNhbWUgSW5TZXJ2aWNlIGFuZCBkb2Vzbm90IGhhdmUgYW55IGFjdGl2ZSBkZXNjcmlwdG9y cywgd2hlcmVhcyB0aGlzIGlzIG5vdCB0aGUgY2FzZS48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBT SVpFPTI+W0tKQklJXSBXaHkgY2FuJ3QgeW91IHVzZSBTQyBSZXN0YXJ0PyZuYnNwOyBUaGUgV2Fy bSBCb290IFNDIFJlYXNvbiBpbmRpY2F0ZXMgdGhhdCB0aGVyZSB3YXMgTk8gbG9zcyBvZiBzdGF0 ZS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5Tb2x1dGlvbjo8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPk1HIHNlbmRzIFNlcnZpY2UgQ2hhbmdlIChtZXRob2QgPSBHcmFjZWZ1bCkg ZGVsYXkgPTIgaG91cnMgdG8gaW5mb3JtIE1HQyBvbmx5IGFib3V0IHRoZSBpbnRlbnRpb25zLiBN RyBzZW5kcyBTZXJ2aWNlIENoYW5nZSAobWV0aG9kID0gRm9yY2VkKSB3aGVuIHRoZSB0ZXJtaW5h dGlvbiBhY3R1YWxseSBnb2VzIG91dC1vZi1zZXJ2aWNlIGFmdGVyIDIgaG91cnMuIFRoaXMgZW5z dXJlcyB0aGF0IGlmIFNlcnZpY2UgQ2hhbmdlIChtZXRob2QgPSBGb3JjZWQpIG5ldmVyIGNhbWUs IHRoZSBpbnRlbnRpb25zIG9mIE1HIG5ldmVyIGdvdCBtYXRlcmlhbGlzZWQuPC9GT05UPjwvUD4N Cg0KPFA+PEZPTlQgU0laRT0yPltLSkJJSV0gSWNrLiZuYnNwOyBTbyB3ZSB3aWxsIGJlIHJlcXVp cmVkIHRvIHNlbmQgVFdPIFNDcyBpbnN0ZWFkIG9mIG9uZSBpZiB3ZSB1c2UgU0MgR3JhY2VmdWw/ Jm5ic3A7IEkgcmVhbGx5IGRvbid0IGxpa2UgdGhhdCBpZGVhLjwvRk9OVD48L1A+DQoNCjxQPjxG T05UIFNJWkU9Mj5Eb2VzIGFueSBib2R5IGhhdmUgYW4gYWx0ZXJuYXRpdmUgc29sdXRpb24/IFBs ZWFzZSBzdWdnZXN0LjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPnRoYW5rcyw8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPmthcGlsIG5heWFyPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj53d3cuaHNzd29ybGQuY29tPC9GT05UPg0KPC9QPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTI+ RElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHByb3ByaWV0YXJ5IHRvIEh1Z2hlcyBTb2Z0d2Fy ZSBTeXN0ZW1zIExpbWl0ZWQgKEhTUykgYW5kIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVz ZSBvZiB0aGUgaW5kaXZpZHVhbCB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSXQgbWF5IGNvbnRh aW4mbmJzcDsgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24mbmJzcDsgYW5k IHNob3VsZCBub3QgYmUgY2lyY3VsYXRlZCBvciB1c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0 aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1l c3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3IgaW1tZWRpYXRlbHku IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgbm90aWZpZWQg dGhhdCB5b3UgYXJlIHN0cmljdGx5IHByb2hpYml0ZWQgZnJvbSB1c2luZywgY29weWluZywgYWx0 ZXJpbmcsIG9yIGRpc2Nsb3NpbmcgdGhlIGNvbnRlbnRzIG9mIHRoaXMgbWVzc2FnZS4gSFNTIGFj Y2VwdHMgbm8gcmVzcG9uc2liaWxpdHkgZm9yIGxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0 aGUgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1 ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy48L0ZPTlQ+PC9QPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpF PTI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPk1lZ2FjbyBtYWlsaW5nIGxpc3Q8L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPk1lZ2Fjb0BpZXRmLm9yZzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+PEEgSFJFRj0i aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWVnYWNvIiBUQVJHRVQ9Il9i bGFuayI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWVnYWNvPC9BPjwv Rk9OVD4NCjwvUD4NCg0KPC9CT0RZPg0KPC9IVE1MPg0K --0__=NZ6nC3yyPtl5gIvZJCXObQBfXc06Lx42DqOzsWQdK6xeRpjTRztTGkBS Content-type: text/plain; charset=us-ascii Content-Disposition: inline DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. --0__=NZ6nC3yyPtl5gIvZJCXObQBfXc06Lx42DqOzsWQdK6xeRpjTRztTGkBS-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 4 05:29:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15341 for ; Tue, 4 Feb 2003 05:29:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14AZ8K14644 for megaco-archive@odin.ietf.org; Tue, 4 Feb 2003 05:35:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14AZ8J14641 for ; Tue, 4 Feb 2003 05:35:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15326 for ; Tue, 4 Feb 2003 05:29:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14AXsJ14588; Tue, 4 Feb 2003 05:33:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14AV3J14539 for ; Tue, 4 Feb 2003 05:31:03 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15206 for ; Tue, 4 Feb 2003 05:25:05 -0500 (EST) From: knayar@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h14ARDj05790 for ; Tue, 4 Feb 2003 15:57:14 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h14ARCM05783 for ; Tue, 4 Feb 2003 15:57:13 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h14ATUn06290 for ; Tue, 4 Feb 2003 15:59:30 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CC3.0038D9A2 ; Tue, 4 Feb 2003 15:50:57 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CC3.0038D878.00@sandesh.hss.hns.com> Date: Tue, 4 Feb 2003 15:55:49 +0530 Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=NZ6nC3yyPtl5gIvZJCXObQBfXc06Lx42DqOzsWQdK6xeRpjTRztTGkBS" Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --0__=NZ6nC3yyPtl5gIvZJCXObQBfXc06Lx42DqOzsWQdK6xeRpjTRztTGkBS Content-type: text/plain; charset=us-ascii Content-Disposition: inline Repeating the mail. Didn't see it on the list... ---------------------- Forwarded by Kapil Nayar/HSS on 02/04/2003 04:01 PM --------------------------- Kapil Nayar 02/04/2003 10:52 AM To: "Kevin Boyle" cc: megaco@ietf.org Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism (Document link not converted) Hi Kevin Thanks for your reply... But, as per H.248.8 the definition of Service Change reason "WarmBoot" is: "This indicates that the entity indicated with the TerminationID is in ServiceState "In-Service", and that it has gone through a start, or recovery, action. All transactions in process may be lost, but otherwise all states are preserved on the termination." with a special comment: "This reason code only applies for TerminationID root" The protocol defines the usage of "WarmBoot" only for root termination. Alternatives? thanks, -kapil "Kevin Boyle" on 02/04/2003 12:50:20 AM To: Kapil Nayar/HSS@HSS, megaco@ietf.org cc: Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Comments inline. [KJBII] Kevin -----Original Message----- From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] Sent: Monday, February 03, 2003 7:19 AM To: megaco@ietf.org Subject: [Megaco] Cancel Service Change (method=Graceful) mechanism Hi It seems the protocol doesnot define any procedure for cancelling an earlier Service Change (method=Graceful) on a non-root termination. Taking a practical case: MG sends a Service Change (method=Graceful) on a termination with delay= 2 hours. After 1 hour, MG realizes that it doesn't want to put the termination out-of-service (after remaining 1 hour) as was earlier intended. How to inform the MGC of the new intentions - cancel graceful..? Sending Service Change (method =Restart) would mean that termination just came InService and doesnot have any active descriptors, whereas this is not the case. [KJBII] Why can't you use SC Restart? The Warm Boot SC Reason indicates that there was NO loss of state. Solution: MG sends Service Change (method = Graceful) delay =2 hours to inform MGC only about the intentions. MG sends Service Change (method = Forced) when the termination actually goes out-of-service after 2 hours. This ensures that if Service Change (method = Forced) never came, the intentions of MG never got materialised. [KJBII] Ick. So we will be required to send TWO SCs instead of one if we use SC Graceful? I really don't like that idea. Does any body have an alternative solution? Please suggest. thanks, kapil nayar www.hssworld.com DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --0__=NZ6nC3yyPtl5gIvZJCXObQBfXc06Lx42DqOzsWQdK6xeRpjTRztTGkBS Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTQuODkiPg0KPFRJVExFPlJFOiBbTWVn YWNvXSBDYW5jZWwgU2VydmljZSBDaGFuZ2UgKG1ldGhvZD1HcmFjZWZ1bCkgbWVjaGFuaXNtPC9U SVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KDQo8UD48Rk9OVCBTSVpFPTI+Q29tbWVudHMgaW5saW5l LiBbS0pCSUldPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+S2V2aW48L0ZPTlQ+DQo8 L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+RnJvbToga25heWFyQGhzcy5obnMuY29tIFs8QSBIUkVGPSJtYWls dG86a25heWFyQGhzcy5obnMuY29tIj5tYWlsdG86a25heWFyQGhzcy5obnMuY29tPC9BPl0gPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj5TZW50OiBNb25kYXksIEZlYnJ1YXJ5IDAzLCAyMDAzIDc6 MTkgQU08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlRvOiBtZWdhY29AaWV0Zi5vcmc8L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPlN1YmplY3Q6IFtNZWdhY29dIENhbmNlbCBTZXJ2aWNlIENoYW5n ZSAobWV0aG9kPUdyYWNlZnVsKSBtZWNoYW5pc208L0ZPTlQ+DQo8L1A+DQo8QlI+DQo8QlI+DQo8 QlI+DQoNCjxQPjxGT05UIFNJWkU9Mj5IaTwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y Pkl0IHNlZW1zIHRoZSBwcm90b2NvbCBkb2Vzbm90IGRlZmluZSBhbnkgcHJvY2VkdXJlIGZvciBj YW5jZWxsaW5nIGFuIGVhcmxpZXIgU2VydmljZSBDaGFuZ2UgKG1ldGhvZD1HcmFjZWZ1bCkgb24g YSBub24tcm9vdCB0ZXJtaW5hdGlvbi48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+VGFr aW5nIGEgcHJhY3RpY2FsIGNhc2U6PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5NRyBzZW5kcyBh IFNlcnZpY2UgQ2hhbmdlIChtZXRob2Q9R3JhY2VmdWwpIG9uIGEgdGVybWluYXRpb24gd2l0aCBk ZWxheT0gMiBob3Vycy4gQWZ0ZXIgMSBob3VyLCBNRyByZWFsaXplcyB0aGF0IGl0IGRvZXNuJ3Qg d2FudCB0byBwdXQgdGhlIHRlcm1pbmF0aW9uIG91dC1vZi1zZXJ2aWNlIChhZnRlciByZW1haW5p bmcgMSBob3VyKSBhcyB3YXMgZWFybGllciBpbnRlbmRlZC4gSG93IHRvIGluZm9ybSB0aGUgTUdD IG9mIHRoZSBuZXcgaW50ZW50aW9ucyAtIGNhbmNlbCBncmFjZWZ1bC4uPyBTZW5kaW5nIFNlcnZp Y2UgQ2hhbmdlIChtZXRob2QgPVJlc3RhcnQpIHdvdWxkIG1lYW4gdGhhdCB0ZXJtaW5hdGlvbiBq dXN0IGNhbWUgSW5TZXJ2aWNlIGFuZCBkb2Vzbm90IGhhdmUgYW55IGFjdGl2ZSBkZXNjcmlwdG9y cywgd2hlcmVhcyB0aGlzIGlzIG5vdCB0aGUgY2FzZS48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBT SVpFPTI+W0tKQklJXSBXaHkgY2FuJ3QgeW91IHVzZSBTQyBSZXN0YXJ0PyZuYnNwOyBUaGUgV2Fy bSBCb290IFNDIFJlYXNvbiBpbmRpY2F0ZXMgdGhhdCB0aGVyZSB3YXMgTk8gbG9zcyBvZiBzdGF0 ZS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5Tb2x1dGlvbjo8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPk1HIHNlbmRzIFNlcnZpY2UgQ2hhbmdlIChtZXRob2QgPSBHcmFjZWZ1bCkg ZGVsYXkgPTIgaG91cnMgdG8gaW5mb3JtIE1HQyBvbmx5IGFib3V0IHRoZSBpbnRlbnRpb25zLiBN RyBzZW5kcyBTZXJ2aWNlIENoYW5nZSAobWV0aG9kID0gRm9yY2VkKSB3aGVuIHRoZSB0ZXJtaW5h dGlvbiBhY3R1YWxseSBnb2VzIG91dC1vZi1zZXJ2aWNlIGFmdGVyIDIgaG91cnMuIFRoaXMgZW5z dXJlcyB0aGF0IGlmIFNlcnZpY2UgQ2hhbmdlIChtZXRob2QgPSBGb3JjZWQpIG5ldmVyIGNhbWUs IHRoZSBpbnRlbnRpb25zIG9mIE1HIG5ldmVyIGdvdCBtYXRlcmlhbGlzZWQuPC9GT05UPjwvUD4N Cg0KPFA+PEZPTlQgU0laRT0yPltLSkJJSV0gSWNrLiZuYnNwOyBTbyB3ZSB3aWxsIGJlIHJlcXVp cmVkIHRvIHNlbmQgVFdPIFNDcyBpbnN0ZWFkIG9mIG9uZSBpZiB3ZSB1c2UgU0MgR3JhY2VmdWw/ Jm5ic3A7IEkgcmVhbGx5IGRvbid0IGxpa2UgdGhhdCBpZGVhLjwvRk9OVD48L1A+DQoNCjxQPjxG T05UIFNJWkU9Mj5Eb2VzIGFueSBib2R5IGhhdmUgYW4gYWx0ZXJuYXRpdmUgc29sdXRpb24/IFBs ZWFzZSBzdWdnZXN0LjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPnRoYW5rcyw8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPmthcGlsIG5heWFyPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj53d3cuaHNzd29ybGQuY29tPC9GT05UPg0KPC9QPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTI+ RElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHByb3ByaWV0YXJ5IHRvIEh1Z2hlcyBTb2Z0d2Fy ZSBTeXN0ZW1zIExpbWl0ZWQgKEhTUykgYW5kIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVz ZSBvZiB0aGUgaW5kaXZpZHVhbCB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSXQgbWF5IGNvbnRh aW4mbmJzcDsgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24mbmJzcDsgYW5k IHNob3VsZCBub3QgYmUgY2lyY3VsYXRlZCBvciB1c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0 aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1l c3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3IgaW1tZWRpYXRlbHku IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgbm90aWZpZWQg dGhhdCB5b3UgYXJlIHN0cmljdGx5IHByb2hpYml0ZWQgZnJvbSB1c2luZywgY29weWluZywgYWx0 ZXJpbmcsIG9yIGRpc2Nsb3NpbmcgdGhlIGNvbnRlbnRzIG9mIHRoaXMgbWVzc2FnZS4gSFNTIGFj Y2VwdHMgbm8gcmVzcG9uc2liaWxpdHkgZm9yIGxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0 aGUgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1 ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy48L0ZPTlQ+PC9QPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpF PTI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPk1lZ2FjbyBtYWlsaW5nIGxpc3Q8L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPk1lZ2Fjb0BpZXRmLm9yZzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+PEEgSFJFRj0i aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWVnYWNvIiBUQVJHRVQ9Il9i bGFuayI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWVnYWNvPC9BPjwv Rk9OVD4NCjwvUD4NCg0KPC9CT0RZPg0KPC9IVE1MPg0K --0__=NZ6nC3yyPtl5gIvZJCXObQBfXc06Lx42DqOzsWQdK6xeRpjTRztTGkBS Content-type: text/plain; charset=us-ascii Content-Disposition: inline DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. --0__=NZ6nC3yyPtl5gIvZJCXObQBfXc06Lx42DqOzsWQdK6xeRpjTRztTGkBS-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 4 06:27:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16465 for ; Tue, 4 Feb 2003 06:27:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BWQJ17828; Tue, 4 Feb 2003 06:32:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BVLJ17768 for ; Tue, 4 Feb 2003 06:31:21 -0500 Received: from auds953.usa.alcatel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16281 for ; Tue, 4 Feb 2003 06:25:24 -0500 (EST) Received: from axes-mach01.axes-mach01.usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.6/8.12.6) with ESMTP id h14BSxeW024555 for ; Tue, 4 Feb 2003 05:29:00 -0600 (CST) Received: from axsppc10 by axes-mach01.axes-mach01.usa.alcatel.com (8.9.3+Sun/SMI-SVR4) id PAA21617; Tue, 4 Feb 2003 15:58:21 -0500 (GMT) Message-ID: <008a01c2cc41$49da77b0$3c01ff0a@axsppc10> From: "Paramesh" To: Date: Tue, 4 Feb 2003 17:03:44 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0085_01C2CC6F.5FE255E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Megaco] unsubscribe Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0085_01C2CC6F.5FE255E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: Paramesh=20 To: megaco@ietf.org=20 Sent: Wednesday, January 29, 2003 11:14 AM Subject: subscription ------=_NextPart_000_0085_01C2CC6F.5FE255E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
----- Original Message -----
From:=20 Paramesh
Sent: Wednesday, January 29, = 2003 11:14=20 AM
Subject: subscription

 
------=_NextPart_000_0085_01C2CC6F.5FE255E0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 4 06:27:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16487 for ; Tue, 4 Feb 2003 06:27:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14BXNw17909 for megaco-archive@odin.ietf.org; Tue, 4 Feb 2003 06:33:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BXNJ17906 for ; Tue, 4 Feb 2003 06:33:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16475 for ; Tue, 4 Feb 2003 06:27:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BWQJ17828; Tue, 4 Feb 2003 06:32:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BVLJ17768 for ; Tue, 4 Feb 2003 06:31:21 -0500 Received: from auds953.usa.alcatel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16281 for ; Tue, 4 Feb 2003 06:25:24 -0500 (EST) Received: from axes-mach01.axes-mach01.usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.6/8.12.6) with ESMTP id h14BSxeW024555 for ; Tue, 4 Feb 2003 05:29:00 -0600 (CST) Received: from axsppc10 by axes-mach01.axes-mach01.usa.alcatel.com (8.9.3+Sun/SMI-SVR4) id PAA21617; Tue, 4 Feb 2003 15:58:21 -0500 (GMT) Message-ID: <008a01c2cc41$49da77b0$3c01ff0a@axsppc10> From: "Paramesh" To: Date: Tue, 4 Feb 2003 17:03:44 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0085_01C2CC6F.5FE255E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Megaco] unsubscribe Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0085_01C2CC6F.5FE255E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: Paramesh=20 To: megaco@ietf.org=20 Sent: Wednesday, January 29, 2003 11:14 AM Subject: subscription ------=_NextPart_000_0085_01C2CC6F.5FE255E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
----- Original Message -----
From:=20 Paramesh
Sent: Wednesday, January 29, = 2003 11:14=20 AM
Subject: subscription

 
------=_NextPart_000_0085_01C2CC6F.5FE255E0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 4 06:35:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16663 for ; Tue, 4 Feb 2003 06:35:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BeVJ18955; Tue, 4 Feb 2003 06:40:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BdWJ18872 for ; Tue, 4 Feb 2003 06:39:32 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16596 for ; Tue, 4 Feb 2003 06:33:32 -0500 (EST) From: vnanda@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h14BZlj18339 for ; Tue, 4 Feb 2003 17:05:47 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h14BZjM18332 for ; Tue, 4 Feb 2003 17:05:45 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h14Bc7c11003 for ; Tue, 4 Feb 2003 17:08:07 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CC3.003F2238 ; Tue, 4 Feb 2003 16:59:35 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CC3.003F2123.00@sandesh.hss.hns.com> Date: Tue, 4 Feb 2003 17:09:27 +0530 Subject: [Megaco] unsubscribe Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 4 06:36:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16683 for ; Tue, 4 Feb 2003 06:36:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14BfTA19018 for megaco-archive@odin.ietf.org; Tue, 4 Feb 2003 06:41:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BfSJ19015 for ; Tue, 4 Feb 2003 06:41:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16668 for ; Tue, 4 Feb 2003 06:35:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BeVJ18955; Tue, 4 Feb 2003 06:40:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BdWJ18872 for ; Tue, 4 Feb 2003 06:39:32 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16596 for ; Tue, 4 Feb 2003 06:33:32 -0500 (EST) From: vnanda@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h14BZlj18339 for ; Tue, 4 Feb 2003 17:05:47 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h14BZjM18332 for ; Tue, 4 Feb 2003 17:05:45 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h14Bc7c11003 for ; Tue, 4 Feb 2003 17:08:07 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CC3.003F2238 ; Tue, 4 Feb 2003 16:59:35 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CC3.003F2123.00@sandesh.hss.hns.com> Date: Tue, 4 Feb 2003 17:09:27 +0530 Subject: [Megaco] unsubscribe Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 4 09:11:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22942 for ; Tue, 4 Feb 2003 09:11:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14EGmJ29468; Tue, 4 Feb 2003 09:16:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14EFHJ29421 for ; Tue, 4 Feb 2003 09:15:17 -0500 Received: from wiprom2mx1.wipro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22874 for ; Tue, 4 Feb 2003 09:09:16 -0500 (EST) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h14ECov27163 for ; Tue, 4 Feb 2003 19:42:50 +0530 (IST) Received: from blr-ec-msg03.wipro.com ([10.200.52.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 4 Feb 2003 19:42:45 +0530 Received: from SureshHB ([192.168.85.8]) by blr-ec-msg03.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 4 Feb 2003 19:42:44 +0530 Message-ID: <02a101c2cc57$e0a55d70$0b01a8c0@SureshHB> Reply-To: "Suresh H.B" From: "Suresh H.B" To: Subject: [Megaco] unsubscribe Date: Tue, 4 Feb 2003 19:45:31 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-921b5ed2-359b-11d7-ba7f-006067005148" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 X-OriginalArrivalTime: 04 Feb 2003 14:12:44.0995 (UTC) FILETIME=[7CED6930:01C2CC57] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPartTM-000-921b5ed2-359b-11d7-ba7f-006067005148 Content-Type: multipart/alternative; boundary="----=_NextPart_000_029E_01C2CC85.FA12ADC0" ------=_NextPart_000_029E_01C2CC85.FA12ADC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_029E_01C2CC85.FA12ADC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_029E_01C2CC85.FA12ADC0-- ------=_NextPartTM-000-921b5ed2-359b-11d7-ba7f-006067005148-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 4 09:12:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22987 for ; Tue, 4 Feb 2003 09:12:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14EHrw29549 for megaco-archive@odin.ietf.org; Tue, 4 Feb 2003 09:17:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14EHrJ29546 for ; Tue, 4 Feb 2003 09:17:53 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22956 for ; Tue, 4 Feb 2003 09:11:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14EGmJ29468; Tue, 4 Feb 2003 09:16:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14EFHJ29421 for ; Tue, 4 Feb 2003 09:15:17 -0500 Received: from wiprom2mx1.wipro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22874 for ; Tue, 4 Feb 2003 09:09:16 -0500 (EST) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h14ECov27163 for ; Tue, 4 Feb 2003 19:42:50 +0530 (IST) Received: from blr-ec-msg03.wipro.com ([10.200.52.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 4 Feb 2003 19:42:45 +0530 Received: from SureshHB ([192.168.85.8]) by blr-ec-msg03.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 4 Feb 2003 19:42:44 +0530 Message-ID: <02a101c2cc57$e0a55d70$0b01a8c0@SureshHB> Reply-To: "Suresh H.B" From: "Suresh H.B" To: Subject: [Megaco] unsubscribe Date: Tue, 4 Feb 2003 19:45:31 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-921b5ed2-359b-11d7-ba7f-006067005148" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 X-OriginalArrivalTime: 04 Feb 2003 14:12:44.0995 (UTC) FILETIME=[7CED6930:01C2CC57] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPartTM-000-921b5ed2-359b-11d7-ba7f-006067005148 Content-Type: multipart/alternative; boundary="----=_NextPart_000_029E_01C2CC85.FA12ADC0" ------=_NextPart_000_029E_01C2CC85.FA12ADC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_029E_01C2CC85.FA12ADC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_029E_01C2CC85.FA12ADC0-- ------=_NextPartTM-000-921b5ed2-359b-11d7-ba7f-006067005148-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 4 10:25:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25103 for ; Tue, 4 Feb 2003 10:25:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14FTfJ01305; Tue, 4 Feb 2003 10:29:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14FSnJ01259 for ; Tue, 4 Feb 2003 10:28:49 -0500 Received: from zrtps0kn.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25048 for ; Tue, 4 Feb 2003 10:22:47 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h14FQNs21832 for ; Tue, 4 Feb 2003 10:26:23 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1DC5ZATM>; Tue, 4 Feb 2003 10:26:23 -0500 Message-ID: From: "Kevin Boyle" To: knayar@hss.hns.com Cc: megaco@ietf.org Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Date: Tue, 4 Feb 2003 10:26:22 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , That's what I get for not looking it up first. Try 900. Kevin -----Original Message----- From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] Sent: Tuesday, February 04, 2003 12:22 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: megaco@ietf.org Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Hi Kevin Thanks for your reply... But, as per H.248.8 the definition of Service Change reason "WarmBoot" is: "This indicates that the entity indicated with the TerminationID is in ServiceState "In-Service", and that it has gone through a start, or recovery, action. All transactions in process may be lost, but otherwise all states are preserved on the termination." with a special comment: "This reason code only applies for TerminationID root" The protocol defines the usage of "WarmBoot" only for root termination. Alternatives? thanks, -kapil "Kevin Boyle" on 02/04/2003 12:50:20 AM To: Kapil Nayar/HSS@HSS, megaco@ietf.org cc: Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Comments inline. [KJBII] Kevin -----Original Message----- From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] Sent: Monday, February 03, 2003 7:19 AM To: megaco@ietf.org Subject: [Megaco] Cancel Service Change (method=Graceful) mechanism Hi It seems the protocol doesnot define any procedure for cancelling an earlier Service Change (method=Graceful) on a non-root termination. Taking a practical case: MG sends a Service Change (method=Graceful) on a termination with delay= 2 hours. After 1 hour, MG realizes that it doesn't want to put the termination out-of-service (after remaining 1 hour) as was earlier intended. How to inform the MGC of the new intentions - cancel graceful..? Sending Service Change (method =Restart) would mean that termination just came InService and doesnot have any active descriptors, whereas this is not the case. [KJBII] Why can't you use SC Restart? The Warm Boot SC Reason indicates that there was NO loss of state. Solution: MG sends Service Change (method = Graceful) delay =2 hours to inform MGC only about the intentions. MG sends Service Change (method = Forced) when the termination actually goes out-of-service after 2 hours. This ensures that if Service Change (method = Forced) never came, the intentions of MG never got materialised. [KJBII] Ick. So we will be required to send TWO SCs instead of one if we use SC Graceful? I really don't like that idea. Does any body have an alternative solution? Please suggest. thanks, kapil nayar www.hssworld.com DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 4 10:25:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25147 for ; Tue, 4 Feb 2003 10:25:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14FVAu01416 for megaco-archive@odin.ietf.org; Tue, 4 Feb 2003 10:31:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14FVAJ01412 for ; Tue, 4 Feb 2003 10:31:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25114 for ; Tue, 4 Feb 2003 10:25:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14FTfJ01305; Tue, 4 Feb 2003 10:29:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14FSnJ01259 for ; Tue, 4 Feb 2003 10:28:49 -0500 Received: from zrtps0kn.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25048 for ; Tue, 4 Feb 2003 10:22:47 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h14FQNs21832 for ; Tue, 4 Feb 2003 10:26:23 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1DC5ZATM>; Tue, 4 Feb 2003 10:26:23 -0500 Message-ID: From: "Kevin Boyle" To: knayar@hss.hns.com Cc: megaco@ietf.org Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Date: Tue, 4 Feb 2003 10:26:22 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , That's what I get for not looking it up first. Try 900. Kevin -----Original Message----- From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] Sent: Tuesday, February 04, 2003 12:22 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: megaco@ietf.org Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Hi Kevin Thanks for your reply... But, as per H.248.8 the definition of Service Change reason "WarmBoot" is: "This indicates that the entity indicated with the TerminationID is in ServiceState "In-Service", and that it has gone through a start, or recovery, action. All transactions in process may be lost, but otherwise all states are preserved on the termination." with a special comment: "This reason code only applies for TerminationID root" The protocol defines the usage of "WarmBoot" only for root termination. Alternatives? thanks, -kapil "Kevin Boyle" on 02/04/2003 12:50:20 AM To: Kapil Nayar/HSS@HSS, megaco@ietf.org cc: Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Comments inline. [KJBII] Kevin -----Original Message----- From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] Sent: Monday, February 03, 2003 7:19 AM To: megaco@ietf.org Subject: [Megaco] Cancel Service Change (method=Graceful) mechanism Hi It seems the protocol doesnot define any procedure for cancelling an earlier Service Change (method=Graceful) on a non-root termination. Taking a practical case: MG sends a Service Change (method=Graceful) on a termination with delay= 2 hours. After 1 hour, MG realizes that it doesn't want to put the termination out-of-service (after remaining 1 hour) as was earlier intended. How to inform the MGC of the new intentions - cancel graceful..? Sending Service Change (method =Restart) would mean that termination just came InService and doesnot have any active descriptors, whereas this is not the case. [KJBII] Why can't you use SC Restart? The Warm Boot SC Reason indicates that there was NO loss of state. Solution: MG sends Service Change (method = Graceful) delay =2 hours to inform MGC only about the intentions. MG sends Service Change (method = Forced) when the termination actually goes out-of-service after 2 hours. This ensures that if Service Change (method = Forced) never came, the intentions of MG never got materialised. [KJBII] Ick. So we will be required to send TWO SCs instead of one if we use SC Graceful? I really don't like that idea. Does any body have an alternative solution? Please suggest. thanks, kapil nayar www.hssworld.com DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 4 10:55:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26051 for ; Tue, 4 Feb 2003 10:55:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14G0IJ03564; Tue, 4 Feb 2003 11:00:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14FxhJ03488 for ; Tue, 4 Feb 2003 10:59:43 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25977 for ; Tue, 4 Feb 2003 10:53:38 -0500 (EST) From: knayar@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h14Ftpj23348 for ; Tue, 4 Feb 2003 21:25:51 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h14FtoM23343; Tue, 4 Feb 2003 21:25:50 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h14FwAq23503; Tue, 4 Feb 2003 21:28:10 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CC3.0056EF4B ; Tue, 4 Feb 2003 21:19:33 +0530 X-Lotus-FromDomain: HSS To: "Kevin Boyle" cc: megaco@ietf.org Message-ID: <65256CC3.0056ED77.00@sandesh.hss.hns.com> Date: Tue, 4 Feb 2003 21:24:22 +0530 Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=FtE7dLV0ytv7zIFQYY9POKm9iRVXZaXCuZlRWKpJXoSMv07dGuD3oKzu" Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --0__=FtE7dLV0ytv7zIFQYY9POKm9iRVXZaXCuZlRWKpJXoSMv07dGuD3oKzu Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi Kevin Thanks again for the reply. Don't worry...it can happen with anybody...neways I didn't mean to offend you. But, I still have a doubt - 900 would be used for 2 cases: 1). Termination state changed from OutOfService to InService. 2). Cancelling Graceful on an InService termination. Is this overloading of the Service Change reason OK. Do we need any additional text in the docs? How do we define the state of descriptors on the terminations in both the cases - is there any difference? -kapil "Kevin Boyle" on 02/04/2003 08:56:22 PM To: Kapil Nayar/HSS@HSS cc: megaco@ietf.org Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism That's what I get for not looking it up first. Try 900. Kevin -----Original Message----- From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] Sent: Tuesday, February 04, 2003 12:22 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: megaco@ietf.org Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Hi Kevin Thanks for your reply... But, as per H.248.8 the definition of Service Change reason "WarmBoot" is: "This indicates that the entity indicated with the TerminationID is in ServiceState "In-Service", and that it has gone through a start, or recovery, action. All transactions in process may be lost, but otherwise all states are preserved on the termination." with a special comment: "This reason code only applies for TerminationID root" The protocol defines the usage of "WarmBoot" only for root termination. Alternatives? thanks, -kapil "Kevin Boyle" on 02/04/2003 12:50:20 AM To: Kapil Nayar/HSS@HSS, megaco@ietf.org cc: Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Comments inline. [KJBII] Kevin -----Original Message----- From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] Sent: Monday, February 03, 2003 7:19 AM To: megaco@ietf.org Subject: [Megaco] Cancel Service Change (method=Graceful) mechanism Hi It seems the protocol doesnot define any procedure for cancelling an earlier Service Change (method=Graceful) on a non-root termination. Taking a practical case: MG sends a Service Change (method=Graceful) on a termination with delay= 2 hours. After 1 hour, MG realizes that it doesn't want to put the termination out-of-service (after remaining 1 hour) as was earlier intended. How to inform the MGC of the new intentions - cancel graceful..? Sending Service Change (method =Restart) would mean that termination just came InService and doesnot have any active descriptors, whereas this is not the case. [KJBII] Why can't you use SC Restart? The Warm Boot SC Reason indicates that there was NO loss of state. Solution: MG sends Service Change (method = Graceful) delay =2 hours to inform MGC only about the intentions. MG sends Service Change (method = Forced) when the termination actually goes out-of-service after 2 hours. This ensures that if Service Change (method = Forced) never came, the intentions of MG never got materialised. [KJBII] Ick. So we will be required to send TWO SCs instead of one if we use SC Graceful? I really don't like that idea. Does any body have an alternative solution? Please suggest. thanks, kapil nayar www.hssworld.com DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --0__=FtE7dLV0ytv7zIFQYY9POKm9iRVXZaXCuZlRWKpJXoSMv07dGuD3oKzu Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTQuODkiPg0KPFRJVExFPlJFOiBbTWVn YWNvXSBDYW5jZWwgU2VydmljZSBDaGFuZ2UgKG1ldGhvZD1HcmFjZWZ1bCkgbWVjaGFuaXNtPC9U SVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KDQo8UD48Rk9OVCBTSVpFPTI+VGhhdCdzIHdoYXQgSSBn ZXQgZm9yIG5vdCBsb29raW5nIGl0IHVwIGZpcnN0LiZuYnNwOyBUcnkgOTAwLjwvRk9OVD4NCjwv UD4NCg0KPFA+PEZPTlQgU0laRT0yPktldmluPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpF PTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkZy b206IGtuYXlhckBoc3MuaG5zLmNvbSBbPEEgSFJFRj0ibWFpbHRvOmtuYXlhckBoc3MuaG5zLmNv bSI+bWFpbHRvOmtuYXlhckBoc3MuaG5zLmNvbTwvQT5dIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF PTI+U2VudDogVHVlc2RheSwgRmVicnVhcnkgMDQsIDIwMDMgMTI6MjIgQU08L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPlRvOiBCb3lsZSwgS2V2aW4gW05DUlRQOjNaNDA6RVhDSF08L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPkNjOiBtZWdhY29AaWV0Zi5vcmc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPlN1YmplY3Q6IFJFOiBbTWVnYWNvXSBDYW5jZWwgU2VydmljZSBDaGFuZ2UgKG1ldGhvZD1H cmFjZWZ1bCkgbWVjaGFuaXNtPC9GT05UPg0KPC9QPg0KPEJSPg0KPEJSPg0KPEJSPg0KDQo8UD48 Rk9OVCBTSVpFPTI+SGkgS2V2aW48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5UaGFu a3MgZm9yIHlvdXIgcmVwbHkuLi48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkJ1dCwgYXMgcGVy IEguMjQ4LjggdGhlIGRlZmluaXRpb24gb2YgU2VydmljZSBDaGFuZ2UgcmVhc29uICZxdW90O1dh cm1Cb290JnF1b3Q7IGlzOjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPiZxdW90O1Ro aXMmbmJzcDsgaW5kaWNhdGVzJm5ic3A7IHRoYXQmbmJzcDsgdGhlJm5ic3A7IGVudGl0eSZuYnNw OyBpbmRpY2F0ZWQmbmJzcDsgd2l0aCZuYnNwOyB0aGUmbmJzcDsgVGVybWluYXRpb25JRCZuYnNw OyBpcyZuYnNwOyBpbiBTZXJ2aWNlU3RhdGUmbmJzcDsgJnF1b3Q7SW4tU2VydmljZSZxdW90Oywm bmJzcDsgYW5kJm5ic3A7IHRoYXQgaXQgaGFzIGdvbmUgdGhyb3VnaCBhIHN0YXJ0LCBvciByZWNv dmVyeSwgYWN0aW9uLiZuYnNwOyBBbGwmbmJzcDsgdHJhbnNhY3Rpb25zJm5ic3A7IGluIHByb2Nl c3MgbWF5IGJlIGxvc3QsIGJ1dCBvdGhlcndpc2UgYWxsIHN0YXRlcyBhcmUgcHJlc2VydmVkIG9u IHRoZSB0ZXJtaW5hdGlvbi4mcXVvdDs8L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+d2l0 aCBhIHNwZWNpYWwgY29tbWVudDogJnF1b3Q7VGhpcyByZWFzb24gY29kZSBvbmx5IGFwcGxpZXMg Zm9yIFRlcm1pbmF0aW9uSUQgcm9vdCZxdW90OyBUaGUgcHJvdG9jb2wgZGVmaW5lcyB0aGUgdXNh Z2Ugb2YgJnF1b3Q7V2FybUJvb3QmcXVvdDsgb25seSBmb3Igcm9vdCB0ZXJtaW5hdGlvbi48L0ZP TlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+QWx0ZXJuYXRpdmVzPzwvRk9OVD4NCjwvUD4NCg0K PFA+PEZPTlQgU0laRT0yPnRoYW5rcyw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPi1rYXBpbDwv Rk9OVD4NCjwvUD4NCjxCUj4NCjxCUj4NCjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yPiZxdW90O0tl dmluIEJveWxlJnF1b3Q7ICZsdDtrYm95bGVAbm9ydGVsbmV0d29ya3MuY29tJmd0OyBvbiAwMi8w NC8yMDAzIDEyOjUwOjIwIEFNPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+VG86Jm5i c3A7Jm5ic3A7IEthcGlsIE5heWFyL0hTU0BIU1MsIG1lZ2Fjb0BpZXRmLm9yZzwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Y2M6PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+U3ViamVj dDombmJzcDsgUkU6IFtNZWdhY29dIENhbmNlbCBTZXJ2aWNlIENoYW5nZSAobWV0aG9kPUdyYWNl ZnVsKSBtZWNoYW5pc208L0ZPTlQ+DQo8L1A+DQo8QlI+DQo8QlI+DQo8QlI+DQoNCjxQPjxGT05U IFNJWkU9Mj5Db21tZW50cyBpbmxpbmUuIFtLSkJJSV08L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05U IFNJWkU9Mj5LZXZpbjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5Gcm9tOiBrbmF5YXJAaHNz Lmhucy5jb20gWzxBIEhSRUY9Im1haWx0bzprbmF5YXJAaHNzLmhucy5jb20iPm1haWx0bzprbmF5 YXJAaHNzLmhucy5jb208L0E+XTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+U2VudDogTW9uZGF5 LCBGZWJydWFyeSAwMywgMjAwMyA3OjE5IEFNPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5Ubzog bWVnYWNvQGlldGYub3JnPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5TdWJqZWN0OiBbTWVnYWNv XSBDYW5jZWwgU2VydmljZSBDaGFuZ2UgKG1ldGhvZD1HcmFjZWZ1bCkgbWVjaGFuaXNtPC9GT05U Pg0KPC9QPg0KPEJSPg0KPEJSPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTI+SGk8L0ZPTlQ+DQo8 L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5JdCBzZWVtcyB0aGUgcHJvdG9jb2wgZG9lc25vdCBkZWZp bmUgYW55IHByb2NlZHVyZSBmb3IgY2FuY2VsbGluZyBhbiBlYXJsaWVyIFNlcnZpY2UgQ2hhbmdl IChtZXRob2Q9R3JhY2VmdWwpIG9uIGEgbm9uLXJvb3QgdGVybWluYXRpb24uPC9GT05UPjwvUD4N Cg0KPFA+PEZPTlQgU0laRT0yPlRha2luZyBhIHByYWN0aWNhbCBjYXNlOjwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+TUcgc2VuZHMgYSBTZXJ2aWNlIENoYW5nZSAobWV0aG9kPUdyYWNlZnVsKSBv biBhIHRlcm1pbmF0aW9uIHdpdGggZGVsYXk9IDIgaG91cnMuIEFmdGVyIDEgaG91ciwgTUcgcmVh bGl6ZXMgdGhhdCBpdCBkb2Vzbid0IHdhbnQgdG8gcHV0IHRoZSB0ZXJtaW5hdGlvbiBvdXQtb2Yt c2VydmljZSAoYWZ0ZXIgcmVtYWluaW5nIDEgaG91cikgYXMgd2FzIGVhcmxpZXIgaW50ZW5kZWQu IEhvdyB0byBpbmZvcm0gdGhlIE1HQyBvZiB0aGUgbmV3IGludGVudGlvbnMgLSBjYW5jZWwgZ3Jh Y2VmdWwuLj8gU2VuZGluZyBTZXJ2aWNlIENoYW5nZSAobWV0aG9kID1SZXN0YXJ0KSB3b3VsZCBt ZWFuIHRoYXQgdGVybWluYXRpb24ganVzdCBjYW1lIEluU2VydmljZSBhbmQgZG9lc25vdCBoYXZl IGFueSBhY3RpdmUgZGVzY3JpcHRvcnMsIHdoZXJlYXMgdGhpcyBpcyBub3QgdGhlIGNhc2UuPC9G T05UPjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPltLSkJJSV0gV2h5IGNhbid0IHlvdSB1c2UgU0Mg UmVzdGFydD8mbmJzcDsgVGhlIFdhcm0gQm9vdCBTQyBSZWFzb24gaW5kaWNhdGVzIHRoYXQgdGhl cmUgd2FzIE5PIGxvc3Mgb2Ygc3RhdGUuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+ U29sdXRpb246PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5NRyBzZW5kcyBTZXJ2aWNlIENoYW5n ZSAobWV0aG9kID0gR3JhY2VmdWwpIGRlbGF5ID0yIGhvdXJzIHRvIGluZm9ybSBNR0Mgb25seSBh Ym91dCB0aGUgaW50ZW50aW9ucy4gTUcgc2VuZHMgU2VydmljZSBDaGFuZ2UgKG1ldGhvZCA9IEZv cmNlZCkgd2hlbiB0aGUgdGVybWluYXRpb24gYWN0dWFsbHkgZ29lcyBvdXQtb2Ytc2VydmljZSBh ZnRlciAyIGhvdXJzLiBUaGlzIGVuc3VyZXMgdGhhdCBpZiBTZXJ2aWNlIENoYW5nZSAobWV0aG9k ID0gRm9yY2VkKSBuZXZlciBjYW1lLCB0aGUgaW50ZW50aW9ucyBvZiBNRyBuZXZlciBnb3QgbWF0 ZXJpYWxpc2VkLjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5bS0pCSUldIEljay4mbmJz cDsgU28gd2Ugd2lsbCBiZSByZXF1aXJlZCB0byBzZW5kIFRXTyBTQ3MgaW5zdGVhZCBvZiBvbmUg aWYgd2UgdXNlIFNDIEdyYWNlZnVsPyZuYnNwOyBJIHJlYWxseSBkb24ndCBsaWtlIHRoYXQgaWRl YS48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+RG9lcyBhbnkgYm9keSBoYXZlIGFuIGFs dGVybmF0aXZlIHNvbHV0aW9uPyBQbGVhc2Ugc3VnZ2VzdC48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxG T05UIFNJWkU9Mj50aGFua3MsPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5rYXBpbCBuYXlhcjwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+d3d3Lmhzc3dvcmxkLmNvbTwvRk9OVD4NCjwvUD4NCjxC Uj4NCg0KPFA+PEZPTlQgU0laRT0yPkRJU0NMQUlNRVI6IFRoaXMgbWVzc2FnZSBpcyBwcm9wcmll dGFyeSB0byBIdWdoZXMgU29mdHdhcmUgU3lzdGVtcyBMaW1pdGVkPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4oSFNTKSBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBp bmRpdmlkdWFsIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiZuYnNwOyBw cml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiZuYnNwOyBhbmQgc2hvdWxkIG5v dCBiZSBjaXJjdWxhdGVkIG9yIHVzZWQgZm9yIGFueSBwdXJwb3NlIG90aGVyIHRoYW4gZm9yIHdo YXQgaXQgaXMgaW50ZW5kZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBpbW1lZGlhdGVseS4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBub3RpZmllZCB0aGF0IHlvdSBh cmUgc3RyaWN0bHkgcHJvaGliaXRlZCBmcm9tIHVzaW5nLCBjb3B5aW5nLCBhbHRlcmluZywgb3Ig ZGlzY2xvc2luZyB0aGUgY29udGVudHMgb2YgdGhpcyBtZXNzYWdlLiBIU1MgYWNjZXB0cyBubyBy ZXNwb25zaWJpbGl0eSBmb3IgbG9zcyBvciBkYW1hZ2UgYXJpc2luZyBmcm9tIHRoZSB1c2Ugb2Yg dGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkIGJ5IHRoaXMgZW1haWwgaW5jbHVkaW5nIGRhbWFn ZSBmcm9tIHZpcnVzLjwvRk9OVD48L1A+DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9Mj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+TWVnYWNvIG1haWxpbmcgbGlzdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+TWVn YWNvQGlldGYub3JnPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj48QSBIUkVGPSJodHRwczovL3d3 dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tZWdhY28iIFRBUkdFVD0iX2JsYW5rIj5odHRw czovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tZWdhY288L0E+PC9GT05UPg0KPC9Q Pg0KDQo8L0JPRFk+DQo8L0hUTUw+DQo= --0__=FtE7dLV0ytv7zIFQYY9POKm9iRVXZaXCuZlRWKpJXoSMv07dGuD3oKzu-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 4 10:56:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26078 for ; Tue, 4 Feb 2003 10:56:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14G1xo03699 for megaco-archive@odin.ietf.org; Tue, 4 Feb 2003 11:01:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14G1xJ03696 for ; Tue, 4 Feb 2003 11:01:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26065 for ; Tue, 4 Feb 2003 10:55:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14G0IJ03564; Tue, 4 Feb 2003 11:00:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14FxhJ03488 for ; Tue, 4 Feb 2003 10:59:43 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25977 for ; Tue, 4 Feb 2003 10:53:38 -0500 (EST) From: knayar@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h14Ftpj23348 for ; Tue, 4 Feb 2003 21:25:51 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h14FtoM23343; Tue, 4 Feb 2003 21:25:50 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h14FwAq23503; Tue, 4 Feb 2003 21:28:10 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CC3.0056EF4B ; Tue, 4 Feb 2003 21:19:33 +0530 X-Lotus-FromDomain: HSS To: "Kevin Boyle" cc: megaco@ietf.org Message-ID: <65256CC3.0056ED77.00@sandesh.hss.hns.com> Date: Tue, 4 Feb 2003 21:24:22 +0530 Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=FtE7dLV0ytv7zIFQYY9POKm9iRVXZaXCuZlRWKpJXoSMv07dGuD3oKzu" Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --0__=FtE7dLV0ytv7zIFQYY9POKm9iRVXZaXCuZlRWKpJXoSMv07dGuD3oKzu Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi Kevin Thanks again for the reply. Don't worry...it can happen with anybody...neways I didn't mean to offend you. But, I still have a doubt - 900 would be used for 2 cases: 1). Termination state changed from OutOfService to InService. 2). Cancelling Graceful on an InService termination. Is this overloading of the Service Change reason OK. Do we need any additional text in the docs? How do we define the state of descriptors on the terminations in both the cases - is there any difference? -kapil "Kevin Boyle" on 02/04/2003 08:56:22 PM To: Kapil Nayar/HSS@HSS cc: megaco@ietf.org Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism That's what I get for not looking it up first. Try 900. Kevin -----Original Message----- From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] Sent: Tuesday, February 04, 2003 12:22 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: megaco@ietf.org Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Hi Kevin Thanks for your reply... But, as per H.248.8 the definition of Service Change reason "WarmBoot" is: "This indicates that the entity indicated with the TerminationID is in ServiceState "In-Service", and that it has gone through a start, or recovery, action. All transactions in process may be lost, but otherwise all states are preserved on the termination." with a special comment: "This reason code only applies for TerminationID root" The protocol defines the usage of "WarmBoot" only for root termination. Alternatives? thanks, -kapil "Kevin Boyle" on 02/04/2003 12:50:20 AM To: Kapil Nayar/HSS@HSS, megaco@ietf.org cc: Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Comments inline. [KJBII] Kevin -----Original Message----- From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] Sent: Monday, February 03, 2003 7:19 AM To: megaco@ietf.org Subject: [Megaco] Cancel Service Change (method=Graceful) mechanism Hi It seems the protocol doesnot define any procedure for cancelling an earlier Service Change (method=Graceful) on a non-root termination. Taking a practical case: MG sends a Service Change (method=Graceful) on a termination with delay= 2 hours. After 1 hour, MG realizes that it doesn't want to put the termination out-of-service (after remaining 1 hour) as was earlier intended. How to inform the MGC of the new intentions - cancel graceful..? Sending Service Change (method =Restart) would mean that termination just came InService and doesnot have any active descriptors, whereas this is not the case. [KJBII] Why can't you use SC Restart? The Warm Boot SC Reason indicates that there was NO loss of state. Solution: MG sends Service Change (method = Graceful) delay =2 hours to inform MGC only about the intentions. MG sends Service Change (method = Forced) when the termination actually goes out-of-service after 2 hours. This ensures that if Service Change (method = Forced) never came, the intentions of MG never got materialised. [KJBII] Ick. So we will be required to send TWO SCs instead of one if we use SC Graceful? I really don't like that idea. Does any body have an alternative solution? Please suggest. thanks, kapil nayar www.hssworld.com DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --0__=FtE7dLV0ytv7zIFQYY9POKm9iRVXZaXCuZlRWKpJXoSMv07dGuD3oKzu Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTQuODkiPg0KPFRJVExFPlJFOiBbTWVn YWNvXSBDYW5jZWwgU2VydmljZSBDaGFuZ2UgKG1ldGhvZD1HcmFjZWZ1bCkgbWVjaGFuaXNtPC9U SVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KDQo8UD48Rk9OVCBTSVpFPTI+VGhhdCdzIHdoYXQgSSBn ZXQgZm9yIG5vdCBsb29raW5nIGl0IHVwIGZpcnN0LiZuYnNwOyBUcnkgOTAwLjwvRk9OVD4NCjwv UD4NCg0KPFA+PEZPTlQgU0laRT0yPktldmluPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpF PTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkZy b206IGtuYXlhckBoc3MuaG5zLmNvbSBbPEEgSFJFRj0ibWFpbHRvOmtuYXlhckBoc3MuaG5zLmNv bSI+bWFpbHRvOmtuYXlhckBoc3MuaG5zLmNvbTwvQT5dIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF PTI+U2VudDogVHVlc2RheSwgRmVicnVhcnkgMDQsIDIwMDMgMTI6MjIgQU08L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPlRvOiBCb3lsZSwgS2V2aW4gW05DUlRQOjNaNDA6RVhDSF08L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPkNjOiBtZWdhY29AaWV0Zi5vcmc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPlN1YmplY3Q6IFJFOiBbTWVnYWNvXSBDYW5jZWwgU2VydmljZSBDaGFuZ2UgKG1ldGhvZD1H cmFjZWZ1bCkgbWVjaGFuaXNtPC9GT05UPg0KPC9QPg0KPEJSPg0KPEJSPg0KPEJSPg0KDQo8UD48 Rk9OVCBTSVpFPTI+SGkgS2V2aW48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5UaGFu a3MgZm9yIHlvdXIgcmVwbHkuLi48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkJ1dCwgYXMgcGVy IEguMjQ4LjggdGhlIGRlZmluaXRpb24gb2YgU2VydmljZSBDaGFuZ2UgcmVhc29uICZxdW90O1dh cm1Cb290JnF1b3Q7IGlzOjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPiZxdW90O1Ro aXMmbmJzcDsgaW5kaWNhdGVzJm5ic3A7IHRoYXQmbmJzcDsgdGhlJm5ic3A7IGVudGl0eSZuYnNw OyBpbmRpY2F0ZWQmbmJzcDsgd2l0aCZuYnNwOyB0aGUmbmJzcDsgVGVybWluYXRpb25JRCZuYnNw OyBpcyZuYnNwOyBpbiBTZXJ2aWNlU3RhdGUmbmJzcDsgJnF1b3Q7SW4tU2VydmljZSZxdW90Oywm bmJzcDsgYW5kJm5ic3A7IHRoYXQgaXQgaGFzIGdvbmUgdGhyb3VnaCBhIHN0YXJ0LCBvciByZWNv dmVyeSwgYWN0aW9uLiZuYnNwOyBBbGwmbmJzcDsgdHJhbnNhY3Rpb25zJm5ic3A7IGluIHByb2Nl c3MgbWF5IGJlIGxvc3QsIGJ1dCBvdGhlcndpc2UgYWxsIHN0YXRlcyBhcmUgcHJlc2VydmVkIG9u IHRoZSB0ZXJtaW5hdGlvbi4mcXVvdDs8L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+d2l0 aCBhIHNwZWNpYWwgY29tbWVudDogJnF1b3Q7VGhpcyByZWFzb24gY29kZSBvbmx5IGFwcGxpZXMg Zm9yIFRlcm1pbmF0aW9uSUQgcm9vdCZxdW90OyBUaGUgcHJvdG9jb2wgZGVmaW5lcyB0aGUgdXNh Z2Ugb2YgJnF1b3Q7V2FybUJvb3QmcXVvdDsgb25seSBmb3Igcm9vdCB0ZXJtaW5hdGlvbi48L0ZP TlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+QWx0ZXJuYXRpdmVzPzwvRk9OVD4NCjwvUD4NCg0K PFA+PEZPTlQgU0laRT0yPnRoYW5rcyw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPi1rYXBpbDwv Rk9OVD4NCjwvUD4NCjxCUj4NCjxCUj4NCjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yPiZxdW90O0tl dmluIEJveWxlJnF1b3Q7ICZsdDtrYm95bGVAbm9ydGVsbmV0d29ya3MuY29tJmd0OyBvbiAwMi8w NC8yMDAzIDEyOjUwOjIwIEFNPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+VG86Jm5i c3A7Jm5ic3A7IEthcGlsIE5heWFyL0hTU0BIU1MsIG1lZ2Fjb0BpZXRmLm9yZzwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Y2M6PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+U3ViamVj dDombmJzcDsgUkU6IFtNZWdhY29dIENhbmNlbCBTZXJ2aWNlIENoYW5nZSAobWV0aG9kPUdyYWNl ZnVsKSBtZWNoYW5pc208L0ZPTlQ+DQo8L1A+DQo8QlI+DQo8QlI+DQo8QlI+DQoNCjxQPjxGT05U IFNJWkU9Mj5Db21tZW50cyBpbmxpbmUuIFtLSkJJSV08L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05U IFNJWkU9Mj5LZXZpbjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5Gcm9tOiBrbmF5YXJAaHNz Lmhucy5jb20gWzxBIEhSRUY9Im1haWx0bzprbmF5YXJAaHNzLmhucy5jb20iPm1haWx0bzprbmF5 YXJAaHNzLmhucy5jb208L0E+XTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+U2VudDogTW9uZGF5 LCBGZWJydWFyeSAwMywgMjAwMyA3OjE5IEFNPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5Ubzog bWVnYWNvQGlldGYub3JnPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5TdWJqZWN0OiBbTWVnYWNv XSBDYW5jZWwgU2VydmljZSBDaGFuZ2UgKG1ldGhvZD1HcmFjZWZ1bCkgbWVjaGFuaXNtPC9GT05U Pg0KPC9QPg0KPEJSPg0KPEJSPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTI+SGk8L0ZPTlQ+DQo8 L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5JdCBzZWVtcyB0aGUgcHJvdG9jb2wgZG9lc25vdCBkZWZp bmUgYW55IHByb2NlZHVyZSBmb3IgY2FuY2VsbGluZyBhbiBlYXJsaWVyIFNlcnZpY2UgQ2hhbmdl IChtZXRob2Q9R3JhY2VmdWwpIG9uIGEgbm9uLXJvb3QgdGVybWluYXRpb24uPC9GT05UPjwvUD4N Cg0KPFA+PEZPTlQgU0laRT0yPlRha2luZyBhIHByYWN0aWNhbCBjYXNlOjwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+TUcgc2VuZHMgYSBTZXJ2aWNlIENoYW5nZSAobWV0aG9kPUdyYWNlZnVsKSBv biBhIHRlcm1pbmF0aW9uIHdpdGggZGVsYXk9IDIgaG91cnMuIEFmdGVyIDEgaG91ciwgTUcgcmVh bGl6ZXMgdGhhdCBpdCBkb2Vzbid0IHdhbnQgdG8gcHV0IHRoZSB0ZXJtaW5hdGlvbiBvdXQtb2Yt c2VydmljZSAoYWZ0ZXIgcmVtYWluaW5nIDEgaG91cikgYXMgd2FzIGVhcmxpZXIgaW50ZW5kZWQu IEhvdyB0byBpbmZvcm0gdGhlIE1HQyBvZiB0aGUgbmV3IGludGVudGlvbnMgLSBjYW5jZWwgZ3Jh Y2VmdWwuLj8gU2VuZGluZyBTZXJ2aWNlIENoYW5nZSAobWV0aG9kID1SZXN0YXJ0KSB3b3VsZCBt ZWFuIHRoYXQgdGVybWluYXRpb24ganVzdCBjYW1lIEluU2VydmljZSBhbmQgZG9lc25vdCBoYXZl IGFueSBhY3RpdmUgZGVzY3JpcHRvcnMsIHdoZXJlYXMgdGhpcyBpcyBub3QgdGhlIGNhc2UuPC9G T05UPjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPltLSkJJSV0gV2h5IGNhbid0IHlvdSB1c2UgU0Mg UmVzdGFydD8mbmJzcDsgVGhlIFdhcm0gQm9vdCBTQyBSZWFzb24gaW5kaWNhdGVzIHRoYXQgdGhl cmUgd2FzIE5PIGxvc3Mgb2Ygc3RhdGUuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+ U29sdXRpb246PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5NRyBzZW5kcyBTZXJ2aWNlIENoYW5n ZSAobWV0aG9kID0gR3JhY2VmdWwpIGRlbGF5ID0yIGhvdXJzIHRvIGluZm9ybSBNR0Mgb25seSBh Ym91dCB0aGUgaW50ZW50aW9ucy4gTUcgc2VuZHMgU2VydmljZSBDaGFuZ2UgKG1ldGhvZCA9IEZv cmNlZCkgd2hlbiB0aGUgdGVybWluYXRpb24gYWN0dWFsbHkgZ29lcyBvdXQtb2Ytc2VydmljZSBh ZnRlciAyIGhvdXJzLiBUaGlzIGVuc3VyZXMgdGhhdCBpZiBTZXJ2aWNlIENoYW5nZSAobWV0aG9k ID0gRm9yY2VkKSBuZXZlciBjYW1lLCB0aGUgaW50ZW50aW9ucyBvZiBNRyBuZXZlciBnb3QgbWF0 ZXJpYWxpc2VkLjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5bS0pCSUldIEljay4mbmJz cDsgU28gd2Ugd2lsbCBiZSByZXF1aXJlZCB0byBzZW5kIFRXTyBTQ3MgaW5zdGVhZCBvZiBvbmUg aWYgd2UgdXNlIFNDIEdyYWNlZnVsPyZuYnNwOyBJIHJlYWxseSBkb24ndCBsaWtlIHRoYXQgaWRl YS48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+RG9lcyBhbnkgYm9keSBoYXZlIGFuIGFs dGVybmF0aXZlIHNvbHV0aW9uPyBQbGVhc2Ugc3VnZ2VzdC48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxG T05UIFNJWkU9Mj50aGFua3MsPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5rYXBpbCBuYXlhcjwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+d3d3Lmhzc3dvcmxkLmNvbTwvRk9OVD4NCjwvUD4NCjxC Uj4NCg0KPFA+PEZPTlQgU0laRT0yPkRJU0NMQUlNRVI6IFRoaXMgbWVzc2FnZSBpcyBwcm9wcmll dGFyeSB0byBIdWdoZXMgU29mdHdhcmUgU3lzdGVtcyBMaW1pdGVkPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4oSFNTKSBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBp bmRpdmlkdWFsIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiZuYnNwOyBw cml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiZuYnNwOyBhbmQgc2hvdWxkIG5v dCBiZSBjaXJjdWxhdGVkIG9yIHVzZWQgZm9yIGFueSBwdXJwb3NlIG90aGVyIHRoYW4gZm9yIHdo YXQgaXQgaXMgaW50ZW5kZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBpbW1lZGlhdGVseS4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBub3RpZmllZCB0aGF0IHlvdSBh cmUgc3RyaWN0bHkgcHJvaGliaXRlZCBmcm9tIHVzaW5nLCBjb3B5aW5nLCBhbHRlcmluZywgb3Ig ZGlzY2xvc2luZyB0aGUgY29udGVudHMgb2YgdGhpcyBtZXNzYWdlLiBIU1MgYWNjZXB0cyBubyBy ZXNwb25zaWJpbGl0eSBmb3IgbG9zcyBvciBkYW1hZ2UgYXJpc2luZyBmcm9tIHRoZSB1c2Ugb2Yg dGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkIGJ5IHRoaXMgZW1haWwgaW5jbHVkaW5nIGRhbWFn ZSBmcm9tIHZpcnVzLjwvRk9OVD48L1A+DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9Mj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+TWVnYWNvIG1haWxpbmcgbGlzdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+TWVn YWNvQGlldGYub3JnPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj48QSBIUkVGPSJodHRwczovL3d3 dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tZWdhY28iIFRBUkdFVD0iX2JsYW5rIj5odHRw czovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tZWdhY288L0E+PC9GT05UPg0KPC9Q Pg0KDQo8L0JPRFk+DQo8L0hUTUw+DQo= --0__=FtE7dLV0ytv7zIFQYY9POKm9iRVXZaXCuZlRWKpJXoSMv07dGuD3oKzu-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 4 11:19:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27030 for ; Tue, 4 Feb 2003 11:19:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14GOXJ05540; Tue, 4 Feb 2003 11:24:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14GFRJ05051 for ; Tue, 4 Feb 2003 11:15:27 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26441 for ; Tue, 4 Feb 2003 11:09:24 -0500 (EST) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h14GCs209744; Tue, 4 Feb 2003 11:12:55 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1DG5KQXB; Tue, 4 Feb 2003 11:12:54 -0500 Received: from nortelnetworks.com (acart1d6.ca.nortel.com [47.129.129.82]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1NC15Y; Tue, 4 Feb 2003 11:12:55 -0500 Message-ID: <3E3FE685.7080703@nortelnetworks.com> Date: Tue, 04 Feb 2003 11:12:53 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Christian Groves , Megaco List CC: Harry Suede Subject: Re: [Megaco] Re: Descriptor state after out of service References: <20030203104156.5720.qmail@email.com> <3E3E8398.8020105@nortelnetworks.com> <3E3F01EC.F4D8014B@ericsson.com.au> In-Reply-To: <3E3F01EC.F4D8014B@ericsson.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit You have me a bit confused here. ServiceChange simply changes the state of the termination -- did you mean that the same Action would contain a Subtract, if issued by the MGC? Christian Groves wrote: > G'Day, > > I think you should concentrate more on the method associated with the service > change that put the termination into the Out of Service state. The result of > Forced or Graceful will be that terminations are subtracted - thus if subtracted > the descriptors will be affected according to H.248.1 sect 7.2.3. > > Christian > > Tom Taylor wrote: > >>I don't believe the ServiceChange action does anything to the descriptors on its >>own. It is up to the MGC to reset them if necessary. I do have the feeling that we >>might want to analyze the situation and possibly refine it. >> >>Harry Suede wrote: >> >>>Hi list, Tom >>> >>>PL ignore my previous mail. By mistake I have written "out of service" in place of "in service" in the last line. >>> >>>What is the state of descriptor of a termination in a non-null context when termination is put "out of service" by MGC or MG? Does the descriptor remain on termination database but inactivated or does they are total flushed. Thus if this termination is put "in service" by MGC or MG then what will be the state of descriptor i.e. they are reapply/reactivated on the termination or not. >>> >>>regards >>>harry >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 4 11:20:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27099 for ; Tue, 4 Feb 2003 11:20:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14GPgg05680 for megaco-archive@odin.ietf.org; Tue, 4 Feb 2003 11:25:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14GPfJ05673 for ; Tue, 4 Feb 2003 11:25:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27040 for ; Tue, 4 Feb 2003 11:19:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14GOXJ05540; Tue, 4 Feb 2003 11:24:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14GFRJ05051 for ; Tue, 4 Feb 2003 11:15:27 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26441 for ; Tue, 4 Feb 2003 11:09:24 -0500 (EST) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h14GCs209744; Tue, 4 Feb 2003 11:12:55 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1DG5KQXB; Tue, 4 Feb 2003 11:12:54 -0500 Received: from nortelnetworks.com (acart1d6.ca.nortel.com [47.129.129.82]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1NC15Y; Tue, 4 Feb 2003 11:12:55 -0500 Message-ID: <3E3FE685.7080703@nortelnetworks.com> Date: Tue, 04 Feb 2003 11:12:53 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Christian Groves , Megaco List CC: Harry Suede Subject: Re: [Megaco] Re: Descriptor state after out of service References: <20030203104156.5720.qmail@email.com> <3E3E8398.8020105@nortelnetworks.com> <3E3F01EC.F4D8014B@ericsson.com.au> In-Reply-To: <3E3F01EC.F4D8014B@ericsson.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit You have me a bit confused here. ServiceChange simply changes the state of the termination -- did you mean that the same Action would contain a Subtract, if issued by the MGC? Christian Groves wrote: > G'Day, > > I think you should concentrate more on the method associated with the service > change that put the termination into the Out of Service state. The result of > Forced or Graceful will be that terminations are subtracted - thus if subtracted > the descriptors will be affected according to H.248.1 sect 7.2.3. > > Christian > > Tom Taylor wrote: > >>I don't believe the ServiceChange action does anything to the descriptors on its >>own. It is up to the MGC to reset them if necessary. I do have the feeling that we >>might want to analyze the situation and possibly refine it. >> >>Harry Suede wrote: >> >>>Hi list, Tom >>> >>>PL ignore my previous mail. By mistake I have written "out of service" in place of "in service" in the last line. >>> >>>What is the state of descriptor of a termination in a non-null context when termination is put "out of service" by MGC or MG? Does the descriptor remain on termination database but inactivated or does they are total flushed. Thus if this termination is put "in service" by MGC or MG then what will be the state of descriptor i.e. they are reapply/reactivated on the termination or not. >>> >>>regards >>>harry >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 4 13:59:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01397 for ; Tue, 4 Feb 2003 13:59:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14J49J15891; Tue, 4 Feb 2003 14:04:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14J2BJ15820 for ; Tue, 4 Feb 2003 14:02:11 -0500 Received: from zcars0m9.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01324 for ; Tue, 4 Feb 2003 13:56:05 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h14IxDA23336; Tue, 4 Feb 2003 13:59:13 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1WBQW4; Tue, 4 Feb 2003 13:59:14 -0500 Received: from nortelnetworks.com (acart1d6.ca.nortel.com [47.129.129.82]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1NC19H; Tue, 4 Feb 2003 13:59:13 -0500 Message-ID: <3E400D7B.8080102@nortelnetworks.com> Date: Tue, 04 Feb 2003 13:59:07 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Simran Chadha CC: Megaco List Subject: Re: [Megaco] Re: Usage of LocalControl,Local and Remote Descriptors ! References: <20030204052156.14303.qmail@webmail28.rediffmail.com> In-Reply-To: <20030204052156.14303.qmail@webmail28.rediffmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit That "cannot not" is a typo -- I'll remove the "not" during the "authors' 48 hours" interval prior to formal publication as a new RFC. On your second point: the two paragraphs apply independently to ReserveGroup and ReserveValue. That is, it is possible to have ReserveGroup TRUE and ReserveValue FALSE -- in which case the MG reserves for multiple session descriptions but is restricted to one codec in each -- or vice versa. Or both could be TRUE, or both FALSE. On the third point, the intended meaning would be conveyed by replacing "if it cannot support any of the alternatives" with "if it can support none of the alternatives". Perhaps I can also do that during the "authors' 48 hours" period, though we would usually do it through the ITU-T Implementor's Guide. The task of developing an unambiguous protocol specification is not simple. Your points have eluded others in the three years since first approval. Thank you for your contribution. Simran Chadha wrote: > > Hi List, > > Can someone please help me at the earliest on the issues raised earlier > by me - particularly, usage of LocalControl,Local and Remote Descriptors ? > > Thanks in advance. > > Simran Chadha > On Thu, 30 Jan 2003 Simran Chadha wrote : > >> Hi List, >> >> Can you please help me with clarifications in my understanding of >> sections 7.1.7 and 7.1.8 on the use of LocalControl,Local and Remote >> Descriptors. >> >> As per draft-ietf-megaco-3015corr-03, in section 7.1.7, >> If the value of a Reserve property is True, the MG SHALL reserve >> resources for all alternatives specified in the Local and/or Remote >> descriptors for which it currently has resources available. It SHALL >> respond with the alternatives for which it reserves resources. If it >> cannot not support any of the alternatives, it SHALL respond with a >> reply to the MGC that contains empty Local and/or Remote descriptors. >> The use of two negations - "cannot not" in the last statement will >> imply that - If it can support any of the alternatives, it SHALL >> respond with a reply to the MGC that contains empty Local and/or >> Remote descriptors. >> I don't think this is what is meant to be conveyed here. >> >> Also in section 7.1.7 the first para starts - If the value of a >> Reserve property is True, ..... >> while the second para starts - If the value of a Reserve property is >> False, .... >> Now as there are two Reserve properties - one Reserve Group and the >> other Reserve Value, One could be False and the other could be True. >> Then in this case what will be the inference - Should para 1 apply or >> para 2 ? Both the paras would seem to be mutually exclusive in what is >> needed to be done. >> >> Also statements like "if it cannot support any of the alternatives ... >> " - will have two meanings. >> 1. Any - Not even one - NONE of the alternatives is supported. >> 2. Any - Atleast one - While a few alternatives can be supported, a >> few might not be. >> >> The protocol needs to be more clear on such aspects in the documents >> henceforth. The English language is understood in different parts of >> the world. Variations to agreed usage of the language terms will make >> it difficult for new users of Megaco protocol, like me. >> >> Can someone please educate me on the exact usage and meaning of >> LocalControl,Local and Remote Descriptors ? >> >> Thanks and awaiting comments and clarifications >> >> Simran Chadha > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 4 13:59:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01428 for ; Tue, 4 Feb 2003 13:59:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14J5Il15961 for megaco-archive@odin.ietf.org; Tue, 4 Feb 2003 14:05:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14J5IJ15958 for ; Tue, 4 Feb 2003 14:05:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01411 for ; Tue, 4 Feb 2003 13:59:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14J49J15891; Tue, 4 Feb 2003 14:04:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14J2BJ15820 for ; Tue, 4 Feb 2003 14:02:11 -0500 Received: from zcars0m9.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01324 for ; Tue, 4 Feb 2003 13:56:05 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h14IxDA23336; Tue, 4 Feb 2003 13:59:13 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1WBQW4; Tue, 4 Feb 2003 13:59:14 -0500 Received: from nortelnetworks.com (acart1d6.ca.nortel.com [47.129.129.82]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1NC19H; Tue, 4 Feb 2003 13:59:13 -0500 Message-ID: <3E400D7B.8080102@nortelnetworks.com> Date: Tue, 04 Feb 2003 13:59:07 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Simran Chadha CC: Megaco List Subject: Re: [Megaco] Re: Usage of LocalControl,Local and Remote Descriptors ! References: <20030204052156.14303.qmail@webmail28.rediffmail.com> In-Reply-To: <20030204052156.14303.qmail@webmail28.rediffmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit That "cannot not" is a typo -- I'll remove the "not" during the "authors' 48 hours" interval prior to formal publication as a new RFC. On your second point: the two paragraphs apply independently to ReserveGroup and ReserveValue. That is, it is possible to have ReserveGroup TRUE and ReserveValue FALSE -- in which case the MG reserves for multiple session descriptions but is restricted to one codec in each -- or vice versa. Or both could be TRUE, or both FALSE. On the third point, the intended meaning would be conveyed by replacing "if it cannot support any of the alternatives" with "if it can support none of the alternatives". Perhaps I can also do that during the "authors' 48 hours" period, though we would usually do it through the ITU-T Implementor's Guide. The task of developing an unambiguous protocol specification is not simple. Your points have eluded others in the three years since first approval. Thank you for your contribution. Simran Chadha wrote: > > Hi List, > > Can someone please help me at the earliest on the issues raised earlier > by me - particularly, usage of LocalControl,Local and Remote Descriptors ? > > Thanks in advance. > > Simran Chadha > On Thu, 30 Jan 2003 Simran Chadha wrote : > >> Hi List, >> >> Can you please help me with clarifications in my understanding of >> sections 7.1.7 and 7.1.8 on the use of LocalControl,Local and Remote >> Descriptors. >> >> As per draft-ietf-megaco-3015corr-03, in section 7.1.7, >> If the value of a Reserve property is True, the MG SHALL reserve >> resources for all alternatives specified in the Local and/or Remote >> descriptors for which it currently has resources available. It SHALL >> respond with the alternatives for which it reserves resources. If it >> cannot not support any of the alternatives, it SHALL respond with a >> reply to the MGC that contains empty Local and/or Remote descriptors. >> The use of two negations - "cannot not" in the last statement will >> imply that - If it can support any of the alternatives, it SHALL >> respond with a reply to the MGC that contains empty Local and/or >> Remote descriptors. >> I don't think this is what is meant to be conveyed here. >> >> Also in section 7.1.7 the first para starts - If the value of a >> Reserve property is True, ..... >> while the second para starts - If the value of a Reserve property is >> False, .... >> Now as there are two Reserve properties - one Reserve Group and the >> other Reserve Value, One could be False and the other could be True. >> Then in this case what will be the inference - Should para 1 apply or >> para 2 ? Both the paras would seem to be mutually exclusive in what is >> needed to be done. >> >> Also statements like "if it cannot support any of the alternatives ... >> " - will have two meanings. >> 1. Any - Not even one - NONE of the alternatives is supported. >> 2. Any - Atleast one - While a few alternatives can be supported, a >> few might not be. >> >> The protocol needs to be more clear on such aspects in the documents >> henceforth. The English language is understood in different parts of >> the world. Variations to agreed usage of the language terms will make >> it difficult for new users of Megaco protocol, like me. >> >> Can someone please educate me on the exact usage and meaning of >> LocalControl,Local and Remote Descriptors ? >> >> Thanks and awaiting comments and clarifications >> >> Simran Chadha > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 4 14:17:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01925 for ; Tue, 4 Feb 2003 14:17:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14JMBJ17433; Tue, 4 Feb 2003 14:22:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14JLhJ17409 for ; Tue, 4 Feb 2003 14:21:43 -0500 Received: from zcars0m9.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01883 for ; Tue, 4 Feb 2003 14:15:37 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h14JIiA00929; Tue, 4 Feb 2003 14:18:44 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1WBRKH; Tue, 4 Feb 2003 14:18:44 -0500 Received: from nortelnetworks.com (acart1d6.ca.nortel.com [47.129.129.82]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1NC19X; Tue, 4 Feb 2003 14:18:44 -0500 Message-ID: <3E401212.9000301@nortelnetworks.com> Date: Tue, 04 Feb 2003 14:18:42 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Harry Suede , Megaco List References: <20030204092217.9036.qmail@email.com> In-Reply-To: <20030204092217.9036.qmail@email.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] Re: Descriptor state after out of service Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit All ServiceChange does is advise the other end that it shouldn't be routing calls to this termination. It does NOT, in itself, delete any connections (although an MG-initiated ServiceChange may reflect that a hardware or software failure has broken them). We couldn't get more stringent than that because of the possibility you might want to route test calls through a termination before returning it to service. Availability states are modelled much more elaborately in traditional management systems. To say all that can be said takes more than one state variable. We are just using one, and as a result its usefulness is limited. Harry Suede wrote: > This means that ServiceChange does not change the descriptor of the termination and its upto MGC to change the descriptor. But consider this case that termination in non-null context is put to "out of service". Thus according to protocol all connections is lost. So at h/w level there is change but not in the database. Now if MG/MGC put termination back to "in service" does this mean that connection is to be re-established i.e. descriptors are to be reapply. > ----- Original Message ----- > From: Tom Taylor > Date: Mon, 03 Feb 2003 09:58:32 -0500 > To: Harry Suede > Subject: Re: Descriptor state after out of service > > >>I don't believe the ServiceChange action does anything to the descriptors on its >>own. It is up to the MGC to reset them if necessary. I do have the feeling that we >>might want to analyze the situation and possibly refine it. >> >>Harry Suede wrote: >> >>>Hi list, Tom >>> >>>PL ignore my previous mail. By mistake I have written "out of service" in place of "in service" in the last line. >>> >>>What is the state of descriptor of a termination in a non-null context when termination is put "out of service" by MGC or MG? Does the descriptor remain on termination database but inactivated or does they are total flushed. Thus if this termination is put "in service" by MGC or MG then what will be the state of descriptor i.e. they are reapply/reactivated on the termination or not. >>> >>>regards >>>harry >> > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 4 14:17:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01977 for ; Tue, 4 Feb 2003 14:17:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14JNBR17484 for megaco-archive@odin.ietf.org; Tue, 4 Feb 2003 14:23:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14JNBJ17481 for ; Tue, 4 Feb 2003 14:23:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01937 for ; Tue, 4 Feb 2003 14:17:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14JMBJ17433; Tue, 4 Feb 2003 14:22:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14JLhJ17409 for ; Tue, 4 Feb 2003 14:21:43 -0500 Received: from zcars0m9.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01883 for ; Tue, 4 Feb 2003 14:15:37 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h14JIiA00929; Tue, 4 Feb 2003 14:18:44 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1WBRKH; Tue, 4 Feb 2003 14:18:44 -0500 Received: from nortelnetworks.com (acart1d6.ca.nortel.com [47.129.129.82]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1NC19X; Tue, 4 Feb 2003 14:18:44 -0500 Message-ID: <3E401212.9000301@nortelnetworks.com> Date: Tue, 04 Feb 2003 14:18:42 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Harry Suede , Megaco List References: <20030204092217.9036.qmail@email.com> In-Reply-To: <20030204092217.9036.qmail@email.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] Re: Descriptor state after out of service Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All ServiceChange does is advise the other end that it shouldn't be routing calls to this termination. It does NOT, in itself, delete any connections (although an MG-initiated ServiceChange may reflect that a hardware or software failure has broken them). We couldn't get more stringent than that because of the possibility you might want to route test calls through a termination before returning it to service. Availability states are modelled much more elaborately in traditional management systems. To say all that can be said takes more than one state variable. We are just using one, and as a result its usefulness is limited. Harry Suede wrote: > This means that ServiceChange does not change the descriptor of the termination and its upto MGC to change the descriptor. But consider this case that termination in non-null context is put to "out of service". Thus according to protocol all connections is lost. So at h/w level there is change but not in the database. Now if MG/MGC put termination back to "in service" does this mean that connection is to be re-established i.e. descriptors are to be reapply. > ----- Original Message ----- > From: Tom Taylor > Date: Mon, 03 Feb 2003 09:58:32 -0500 > To: Harry Suede > Subject: Re: Descriptor state after out of service > > >>I don't believe the ServiceChange action does anything to the descriptors on its >>own. It is up to the MGC to reset them if necessary. I do have the feeling that we >>might want to analyze the situation and possibly refine it. >> >>Harry Suede wrote: >> >>>Hi list, Tom >>> >>>PL ignore my previous mail. By mistake I have written "out of service" in place of "in service" in the last line. >>> >>>What is the state of descriptor of a termination in a non-null context when termination is put "out of service" by MGC or MG? Does the descriptor remain on termination database but inactivated or does they are total flushed. Thus if this termination is put "in service" by MGC or MG then what will be the state of descriptor i.e. they are reapply/reactivated on the termination or not. >>> >>>regards >>>harry >> > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 4 15:13:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03154 for ; Tue, 4 Feb 2003 15:13:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14KIuJ20646; Tue, 4 Feb 2003 15:18:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14KH5J20602 for ; Tue, 4 Feb 2003 15:17:05 -0500 Received: from sparky.afc.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03105 for ; Tue, 4 Feb 2003 15:10:57 -0500 (EST) Received: (qmail 6804 invoked from network); 4 Feb 2003 20:09:39 -0000 Received: from unknown (HELO zzzconn03.fibre.com) (10.1.4.53) by 0 with SMTP; 4 Feb 2003 20:09:39 -0000 Received: FROM xconn01.fibre.com BY zzzconn03.fibre.com ; Tue Feb 04 12:13:56 2003 -0800 Received: by xconn01.fibre.com with Internet Mail Service (5.5.2653.19) id <1JRCJKBS>; Tue, 4 Feb 2003 12:12:27 -0800 Message-ID: From: John Stock To: "'megaco@ietf.org'" Date: Tue, 4 Feb 2003 11:56:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Megaco] Digitmap event remain active after onhook? Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi all, I was wondering about this - if a user goes offhook, and both the "dd/ce" and the "al/on" events are active, and the user then goes onhook, is the "dd/ce" (digitmap completion event) still active? That is, might it still time out via one of the timers, before it gets replaced by the new "al/of" event descriptor? The spec seems to address this in the case where the EventBufferControl is LockStep ("The MG SHALL wait for a new EventsDescriptor to be loaded" in 7.1.9), however doesn't address it when EventBufferControl is OFF. I looked through past emails, and couldn't find anything definitive (maybe I missed it). I saw this exchange in an old email: >> Question : >> While dialing the MG detects the onhook events, then will it happen the >> DigitMapCompletion event? If it happens, what the kind of Termination >> Method is ? >> And, Which event happens first ? Onhook or DigitMap Completion? > [[TomT]] > The usual case would be that the EventsDescriptor changes as a >result of on-hook. If this doesn't happen, DigitMapCompletion will come >about as a result of timer expiry, and thus will generally follow some time >after the on-hook. However how does the EventsDescriptor "change"? It's supposed to remain active until replaced by another events descriptor, according to the spec. Does this change refer to when the new "al/of" EventsDescriptor is sent? If so, then what about in the meantime before this message is received by the MG? It seems like it might be OK for this timeout and "dd/ce" event to still be sent to the MGC after the "al/on" event, and if so of course the MGC should handle it correctly. Just wanted to see what everyone else thought. Sorry again if this has already been resolved. Thanks. John Stock Systems Engineering Advanced Fibre Communications john.stock@afc.com 707-792-6249 And now for the standard disclaimer (don't lawyers just make life fun?): This message (including any attachments) is intended only for the use of the named addressee(s), and may contain information that is legally privileged, confidential or exempt from disclosure under applicable law. If you are not a named addressee, you are hereby notified that any use, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the original sender immediately by telephone or by return E-mail and delete this message, along with any attachments, from your computer. Thank you. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 4 15:14:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03171 for ; Tue, 4 Feb 2003 15:14:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14KK2w20710 for megaco-archive@odin.ietf.org; Tue, 4 Feb 2003 15:20:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14KK1J20707 for ; Tue, 4 Feb 2003 15:20:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03162 for ; Tue, 4 Feb 2003 15:13:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14KIuJ20646; Tue, 4 Feb 2003 15:18:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14KH5J20602 for ; Tue, 4 Feb 2003 15:17:05 -0500 Received: from sparky.afc.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03105 for ; Tue, 4 Feb 2003 15:10:57 -0500 (EST) Received: (qmail 6804 invoked from network); 4 Feb 2003 20:09:39 -0000 Received: from unknown (HELO zzzconn03.fibre.com) (10.1.4.53) by 0 with SMTP; 4 Feb 2003 20:09:39 -0000 Received: FROM xconn01.fibre.com BY zzzconn03.fibre.com ; Tue Feb 04 12:13:56 2003 -0800 Received: by xconn01.fibre.com with Internet Mail Service (5.5.2653.19) id <1JRCJKBS>; Tue, 4 Feb 2003 12:12:27 -0800 Message-ID: From: John Stock To: "'megaco@ietf.org'" Date: Tue, 4 Feb 2003 11:56:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Megaco] Digitmap event remain active after onhook? Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi all, I was wondering about this - if a user goes offhook, and both the "dd/ce" and the "al/on" events are active, and the user then goes onhook, is the "dd/ce" (digitmap completion event) still active? That is, might it still time out via one of the timers, before it gets replaced by the new "al/of" event descriptor? The spec seems to address this in the case where the EventBufferControl is LockStep ("The MG SHALL wait for a new EventsDescriptor to be loaded" in 7.1.9), however doesn't address it when EventBufferControl is OFF. I looked through past emails, and couldn't find anything definitive (maybe I missed it). I saw this exchange in an old email: >> Question : >> While dialing the MG detects the onhook events, then will it happen the >> DigitMapCompletion event? If it happens, what the kind of Termination >> Method is ? >> And, Which event happens first ? Onhook or DigitMap Completion? > [[TomT]] > The usual case would be that the EventsDescriptor changes as a >result of on-hook. If this doesn't happen, DigitMapCompletion will come >about as a result of timer expiry, and thus will generally follow some time >after the on-hook. However how does the EventsDescriptor "change"? It's supposed to remain active until replaced by another events descriptor, according to the spec. Does this change refer to when the new "al/of" EventsDescriptor is sent? If so, then what about in the meantime before this message is received by the MG? It seems like it might be OK for this timeout and "dd/ce" event to still be sent to the MGC after the "al/on" event, and if so of course the MGC should handle it correctly. Just wanted to see what everyone else thought. Sorry again if this has already been resolved. Thanks. John Stock Systems Engineering Advanced Fibre Communications john.stock@afc.com 707-792-6249 And now for the standard disclaimer (don't lawyers just make life fun?): This message (including any attachments) is intended only for the use of the named addressee(s), and may contain information that is legally privileged, confidential or exempt from disclosure under applicable law. If you are not a named addressee, you are hereby notified that any use, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the original sender immediately by telephone or by return E-mail and delete this message, along with any attachments, from your computer. Thank you. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 4 16:12:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04502 for ; Tue, 4 Feb 2003 16:12:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14LHeJ24053; Tue, 4 Feb 2003 16:17:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14LGnJ24009 for ; Tue, 4 Feb 2003 16:16:49 -0500 Received: from zrtps06s.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04468 for ; Tue, 4 Feb 2003 16:10:40 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h14LEGK25895 for ; Tue, 4 Feb 2003 16:14:16 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1DC5ZMHA>; Tue, 4 Feb 2003 16:14:16 -0500 Message-ID: From: "Kevin Boyle" To: John Stock , "'megaco@ietf.org'" Subject: RE: [Megaco] Digitmap event remain active after onhook? Date: Tue, 4 Feb 2003 16:14:15 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Comments inline. [KJBII] Kevin -----Original Message----- From: John Stock [mailto:John.Stock@afc.com] Sent: Tuesday, February 04, 2003 2:57 PM To: 'megaco@ietf.org' Subject: [Megaco] Digitmap event remain active after onhook? Hi all, I was wondering about this - if a user goes offhook, and both the "dd/ce" and the "al/on" events are active, and the user then goes onhook, is the "dd/ce" (digitmap completion event) still active? That is, might it still time out via one of the timers, before it gets replaced by the new "al/of" event descriptor? [KJBII] This is, in fact, the case. The spec seems to address this in the case where the EventBufferControl is LockStep ("The MG SHALL wait for a new EventsDescriptor to be loaded" in 7.1.9), however doesn't address it when EventBufferControl is OFF. I looked through past emails, and couldn't find anything definitive (maybe I missed it). I saw this exchange in an old email: >> Question : >> While dialing the MG detects the onhook events, then will it happen >> the DigitMapCompletion event? If it happens, what the kind of >> Termination Method is ? And, Which event happens first ? Onhook or >> DigitMap Completion? > [[TomT]] > The usual case would be that the EventsDescriptor changes as a >result of on-hook. If this doesn't happen, DigitMapCompletion will >come about as a result of timer expiry, and thus will generally follow >some time after the on-hook. However how does the EventsDescriptor "change"? It's supposed to remain active until replaced by another events descriptor, according to the spec. Does this change refer to when the new "al/of" EventsDescriptor is sent? If so, then what about in the meantime before this message is received by the MG? [KJBII] Yes, the change indicated is the replacement of the E descriptor. In the meantime, the MG should continue to process the E descriptor it has. It seems like it might be OK for this timeout and "dd/ce" event to still be sent to the MGC after the "al/on" event, and if so of course the MGC should handle it correctly. Just wanted to see what everyone else thought. Sorry again if this has already been resolved. [KJBII] You supposition is correct, IMO. If this potential race condition is a concern, then the MGC could embed the al/of event on the al/on event, and avoid the problem altogether. Thanks. John Stock Systems Engineering Advanced Fibre Communications john.stock@afc.com 707-792-6249 And now for the standard disclaimer (don't lawyers just make life fun?): This message (including any attachments) is intended only for the use of the named addressee(s), and may contain information that is legally privileged, confidential or exempt from disclosure under applicable law. If you are not a named addressee, you are hereby notified that any use, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the original sender immediately by telephone or by return E-mail and delete this message, along with any attachments, from your computer. Thank you. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 4 16:13:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04519 for ; Tue, 4 Feb 2003 16:13:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14LIwG24114 for megaco-archive@odin.ietf.org; Tue, 4 Feb 2003 16:18:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14LIvJ24111 for ; Tue, 4 Feb 2003 16:18:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04507 for ; Tue, 4 Feb 2003 16:12:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14LHeJ24053; Tue, 4 Feb 2003 16:17:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14LGnJ24009 for ; Tue, 4 Feb 2003 16:16:49 -0500 Received: from zrtps06s.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04468 for ; Tue, 4 Feb 2003 16:10:40 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h14LEGK25895 for ; Tue, 4 Feb 2003 16:14:16 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1DC5ZMHA>; Tue, 4 Feb 2003 16:14:16 -0500 Message-ID: From: "Kevin Boyle" To: John Stock , "'megaco@ietf.org'" Subject: RE: [Megaco] Digitmap event remain active after onhook? Date: Tue, 4 Feb 2003 16:14:15 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Comments inline. [KJBII] Kevin -----Original Message----- From: John Stock [mailto:John.Stock@afc.com] Sent: Tuesday, February 04, 2003 2:57 PM To: 'megaco@ietf.org' Subject: [Megaco] Digitmap event remain active after onhook? Hi all, I was wondering about this - if a user goes offhook, and both the "dd/ce" and the "al/on" events are active, and the user then goes onhook, is the "dd/ce" (digitmap completion event) still active? That is, might it still time out via one of the timers, before it gets replaced by the new "al/of" event descriptor? [KJBII] This is, in fact, the case. The spec seems to address this in the case where the EventBufferControl is LockStep ("The MG SHALL wait for a new EventsDescriptor to be loaded" in 7.1.9), however doesn't address it when EventBufferControl is OFF. I looked through past emails, and couldn't find anything definitive (maybe I missed it). I saw this exchange in an old email: >> Question : >> While dialing the MG detects the onhook events, then will it happen >> the DigitMapCompletion event? If it happens, what the kind of >> Termination Method is ? And, Which event happens first ? Onhook or >> DigitMap Completion? > [[TomT]] > The usual case would be that the EventsDescriptor changes as a >result of on-hook. If this doesn't happen, DigitMapCompletion will >come about as a result of timer expiry, and thus will generally follow >some time after the on-hook. However how does the EventsDescriptor "change"? It's supposed to remain active until replaced by another events descriptor, according to the spec. Does this change refer to when the new "al/of" EventsDescriptor is sent? If so, then what about in the meantime before this message is received by the MG? [KJBII] Yes, the change indicated is the replacement of the E descriptor. In the meantime, the MG should continue to process the E descriptor it has. It seems like it might be OK for this timeout and "dd/ce" event to still be sent to the MGC after the "al/on" event, and if so of course the MGC should handle it correctly. Just wanted to see what everyone else thought. Sorry again if this has already been resolved. [KJBII] You supposition is correct, IMO. If this potential race condition is a concern, then the MGC could embed the al/of event on the al/on event, and avoid the problem altogether. Thanks. John Stock Systems Engineering Advanced Fibre Communications john.stock@afc.com 707-792-6249 And now for the standard disclaimer (don't lawyers just make life fun?): This message (including any attachments) is intended only for the use of the named addressee(s), and may contain information that is legally privileged, confidential or exempt from disclosure under applicable law. If you are not a named addressee, you are hereby notified that any use, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the original sender immediately by telephone or by return E-mail and delete this message, along with any attachments, from your computer. Thank you. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 4 19:35:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09002 for ; Tue, 4 Feb 2003 19:35:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h150dxJ04737; Tue, 4 Feb 2003 19:39:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h150cOJ04679 for ; Tue, 4 Feb 2003 19:38:24 -0500 Received: from motgate5.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08976 for ; Tue, 4 Feb 2003 19:32:12 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h150ZfRK023149 for ; Tue, 4 Feb 2003 17:35:42 -0700 (MST) Received: [from az33exm05.corp.mot.com (az33exm05.corp.mot.com [199.2.84.25]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id RAA26829 for ; Tue, 4 Feb 2003 17:34:38 -0700 (MST)] Received: by az33exm05.corp.mot.com with Internet Mail Service (5.5.2656.59) id ; Tue, 4 Feb 2003 17:35:48 -0700 Message-ID: <7FD24C15A06DD511BF9E00D0B73E995207139332@az33exm05.corp.mot.com> From: Maschoff Mark-P53708 To: "'megaco@ietf.org'" Date: Tue, 4 Feb 2003 17:35:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2CCAE.79BD5450" Subject: [Megaco] Subtract Command after ServiceChange "Forced" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2CCAE.79BD5450 Content-Type: text/plain; charset="iso-8859-1" In the case where a MG sends a ServiceChange - Forced to the MGC indicating that all ephemeral terminations within a Context were abruptly taken out of service (e.g., due to a failure within the MG), does Megaco insist that the MGC subsequently send a Subtract command to the MG to subtract these terminations from the context (and thus remove the Context)? Since all terminations within this Context have been taken out of service, the Context could simply be removed by the MG without the need for the Subtract command. Is this acceptable Megaco behavior? Thanks, Mark ------_=_NextPart_001_01C2CCAE.79BD5450 Content-Type: text/html; charset="iso-8859-1"
In the case where a MG sends a ServiceChange - Forced to the MGC indicating that all ephemeral terminations within a Context were abruptly taken out of service (e.g., due to a failure within the MG), does Megaco insist that the MGC subsequently send a Subtract command to the MG to subtract these terminations from the context (and thus remove the Context)? 
 
Since all terminations within this Context have been taken out of service, the Context could simply be removed by the MG without the need for the Subtract command.  Is this acceptable Megaco behavior?
 
Thanks,
 
Mark
------_=_NextPart_001_01C2CCAE.79BD5450-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 4 19:35:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09035 for ; Tue, 4 Feb 2003 19:35:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h150fGu04814 for megaco-archive@odin.ietf.org; Tue, 4 Feb 2003 19:41:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h150fFJ04811 for ; Tue, 4 Feb 2003 19:41:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09015 for ; Tue, 4 Feb 2003 19:35:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h150dxJ04737; Tue, 4 Feb 2003 19:39:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h150cOJ04679 for ; Tue, 4 Feb 2003 19:38:24 -0500 Received: from motgate5.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08976 for ; Tue, 4 Feb 2003 19:32:12 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h150ZfRK023149 for ; Tue, 4 Feb 2003 17:35:42 -0700 (MST) Received: [from az33exm05.corp.mot.com (az33exm05.corp.mot.com [199.2.84.25]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id RAA26829 for ; Tue, 4 Feb 2003 17:34:38 -0700 (MST)] Received: by az33exm05.corp.mot.com with Internet Mail Service (5.5.2656.59) id ; Tue, 4 Feb 2003 17:35:48 -0700 Message-ID: <7FD24C15A06DD511BF9E00D0B73E995207139332@az33exm05.corp.mot.com> From: Maschoff Mark-P53708 To: "'megaco@ietf.org'" Date: Tue, 4 Feb 2003 17:35:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2CCAE.79BD5450" Subject: [Megaco] Subtract Command after ServiceChange "Forced" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2CCAE.79BD5450 Content-Type: text/plain; charset="iso-8859-1" In the case where a MG sends a ServiceChange - Forced to the MGC indicating that all ephemeral terminations within a Context were abruptly taken out of service (e.g., due to a failure within the MG), does Megaco insist that the MGC subsequently send a Subtract command to the MG to subtract these terminations from the context (and thus remove the Context)? Since all terminations within this Context have been taken out of service, the Context could simply be removed by the MG without the need for the Subtract command. Is this acceptable Megaco behavior? Thanks, Mark ------_=_NextPart_001_01C2CCAE.79BD5450 Content-Type: text/html; charset="iso-8859-1"
In the case where a MG sends a ServiceChange - Forced to the MGC indicating that all ephemeral terminations within a Context were abruptly taken out of service (e.g., due to a failure within the MG), does Megaco insist that the MGC subsequently send a Subtract command to the MG to subtract these terminations from the context (and thus remove the Context)? 
 
Since all terminations within this Context have been taken out of service, the Context could simply be removed by the MG without the need for the Subtract command.  Is this acceptable Megaco behavior?
 
Thanks,
 
Mark
------_=_NextPart_001_01C2CCAE.79BD5450-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 4 20:11:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09796 for ; Tue, 4 Feb 2003 20:11:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h151FQJ06505; Tue, 4 Feb 2003 20:15:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h151EJJ06441 for ; Tue, 4 Feb 2003 20:14:19 -0500 Received: from zrtps0kn.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09727 for ; Tue, 4 Feb 2003 20:08:06 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h151Bfs24558 for ; Tue, 4 Feb 2003 20:11:41 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1DC5ZPKX>; Tue, 4 Feb 2003 20:11:42 -0500 Message-ID: From: "Kevin Boyle" To: Maschoff Mark-P53708 , "'megaco@ietf.org'" Subject: RE: [Megaco] Subtract Command after ServiceChange "Forced" Date: Tue, 4 Feb 2003 20:11:42 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Comments inline. [KJBII] Kevin -----Original Message----- From: Maschoff Mark-P53708 [mailto:Mark.Maschoff@motorola.com] Sent: Tuesday, February 04, 2003 7:35 PM To: 'megaco@ietf.org' Subject: [Megaco] Subtract Command after ServiceChange "Forced" In the case where a MG sends a ServiceChange - Forced to the MGC indicating that all ephemeral terminations within a Context were abruptly taken out of service (e.g., due to a failure within the MG), does Megaco insist that the MGC subsequently send a Subtract command to the MG to subtract these terminations from the context (and thus remove the Context)? [KJBII] Yes. The MGC may wish to do things like audit the terminations, or take other actions that would/could be precluded by the MG autonomously destroying the ephemerals. The MG is not equipped to make call processing decisions, and therefore shouldn't. Since all terminations within this Context have been taken out of service, the Context could simply be removed by the MG without the need for the Subtract command. Is this acceptable Megaco behavior? [KJBII] No. See my reasoning above. It is the MGC's job to control, not the MG. Also note that removal of all ephemeral terminations does not destroy the context. ALL terminations must be removed -- physical and ephemeral alike. Thanks, Mark _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 4 20:11:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09821 for ; Tue, 4 Feb 2003 20:11:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h151HJc06600 for megaco-archive@odin.ietf.org; Tue, 4 Feb 2003 20:17:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h151HJJ06597 for ; Tue, 4 Feb 2003 20:17:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09803 for ; Tue, 4 Feb 2003 20:11:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h151FQJ06505; Tue, 4 Feb 2003 20:15:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h151EJJ06441 for ; Tue, 4 Feb 2003 20:14:19 -0500 Received: from zrtps0kn.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09727 for ; Tue, 4 Feb 2003 20:08:06 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h151Bfs24558 for ; Tue, 4 Feb 2003 20:11:41 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1DC5ZPKX>; Tue, 4 Feb 2003 20:11:42 -0500 Message-ID: From: "Kevin Boyle" To: Maschoff Mark-P53708 , "'megaco@ietf.org'" Subject: RE: [Megaco] Subtract Command after ServiceChange "Forced" Date: Tue, 4 Feb 2003 20:11:42 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Comments inline. [KJBII] Kevin -----Original Message----- From: Maschoff Mark-P53708 [mailto:Mark.Maschoff@motorola.com] Sent: Tuesday, February 04, 2003 7:35 PM To: 'megaco@ietf.org' Subject: [Megaco] Subtract Command after ServiceChange "Forced" In the case where a MG sends a ServiceChange - Forced to the MGC indicating that all ephemeral terminations within a Context were abruptly taken out of service (e.g., due to a failure within the MG), does Megaco insist that the MGC subsequently send a Subtract command to the MG to subtract these terminations from the context (and thus remove the Context)? [KJBII] Yes. The MGC may wish to do things like audit the terminations, or take other actions that would/could be precluded by the MG autonomously destroying the ephemerals. The MG is not equipped to make call processing decisions, and therefore shouldn't. Since all terminations within this Context have been taken out of service, the Context could simply be removed by the MG without the need for the Subtract command. Is this acceptable Megaco behavior? [KJBII] No. See my reasoning above. It is the MGC's job to control, not the MG. Also note that removal of all ephemeral terminations does not destroy the context. ALL terminations must be removed -- physical and ephemeral alike. Thanks, Mark _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Feb 5 00:51:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16766 for ; Wed, 5 Feb 2003 00:51:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h155v6J19717; Wed, 5 Feb 2003 00:57:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h155t4J19666 for ; Wed, 5 Feb 2003 00:55:04 -0500 Received: from ish7.ericsson.com.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16719 for ; Wed, 5 Feb 2003 00:48:42 -0500 (EST) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id h155o6x09476; Wed, 5 Feb 2003 16:50:06 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h155qJV19023; Wed, 5 Feb 2003 16:52:19 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.194]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DZ3501GD; Wed, 5 Feb 2003 16:52:18 +1100 Message-ID: <3E404C49.47F5DC50@ericsson.com.au> Date: Wed, 05 Feb 2003 10:27:05 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: knayar@hss.hns.com CC: megaco@ietf.org Subject: Re: [Megaco] Cancel Service Change (method=Graceful) mechanism References: <65256CC3.0020566D.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Kapil, It seems Kevin is following up the "warmboot" thread. For the method=graceful in a NULL context I would say its simply a case of the MGC not requesting this termination. It may be useful when doing some sort of scheduled maintenance on the MG. Regards, Christian knayar@hss.hns.com wrote: > > Hi Christian > > Thanks for your replies in line... > You would have read my comments to Kevin's response. We would need some changes > to the following if no other alternative is acceptable/ available: > 1). Definition of reason "WarmBoot". > 2). Definition of method "Restart" which currently states only "service will be > restored on the specified Terminations" > > BTW, I am inquisitive - if an MG would typically send a Service Change > (method=Graceful) with finite delay for a termination in Null context. Any > comments? > > thanks, > kapil nayar > www.hssworld.com > > Christian Groves on 02/04/2003 05:34:44 AM > > To: Kapil Nayar/HSS@HSS > cc: megaco@ietf.org > > Subject: Re: [Megaco] Cancel Service Change (method=Graceful) mechanism > > Hello Kapil, > > Please see my comments below. > > Christian > > knayar@hss.hns.com wrote: > > > > Hi > > > > It seems the protocol doesnot define any procedure for cancelling an earlier > > Service Change (method=Graceful) on a non-root termination. > > > > Taking a practical case: > > MG sends a Service Change (method=Graceful) on a termination with delay= 2 > > hours. > > After 1 hour, MG realizes that it doesn't want to put the termination > > out-of-service (after remaining 1 hour) as was earlier intended. > > How to inform the MGC of the new intentions - cancel graceful..? > > Sending Service Change (method =Restart) would mean that termination just came > > InService and doesnot have any active descriptors, whereas this is not the > case. > > [CHG] Method = Restart, Reason Warm Boot would work as Kevin mentions. > > > > > Solution: > > MG sends Service Change (method = Graceful) delay =2 hours to inform MGC only > > about the intentions. > > MG sends Service Change (method = Forced) when the termination actually goes > > out-of-service after 2 hours. > > This ensures that if Service Change (method = Forced) never came, the > intentions > > of MG never got materialised. > > > > Does any body have an alternative solution? Please suggest. > > [CHG] Why do you need to do this? The MGC should have a timer of 2 hours > associated with that termination. So the MGC knows when to subtract the > termination from the context. The MGC should not use this termination for > traffic after it has subtracted it. > > > > > thanks, > > kapil nayar > > www.hssworld.com > > > > DISCLAIMER: This message is proprietary to Hughes Software Systems > > Limited (HSS) and is intended solely for the use of the individual > > to whom it is addressed. It may contain privileged or confidential > > information and should not be circulated or used for any purpose other > > than for what it is intended. If you have received this message in error, > > please notify the originator immediately. If you are not the intended > > recipient, you are notified that you are strictly prohibited from using, > > copying, altering, or disclosing the contents of this message. HSS accepts > > no responsibility for loss or damage arising from the use of the information > > transmitted by this email including damage from virus. > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Feb 5 00:51:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16782 for ; Wed, 5 Feb 2003 00:51:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h155vDJ19737; Wed, 5 Feb 2003 00:57:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h155t4J19663 for ; Wed, 5 Feb 2003 00:55:04 -0500 Received: from ish7.ericsson.com.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16718 for ; Wed, 5 Feb 2003 00:48:42 -0500 (EST) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id h155o5x09459; Wed, 5 Feb 2003 16:50:05 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h155qIV19019; Wed, 5 Feb 2003 16:52:18 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.194]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DZ3501GA; Wed, 5 Feb 2003 16:52:18 +1100 Message-ID: <3E404B08.CA44A71F@ericsson.com.au> Date: Wed, 05 Feb 2003 10:21:44 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Harry Suede CC: taylor@nortelnetworks.com, megaco@ietf.org Subject: Re: [Megaco] Re: Descriptor state after out of service References: <20030204094209.10170.qmail@email.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit If its already in the NULL context then there's nothing to reset. The out-of-service implies that the termination shall not be used by the MGC. Cheers, Christian Harry Suede wrote: > > That means that "out of service" termination shall be subtracted by MGC. > But how MGC shall reset the descriptor of "out of service" termination in null context. > > ----- Original Message ----- > From: Christian Groves > Date: Tue, 04 Feb 2003 10:57:32 +1100 > To: Tom Taylor > Subject: Re: [Megaco] Re: Descriptor state after out of service > > > G'Day, > > > > I think you should concentrate more on the method associated with the service > > change that put the termination into the Out of Service state. The result of > > Forced or Graceful will be that terminations are subtracted - thus if subtracted > > the descriptors will be affected according to H.248.1 sect 7.2.3. > > > > Christian > > > > Tom Taylor wrote: > > > > > > I don't believe the ServiceChange action does anything to the descriptors on its > > > own. It is up to the MGC to reset them if necessary. I do have the feeling that we > > > might want to analyze the situation and possibly refine it. > > > > > > Harry Suede wrote: > > > > Hi list, Tom > > > > > > > > PL ignore my previous mail. By mistake I have written "out of service" in place of "in service" in the last line. > > > > > > > > What is the state of descriptor of a termination in a non-null context when termination is put "out of service" by MGC or MG? Does the descriptor remain on termination database but inactivated or does they are total flushed. Thus if this termination is put "in service" by MGC or MG then what will be the state of descriptor i.e. they are reapply/reactivated on the termination or not. > > > > > > > > regards > > > > harry > > > > > > _______________________________________________ > > > Megaco mailing list > > > Megaco@ietf.org > > > https://www1.ietf.org/mailman/listinfo/megaco > > > > > > -- > _______________________________________________ > Sign-up for your own FREE Personalized E-mail at Mail.com > http://www.mail.com/?sr=signup > > Meet Singles > http://corp.mail.com/lavalife _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Feb 5 00:51:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16799 for ; Wed, 5 Feb 2003 00:51:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h155vFJ19757; Wed, 5 Feb 2003 00:57:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h155tFJ19675 for ; Wed, 5 Feb 2003 00:55:15 -0500 Received: from ish7.ericsson.com.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16727 for ; Wed, 5 Feb 2003 00:48:54 -0500 (EST) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id h155o4x09451; Wed, 5 Feb 2003 16:50:04 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h155qHV19013; Wed, 5 Feb 2003 16:52:17 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.194]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DZ3501F9; Wed, 5 Feb 2003 16:52:17 +1100 Message-ID: <3E404A38.7FC4CFD2@ericsson.com.au> Date: Wed, 05 Feb 2003 10:18:16 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom Taylor CC: Megaco List , Harry Suede Subject: Re: [Megaco] Re: Descriptor state after out of service References: <20030203104156.5720.qmail@email.com> <3E3E8398.8020105@nortelnetworks.com> <3E3F01EC.F4D8014B@ericsson.com.au> <3E3FE685.7080703@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit G'Day Tom, Servicechange change does not "only" change state. Depending on the method there are certain procedures around the Servicechange. ie. for Servicechange = Graceful it is expected that the MGC should subtract the termination when a call if finished or expiry. When this happens according to graceful the terminations will be put out of service. Cheers, Christian Tom Taylor wrote: > > You have me a bit confused here. ServiceChange simply changes the state of the > termination -- did you mean that the same Action would contain a Subtract, if issued > by the MGC? > > Christian Groves wrote: > > G'Day, > > > > I think you should concentrate more on the method associated with the service > > change that put the termination into the Out of Service state. The result of > > Forced or Graceful will be that terminations are subtracted - thus if subtracted > > the descriptors will be affected according to H.248.1 sect 7.2.3. > > > > Christian > > > > Tom Taylor wrote: > > > >>I don't believe the ServiceChange action does anything to the descriptors on its > >>own. It is up to the MGC to reset them if necessary. I do have the feeling that we > >>might want to analyze the situation and possibly refine it. > >> > >>Harry Suede wrote: > >> > >>>Hi list, Tom > >>> > >>>PL ignore my previous mail. By mistake I have written "out of service" in place of "in service" in the last line. > >>> > >>>What is the state of descriptor of a termination in a non-null context when termination is put "out of service" by MGC or MG? Does the descriptor remain on termination database but inactivated or does they are total flushed. Thus if this termination is put "in service" by MGC or MG then what will be the state of descriptor i.e. they are reapply/reactivated on the termination or not. > >>> > >>>regards > >>>harry > >> > >>_______________________________________________ > >>Megaco mailing list > >>Megaco@ietf.org > >>https://www1.ietf.org/mailman/listinfo/megaco > > > > > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Feb 5 00:52:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16826 for ; Wed, 5 Feb 2003 00:52:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h155w6q19807 for megaco-archive@odin.ietf.org; Wed, 5 Feb 2003 00:58:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h155w5J19804 for ; Wed, 5 Feb 2003 00:58:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16775 for ; Wed, 5 Feb 2003 00:51:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h155v6J19717; Wed, 5 Feb 2003 00:57:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h155t4J19666 for ; Wed, 5 Feb 2003 00:55:04 -0500 Received: from ish7.ericsson.com.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16719 for ; Wed, 5 Feb 2003 00:48:42 -0500 (EST) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id h155o6x09476; Wed, 5 Feb 2003 16:50:06 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h155qJV19023; Wed, 5 Feb 2003 16:52:19 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.194]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DZ3501GD; Wed, 5 Feb 2003 16:52:18 +1100 Message-ID: <3E404C49.47F5DC50@ericsson.com.au> Date: Wed, 05 Feb 2003 10:27:05 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: knayar@hss.hns.com CC: megaco@ietf.org Subject: Re: [Megaco] Cancel Service Change (method=Graceful) mechanism References: <65256CC3.0020566D.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Kapil, It seems Kevin is following up the "warmboot" thread. For the method=graceful in a NULL context I would say its simply a case of the MGC not requesting this termination. It may be useful when doing some sort of scheduled maintenance on the MG. Regards, Christian knayar@hss.hns.com wrote: > > Hi Christian > > Thanks for your replies in line... > You would have read my comments to Kevin's response. We would need some changes > to the following if no other alternative is acceptable/ available: > 1). Definition of reason "WarmBoot". > 2). Definition of method "Restart" which currently states only "service will be > restored on the specified Terminations" > > BTW, I am inquisitive - if an MG would typically send a Service Change > (method=Graceful) with finite delay for a termination in Null context. Any > comments? > > thanks, > kapil nayar > www.hssworld.com > > Christian Groves on 02/04/2003 05:34:44 AM > > To: Kapil Nayar/HSS@HSS > cc: megaco@ietf.org > > Subject: Re: [Megaco] Cancel Service Change (method=Graceful) mechanism > > Hello Kapil, > > Please see my comments below. > > Christian > > knayar@hss.hns.com wrote: > > > > Hi > > > > It seems the protocol doesnot define any procedure for cancelling an earlier > > Service Change (method=Graceful) on a non-root termination. > > > > Taking a practical case: > > MG sends a Service Change (method=Graceful) on a termination with delay= 2 > > hours. > > After 1 hour, MG realizes that it doesn't want to put the termination > > out-of-service (after remaining 1 hour) as was earlier intended. > > How to inform the MGC of the new intentions - cancel graceful..? > > Sending Service Change (method =Restart) would mean that termination just came > > InService and doesnot have any active descriptors, whereas this is not the > case. > > [CHG] Method = Restart, Reason Warm Boot would work as Kevin mentions. > > > > > Solution: > > MG sends Service Change (method = Graceful) delay =2 hours to inform MGC only > > about the intentions. > > MG sends Service Change (method = Forced) when the termination actually goes > > out-of-service after 2 hours. > > This ensures that if Service Change (method = Forced) never came, the > intentions > > of MG never got materialised. > > > > Does any body have an alternative solution? Please suggest. > > [CHG] Why do you need to do this? The MGC should have a timer of 2 hours > associated with that termination. So the MGC knows when to subtract the > termination from the context. The MGC should not use this termination for > traffic after it has subtracted it. > > > > > thanks, > > kapil nayar > > www.hssworld.com > > > > DISCLAIMER: This message is proprietary to Hughes Software Systems > > Limited (HSS) and is intended solely for the use of the individual > > to whom it is addressed. It may contain privileged or confidential > > information and should not be circulated or used for any purpose other > > than for what it is intended. If you have received this message in error, > > please notify the originator immediately. If you are not the intended > > recipient, you are notified that you are strictly prohibited from using, > > copying, altering, or disclosing the contents of this message. HSS accepts > > no responsibility for loss or damage arising from the use of the information > > transmitted by this email including damage from virus. > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Feb 5 00:52:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16841 for ; Wed, 5 Feb 2003 00:52:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h155w7t19823 for megaco-archive@odin.ietf.org; Wed, 5 Feb 2003 00:58:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h155w7J19820 for ; Wed, 5 Feb 2003 00:58:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16788 for ; Wed, 5 Feb 2003 00:51:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h155vDJ19737; Wed, 5 Feb 2003 00:57:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h155t4J19663 for ; Wed, 5 Feb 2003 00:55:04 -0500 Received: from ish7.ericsson.com.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16718 for ; Wed, 5 Feb 2003 00:48:42 -0500 (EST) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id h155o5x09459; Wed, 5 Feb 2003 16:50:05 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h155qIV19019; Wed, 5 Feb 2003 16:52:18 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.194]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DZ3501GA; Wed, 5 Feb 2003 16:52:18 +1100 Message-ID: <3E404B08.CA44A71F@ericsson.com.au> Date: Wed, 05 Feb 2003 10:21:44 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Harry Suede CC: taylor@nortelnetworks.com, megaco@ietf.org Subject: Re: [Megaco] Re: Descriptor state after out of service References: <20030204094209.10170.qmail@email.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit If its already in the NULL context then there's nothing to reset. The out-of-service implies that the termination shall not be used by the MGC. Cheers, Christian Harry Suede wrote: > > That means that "out of service" termination shall be subtracted by MGC. > But how MGC shall reset the descriptor of "out of service" termination in null context. > > ----- Original Message ----- > From: Christian Groves > Date: Tue, 04 Feb 2003 10:57:32 +1100 > To: Tom Taylor > Subject: Re: [Megaco] Re: Descriptor state after out of service > > > G'Day, > > > > I think you should concentrate more on the method associated with the service > > change that put the termination into the Out of Service state. The result of > > Forced or Graceful will be that terminations are subtracted - thus if subtracted > > the descriptors will be affected according to H.248.1 sect 7.2.3. > > > > Christian > > > > Tom Taylor wrote: > > > > > > I don't believe the ServiceChange action does anything to the descriptors on its > > > own. It is up to the MGC to reset them if necessary. I do have the feeling that we > > > might want to analyze the situation and possibly refine it. > > > > > > Harry Suede wrote: > > > > Hi list, Tom > > > > > > > > PL ignore my previous mail. By mistake I have written "out of service" in place of "in service" in the last line. > > > > > > > > What is the state of descriptor of a termination in a non-null context when termination is put "out of service" by MGC or MG? Does the descriptor remain on termination database but inactivated or does they are total flushed. Thus if this termination is put "in service" by MGC or MG then what will be the state of descriptor i.e. they are reapply/reactivated on the termination or not. > > > > > > > > regards > > > > harry > > > > > > _______________________________________________ > > > Megaco mailing list > > > Megaco@ietf.org > > > https://www1.ietf.org/mailman/listinfo/megaco > > > > > > -- > _______________________________________________ > Sign-up for your own FREE Personalized E-mail at Mail.com > http://www.mail.com/?sr=signup > > Meet Singles > http://corp.mail.com/lavalife _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Feb 5 00:52:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16855 for ; Wed, 5 Feb 2003 00:52:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h155w9719839 for megaco-archive@odin.ietf.org; Wed, 5 Feb 2003 00:58:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h155w9J19836 for ; Wed, 5 Feb 2003 00:58:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16805 for ; Wed, 5 Feb 2003 00:51:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h155vFJ19757; Wed, 5 Feb 2003 00:57:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h155tFJ19675 for ; Wed, 5 Feb 2003 00:55:15 -0500 Received: from ish7.ericsson.com.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16727 for ; Wed, 5 Feb 2003 00:48:54 -0500 (EST) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id h155o4x09451; Wed, 5 Feb 2003 16:50:04 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h155qHV19013; Wed, 5 Feb 2003 16:52:17 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.194]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DZ3501F9; Wed, 5 Feb 2003 16:52:17 +1100 Message-ID: <3E404A38.7FC4CFD2@ericsson.com.au> Date: Wed, 05 Feb 2003 10:18:16 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom Taylor CC: Megaco List , Harry Suede Subject: Re: [Megaco] Re: Descriptor state after out of service References: <20030203104156.5720.qmail@email.com> <3E3E8398.8020105@nortelnetworks.com> <3E3F01EC.F4D8014B@ericsson.com.au> <3E3FE685.7080703@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit G'Day Tom, Servicechange change does not "only" change state. Depending on the method there are certain procedures around the Servicechange. ie. for Servicechange = Graceful it is expected that the MGC should subtract the termination when a call if finished or expiry. When this happens according to graceful the terminations will be put out of service. Cheers, Christian Tom Taylor wrote: > > You have me a bit confused here. ServiceChange simply changes the state of the > termination -- did you mean that the same Action would contain a Subtract, if issued > by the MGC? > > Christian Groves wrote: > > G'Day, > > > > I think you should concentrate more on the method associated with the service > > change that put the termination into the Out of Service state. The result of > > Forced or Graceful will be that terminations are subtracted - thus if subtracted > > the descriptors will be affected according to H.248.1 sect 7.2.3. > > > > Christian > > > > Tom Taylor wrote: > > > >>I don't believe the ServiceChange action does anything to the descriptors on its > >>own. It is up to the MGC to reset them if necessary. I do have the feeling that we > >>might want to analyze the situation and possibly refine it. > >> > >>Harry Suede wrote: > >> > >>>Hi list, Tom > >>> > >>>PL ignore my previous mail. By mistake I have written "out of service" in place of "in service" in the last line. > >>> > >>>What is the state of descriptor of a termination in a non-null context when termination is put "out of service" by MGC or MG? Does the descriptor remain on termination database but inactivated or does they are total flushed. Thus if this termination is put "in service" by MGC or MG then what will be the state of descriptor i.e. they are reapply/reactivated on the termination or not. > >>> > >>>regards > >>>harry > >> > >>_______________________________________________ > >>Megaco mailing list > >>Megaco@ietf.org > >>https://www1.ietf.org/mailman/listinfo/megaco > > > > > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Feb 5 07:49:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23139 for ; Wed, 5 Feb 2003 07:49:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15CsRJ22283; Wed, 5 Feb 2003 07:54:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15CqUJ22157 for ; Wed, 5 Feb 2003 07:52:30 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23043 for ; Wed, 5 Feb 2003 07:46:01 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h15CnUb23569; Wed, 5 Feb 2003 07:49:33 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1WBZ35; Wed, 5 Feb 2003 07:49:31 -0500 Received: from nortelnetworks.com (acart1cx.ca.nortel.com [47.129.129.73]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1NCFGR; Wed, 5 Feb 2003 07:49:31 -0500 Message-ID: <3E410856.6010205@nortelnetworks.com> Date: Wed, 05 Feb 2003 07:49:26 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Christian Groves , Megaco List CC: Harry Suede Subject: Re: [Megaco] Re: Descriptor state after out of service References: <20030203104156.5720.qmail@email.com> <3E3E8398.8020105@nortelnetworks.com> <3E3F01EC.F4D8014B@ericsson.com.au> <3E3FE685.7080703@nortelnetworks.com> <3E404A38.7FC4CFD2@ericsson.com.au> In-Reply-To: <3E404A38.7FC4CFD2@ericsson.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit We're on the same page, then. I was worried you were saying the ServiceChange itself was doing a subtraction. Christian Groves wrote: > G'Day Tom, > > Servicechange change does not "only" change state. Depending on the method there > are certain procedures around the Servicechange. ie. for Servicechange = > Graceful it is expected that the MGC should subtract the termination when a call > if finished or expiry. When this happens according to graceful the terminations > will be put out of service. > > Cheers, Christian > > Tom Taylor wrote: > >>You have me a bit confused here. ServiceChange simply changes the state of the >>termination -- did you mean that the same Action would contain a Subtract, if issued >>by the MGC? >> >>Christian Groves wrote: >> >>>G'Day, >>> >>>I think you should concentrate more on the method associated with the service >>>change that put the termination into the Out of Service state. The result of >>>Forced or Graceful will be that terminations are subtracted - thus if subtracted >>>the descriptors will be affected according to H.248.1 sect 7.2.3. >>> >>>Christian >>> >>>Tom Taylor wrote: >>> >>> >>>>I don't believe the ServiceChange action does anything to the descriptors on its >>>>own. It is up to the MGC to reset them if necessary. I do have the feeling that we >>>>might want to analyze the situation and possibly refine it. >>>> >>>>Harry Suede wrote: >>>> >>>> >>>>>Hi list, Tom >>>>> >>>>>PL ignore my previous mail. By mistake I have written "out of service" in place of "in service" in the last line. >>>>> >>>>>What is the state of descriptor of a termination in a non-null context when termination is put "out of service" by MGC or MG? Does the descriptor remain on termination database but inactivated or does they are total flushed. Thus if this termination is put "in service" by MGC or MG then what will be the state of descriptor i.e. they are reapply/reactivated on the termination or not. >>>>> >>>>>regards >>>>>harry >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>> >>> >>> >>> > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Feb 5 07:49:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23204 for ; Wed, 5 Feb 2003 07:49:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15CtXQ22362 for megaco-archive@odin.ietf.org; Wed, 5 Feb 2003 07:55:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15CtXJ22359 for ; Wed, 5 Feb 2003 07:55:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23144 for ; Wed, 5 Feb 2003 07:49:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15CsRJ22283; Wed, 5 Feb 2003 07:54:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15CqUJ22157 for ; Wed, 5 Feb 2003 07:52:30 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23043 for ; Wed, 5 Feb 2003 07:46:01 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h15CnUb23569; Wed, 5 Feb 2003 07:49:33 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1WBZ35; Wed, 5 Feb 2003 07:49:31 -0500 Received: from nortelnetworks.com (acart1cx.ca.nortel.com [47.129.129.73]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1NCFGR; Wed, 5 Feb 2003 07:49:31 -0500 Message-ID: <3E410856.6010205@nortelnetworks.com> Date: Wed, 05 Feb 2003 07:49:26 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Christian Groves , Megaco List CC: Harry Suede Subject: Re: [Megaco] Re: Descriptor state after out of service References: <20030203104156.5720.qmail@email.com> <3E3E8398.8020105@nortelnetworks.com> <3E3F01EC.F4D8014B@ericsson.com.au> <3E3FE685.7080703@nortelnetworks.com> <3E404A38.7FC4CFD2@ericsson.com.au> In-Reply-To: <3E404A38.7FC4CFD2@ericsson.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We're on the same page, then. I was worried you were saying the ServiceChange itself was doing a subtraction. Christian Groves wrote: > G'Day Tom, > > Servicechange change does not "only" change state. Depending on the method there > are certain procedures around the Servicechange. ie. for Servicechange = > Graceful it is expected that the MGC should subtract the termination when a call > if finished or expiry. When this happens according to graceful the terminations > will be put out of service. > > Cheers, Christian > > Tom Taylor wrote: > >>You have me a bit confused here. ServiceChange simply changes the state of the >>termination -- did you mean that the same Action would contain a Subtract, if issued >>by the MGC? >> >>Christian Groves wrote: >> >>>G'Day, >>> >>>I think you should concentrate more on the method associated with the service >>>change that put the termination into the Out of Service state. The result of >>>Forced or Graceful will be that terminations are subtracted - thus if subtracted >>>the descriptors will be affected according to H.248.1 sect 7.2.3. >>> >>>Christian >>> >>>Tom Taylor wrote: >>> >>> >>>>I don't believe the ServiceChange action does anything to the descriptors on its >>>>own. It is up to the MGC to reset them if necessary. I do have the feeling that we >>>>might want to analyze the situation and possibly refine it. >>>> >>>>Harry Suede wrote: >>>> >>>> >>>>>Hi list, Tom >>>>> >>>>>PL ignore my previous mail. By mistake I have written "out of service" in place of "in service" in the last line. >>>>> >>>>>What is the state of descriptor of a termination in a non-null context when termination is put "out of service" by MGC or MG? Does the descriptor remain on termination database but inactivated or does they are total flushed. Thus if this termination is put "in service" by MGC or MG then what will be the state of descriptor i.e. they are reapply/reactivated on the termination or not. >>>>> >>>>>regards >>>>>harry >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>> >>> >>> >>> > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Feb 6 12:23:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26783 for ; Thu, 6 Feb 2003 12:23:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16HTHp17195; Thu, 6 Feb 2003 12:29:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16HRPp17076 for ; Thu, 6 Feb 2003 12:27:25 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26649 for ; Thu, 6 Feb 2003 12:20:22 -0500 (EST) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h16HNx224309 for ; Thu, 6 Feb 2003 12:23:59 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1LM1CZ0T; Thu, 6 Feb 2003 12:23:59 -0500 Received: from nortelnetworks.com (taylor-2.ca.nortel.com [47.130.10.130]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1NCFZ3; Thu, 6 Feb 2003 12:23:59 -0500 Message-ID: <3E429A2E.9060100@nortelnetworks.com> Date: Thu, 06 Feb 2003 12:23:58 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Megaco List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] Meeting In SF?? Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit It's pretty late to ask, but are people interested in a meeting in San Francisco? Possible topics would be the MIB, potential Megaco evolution, ... Tom Taylor _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Feb 6 12:23:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26810 for ; Thu, 6 Feb 2003 12:23:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16HURq17266 for megaco-archive@odin.ietf.org; Thu, 6 Feb 2003 12:30:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16HURp17263 for ; Thu, 6 Feb 2003 12:30:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26796 for ; Thu, 6 Feb 2003 12:23:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16HTHp17195; Thu, 6 Feb 2003 12:29:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16HRPp17076 for ; Thu, 6 Feb 2003 12:27:25 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26649 for ; Thu, 6 Feb 2003 12:20:22 -0500 (EST) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h16HNx224309 for ; Thu, 6 Feb 2003 12:23:59 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1LM1CZ0T; Thu, 6 Feb 2003 12:23:59 -0500 Received: from nortelnetworks.com (taylor-2.ca.nortel.com [47.130.10.130]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1NCFZ3; Thu, 6 Feb 2003 12:23:59 -0500 Message-ID: <3E429A2E.9060100@nortelnetworks.com> Date: Thu, 06 Feb 2003 12:23:58 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Megaco List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] Meeting In SF?? Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It's pretty late to ask, but are people interested in a meeting in San Francisco? Possible topics would be the MIB, potential Megaco evolution, ... Tom Taylor _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Sat Feb 8 00:43:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02396 for ; Sat, 8 Feb 2003 00:43:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h185oCp23067; Sat, 8 Feb 2003 00:50:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h185g2p22934 for ; Sat, 8 Feb 2003 00:42:02 -0500 Received: from web20903.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02281 for ; Sat, 8 Feb 2003 00:34:15 -0500 (EST) Message-ID: <20030208053754.36998.qmail@web20903.mail.yahoo.com> Received: from [66.139.197.164] by web20903.mail.yahoo.com via HTTP; Fri, 07 Feb 2003 21:37:54 PST Date: Fri, 7 Feb 2003 21:37:54 -0800 (PST) From: kt r To: megaco@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Megaco] COT... Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi all, I just wanted to know some detailed description about the COT (Continuity). I would appreciate if someone can throw some light on how this is accomplished...I have questions like when the call server sends this message with COT signal, how does the Gateway handles this message i.e. how COT is performed. Thanks, KTR __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Sat Feb 8 00:44:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02417 for ; Sat, 8 Feb 2003 00:44:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h185pUG23096 for megaco-archive@odin.ietf.org; Sat, 8 Feb 2003 00:51:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h185pUp23093 for ; Sat, 8 Feb 2003 00:51:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02407 for ; Sat, 8 Feb 2003 00:43:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h185oCp23067; Sat, 8 Feb 2003 00:50:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h185g2p22934 for ; Sat, 8 Feb 2003 00:42:02 -0500 Received: from web20903.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02281 for ; Sat, 8 Feb 2003 00:34:15 -0500 (EST) Message-ID: <20030208053754.36998.qmail@web20903.mail.yahoo.com> Received: from [66.139.197.164] by web20903.mail.yahoo.com via HTTP; Fri, 07 Feb 2003 21:37:54 PST Date: Fri, 7 Feb 2003 21:37:54 -0800 (PST) From: kt r To: megaco@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Megaco] COT... Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi all, I just wanted to know some detailed description about the COT (Continuity). I would appreciate if someone can throw some light on how this is accomplished...I have questions like when the call server sends this message with COT signal, how does the Gateway handles this message i.e. how COT is performed. Thanks, KTR __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Feb 10 12:31:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17221 for ; Mon, 10 Feb 2003 12:31:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AHdUp30876; Mon, 10 Feb 2003 12:39:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AFmHp23318 for ; Mon, 10 Feb 2003 10:48:17 -0500 Received: from mink.ecitele.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12636 for ; Mon, 10 Feb 2003 10:39:18 -0500 (EST) From: Dana.Herskowitz@veraznetworks.com Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id RAA29288 for ; Mon, 10 Feb 2003 17:37:41 +0200 (IST) To: megaco@ietf.org Cc: Eli.Liluz@veraznetworks.com, Benny.Lavi@veraznetworks.com, Ilana.Leibovitch@veraznetworks.com, Meir.Leshem@veraznetworks.com, Artur.Karaev@veraznetworks.com X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Mon, 10 Feb 2003 17:42:51 +0200 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 02/10/2003 05:42:58 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Megaco] Accumulating detected events Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hello, Suppose EBC = Lockstep and event was detected in the Media level. The event appears in Events-Buffer-Descriptor but does not in Events-Descriptor. 1) Should his event be accumulated? 2) Does it depend whether this event was requested before in one of the former Events Descriptors? - If yes - till when this event is being requested? Generally speaking - I'd like to know which events should I accumulate - 1) those which appear in EB Desciptor only or 2) those which appear in one of Events Descriptor and EB Descriptor? Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Feb 10 12:32:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17271 for ; Mon, 10 Feb 2003 12:32:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1AHeos30995 for megaco-archive@odin.ietf.org; Mon, 10 Feb 2003 12:40:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AHeop30992 for ; Mon, 10 Feb 2003 12:40:50 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17237 for ; Mon, 10 Feb 2003 12:31:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AHdUp30876; Mon, 10 Feb 2003 12:39:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AFmHp23318 for ; Mon, 10 Feb 2003 10:48:17 -0500 Received: from mink.ecitele.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12636 for ; Mon, 10 Feb 2003 10:39:18 -0500 (EST) From: Dana.Herskowitz@veraznetworks.com Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id RAA29288 for ; Mon, 10 Feb 2003 17:37:41 +0200 (IST) To: megaco@ietf.org Cc: Eli.Liluz@veraznetworks.com, Benny.Lavi@veraznetworks.com, Ilana.Leibovitch@veraznetworks.com, Meir.Leshem@veraznetworks.com, Artur.Karaev@veraznetworks.com X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Mon, 10 Feb 2003 17:42:51 +0200 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 02/10/2003 05:42:58 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Megaco] Accumulating detected events Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hello, Suppose EBC = Lockstep and event was detected in the Media level. The event appears in Events-Buffer-Descriptor but does not in Events-Descriptor. 1) Should his event be accumulated? 2) Does it depend whether this event was requested before in one of the former Events Descriptors? - If yes - till when this event is being requested? Generally speaking - I'd like to know which events should I accumulate - 1) those which appear in EB Desciptor only or 2) those which appear in one of Events Descriptor and EB Descriptor? Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Feb 10 13:39:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20035 for ; Mon, 10 Feb 2003 13:39:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AIlBp02748; Mon, 10 Feb 2003 13:47:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AIjHp02644 for ; Mon, 10 Feb 2003 13:45:17 -0500 Received: from revere.sonusnet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19934 for ; Mon, 10 Feb 2003 13:36:13 -0500 (EST) Received: from sonusdc3.sonusnet.com (sonusdc3.sonusnet.com [10.128.32.53]) by revere.sonusnet.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id h1AIdl724353; Mon, 10 Feb 2003 13:39:47 -0500 (EST) Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Feb 2003 13:39:54 -0500 Message-ID: <4CF48720B6E9D4118D040060CF2074E907B34510@sonusdc3.sonusnet.com> From: "Kamitses, Jerry" To: "'kt r'" , megaco@ietf.org Subject: RE: [Megaco] COT... Date: Mon, 10 Feb 2003 13:39:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , There was a discussion on this topic last Spring with contributions from Al Varney, Madhu Babu Brahmanapally, and Anil Jangam, which I have reproduced below. Maybe this will help? There is also a good description of the COT protocol in the MGCP Trunk Package write up (Section 2.3 of draft-foster-mgcp-basic-packages-09.txt). See also GR-317-CORE. ---------------------------------------------------------------------------- ---- To: Subject: Re: [Megaco] Continuity test procedure. From: Al Varney Date: Wed, 15 May 2002 12:35:01 -0500 In-Reply-To: List-Id: Media Gateway Control Sender: megaco-admin@ietf.org ---------------------------------------------------------------------------- ---- Some further details on continuity test, and comments on Madhu's, et al callflows draft: At 09:01 PM 5/13/02 +0530, Anil Jangam wrote: >In carrying out the continuity check on the given Physical terminal (CIC), >there are two cases are defined (see 2.12 in Madhu's call flow). > >In the case a, the message flow depicts the transaction between the MGC and >MG. My question is -- When the continuity signal is applied at the MG side >of the link, who does the loopback at the other end of the link? It is shown >that upon receiving the "Continuity Signal Resp", a Notify message signal is >sent back to the MGC. Continuity checks are initiated and controlled by MGCs (or SS7 exchanges/switches in non-MGC architectures). The loopback at the other end of the circuit (link?) is initiated by a PSTN switch or MGC controlling that end of the circuit. But that switch/MGC is acting on an (SS7) request by the initiating MGC described in case (a). >This is imperative from the description of the case b that there has to be >some form of message exchange between the node who is initialting/requesting >the continuity (the MG end) and the other end (may be MGC or MG). The MGC is initiating the continuity test (not the MG). And yes, there is a message sent to the other end (MGC or switch) to stimulate the case (b) behavior at that end. The SS7 message might be an IAM or a maintenance message (CCR) -- in either instance, the loopback remains until a further SS7 message (COT or REL or ...) requests removal of the loopback. >In case b it is mentioned that PSTN requests for the continuity check. >Please complete the call flow. Both cases are missing some Megaco information. Adding the associated SS7 messages (IAM/COT?) would also add some clarity. Assuming a typical call (rather than the CCR scenario), in case (a) show the MGC sending an "IAM with Continuity Request" prior to step 1, and sending a "COT with Success" after receiving the MG Notify and completing Step 4. Step 4 needs to remove the "test" state from the circuit, and place it in a context or mode allowing transmission in the backward (or both) direction(s). (Transmission of COT w/Success in ISUP implies the test equipment has been removed and the circuit is ready to transport in-band tones at least in the backwards direction.) For the case (b) scenario, the MGC receives the above IAM prior to Step 1, and receives the COT after Step 2. Add a Step 3 showing the removal of the "test/loopback" condition and "rsp" signal after receipt of COT. In most cases, after the continuity test is complete, the circuit should be added to (or already be in) a context where it can receive and transport audible ring tone from the succeeding leg of the connection back to the originating end. Since these are call-flows, they correctly show little detail about the continuity test itself. Nor does RFC 3015 aid in understanding the timing and tones required for the test. For that, ITU-T Q.724 (TUP) is perhaps the best reference for test tones and the 2-wire (non-loopback) test. Note that, unlike the loopback form of the test, the 2-wire test returns a different frequency than the sent frequency. Thus the 2-wire test will fail if an accidental digital loopback is left in place in the circuit (transmission) network -- the loopback test cannot detect this error. For that reason, some service providers prefer to use the 2-wire test even on ISUP/digital circuits. In ISUP, ITU-T Q.764 should be used to determine the specific states of the continuity test (TUP uses an end-to-end test, where ISUP uses a circuit-by-circuit test). Q.764 assumes (incorrectly) that there will be no 2-wire circuits used by ISUP, so it specifies only the loopback form of the test. The ANSI T1.113 version describes both forms. Also, note that actual test frequencies/timing vary from country to country. Al Varney _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ---------------------------------------------------------------------------- ---- -----Original Message----- From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] Sent: Tuesday, May 14, 2002 1:02 PM To: 'Anil Jangam'; megaco@ietf.org Subject: RE: [Megaco] Continuity test procedure. HI anil, There are two ways of performing the continuity tests. One in which the remote end is set to loopback and the same signal generated at near end will be loop backed from the far end. Another method in which the near end and far end generate different signals . Irrespective of the type of test, it is assumed that the MGC will generate necessary messages to both sides to generate and detect necessary signals/events. Both cases of terminating and originating continuity tests were considered in the call flows. Regards Madhubabu Brahmanapally. -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of Anil Jangam Sent: Monday, May 13, 2002 11:32 AM To: 'megaco@ietf.org ' Subject: [Megaco] Continuity test procedure. Hi, In carrying out the continuity check on the given Physical terminal (CIC), there are two cases are defined (see 2.12 in Madhu's call flow). In the case a, the message flow depicts the transaction between the MGC and MG. My question is -- When the continuity signal is applied at the MG side of the link, who does the loopback at the other end of the link? It is shown that upon receiving the "Continuity Signal Resp", a Notify message signal is sent back to the MGC. This is imperative from the description of the case b that there has to be some form of message exchange between the node who is initialting/requesting the continuity (the MG end) and the other end (may be MGC or MG). In case b it is mentioned that PSTN requests for the continuity check. Please complete the call flow. /anil. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --- [This E-mail was scanned for viruses and is clean.] _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco \-----Original Message----- From: kt r [mailto:ktr449@yahoo.com] Sent: Saturday, February 08, 2003 12:38 AM To: megaco@ietf.org Subject: [Megaco] COT... Hi all, I just wanted to know some detailed description about the COT (Continuity). I would appreciate if someone can throw some light on how this is accomplished...I have questions like when the call server sends this message with COT signal, how does the Gateway handles this message i.e. how COT is performed. Thanks, KTR __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Feb 10 13:39:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20065 for ; Mon, 10 Feb 2003 13:39:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1AImUp02786 for megaco-archive@odin.ietf.org; Mon, 10 Feb 2003 13:48:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AImTp02783 for ; Mon, 10 Feb 2003 13:48:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20050 for ; Mon, 10 Feb 2003 13:39:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AIlBp02748; Mon, 10 Feb 2003 13:47:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AIjHp02644 for ; Mon, 10 Feb 2003 13:45:17 -0500 Received: from revere.sonusnet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19934 for ; Mon, 10 Feb 2003 13:36:13 -0500 (EST) Received: from sonusdc3.sonusnet.com (sonusdc3.sonusnet.com [10.128.32.53]) by revere.sonusnet.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id h1AIdl724353; Mon, 10 Feb 2003 13:39:47 -0500 (EST) Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Feb 2003 13:39:54 -0500 Message-ID: <4CF48720B6E9D4118D040060CF2074E907B34510@sonusdc3.sonusnet.com> From: "Kamitses, Jerry" To: "'kt r'" , megaco@ietf.org Subject: RE: [Megaco] COT... Date: Mon, 10 Feb 2003 13:39:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , There was a discussion on this topic last Spring with contributions from Al Varney, Madhu Babu Brahmanapally, and Anil Jangam, which I have reproduced below. Maybe this will help? There is also a good description of the COT protocol in the MGCP Trunk Package write up (Section 2.3 of draft-foster-mgcp-basic-packages-09.txt). See also GR-317-CORE. ---------------------------------------------------------------------------- ---- To: Subject: Re: [Megaco] Continuity test procedure. From: Al Varney Date: Wed, 15 May 2002 12:35:01 -0500 In-Reply-To: List-Id: Media Gateway Control Sender: megaco-admin@ietf.org ---------------------------------------------------------------------------- ---- Some further details on continuity test, and comments on Madhu's, et al callflows draft: At 09:01 PM 5/13/02 +0530, Anil Jangam wrote: >In carrying out the continuity check on the given Physical terminal (CIC), >there are two cases are defined (see 2.12 in Madhu's call flow). > >In the case a, the message flow depicts the transaction between the MGC and >MG. My question is -- When the continuity signal is applied at the MG side >of the link, who does the loopback at the other end of the link? It is shown >that upon receiving the "Continuity Signal Resp", a Notify message signal is >sent back to the MGC. Continuity checks are initiated and controlled by MGCs (or SS7 exchanges/switches in non-MGC architectures). The loopback at the other end of the circuit (link?) is initiated by a PSTN switch or MGC controlling that end of the circuit. But that switch/MGC is acting on an (SS7) request by the initiating MGC described in case (a). >This is imperative from the description of the case b that there has to be >some form of message exchange between the node who is initialting/requesting >the continuity (the MG end) and the other end (may be MGC or MG). The MGC is initiating the continuity test (not the MG). And yes, there is a message sent to the other end (MGC or switch) to stimulate the case (b) behavior at that end. The SS7 message might be an IAM or a maintenance message (CCR) -- in either instance, the loopback remains until a further SS7 message (COT or REL or ...) requests removal of the loopback. >In case b it is mentioned that PSTN requests for the continuity check. >Please complete the call flow. Both cases are missing some Megaco information. Adding the associated SS7 messages (IAM/COT?) would also add some clarity. Assuming a typical call (rather than the CCR scenario), in case (a) show the MGC sending an "IAM with Continuity Request" prior to step 1, and sending a "COT with Success" after receiving the MG Notify and completing Step 4. Step 4 needs to remove the "test" state from the circuit, and place it in a context or mode allowing transmission in the backward (or both) direction(s). (Transmission of COT w/Success in ISUP implies the test equipment has been removed and the circuit is ready to transport in-band tones at least in the backwards direction.) For the case (b) scenario, the MGC receives the above IAM prior to Step 1, and receives the COT after Step 2. Add a Step 3 showing the removal of the "test/loopback" condition and "rsp" signal after receipt of COT. In most cases, after the continuity test is complete, the circuit should be added to (or already be in) a context where it can receive and transport audible ring tone from the succeeding leg of the connection back to the originating end. Since these are call-flows, they correctly show little detail about the continuity test itself. Nor does RFC 3015 aid in understanding the timing and tones required for the test. For that, ITU-T Q.724 (TUP) is perhaps the best reference for test tones and the 2-wire (non-loopback) test. Note that, unlike the loopback form of the test, the 2-wire test returns a different frequency than the sent frequency. Thus the 2-wire test will fail if an accidental digital loopback is left in place in the circuit (transmission) network -- the loopback test cannot detect this error. For that reason, some service providers prefer to use the 2-wire test even on ISUP/digital circuits. In ISUP, ITU-T Q.764 should be used to determine the specific states of the continuity test (TUP uses an end-to-end test, where ISUP uses a circuit-by-circuit test). Q.764 assumes (incorrectly) that there will be no 2-wire circuits used by ISUP, so it specifies only the loopback form of the test. The ANSI T1.113 version describes both forms. Also, note that actual test frequencies/timing vary from country to country. Al Varney _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ---------------------------------------------------------------------------- ---- -----Original Message----- From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] Sent: Tuesday, May 14, 2002 1:02 PM To: 'Anil Jangam'; megaco@ietf.org Subject: RE: [Megaco] Continuity test procedure. HI anil, There are two ways of performing the continuity tests. One in which the remote end is set to loopback and the same signal generated at near end will be loop backed from the far end. Another method in which the near end and far end generate different signals . Irrespective of the type of test, it is assumed that the MGC will generate necessary messages to both sides to generate and detect necessary signals/events. Both cases of terminating and originating continuity tests were considered in the call flows. Regards Madhubabu Brahmanapally. -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of Anil Jangam Sent: Monday, May 13, 2002 11:32 AM To: 'megaco@ietf.org ' Subject: [Megaco] Continuity test procedure. Hi, In carrying out the continuity check on the given Physical terminal (CIC), there are two cases are defined (see 2.12 in Madhu's call flow). In the case a, the message flow depicts the transaction between the MGC and MG. My question is -- When the continuity signal is applied at the MG side of the link, who does the loopback at the other end of the link? It is shown that upon receiving the "Continuity Signal Resp", a Notify message signal is sent back to the MGC. This is imperative from the description of the case b that there has to be some form of message exchange between the node who is initialting/requesting the continuity (the MG end) and the other end (may be MGC or MG). In case b it is mentioned that PSTN requests for the continuity check. Please complete the call flow. /anil. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --- [This E-mail was scanned for viruses and is clean.] _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco \-----Original Message----- From: kt r [mailto:ktr449@yahoo.com] Sent: Saturday, February 08, 2003 12:38 AM To: megaco@ietf.org Subject: [Megaco] COT... Hi all, I just wanted to know some detailed description about the COT (Continuity). I would appreciate if someone can throw some light on how this is accomplished...I have questions like when the call server sends this message with COT signal, how does the Gateway handles this message i.e. how COT is performed. Thanks, KTR __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Feb 10 13:49:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20526 for ; Mon, 10 Feb 2003 13:49:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AIv8p03227; Mon, 10 Feb 2003 13:57:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AIuLp03181 for ; Mon, 10 Feb 2003 13:56:21 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20462 for ; Mon, 10 Feb 2003 13:47:18 -0500 (EST) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1AIoso16787; Mon, 10 Feb 2003 13:50:54 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1V6XXTDL; Mon, 10 Feb 2003 13:50:55 -0500 Received: from nortelnetworks.com (acart1e2.ca.nortel.com [47.129.129.111]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1NCG0R; Mon, 10 Feb 2003 13:50:54 -0500 Message-ID: <3E47F487.7090006@nortelnetworks.com> Date: Mon, 10 Feb 2003 13:50:47 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Dana.Herskowitz@veraznetworks.com, Megaco List CC: Eli.Liluz@veraznetworks.com, Benny.Lavi@veraznetworks.com, Ilana.Leibovitch@veraznetworks.com, Meir.Leshem@veraznetworks.com, Artur.Karaev@veraznetworks.com Subject: Re: [Megaco] Accumulating detected events References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit When running in Lockstep, the EventBuffer Descriptor determines which events are accumulated. The Events Descriptor determines which events are subsequently recognized and reported. Dana.Herskowitz@veraznetworks.com wrote: > Hello, > Suppose EBC = Lockstep and event was detected in the Media level. > The event appears in Events-Buffer-Descriptor but does not in > Events-Descriptor. > 1) Should his event be accumulated? > 2) Does it depend whether this event was requested before in one of the > former Events Descriptors? - If yes - till when this event is being > requested? > > Generally speaking - I'd like to know which events should I accumulate - > 1) those which appear in EB Desciptor only > or > 2) those which appear in one of Events Descriptor and EB Descriptor? > > Regards, > Dana H. > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Feb 10 13:49:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20556 for ; Mon, 10 Feb 2003 13:49:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1AIwK403272 for megaco-archive@odin.ietf.org; Mon, 10 Feb 2003 13:58:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AIwKp03269 for ; Mon, 10 Feb 2003 13:58:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20540 for ; Mon, 10 Feb 2003 13:49:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AIv8p03227; Mon, 10 Feb 2003 13:57:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AIuLp03181 for ; Mon, 10 Feb 2003 13:56:21 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20462 for ; Mon, 10 Feb 2003 13:47:18 -0500 (EST) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1AIoso16787; Mon, 10 Feb 2003 13:50:54 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1V6XXTDL; Mon, 10 Feb 2003 13:50:55 -0500 Received: from nortelnetworks.com (acart1e2.ca.nortel.com [47.129.129.111]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1NCG0R; Mon, 10 Feb 2003 13:50:54 -0500 Message-ID: <3E47F487.7090006@nortelnetworks.com> Date: Mon, 10 Feb 2003 13:50:47 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Dana.Herskowitz@veraznetworks.com, Megaco List CC: Eli.Liluz@veraznetworks.com, Benny.Lavi@veraznetworks.com, Ilana.Leibovitch@veraznetworks.com, Meir.Leshem@veraznetworks.com, Artur.Karaev@veraznetworks.com Subject: Re: [Megaco] Accumulating detected events References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit When running in Lockstep, the EventBuffer Descriptor determines which events are accumulated. The Events Descriptor determines which events are subsequently recognized and reported. Dana.Herskowitz@veraznetworks.com wrote: > Hello, > Suppose EBC = Lockstep and event was detected in the Media level. > The event appears in Events-Buffer-Descriptor but does not in > Events-Descriptor. > 1) Should his event be accumulated? > 2) Does it depend whether this event was requested before in one of the > former Events Descriptors? - If yes - till when this event is being > requested? > > Generally speaking - I'd like to know which events should I accumulate - > 1) those which appear in EB Desciptor only > or > 2) those which appear in one of Events Descriptor and EB Descriptor? > > Regards, > Dana H. > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 11 01:38:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11044 for ; Tue, 11 Feb 2003 01:38:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B6kQp12179; Tue, 11 Feb 2003 01:46:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B6ijp12098 for ; Tue, 11 Feb 2003 01:44:45 -0500 Received: from web10701.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10994 for ; Tue, 11 Feb 2003 01:35:28 -0500 (EST) Message-ID: <20030211063911.58155.qmail@web10701.mail.yahoo.com> Received: from [203.124.158.2] by web10701.mail.yahoo.com via HTTP; Tue, 11 Feb 2003 17:39:11 EST Date: Tue, 11 Feb 2003 17:39:11 +1100 (EST) From: =?iso-8859-1?q?petric=20john?= To: megaco@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Megaco] Long Timer! Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit wrt D.1.1 , the follwing text: >> Peer protocol entities are expected to keep in memory a list of the responses that they sent to recent transactions and a list of the transactions that are currently outstanding. The transaction identifier of each incoming message is compared to the transaction identifiers of the recent responses sent to the same MId. If a match is found, the entity does not execute the transaction, but simply repeats the response. If no match is found, the message will be >> compared to the list of currently outstanding transactions. If a match is found in that list, indicating a duplicate transaction, the entity does not execute the transaction (see D.1.4 for procedures on sending TransactionPending). ----- Does it implies that even if the Transaction has been successfully replied, we have to retain the Reply till the Long Timer associated with it gets expired?? ~|~ o john. http://greetings.yahoo.com.au - Yahoo! Greetings - Send some online love this Valentine's Day. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 11 01:38:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11099 for ; Tue, 11 Feb 2003 01:38:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1B6lXm12230 for megaco-archive@odin.ietf.org; Tue, 11 Feb 2003 01:47:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B6lXp12227 for ; Tue, 11 Feb 2003 01:47:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11057 for ; Tue, 11 Feb 2003 01:38:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B6kQp12179; Tue, 11 Feb 2003 01:46:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B6ijp12098 for ; Tue, 11 Feb 2003 01:44:45 -0500 Received: from web10701.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10994 for ; Tue, 11 Feb 2003 01:35:28 -0500 (EST) Message-ID: <20030211063911.58155.qmail@web10701.mail.yahoo.com> Received: from [203.124.158.2] by web10701.mail.yahoo.com via HTTP; Tue, 11 Feb 2003 17:39:11 EST Date: Tue, 11 Feb 2003 17:39:11 +1100 (EST) From: =?iso-8859-1?q?petric=20john?= To: megaco@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Megaco] Long Timer! Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit wrt D.1.1 , the follwing text: >> Peer protocol entities are expected to keep in memory a list of the responses that they sent to recent transactions and a list of the transactions that are currently outstanding. The transaction identifier of each incoming message is compared to the transaction identifiers of the recent responses sent to the same MId. If a match is found, the entity does not execute the transaction, but simply repeats the response. If no match is found, the message will be >> compared to the list of currently outstanding transactions. If a match is found in that list, indicating a duplicate transaction, the entity does not execute the transaction (see D.1.4 for procedures on sending TransactionPending). ----- Does it implies that even if the Transaction has been successfully replied, we have to retain the Reply till the Long Timer associated with it gets expired?? ~|~ o john. http://greetings.yahoo.com.au - Yahoo! Greetings - Send some online love this Valentine's Day. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 11 03:34:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23574 for ; Tue, 11 Feb 2003 03:34:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B8gnp29540; Tue, 11 Feb 2003 03:42:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B8fLp29489 for ; Tue, 11 Feb 2003 03:41:21 -0500 Received: from exchange.td-soft.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA23511 for ; Tue, 11 Feb 2003 03:32:02 -0500 (EST) Received: through eSafe SMTP Relay 1044768003; Tue Feb 11 10:34:14 2003 Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id <1SWY7CKA>; Tue, 11 Feb 2003 10:32:24 +0200 Message-ID: From: Raphael Tryster To: petric john , megaco@ietf.org Subject: RE: [Megaco] Long Timer! Date: Tue, 11 Feb 2003 10:32:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D1A8.19AFD5A0" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D1A8.19AFD5A0 Content-Type: text/plain; charset="iso-8859-1" The answer appears in the paragraph after the next: "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'. For transactions that are acknowledged through this parameter, the entity shall keep a copy of the transaction-id for LONG-TIMER seconds after the response is issued, in order to detect and ignore duplicate copies of the transaction request that could be produced by the network". So, if by "the Transaction has been successfully replied", you mean that the MG has received a response acknowledgement for it, it may discard the reply, but it must still keep the transaction-id until LONG-TIMER expires. This is because it may still receive an out-of-order retransmission of the original request, and it has to know to ignore it as a duplicate. If the MG has not received a response acknowledgement, then it must keep both the transaction-id and the reply until LONG-TIMER expires. In this case, the MG does not know whether its reply reached the MGC, so if it receives a retransmission of the request, it has to retransmit the reply. Raphael Tryster -----Original Message----- From: petric john [SMTP:petric_john@yahoo.com.au] Sent: Tuesday, 11 February, 2003 8:39 AM To: megaco@ietf.org Subject: [Megaco] Long Timer! wrt D.1.1 , the follwing text: >> Peer protocol entities are expected to keep in memory a list of the responses that they sent to recent transactions and a list of the transactions that are currently outstanding. The transaction identifier of each incoming message is compared to the transaction identifiers of the recent responses sent to the same MId. If a match is found, the entity does not execute the transaction, but simply repeats the response. If no match is found, the message will be >> compared to the list of currently outstanding transactions. If a match is found in that list, indicating a duplicate transaction, the entity does not execute the transaction (see D.1.4 for procedures on sending TransactionPending). ----- Does it implies that even if the Transaction has been successfully replied, we have to retain the Reply till the Long Timer associated with it gets expired?? ~|~ o john. http://greetings.yahoo.com.au - Yahoo! Greetings - Send some online love this Valentine's Day. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C2D1A8.19AFD5A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] Long Timer!

The answer appears in the paragraph afte= r the next:

"Th= e copy of the responses may be destroyed either LONG-TIMER seconds after = the response is issued, or when the entity receives a confirmation that t= he response has been received, through the 'Response Acknowledgement par= ameter'. For transactions that are acknowledged through this parameter, = the entity shall keep a copy of the transaction-id for LONG-TIMER seconds= after the response is issued, in order to detect and ignore duplicate co= pies of the transaction request that could be produced by the network".

So, if by "the Transaction has been successfully replied<= /FONT>", you mean that the MG has received a response acknowledgement for= it, it may discard the reply, but it must still keep the transaction-id = until LONG-TIMER expires.  This is because it may still receive an o= ut-of-order retransmission of the original request, and it has to know to= ignore it as a duplicate.  If the MG has not received a response acknowledgement, then it must keep both the transaction-id and the repl y until LONG-TIMER expires.  In this case, the MG does not know whe= ther its reply reached the MGC, so if it receives a retransmission of the= request, it has to retransmit the reply.

Raphael Tryster

    -----Original Mess= age-----
    From:   petric john [SMTP:= petric_john@yahoo.com.au]
    Sent:   Tuesday, 11 February, 2003 8:39 AM
    To:     megaco@ietf.org
    Subject:    &nbs= p;   [Megaco] Long Tim= er!

    wrt D.1.1 , the follwing text:

    >> Peer protocol entities ar= e expected to keep in
    memory a list of the responses th= at they sent to
    recent transactions and a list of= the transactions
    that are currently outstanding. T= he transaction
    identifier of each incoming messa= ge is compared to the
    transaction identifiers of the re= cent responses sent
    to the same MId. If a match is fo= und, the entity does
    not execute the transaction, but = simply repeats the
    response. If no match is found, t= he message will be
    >> compared to the list of = currently outstanding
    transactions. If a match is found= in that list,
    indicating a duplicate transactio= n, the entity does
    not execute the transaction (see = D.1.4 for procedures
    on sending TransactionPending). <= /FONT>

    -----

    Does it implies that even if the T= ransaction has been
    successfully replied, we have to = retain the Reply till
    the Long Timer associated with it= gets expired??

    ~|~
     o
    john.




    http://greetings.yahoo.com.au - Yahoo! Gree= tings
    - Send some online love this Vale= ntine's Day.
    _________________________________= ______________
    Megaco mailing list
    Megaco@ietf.org
    https://www1.ietf.org/mailman/= listinfo/megaco

------_=_NextPart_001_01C2D1A8.19AFD5A0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 11 03:35:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23593 for ; Tue, 11 Feb 2003 03:35:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1B8iDw29567 for megaco-archive@odin.ietf.org; Tue, 11 Feb 2003 03:44:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B8iCp29564 for ; Tue, 11 Feb 2003 03:44:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23584 for ; Tue, 11 Feb 2003 03:34:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B8gnp29540; Tue, 11 Feb 2003 03:42:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B8fLp29489 for ; Tue, 11 Feb 2003 03:41:21 -0500 Received: from exchange.td-soft.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA23511 for ; Tue, 11 Feb 2003 03:32:02 -0500 (EST) Received: through eSafe SMTP Relay 1044768003; Tue Feb 11 10:34:14 2003 Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id <1SWY7CKA>; Tue, 11 Feb 2003 10:32:24 +0200 Message-ID: From: Raphael Tryster To: petric john , megaco@ietf.org Subject: RE: [Megaco] Long Timer! Date: Tue, 11 Feb 2003 10:32:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D1A8.19AFD5A0" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D1A8.19AFD5A0 Content-Type: text/plain; charset="iso-8859-1" The answer appears in the paragraph after the next: "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'. For transactions that are acknowledged through this parameter, the entity shall keep a copy of the transaction-id for LONG-TIMER seconds after the response is issued, in order to detect and ignore duplicate copies of the transaction request that could be produced by the network". So, if by "the Transaction has been successfully replied", you mean that the MG has received a response acknowledgement for it, it may discard the reply, but it must still keep the transaction-id until LONG-TIMER expires. This is because it may still receive an out-of-order retransmission of the original request, and it has to know to ignore it as a duplicate. If the MG has not received a response acknowledgement, then it must keep both the transaction-id and the reply until LONG-TIMER expires. In this case, the MG does not know whether its reply reached the MGC, so if it receives a retransmission of the request, it has to retransmit the reply. Raphael Tryster -----Original Message----- From: petric john [SMTP:petric_john@yahoo.com.au] Sent: Tuesday, 11 February, 2003 8:39 AM To: megaco@ietf.org Subject: [Megaco] Long Timer! wrt D.1.1 , the follwing text: >> Peer protocol entities are expected to keep in memory a list of the responses that they sent to recent transactions and a list of the transactions that are currently outstanding. The transaction identifier of each incoming message is compared to the transaction identifiers of the recent responses sent to the same MId. If a match is found, the entity does not execute the transaction, but simply repeats the response. If no match is found, the message will be >> compared to the list of currently outstanding transactions. If a match is found in that list, indicating a duplicate transaction, the entity does not execute the transaction (see D.1.4 for procedures on sending TransactionPending). ----- Does it implies that even if the Transaction has been successfully replied, we have to retain the Reply till the Long Timer associated with it gets expired?? ~|~ o john. http://greetings.yahoo.com.au - Yahoo! Greetings - Send some online love this Valentine's Day. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C2D1A8.19AFD5A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] Long Timer!

The answer appears in the paragraph afte= r the next:

"Th= e copy of the responses may be destroyed either LONG-TIMER seconds after = the response is issued, or when the entity receives a confirmation that t= he response has been received, through the 'Response Acknowledgement par= ameter'. For transactions that are acknowledged through this parameter, = the entity shall keep a copy of the transaction-id for LONG-TIMER seconds= after the response is issued, in order to detect and ignore duplicate co= pies of the transaction request that could be produced by the network".

So, if by "the Transaction has been successfully replied<= /FONT>", you mean that the MG has received a response acknowledgement for= it, it may discard the reply, but it must still keep the transaction-id = until LONG-TIMER expires.  This is because it may still receive an o= ut-of-order retransmission of the original request, and it has to know to= ignore it as a duplicate.  If the MG has not received a response acknowledgement, then it must keep both the transaction-id and the repl y until LONG-TIMER expires.  In this case, the MG does not know whe= ther its reply reached the MGC, so if it receives a retransmission of the= request, it has to retransmit the reply.

Raphael Tryster

    -----Original Mess= age-----
    From:   petric john [SMTP:= petric_john@yahoo.com.au]
    Sent:   Tuesday, 11 February, 2003 8:39 AM
    To:     megaco@ietf.org
    Subject:    &nbs= p;   [Megaco] Long Tim= er!

    wrt D.1.1 , the follwing text:

    >> Peer protocol entities ar= e expected to keep in
    memory a list of the responses th= at they sent to
    recent transactions and a list of= the transactions
    that are currently outstanding. T= he transaction
    identifier of each incoming messa= ge is compared to the
    transaction identifiers of the re= cent responses sent
    to the same MId. If a match is fo= und, the entity does
    not execute the transaction, but = simply repeats the
    response. If no match is found, t= he message will be
    >> compared to the list of = currently outstanding
    transactions. If a match is found= in that list,
    indicating a duplicate transactio= n, the entity does
    not execute the transaction (see = D.1.4 for procedures
    on sending TransactionPending). <= /FONT>

    -----

    Does it implies that even if the T= ransaction has been
    successfully replied, we have to = retain the Reply till
    the Long Timer associated with it= gets expired??

    ~|~
     o
    john.




    http://greetings.yahoo.com.au - Yahoo! Gree= tings
    - Send some online love this Vale= ntine's Day.
    _________________________________= ______________
    Megaco mailing list
    Megaco@ietf.org
    https://www1.ietf.org/mailman/= listinfo/megaco

------_=_NextPart_001_01C2D1A8.19AFD5A0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 11 04:14:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24318 for ; Tue, 11 Feb 2003 04:14:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B9MOp31697; Tue, 11 Feb 2003 04:22:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B9Lrp31657 for ; Tue, 11 Feb 2003 04:21:53 -0500 Received: from exchange.td-soft.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24295 for ; Tue, 11 Feb 2003 04:12:32 -0500 (EST) Received: through eSafe SMTP Relay 1044768003; Tue Feb 11 11:14:39 2003 Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id <1SWY7CLZ>; Tue, 11 Feb 2003 11:12:50 +0200 Message-ID: From: Raphael Tryster To: Tom-PT Taylor , "'mukta vasudeva'" , megaco@ietf.org Subject: RE: [Megaco] Action Processing:priority or sequence? Date: Tue, 11 Feb 2003 11:12:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D1AD.BFF99EF0" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D1AD.BFF99EF0 Content-Type: text/plain; charset="iso-8859-1" Hello Tom and list, The example you have given refers to Priority handling within the actions of a single transaction. Am I correct that the scope of Priority applies not just to that transaction, but to the lifetime of the context? For example, I am thinking about an MG consisting of multiple hardware entities, so that events and signals have to traverse one or more communications interfaces between the subscriber and that part of the MG that talks to the MGC. Suppose several events or signals are communicated in the same buffer. Would it be reasonable to expect the recipient to examine buffer contents and process those terminations whose contexts are higher priority first? I am puzzled by the following sentence: "The MGC can also use the priority to control autonomously the traffic precedence in the MG in a smooth way in certain situations (e.g. restart), when a lot of contexts must be handled simultaneously". But contexts don't exist on restart, do they? Raphael Tryster -----Original Message----- From: Tom-PT Taylor [SMTP:taylor@nortelnetworks.com] Sent: Friday, 13 December, 2002 8:06 PM To: 'mukta vasudeva'; megaco@ietf.org Subject: RE: [Megaco] Action Processing:priority or sequence? The transaction processing rules defined for the protocol take precedence over context Priority. Really, the handling of Priority is very implementation specific. As an example, suppose the implementation does some sort of look-ahead after it parses the transaction. An earlier Action has something like ReserveGroup or ReserveValue and asks for a bunch of resources to be reserved. The implementation looks ahead to the later, higher priority Action and makes sure it saves some resources for that one. -----Original Message----- From: mukta vasudeva [mailto:reachtomukta@yahoo.co.in] Sent: Friday, December 13, 2002 7:44 AM To: megaco@ietf.org Subject: [Megaco] Action Processing:priority or sequence? Hi All, According to the RFC-3015, "The priority is used for a Context in order to provide the MG with information about a certain precedence handling for a Context. The MGC can also use the priority to control autonomously the traffic precedence in the MG in a smooth way in certain situations (e.g. restart), when a lot of Contexts must be handled simultaneously. Priority 0 is the lowest priority and a priority of 15 is the highest priority. " Q1. "Commands within a Transaction are executed sequentially" But if Actions with different Priorities assigned to them are processed according to the priorites-not sequence- then the "sequential execution of commands withn transactions " would not be ensured.So how should we access actions with different priorities? Q2. Are the priorities valid on Per Transaction basis or are they retained for the entire life of the call unless replaced ? regards, Mukta Catch all the cricket action. Download Yahoo! Score tracker _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C2D1AD.BFF99EF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] Action Processing:priority or sequence?

Hello Tom and list,

The example you have given refers to Pri= ority handling within the actions of a single transaction.  Am I cor= rect that the scope of Priority applies not just to that transaction, but= to the lifetime of the context?

For example, I am thinking about an MG c= onsisting of multiple hardware entities, so that events and signals have = to traverse one or more communications interfaces between the subscriber = and that part of the MG that talks to the MGC.  Suppose several even= ts or signals are communicated in the same buffer.  Would it be reas= onable to expect the recipient to examine buffer contents and process tho= se terminations whose contexts are higher priority first?

I am puzzled by the following sentence:<= /FONT>

"Th= e MGC can also use the priority to control autonomously the traffic prece= dence in the MG in a smooth way in certain situations (e.g. restart), whe= n a lot of contexts must be handled simultaneously".

But contexts don't exist on restart, do = they?

Raphael Tryster

    -----Original Mess= age-----
    From:   Tom-PT Taylor [SMT= P:taylor@nortelnetworks.com]
    Sent:   Friday, 13 December, 2002 8:06 PM
    To:     'mukta vasudeva'; megaco@ietf.org
    Subject:    &nbs= p;   RE: [Megaco] Acti= on Processing:priority or sequence?

    The transaction processing rules d= efined for the protocol take precedence
    over context Priority.  Real= ly, the handling of Priority is very
    implementation specific.  As= an example, suppose the implementation does
    some sort of look-ahead after it = parses the transaction.  An earlier Action
    has something like ReserveGroup o= r ReserveValue and asks for a bunch of
    resources to be reserved.  T= he implementation looks ahead to the later,
    higher priority Action and makes = sure it saves some resources for that one.

    -----Original Message-----
    From: mukta vasudeva [mailto:reachtomukta@yahoo.co.in]
    Sent: Friday, December 13, 2002 7= :44 AM
    To: megaco@ietf.org
    Subject: [Megaco] Action Processi= ng:priority or sequence?


    Hi All,
    According to the RFC-3015, "= The priority is used for a Context in order to
    provide the MG with information a= bout a certain precedence handling for a
    Context. The MGC can also use the= priority to control autonomously the
    traffic precedence in the MG in a= smooth way in certain situations (e.g.
    restart), when a lot of Contexts = must be handled simultaneously. Priority 0
    is the lowest priority and a prio= rity of 15 is the highest priority. "
    Q1. "Commands within a Trans= action are executed sequentially" But if Actions
    with different Priorities assigne= d to them are processed according to the
    priorites-not sequence- then the = "sequential execution of commands withn
    transactions " would not be = ensured.So how should we access actions with
    different priorities?
    Q2. Are the priorities valid on P= er Transaction basis or are they  retained
    for the entire life of the call u= nless replaced ?
    regards,
    Mukta
     Catch all the cricket actio= n. Download Yahoo! Score tracker
    _________________________________= ______________
    Megaco mailing list
    Megaco@ietf.org
    https://www1.ietf.org/mailman/= listinfo/megaco

------_=_NextPart_001_01C2D1AD.BFF99EF0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 11 04:14:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24345 for ; Tue, 11 Feb 2003 04:14:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1B9Nbx31764 for megaco-archive@odin.ietf.org; Tue, 11 Feb 2003 04:23:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B9Nap31761 for ; Tue, 11 Feb 2003 04:23:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24329 for ; Tue, 11 Feb 2003 04:14:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B9MOp31697; Tue, 11 Feb 2003 04:22:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B9Lrp31657 for ; Tue, 11 Feb 2003 04:21:53 -0500 Received: from exchange.td-soft.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24295 for ; Tue, 11 Feb 2003 04:12:32 -0500 (EST) Received: through eSafe SMTP Relay 1044768003; Tue Feb 11 11:14:39 2003 Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id <1SWY7CLZ>; Tue, 11 Feb 2003 11:12:50 +0200 Message-ID: From: Raphael Tryster To: Tom-PT Taylor , "'mukta vasudeva'" , megaco@ietf.org Subject: RE: [Megaco] Action Processing:priority or sequence? Date: Tue, 11 Feb 2003 11:12:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D1AD.BFF99EF0" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D1AD.BFF99EF0 Content-Type: text/plain; charset="iso-8859-1" Hello Tom and list, The example you have given refers to Priority handling within the actions of a single transaction. Am I correct that the scope of Priority applies not just to that transaction, but to the lifetime of the context? For example, I am thinking about an MG consisting of multiple hardware entities, so that events and signals have to traverse one or more communications interfaces between the subscriber and that part of the MG that talks to the MGC. Suppose several events or signals are communicated in the same buffer. Would it be reasonable to expect the recipient to examine buffer contents and process those terminations whose contexts are higher priority first? I am puzzled by the following sentence: "The MGC can also use the priority to control autonomously the traffic precedence in the MG in a smooth way in certain situations (e.g. restart), when a lot of contexts must be handled simultaneously". But contexts don't exist on restart, do they? Raphael Tryster -----Original Message----- From: Tom-PT Taylor [SMTP:taylor@nortelnetworks.com] Sent: Friday, 13 December, 2002 8:06 PM To: 'mukta vasudeva'; megaco@ietf.org Subject: RE: [Megaco] Action Processing:priority or sequence? The transaction processing rules defined for the protocol take precedence over context Priority. Really, the handling of Priority is very implementation specific. As an example, suppose the implementation does some sort of look-ahead after it parses the transaction. An earlier Action has something like ReserveGroup or ReserveValue and asks for a bunch of resources to be reserved. The implementation looks ahead to the later, higher priority Action and makes sure it saves some resources for that one. -----Original Message----- From: mukta vasudeva [mailto:reachtomukta@yahoo.co.in] Sent: Friday, December 13, 2002 7:44 AM To: megaco@ietf.org Subject: [Megaco] Action Processing:priority or sequence? Hi All, According to the RFC-3015, "The priority is used for a Context in order to provide the MG with information about a certain precedence handling for a Context. The MGC can also use the priority to control autonomously the traffic precedence in the MG in a smooth way in certain situations (e.g. restart), when a lot of Contexts must be handled simultaneously. Priority 0 is the lowest priority and a priority of 15 is the highest priority. " Q1. "Commands within a Transaction are executed sequentially" But if Actions with different Priorities assigned to them are processed according to the priorites-not sequence- then the "sequential execution of commands withn transactions " would not be ensured.So how should we access actions with different priorities? Q2. Are the priorities valid on Per Transaction basis or are they retained for the entire life of the call unless replaced ? regards, Mukta Catch all the cricket action. Download Yahoo! Score tracker _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C2D1AD.BFF99EF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] Action Processing:priority or sequence?

Hello Tom and list,

The example you have given refers to Pri= ority handling within the actions of a single transaction.  Am I cor= rect that the scope of Priority applies not just to that transaction, but= to the lifetime of the context?

For example, I am thinking about an MG c= onsisting of multiple hardware entities, so that events and signals have = to traverse one or more communications interfaces between the subscriber = and that part of the MG that talks to the MGC.  Suppose several even= ts or signals are communicated in the same buffer.  Would it be reas= onable to expect the recipient to examine buffer contents and process tho= se terminations whose contexts are higher priority first?

I am puzzled by the following sentence:<= /FONT>

"Th= e MGC can also use the priority to control autonomously the traffic prece= dence in the MG in a smooth way in certain situations (e.g. restart), whe= n a lot of contexts must be handled simultaneously".

But contexts don't exist on restart, do = they?

Raphael Tryster

    -----Original Mess= age-----
    From:   Tom-PT Taylor [SMT= P:taylor@nortelnetworks.com]
    Sent:   Friday, 13 December, 2002 8:06 PM
    To:     'mukta vasudeva'; megaco@ietf.org
    Subject:    &nbs= p;   RE: [Megaco] Acti= on Processing:priority or sequence?

    The transaction processing rules d= efined for the protocol take precedence
    over context Priority.  Real= ly, the handling of Priority is very
    implementation specific.  As= an example, suppose the implementation does
    some sort of look-ahead after it = parses the transaction.  An earlier Action
    has something like ReserveGroup o= r ReserveValue and asks for a bunch of
    resources to be reserved.  T= he implementation looks ahead to the later,
    higher priority Action and makes = sure it saves some resources for that one.

    -----Original Message-----
    From: mukta vasudeva [mailto:reachtomukta@yahoo.co.in]
    Sent: Friday, December 13, 2002 7= :44 AM
    To: megaco@ietf.org
    Subject: [Megaco] Action Processi= ng:priority or sequence?


    Hi All,
    According to the RFC-3015, "= The priority is used for a Context in order to
    provide the MG with information a= bout a certain precedence handling for a
    Context. The MGC can also use the= priority to control autonomously the
    traffic precedence in the MG in a= smooth way in certain situations (e.g.
    restart), when a lot of Contexts = must be handled simultaneously. Priority 0
    is the lowest priority and a prio= rity of 15 is the highest priority. "
    Q1. "Commands within a Trans= action are executed sequentially" But if Actions
    with different Priorities assigne= d to them are processed according to the
    priorites-not sequence- then the = "sequential execution of commands withn
    transactions " would not be = ensured.So how should we access actions with
    different priorities?
    Q2. Are the priorities valid on P= er Transaction basis or are they  retained
    for the entire life of the call u= nless replaced ?
    regards,
    Mukta
     Catch all the cricket actio= n. Download Yahoo! Score tracker
    _________________________________= ______________
    Megaco mailing list
    Megaco@ietf.org
    https://www1.ietf.org/mailman/= listinfo/megaco

------_=_NextPart_001_01C2D1AD.BFF99EF0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 11 08:20:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03854 for ; Tue, 11 Feb 2003 08:20:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BDSlp14194; Tue, 11 Feb 2003 08:28:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BDR2p14119 for ; Tue, 11 Feb 2003 08:27:02 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03719 for ; Tue, 11 Feb 2003 08:17:36 -0500 (EST) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1BDLHe16269; Tue, 11 Feb 2003 08:21:17 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1V6XZA7V; Tue, 11 Feb 2003 08:21:17 -0500 Received: from nortelnetworks.com (acart1dp.ca.nortel.com [47.129.129.98]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1NCHF6; Tue, 11 Feb 2003 08:21:17 -0500 Message-ID: <3E48F8CA.6050003@nortelnetworks.com> Date: Tue, 11 Feb 2003 08:21:14 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: petric john CC: Megaco List Subject: Re: [Megaco] Long Timer! References: <20030211063911.58155.qmail@web10701.mail.yahoo.com> In-Reply-To: <20030211063911.58155.qmail@web10701.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The final paragraph of D.1.1 is unambiguous on this point. It is possible that the network could supply duplicates of the original request even after you have sent the response. The LONG_TIMER procedure prevents undesired re-execution of such duplicates. petric john wrote: > wrt D.1.1 , the follwing text: > > >>>Peer protocol entities are expected to keep in > > memory a list of the responses that they sent to > recent transactions and a list of the transactions > that are currently outstanding. The transaction > identifier of each incoming message is compared to the > transaction identifiers of the recent responses sent > to the same MId. If a match is found, the entity does > not execute the transaction, but simply repeats the > response. If no match is found, the message will be > >>>compared to the list of currently outstanding > > transactions. If a match is found in that list, > indicating a duplicate transaction, the entity does > not execute the transaction (see D.1.4 for procedures > on sending TransactionPending). > > ----- > > Does it implies that even if the Transaction has been > successfully replied, we have to retain the Reply till > the Long Timer associated with it gets expired?? > > ~|~ > o > john. > > > > > http://greetings.yahoo.com.au - Yahoo! Greetings > - Send some online love this Valentine's Day. > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 11 08:21:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03909 for ; Tue, 11 Feb 2003 08:21:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BDU2614332 for megaco-archive@odin.ietf.org; Tue, 11 Feb 2003 08:30:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BDU2p14329 for ; Tue, 11 Feb 2003 08:30:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03869 for ; Tue, 11 Feb 2003 08:20:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BDSlp14194; Tue, 11 Feb 2003 08:28:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BDR2p14119 for ; Tue, 11 Feb 2003 08:27:02 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03719 for ; Tue, 11 Feb 2003 08:17:36 -0500 (EST) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1BDLHe16269; Tue, 11 Feb 2003 08:21:17 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1V6XZA7V; Tue, 11 Feb 2003 08:21:17 -0500 Received: from nortelnetworks.com (acart1dp.ca.nortel.com [47.129.129.98]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1NCHF6; Tue, 11 Feb 2003 08:21:17 -0500 Message-ID: <3E48F8CA.6050003@nortelnetworks.com> Date: Tue, 11 Feb 2003 08:21:14 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: petric john CC: Megaco List Subject: Re: [Megaco] Long Timer! References: <20030211063911.58155.qmail@web10701.mail.yahoo.com> In-Reply-To: <20030211063911.58155.qmail@web10701.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The final paragraph of D.1.1 is unambiguous on this point. It is possible that the network could supply duplicates of the original request even after you have sent the response. The LONG_TIMER procedure prevents undesired re-execution of such duplicates. petric john wrote: > wrt D.1.1 , the follwing text: > > >>>Peer protocol entities are expected to keep in > > memory a list of the responses that they sent to > recent transactions and a list of the transactions > that are currently outstanding. The transaction > identifier of each incoming message is compared to the > transaction identifiers of the recent responses sent > to the same MId. If a match is found, the entity does > not execute the transaction, but simply repeats the > response. If no match is found, the message will be > >>>compared to the list of currently outstanding > > transactions. If a match is found in that list, > indicating a duplicate transaction, the entity does > not execute the transaction (see D.1.4 for procedures > on sending TransactionPending). > > ----- > > Does it implies that even if the Transaction has been > successfully replied, we have to retain the Reply till > the Long Timer associated with it gets expired?? > > ~|~ > o > john. > > > > > http://greetings.yahoo.com.au - Yahoo! Greetings > - Send some online love this Valentine's Day. > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 11 19:38:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23039 for ; Tue, 11 Feb 2003 19:38:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C0lEp25166; Tue, 11 Feb 2003 19:47:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C0jZp25094 for ; Tue, 11 Feb 2003 19:45:35 -0500 Received: from 127.0.0.1 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23007 for ; Tue, 11 Feb 2003 19:35:54 -0500 (EST) Message-ID: <3E4996F5.FA68FBE4@ericsson.com.au> Date: Wed, 12 Feb 2003 11:36:05 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Raphael Tryster CC: Tom-PT Taylor , "'mukta vasudeva'" , megaco@ietf.org Subject: Re: [Megaco] Action Processing:priority or sequence? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-GCMulti: 1 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Raphael, As you have indicated the priority exists for the life time that the property is set on the context. With regards to your question on contexts existing at restart- if the whole MG goes out of service and comes back I agree with you. If the MG partially restarts then the MG can give processing priority to existing priority marked contexts. Christian Raphael Tryster wrote: > > Hello Tom and list, > > The example you have given refers to Priority handling within the actions of a > single transaction. Am I correct that the scope of Priority applies not just > to that transaction, but to the lifetime of the context? > > For example, I am thinking about an MG consisting of multiple hardware > entities, so that events and signals have to traverse one or more > communications interfaces between the subscriber and that part of the MG that > talks to the MGC. Suppose several events or signals are communicated in the > same buffer. Would it be reasonable to expect the recipient to examine buffer > contents and process those terminations whose contexts are higher priority > first? > > I am puzzled by the following sentence: > > "The MGC can also use the priority to control autonomously the traffic > precedence in the MG in a smooth way in certain situations (e.g. restart), > when a lot of contexts must be handled simultaneously". > > But contexts don't exist on restart, do they? > > Raphael Tryster > > -----Original Message----- > From: Tom-PT Taylor [SMTP:taylor@nortelnetworks.com] > Sent: Friday, 13 December, 2002 8:06 PM > To: 'mukta vasudeva'; megaco@ietf.org > Subject: RE: [Megaco] Action Processing:priority or sequence? > > The transaction processing rules defined for the protocol take precedence > > over context Priority. Really, the handling of Priority is very > implementation specific. As an example, suppose the implementation does > some sort of look-ahead after it parses the transaction. An earlier > Action > has something like ReserveGroup or ReserveValue and asks for a bunch of > resources to be reserved. The implementation looks ahead to the later, > higher priority Action and makes sure it saves some resources for that > one. > > -----Original Message----- > From: mukta vasudeva [mailto:reachtomukta@yahoo.co.in] > Sent: Friday, December 13, 2002 7:44 AM > To: megaco@ietf.org > Subject: [Megaco] Action Processing:priority or sequence? > > Hi All, > According to the RFC-3015, "The priority is used for a Context in order > to > provide the MG with information about a certain precedence handling for a > > Context. The MGC can also use the priority to control autonomously the > traffic precedence in the MG in a smooth way in certain situations (e.g. > restart), when a lot of Contexts must be handled simultaneously. Priority > 0 > is the lowest priority and a priority of 15 is the highest priority. " > Q1. "Commands within a Transaction are executed sequentially" But if > Actions > with different Priorities assigned to them are processed according to the > > priorites-not sequence- then the "sequential execution of commands withn > transactions " would not be ensured.So how should we access actions with > different priorities? > Q2. Are the priorities valid on Per Transaction basis or are they > retained > for the entire life of the call unless replaced ? > regards, > Mukta > Catch all the cricket action. Download Yahoo! Score tracker > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 11 19:39:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23056 for ; Tue, 11 Feb 2003 19:39:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1C0mLk25218 for megaco-archive@odin.ietf.org; Tue, 11 Feb 2003 19:48:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C0mLp25215 for ; Tue, 11 Feb 2003 19:48:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23053 for ; Tue, 11 Feb 2003 19:38:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C0lEp25166; Tue, 11 Feb 2003 19:47:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C0jZp25094 for ; Tue, 11 Feb 2003 19:45:35 -0500 Received: from 127.0.0.1 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23007 for ; Tue, 11 Feb 2003 19:35:54 -0500 (EST) Message-ID: <3E4996F5.FA68FBE4@ericsson.com.au> Date: Wed, 12 Feb 2003 11:36:05 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Raphael Tryster CC: Tom-PT Taylor , "'mukta vasudeva'" , megaco@ietf.org Subject: Re: [Megaco] Action Processing:priority or sequence? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-GCMulti: 1 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Raphael, As you have indicated the priority exists for the life time that the property is set on the context. With regards to your question on contexts existing at restart- if the whole MG goes out of service and comes back I agree with you. If the MG partially restarts then the MG can give processing priority to existing priority marked contexts. Christian Raphael Tryster wrote: > > Hello Tom and list, > > The example you have given refers to Priority handling within the actions of a > single transaction. Am I correct that the scope of Priority applies not just > to that transaction, but to the lifetime of the context? > > For example, I am thinking about an MG consisting of multiple hardware > entities, so that events and signals have to traverse one or more > communications interfaces between the subscriber and that part of the MG that > talks to the MGC. Suppose several events or signals are communicated in the > same buffer. Would it be reasonable to expect the recipient to examine buffer > contents and process those terminations whose contexts are higher priority > first? > > I am puzzled by the following sentence: > > "The MGC can also use the priority to control autonomously the traffic > precedence in the MG in a smooth way in certain situations (e.g. restart), > when a lot of contexts must be handled simultaneously". > > But contexts don't exist on restart, do they? > > Raphael Tryster > > -----Original Message----- > From: Tom-PT Taylor [SMTP:taylor@nortelnetworks.com] > Sent: Friday, 13 December, 2002 8:06 PM > To: 'mukta vasudeva'; megaco@ietf.org > Subject: RE: [Megaco] Action Processing:priority or sequence? > > The transaction processing rules defined for the protocol take precedence > > over context Priority. Really, the handling of Priority is very > implementation specific. As an example, suppose the implementation does > some sort of look-ahead after it parses the transaction. An earlier > Action > has something like ReserveGroup or ReserveValue and asks for a bunch of > resources to be reserved. The implementation looks ahead to the later, > higher priority Action and makes sure it saves some resources for that > one. > > -----Original Message----- > From: mukta vasudeva [mailto:reachtomukta@yahoo.co.in] > Sent: Friday, December 13, 2002 7:44 AM > To: megaco@ietf.org > Subject: [Megaco] Action Processing:priority or sequence? > > Hi All, > According to the RFC-3015, "The priority is used for a Context in order > to > provide the MG with information about a certain precedence handling for a > > Context. The MGC can also use the priority to control autonomously the > traffic precedence in the MG in a smooth way in certain situations (e.g. > restart), when a lot of Contexts must be handled simultaneously. Priority > 0 > is the lowest priority and a priority of 15 is the highest priority. " > Q1. "Commands within a Transaction are executed sequentially" But if > Actions > with different Priorities assigned to them are processed according to the > > priorites-not sequence- then the "sequential execution of commands withn > transactions " would not be ensured.So how should we access actions with > different priorities? > Q2. Are the priorities valid on Per Transaction basis or are they > retained > for the entire life of the call unless replaced ? > regards, > Mukta > Catch all the cricket action. Download Yahoo! Score tracker > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Feb 11 20:41:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24479 for ; Tue, 11 Feb 2003 20:41:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C1o1p28801; Tue, 11 Feb 2003 20:50:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C1mep28755 for ; Tue, 11 Feb 2003 20:48:40 -0500 Received: from cms3.etri.re.kr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24411 for ; Tue, 11 Feb 2003 20:38:58 -0500 (EST) From: hektor@etri.re.kr Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id <1Y3GVPN9>; Wed, 12 Feb 2003 10:43:04 +0900 Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A5DA4D9@cms3.etri.re.kr> To: megaco@ietf.org Date: Wed, 12 Feb 2003 10:43:04 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D238.15BAF250" Subject: [Megaco] A simple question Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D238.15BAF250 Content-Type: text/plain; charset="EUC-KR" hi, In Section 7.1.11, RFC 3015, "Signals are defined as proceeding from the Termination towards the exterior of the Context unless otherwise specified in a package" Would you please explain above definition in detail. TIS. ------_=_NextPart_001_01C2D238.15BAF250 Content-Type: text/html; charset="EUC-KR" A simple question

hi,
In Section 7.1.11, RFC 3015,
"Signals are defined as proceeding from the Termination towards the exterior
of the Context unless otherwise specified in a package"

Would you please explain above definition in detail.

TIS.

------_=_NextPart_001_01C2D238.15BAF250-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Feb 11 20:41:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24505 for ; Tue, 11 Feb 2003 20:41:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1C1p0v28844 for megaco-archive@odin.ietf.org; Tue, 11 Feb 2003 20:51:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C1p0p28841 for ; Tue, 11 Feb 2003 20:51:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24493 for ; Tue, 11 Feb 2003 20:41:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C1o1p28801; Tue, 11 Feb 2003 20:50:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C1mep28755 for ; Tue, 11 Feb 2003 20:48:40 -0500 Received: from cms3.etri.re.kr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24411 for ; Tue, 11 Feb 2003 20:38:58 -0500 (EST) From: hektor@etri.re.kr Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id <1Y3GVPN9>; Wed, 12 Feb 2003 10:43:04 +0900 Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A5DA4D9@cms3.etri.re.kr> To: megaco@ietf.org Date: Wed, 12 Feb 2003 10:43:04 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D238.15BAF250" Subject: [Megaco] A simple question Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D238.15BAF250 Content-Type: text/plain; charset="EUC-KR" hi, In Section 7.1.11, RFC 3015, "Signals are defined as proceeding from the Termination towards the exterior of the Context unless otherwise specified in a package" Would you please explain above definition in detail. TIS. ------_=_NextPart_001_01C2D238.15BAF250 Content-Type: text/html; charset="EUC-KR" A simple question

hi,
In Section 7.1.11, RFC 3015,
"Signals are defined as proceeding from the Termination towards the exterior
of the Context unless otherwise specified in a package"

Would you please explain above definition in detail.

TIS.

------_=_NextPart_001_01C2D238.15BAF250-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Feb 12 14:12:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12422 for ; Wed, 12 Feb 2003 14:12:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CJL5p14516; Wed, 12 Feb 2003 14:21:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CJJ7p14412 for ; Wed, 12 Feb 2003 14:19:07 -0500 Received: from zcars0m9.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12370 for ; Wed, 12 Feb 2003 14:09:06 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1CJCip05401; Wed, 12 Feb 2003 14:12:44 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1LM3GHGQ; Wed, 12 Feb 2003 14:12:44 -0500 Received: from nortelnetworks.com (acart1bc.ca.nortel.com [47.129.129.22]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1NCHXB; Wed, 12 Feb 2003 14:12:44 -0500 Message-ID: <3E4A9CAB.6010508@nortelnetworks.com> Date: Wed, 12 Feb 2003 14:12:43 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: hektor@etri.re.kr CC: Megaco List Subject: Re: [Megaco] A simple question References: <8470181DABD5D511B3E700D0B7A8AC4A5DA4D9@cms3.etri.re.kr> In-Reply-To: <8470181DABD5D511B3E700D0B7A8AC4A5DA4D9@cms3.etri.re.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The two possibilities are that the signal is directed toward the exterior (i.e. the remote device represented by the termination) or it is directed inward toward the context and hence toward all the other terminations. One of the the H.248.x announcement packages (used to be H.248 Annex K) includes a direction parameter so you could effectively broadcast a signal from one termination to all the other terminations in the context. hektor@etri.re.kr wrote: > hi, > In Section 7.1.11, RFC 3015, > "Signals are defined as proceeding from the Termination towards the > exterior > of the Context unless otherwise specified in a package" > > Would you please explain above definition in detail. > > TIS. > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Feb 12 14:12:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12441 for ; Wed, 12 Feb 2003 14:12:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CJMRX14559 for megaco-archive@odin.ietf.org; Wed, 12 Feb 2003 14:22:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CJMRp14556 for ; Wed, 12 Feb 2003 14:22:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12436 for ; Wed, 12 Feb 2003 14:12:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CJL5p14516; Wed, 12 Feb 2003 14:21:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CJJ7p14412 for ; Wed, 12 Feb 2003 14:19:07 -0500 Received: from zcars0m9.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12370 for ; Wed, 12 Feb 2003 14:09:06 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1CJCip05401; Wed, 12 Feb 2003 14:12:44 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1LM3GHGQ; Wed, 12 Feb 2003 14:12:44 -0500 Received: from nortelnetworks.com (acart1bc.ca.nortel.com [47.129.129.22]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1NCHXB; Wed, 12 Feb 2003 14:12:44 -0500 Message-ID: <3E4A9CAB.6010508@nortelnetworks.com> Date: Wed, 12 Feb 2003 14:12:43 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: hektor@etri.re.kr CC: Megaco List Subject: Re: [Megaco] A simple question References: <8470181DABD5D511B3E700D0B7A8AC4A5DA4D9@cms3.etri.re.kr> In-Reply-To: <8470181DABD5D511B3E700D0B7A8AC4A5DA4D9@cms3.etri.re.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The two possibilities are that the signal is directed toward the exterior (i.e. the remote device represented by the termination) or it is directed inward toward the context and hence toward all the other terminations. One of the the H.248.x announcement packages (used to be H.248 Annex K) includes a direction parameter so you could effectively broadcast a signal from one termination to all the other terminations in the context. hektor@etri.re.kr wrote: > hi, > In Section 7.1.11, RFC 3015, > "Signals are defined as proceeding from the Termination towards the > exterior > of the Context unless otherwise specified in a package" > > Would you please explain above definition in detail. > > TIS. > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Feb 12 14:45:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13330 for ; Wed, 12 Feb 2003 14:45:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CJsNp16282; Wed, 12 Feb 2003 14:54:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CJrMp16254 for ; Wed, 12 Feb 2003 14:53:22 -0500 Received: from 127.0.0.1 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13258 for ; Wed, 12 Feb 2003 14:43:20 -0500 (EST) Message-ID: <3E4AA29C.F488D004@ericsson.com.au> Date: Thu, 13 Feb 2003 06:38:04 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: hektor@etri.re.kr CC: megaco@ietf.org Subject: Re: [Megaco] A simple question References: <8470181DABD5D511B3E700D0B7A8AC4A5DA4D9@cms3.etri.re.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-GCMulti: 1 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit See Q.1950 Annex A for an example usage. Christian hektor@etri.re.kr wrote: > > hi, > In Section 7.1.11, RFC 3015, > "Signals are defined as proceeding from the Termination towards the exterior > of the Context unless otherwise specified in a package" > > Would you please explain above definition in detail. > > TIS. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Feb 12 14:45:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13380 for ; Wed, 12 Feb 2003 14:45:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CJtSW16346 for megaco-archive@odin.ietf.org; Wed, 12 Feb 2003 14:55:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CJtSp16343 for ; Wed, 12 Feb 2003 14:55:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13344 for ; Wed, 12 Feb 2003 14:45:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CJsNp16282; Wed, 12 Feb 2003 14:54:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CJrMp16254 for ; Wed, 12 Feb 2003 14:53:22 -0500 Received: from 127.0.0.1 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13258 for ; Wed, 12 Feb 2003 14:43:20 -0500 (EST) Message-ID: <3E4AA29C.F488D004@ericsson.com.au> Date: Thu, 13 Feb 2003 06:38:04 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: hektor@etri.re.kr CC: megaco@ietf.org Subject: Re: [Megaco] A simple question References: <8470181DABD5D511B3E700D0B7A8AC4A5DA4D9@cms3.etri.re.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-GCMulti: 1 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit See Q.1950 Annex A for an example usage. Christian hektor@etri.re.kr wrote: > > hi, > In Section 7.1.11, RFC 3015, > "Signals are defined as proceeding from the Termination towards the exterior > of the Context unless otherwise specified in a package" > > Would you please explain above definition in detail. > > TIS. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Feb 13 00:31:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25073 for ; Thu, 13 Feb 2003 00:31:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D5eLp16708; Thu, 13 Feb 2003 00:40:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D5cGp16640 for ; Thu, 13 Feb 2003 00:38:16 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25038 for ; Thu, 13 Feb 2003 00:28:01 -0500 (EST) From: knayar@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h1D5UFs13501 for ; Thu, 13 Feb 2003 11:00:15 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h1D5UC213485; Thu, 13 Feb 2003 11:00:12 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h1D5WW927673; Thu, 13 Feb 2003 11:02:38 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CCC.001DA6BE ; Thu, 13 Feb 2003 10:53:52 +0530 X-Lotus-FromDomain: HSS To: Christian Groves cc: hektor@etri.re.kr, megaco@ietf.org Message-ID: <65256CCC.001DA49E.00@sandesh.hss.hns.com> Date: Thu, 13 Feb 2003 10:58:46 +0530 Subject: Re: [Megaco] A simple question Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi An additional query related to this issue.... Does the topology within the context (between the termination in question and the rest of the terminations) have any effect on the signal (with directionality = internal) being applied. e.g. termA and termB are part of a context (topology - termA, termB, isolate). A signal applied on termA (direction = internal) will reach termB or not? thanks, -kapil nayar Hughes Software Systems Ltd. www.hssworld.com Christian Groves on 02/13/2003 01:08:04 AM To: hektor@etri.re.kr cc: megaco@ietf.org (bcc: Kapil Nayar/HSS) Subject: Re: [Megaco] A simple question See Q.1950 Annex A for an example usage. Christian hektor@etri.re.kr wrote: > > hi, > In Section 7.1.11, RFC 3015, > "Signals are defined as proceeding from the Termination towards the exterior > of the Context unless otherwise specified in a package" > > Would you please explain above definition in detail. > > TIS. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Feb 13 00:31:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25095 for ; Thu, 13 Feb 2003 00:31:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1D5fTW16730 for megaco-archive@odin.ietf.org; Thu, 13 Feb 2003 00:41:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D5fTp16727 for ; Thu, 13 Feb 2003 00:41:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25084 for ; Thu, 13 Feb 2003 00:31:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D5eLp16708; Thu, 13 Feb 2003 00:40:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D5cGp16640 for ; Thu, 13 Feb 2003 00:38:16 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25038 for ; Thu, 13 Feb 2003 00:28:01 -0500 (EST) From: knayar@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h1D5UFs13501 for ; Thu, 13 Feb 2003 11:00:15 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h1D5UC213485; Thu, 13 Feb 2003 11:00:12 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h1D5WW927673; Thu, 13 Feb 2003 11:02:38 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CCC.001DA6BE ; Thu, 13 Feb 2003 10:53:52 +0530 X-Lotus-FromDomain: HSS To: Christian Groves cc: hektor@etri.re.kr, megaco@ietf.org Message-ID: <65256CCC.001DA49E.00@sandesh.hss.hns.com> Date: Thu, 13 Feb 2003 10:58:46 +0530 Subject: Re: [Megaco] A simple question Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi An additional query related to this issue.... Does the topology within the context (between the termination in question and the rest of the terminations) have any effect on the signal (with directionality = internal) being applied. e.g. termA and termB are part of a context (topology - termA, termB, isolate). A signal applied on termA (direction = internal) will reach termB or not? thanks, -kapil nayar Hughes Software Systems Ltd. www.hssworld.com Christian Groves on 02/13/2003 01:08:04 AM To: hektor@etri.re.kr cc: megaco@ietf.org (bcc: Kapil Nayar/HSS) Subject: Re: [Megaco] A simple question See Q.1950 Annex A for an example usage. Christian hektor@etri.re.kr wrote: > > hi, > In Section 7.1.11, RFC 3015, > "Signals are defined as proceeding from the Termination towards the exterior > of the Context unless otherwise specified in a package" > > Would you please explain above definition in detail. > > TIS. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Feb 13 04:08:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07554 for ; Thu, 13 Feb 2003 04:08:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D9HDp05541; Thu, 13 Feb 2003 04:17:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D9Fhp05486 for ; Thu, 13 Feb 2003 04:15:43 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07523 for ; Thu, 13 Feb 2003 04:05:22 -0500 (EST) From: ajhingran@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h1D97bs20847 for ; Thu, 13 Feb 2003 14:37:37 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h1D97a220842 for ; Thu, 13 Feb 2003 14:37:36 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h1D9A2v10726 for ; Thu, 13 Feb 2003 14:40:02 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CCC.003190CF ; Thu, 13 Feb 2003 14:31:23 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CCC.00318F4B.00@sandesh.hss.hns.com> Date: Thu, 13 Feb 2003 14:36:18 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Audit Descriptor and under/overspecified Descriptor Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi I have a query with respect to conflicts between the underspecified/ overspecified descriptor processing and audit descriptor processing. Both of these descriptors in a command request mandate the inclusion of descriptors in the command reply. Whereas there can be scenarios when multiple candidate descriptors can occur in the command reply. How is the contention resolved? In case this has been discussed before, please give a pointer to the relevant mails. I am taking an example of media descriptor. e.g. Assuming an ephemeral termination with the following current state of the descriptors: LocalControl { Mode = Inactive, nt/jit=120 } Local { v=0 c=IN IP4 132.168.200.4 m=audio 6000 RTP/AVP 4 } Now, a MODIFY command with Audit descriptor and an underspecified/ overspecified Media Desc (Local desc) is received. Modify = rtp1000 { Audit { Media }, Media { Stream = 1 { LocalControl { Mode = ReceiveOnly, nt/jit=40 }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 0 8 }}}} Assuming that during the MODIFY command processing, MG selects the following new values: IP address - 132.168.200.5 port number - 7000 payload type - 8 How should the MODIFY command reply look like: Option 1 Old media descriptor is sent. Modify = rtp1000 { Media { Stream = 1 { LocalControl { Mode = Inactive, nt/jit=120 }, Local { v=0 c=IN IP4 132.168.200.4 m=audio 6000 RTP/AVP 4 }}}} But, as per the protocol the underspecified/ overspecified Local descriptor after resolution in the MG must be returned in the response. Option 2 Old media descriptor with overwritten underspecified/ overspecified Local descriptor after resolution is sent. Modify = rtp1000 { Media { Stream = 1 { LocalControl { Mode = Inactive, nt/jit=120 }, Local { v=0 c=IN IP4 132.168.200.5 m=audio 7000 RTP/AVP 8 }}}} But, the complete Media descriptor is inconsistent, i.e., Local COntrol is old but the Local descriptor is the new one. Although, MGC would know which descriptor was underspecified/ overspecfied in the request and can relate. Option 3 New media descriptor is sent. Modify = rtp1000 { Media { Stream = 1 { LocalControl { Mode = ReceiveOnly, nt/jit=40 }, Local { v=0 c=IN IP4 132.168.200.5 m=audio 7000 RTP/AVP 8 }}}} But, as per the protocol the descriptors need to be processed in sequence of occurance and therefore, media descriptor should be the old one. I am still unclear if the protocol resolves this problem. Please comment? Rgds DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Feb 13 04:08:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07593 for ; Thu, 13 Feb 2003 04:08:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1D9ITA05591 for megaco-archive@odin.ietf.org; Thu, 13 Feb 2003 04:18:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D9ITp05588 for ; Thu, 13 Feb 2003 04:18:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07567 for ; Thu, 13 Feb 2003 04:08:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D9HDp05541; Thu, 13 Feb 2003 04:17:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D9Fhp05486 for ; Thu, 13 Feb 2003 04:15:43 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07523 for ; Thu, 13 Feb 2003 04:05:22 -0500 (EST) From: ajhingran@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h1D97bs20847 for ; Thu, 13 Feb 2003 14:37:37 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h1D97a220842 for ; Thu, 13 Feb 2003 14:37:36 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h1D9A2v10726 for ; Thu, 13 Feb 2003 14:40:02 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CCC.003190CF ; Thu, 13 Feb 2003 14:31:23 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CCC.00318F4B.00@sandesh.hss.hns.com> Date: Thu, 13 Feb 2003 14:36:18 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Audit Descriptor and under/overspecified Descriptor Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi I have a query with respect to conflicts between the underspecified/ overspecified descriptor processing and audit descriptor processing. Both of these descriptors in a command request mandate the inclusion of descriptors in the command reply. Whereas there can be scenarios when multiple candidate descriptors can occur in the command reply. How is the contention resolved? In case this has been discussed before, please give a pointer to the relevant mails. I am taking an example of media descriptor. e.g. Assuming an ephemeral termination with the following current state of the descriptors: LocalControl { Mode = Inactive, nt/jit=120 } Local { v=0 c=IN IP4 132.168.200.4 m=audio 6000 RTP/AVP 4 } Now, a MODIFY command with Audit descriptor and an underspecified/ overspecified Media Desc (Local desc) is received. Modify = rtp1000 { Audit { Media }, Media { Stream = 1 { LocalControl { Mode = ReceiveOnly, nt/jit=40 }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 0 8 }}}} Assuming that during the MODIFY command processing, MG selects the following new values: IP address - 132.168.200.5 port number - 7000 payload type - 8 How should the MODIFY command reply look like: Option 1 Old media descriptor is sent. Modify = rtp1000 { Media { Stream = 1 { LocalControl { Mode = Inactive, nt/jit=120 }, Local { v=0 c=IN IP4 132.168.200.4 m=audio 6000 RTP/AVP 4 }}}} But, as per the protocol the underspecified/ overspecified Local descriptor after resolution in the MG must be returned in the response. Option 2 Old media descriptor with overwritten underspecified/ overspecified Local descriptor after resolution is sent. Modify = rtp1000 { Media { Stream = 1 { LocalControl { Mode = Inactive, nt/jit=120 }, Local { v=0 c=IN IP4 132.168.200.5 m=audio 7000 RTP/AVP 8 }}}} But, the complete Media descriptor is inconsistent, i.e., Local COntrol is old but the Local descriptor is the new one. Although, MGC would know which descriptor was underspecified/ overspecfied in the request and can relate. Option 3 New media descriptor is sent. Modify = rtp1000 { Media { Stream = 1 { LocalControl { Mode = ReceiveOnly, nt/jit=40 }, Local { v=0 c=IN IP4 132.168.200.5 m=audio 7000 RTP/AVP 8 }}}} But, as per the protocol the descriptors need to be processed in sequence of occurance and therefore, media descriptor should be the old one. I am still unclear if the protocol resolves this problem. Please comment? Rgds DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Feb 13 06:15:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09362 for ; Thu, 13 Feb 2003 06:15:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DBOop12185; Thu, 13 Feb 2003 06:24:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DBNNp12145 for ; Thu, 13 Feb 2003 06:23:23 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09335 for ; Thu, 13 Feb 2003 06:13:00 -0500 (EST) From: shbansal@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h1DBFDs11460 for ; Thu, 13 Feb 2003 16:45:13 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h1DBFC211456; Thu, 13 Feb 2003 16:45:12 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h1DBHXH17864; Thu, 13 Feb 2003 16:47:38 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CCC.003D3D31 ; Thu, 13 Feb 2003 16:38:53 +0530 X-Lotus-FromDomain: HSS To: Christian Groves , megaco@ietf.org Message-ID: <65256CCC.003D3B98.00@sandesh.hss.hns.com> Date: Thu, 13 Feb 2003 16:48:50 +0530 Subject: Re: [Megaco] Re: Topology Descriptor Processing Logic Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Christian/list, We didn't get any reply/ comments on this mail. From the earlier discussions on the mailing list, it seems that there definitely are some existing implementations supporting Topology descriptor. I would request them to provide some clarity on these issues in the interest of the MEGACO interoperability. Unless the questions/ issues raised in this mail are inconsequential and grossly missing something, in which case please indicate so. Thanks in advance Shobhit (HSS MEGACO Team) prjain@hss.hns.com on 02/03/2003 08:13:29 PM To: Christian Groves cc: Shobhit Bansal/HSS@HSS, megaco@ietf.org (bcc: megaco_maillist) Subject: Re: [Megaco] Re: Topology Descriptor Processing Logic Hi Christian/list, Thanks a lot for clarifying all the doubts. In addition to what you have said, I have two more questions as asked below. I beg your pardon in case these questions have already been discussed or asked on the list before. <> You have told that in case the topology tuple happens to be fully specified (except $), the topology descriptor would be executed first (at the action level befoe any command processing starts, even though the protocol command like ADD or MODIFY with fully-specified terminations were there in the context further, for the corresponding terminations in the topology tuples). If the above statement holds true, does it imply that the topology descriptor would always be first descriptor in the entire descriptor processing sequence that would get executed, taking into account the other descriptors processing like events, signals, stream descriptors (for all descriptors except topology, the processing sequence can be specified by MGC) etc. ?? Is this implication about the "sequence of processing" valid whether MG executes topology descriptor at the action level or at the command level (in case of ADD $) ?? <> Thanks and Regards, Prashant Jain Christian Groves on 02/03/2003 08:34:04 AM To: Shobhit Bansal/HSS@HSS cc: megaco@ietf.org (bcc: Prashant Jain/HSS) Subject: [Megaco] Re: Topology Descriptor Processing Logic Hello Shobhit, As everything is fully specified I believe it is your first description. Christian shbansal@hss.hns.com wrote: > > Hi Chris, > > I have gone through the mailing list discussions > But I still have some doubts in topology descriptor procressing > I will be really very thankful and obliged if you help in resolving them > > Assuming that we have a context C1 with terminations T1, T2 and T3 > and command comes like > > Action C1 Topolgy ( T1, T3, Isolate) > Command Modify T1 > Command Modify T2 > > In this case: > > Will the topology (T1, T3, Isolate) be applied before the > command execution starts i.e. tuples of specified terminations > will get applied before any command execution starts. > If this understanding is correct, topology will get applied > before execution of MODIFY T1 > > OR > > Will the topology application be deffered till the command > execution starts for the respective terminations that are present in tuples. > If this understanding is correct, after MODIFY T1 gets executed, > topology would be applied in conjunction thereof. > Further after that, MODIFY T2 will get executed. > > Thanking you in advance > Shobhit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Feb 13 06:16:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09389 for ; Thu, 13 Feb 2003 06:16:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DBQ3i12236 for megaco-archive@odin.ietf.org; Thu, 13 Feb 2003 06:26:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DBQ3p12233 for ; Thu, 13 Feb 2003 06:26:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09372 for ; Thu, 13 Feb 2003 06:15:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DBOop12185; Thu, 13 Feb 2003 06:24:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DBNNp12145 for ; Thu, 13 Feb 2003 06:23:23 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09335 for ; Thu, 13 Feb 2003 06:13:00 -0500 (EST) From: shbansal@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h1DBFDs11460 for ; Thu, 13 Feb 2003 16:45:13 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h1DBFC211456; Thu, 13 Feb 2003 16:45:12 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h1DBHXH17864; Thu, 13 Feb 2003 16:47:38 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CCC.003D3D31 ; Thu, 13 Feb 2003 16:38:53 +0530 X-Lotus-FromDomain: HSS To: Christian Groves , megaco@ietf.org Message-ID: <65256CCC.003D3B98.00@sandesh.hss.hns.com> Date: Thu, 13 Feb 2003 16:48:50 +0530 Subject: Re: [Megaco] Re: Topology Descriptor Processing Logic Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Christian/list, We didn't get any reply/ comments on this mail. From the earlier discussions on the mailing list, it seems that there definitely are some existing implementations supporting Topology descriptor. I would request them to provide some clarity on these issues in the interest of the MEGACO interoperability. Unless the questions/ issues raised in this mail are inconsequential and grossly missing something, in which case please indicate so. Thanks in advance Shobhit (HSS MEGACO Team) prjain@hss.hns.com on 02/03/2003 08:13:29 PM To: Christian Groves cc: Shobhit Bansal/HSS@HSS, megaco@ietf.org (bcc: megaco_maillist) Subject: Re: [Megaco] Re: Topology Descriptor Processing Logic Hi Christian/list, Thanks a lot for clarifying all the doubts. In addition to what you have said, I have two more questions as asked below. I beg your pardon in case these questions have already been discussed or asked on the list before. <> You have told that in case the topology tuple happens to be fully specified (except $), the topology descriptor would be executed first (at the action level befoe any command processing starts, even though the protocol command like ADD or MODIFY with fully-specified terminations were there in the context further, for the corresponding terminations in the topology tuples). If the above statement holds true, does it imply that the topology descriptor would always be first descriptor in the entire descriptor processing sequence that would get executed, taking into account the other descriptors processing like events, signals, stream descriptors (for all descriptors except topology, the processing sequence can be specified by MGC) etc. ?? Is this implication about the "sequence of processing" valid whether MG executes topology descriptor at the action level or at the command level (in case of ADD $) ?? <> Thanks and Regards, Prashant Jain Christian Groves on 02/03/2003 08:34:04 AM To: Shobhit Bansal/HSS@HSS cc: megaco@ietf.org (bcc: Prashant Jain/HSS) Subject: [Megaco] Re: Topology Descriptor Processing Logic Hello Shobhit, As everything is fully specified I believe it is your first description. Christian shbansal@hss.hns.com wrote: > > Hi Chris, > > I have gone through the mailing list discussions > But I still have some doubts in topology descriptor procressing > I will be really very thankful and obliged if you help in resolving them > > Assuming that we have a context C1 with terminations T1, T2 and T3 > and command comes like > > Action C1 Topolgy ( T1, T3, Isolate) > Command Modify T1 > Command Modify T2 > > In this case: > > Will the topology (T1, T3, Isolate) be applied before the > command execution starts i.e. tuples of specified terminations > will get applied before any command execution starts. > If this understanding is correct, topology will get applied > before execution of MODIFY T1 > > OR > > Will the topology application be deffered till the command > execution starts for the respective terminations that are present in tuples. > If this understanding is correct, after MODIFY T1 gets executed, > topology would be applied in conjunction thereof. > Further after that, MODIFY T2 will get executed. > > Thanking you in advance > Shobhit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Feb 13 06:18:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09414 for ; Thu, 13 Feb 2003 06:18:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DBR5p12315; Thu, 13 Feb 2003 06:27:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DBQ5p12250 for ; Thu, 13 Feb 2003 06:26:05 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09380 for ; Thu, 13 Feb 2003 06:15:45 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1DBJ4t12930; Thu, 13 Feb 2003 06:19:04 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 15GFQL31; Thu, 13 Feb 2003 06:19:05 -0500 Received: from nortelnetworks.com (acart1bq.ca.nortel.com [47.129.129.33]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1NCH8K; Thu, 13 Feb 2003 06:19:04 -0500 Message-ID: <3E4B7F24.9040205@nortelnetworks.com> Date: Thu, 13 Feb 2003 06:19:00 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: knayar@hss.hns.com CC: Christian Groves , hektor@etri.re.kr, Megaco List Subject: Re: [Megaco] A simple question References: <65256CCC.001DA49E.00@sandesh.hss.hns.com> In-Reply-To: <65256CCC.001DA49E.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'd say the signal would NOT reach termB. That is, inwardly-directed signals follow the same rules as ordinary media flows. knayar@hss.hns.com wrote: > > Hi > > An additional query related to this issue.... > Does the topology within the context (between the termination in question and > the > rest of the terminations) have any effect on the signal (with directionality = > internal) > being applied. > e.g. > termA and termB are part of a context (topology - termA, termB, isolate). > A signal applied on termA (direction = internal) will reach termB or not? > > thanks, > -kapil nayar > Hughes Software Systems Ltd. > www.hssworld.com > > > > > > Christian Groves on 02/13/2003 01:08:04 AM > > To: hektor@etri.re.kr > cc: megaco@ietf.org (bcc: Kapil Nayar/HSS) > > Subject: Re: [Megaco] A simple question > > > > > See Q.1950 Annex A for an example usage. > > Christian > > hektor@etri.re.kr wrote: > >>hi, >>In Section 7.1.11, RFC 3015, >>"Signals are defined as proceeding from the Termination towards the exterior >>of the Context unless otherwise specified in a package" >> >>Would you please explain above definition in detail. >> >>TIS. > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Feb 13 06:18:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09447 for ; Thu, 13 Feb 2003 06:18:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DBSSO12392 for megaco-archive@odin.ietf.org; Thu, 13 Feb 2003 06:28:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DBSSp12389 for ; Thu, 13 Feb 2003 06:28:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09424 for ; Thu, 13 Feb 2003 06:18:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DBR5p12315; Thu, 13 Feb 2003 06:27:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DBQ5p12250 for ; Thu, 13 Feb 2003 06:26:05 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09380 for ; Thu, 13 Feb 2003 06:15:45 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1DBJ4t12930; Thu, 13 Feb 2003 06:19:04 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 15GFQL31; Thu, 13 Feb 2003 06:19:05 -0500 Received: from nortelnetworks.com (acart1bq.ca.nortel.com [47.129.129.33]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1D1NCH8K; Thu, 13 Feb 2003 06:19:04 -0500 Message-ID: <3E4B7F24.9040205@nortelnetworks.com> Date: Thu, 13 Feb 2003 06:19:00 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: knayar@hss.hns.com CC: Christian Groves , hektor@etri.re.kr, Megaco List Subject: Re: [Megaco] A simple question References: <65256CCC.001DA49E.00@sandesh.hss.hns.com> In-Reply-To: <65256CCC.001DA49E.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'd say the signal would NOT reach termB. That is, inwardly-directed signals follow the same rules as ordinary media flows. knayar@hss.hns.com wrote: > > Hi > > An additional query related to this issue.... > Does the topology within the context (between the termination in question and > the > rest of the terminations) have any effect on the signal (with directionality = > internal) > being applied. > e.g. > termA and termB are part of a context (topology - termA, termB, isolate). > A signal applied on termA (direction = internal) will reach termB or not? > > thanks, > -kapil nayar > Hughes Software Systems Ltd. > www.hssworld.com > > > > > > Christian Groves on 02/13/2003 01:08:04 AM > > To: hektor@etri.re.kr > cc: megaco@ietf.org (bcc: Kapil Nayar/HSS) > > Subject: Re: [Megaco] A simple question > > > > > See Q.1950 Annex A for an example usage. > > Christian > > hektor@etri.re.kr wrote: > >>hi, >>In Section 7.1.11, RFC 3015, >>"Signals are defined as proceeding from the Termination towards the exterior >>of the Context unless otherwise specified in a package" >> >>Would you please explain above definition in detail. >> >>TIS. > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Feb 13 12:51:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19758 for ; Thu, 13 Feb 2003 12:51:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DI0Yp06145; Thu, 13 Feb 2003 13:00:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DF26p25524 for ; Thu, 13 Feb 2003 10:02:06 -0500 Received: from mink.ecitele.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13540 for ; Thu, 13 Feb 2003 09:51:39 -0500 (EST) From: Dana.Herskowitz@veraznetworks.com Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id QAA20148 for ; Thu, 13 Feb 2003 16:50:08 +0200 (IST) To: megaco@ietf.org Cc: Eli.Liluz@veraznetworks.com, Benny.Lavi@veraznetworks.com, Ilana.Leibovitch@veraznetworks.com, Meir.Leshem@veraznetworks.com, Artur.Karaev@veraznetworks.com, Oded.Katz@veraznetworks.com, Serge.Stepansky@ecitele.com, Izabella.Itskovitch@veraznetworks.com X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Thu, 13 Feb 2003 16:55:24 +0200 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 02/13/2003 04:55:22 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Megaco] Subtracting a termination when EBC = LockStep Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hello, When EBC = LockStep, there are three triggers for the MG to clean all accumulated events from the buffer: - The MGC sends an empty Events descriptor - The MGC sends an empty Events buffer descriptor - The MGC sends a Termination State descriptor with EBC = OFF. Suppose there is a physical termination within a specific context, the EBC = Lockstep, and there are accumulated events in the buffer. If the MGC sends Subtract command without any request (of the 3 above) to clean the buffer, there is a possibility that historic irrelevant events will be notified to the MGC. How can I avoid this situation? Should the MG put the EBC back to default (OFF) in each Subtract command, even if MGC hasn't ordered to clean the buffer? Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Feb 13 12:52:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19786 for ; Thu, 13 Feb 2003 12:52:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DI24o06313 for megaco-archive@odin.ietf.org; Thu, 13 Feb 2003 13:02:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DI24p06310 for ; Thu, 13 Feb 2003 13:02:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19772 for ; Thu, 13 Feb 2003 12:51:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DI0Yp06145; Thu, 13 Feb 2003 13:00:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DF26p25524 for ; Thu, 13 Feb 2003 10:02:06 -0500 Received: from mink.ecitele.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13540 for ; Thu, 13 Feb 2003 09:51:39 -0500 (EST) From: Dana.Herskowitz@veraznetworks.com Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id QAA20148 for ; Thu, 13 Feb 2003 16:50:08 +0200 (IST) To: megaco@ietf.org Cc: Eli.Liluz@veraznetworks.com, Benny.Lavi@veraznetworks.com, Ilana.Leibovitch@veraznetworks.com, Meir.Leshem@veraznetworks.com, Artur.Karaev@veraznetworks.com, Oded.Katz@veraznetworks.com, Serge.Stepansky@ecitele.com, Izabella.Itskovitch@veraznetworks.com X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Thu, 13 Feb 2003 16:55:24 +0200 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 02/13/2003 04:55:22 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Megaco] Subtracting a termination when EBC = LockStep Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hello, When EBC = LockStep, there are three triggers for the MG to clean all accumulated events from the buffer: - The MGC sends an empty Events descriptor - The MGC sends an empty Events buffer descriptor - The MGC sends a Termination State descriptor with EBC = OFF. Suppose there is a physical termination within a specific context, the EBC = Lockstep, and there are accumulated events in the buffer. If the MGC sends Subtract command without any request (of the 3 above) to clean the buffer, there is a possibility that historic irrelevant events will be notified to the MGC. How can I avoid this situation? Should the MG put the EBC back to default (OFF) in each Subtract command, even if MGC hasn't ordered to clean the buffer? Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Feb 13 13:11:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20625 for ; Thu, 13 Feb 2003 13:11:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DIEHp07839; Thu, 13 Feb 2003 13:14:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DIDCp07787 for ; Thu, 13 Feb 2003 13:13:12 -0500 Received: from syndeocorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20563 for ; Thu, 13 Feb 2003 13:09:22 -0500 (EST) Received: from madhupc (madhu-pc.syndeocorp.com [4.21.35.182]) by syndeocorp.com (Switch-2.0.1/Switch-2.0.1) with SMTP id h1DIClm22598; Thu, 13 Feb 2003 10:12:47 -0800 (PST) Reply-To: From: "Madhu Babu Brahmanapally" To: , Cc: , , , , , , , Subject: RE: [Megaco] Subtracting a termination when EBC = LockStep Date: Thu, 13 Feb 2003 10:11:56 -0800 Message-ID: <008b01c2d38b$65750d40$b6231504@madhupc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit HI Dana, A subtract command reverts the property values to thier default value (unless overridden by provisioning). The subtract from MGC implicitly indicates EBC=OFF. Hope this helps. Regards Madhubabu -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of Dana.Herskowitz@veraznetworks.com Sent: Thursday, February 13, 2003 6:55 AM To: megaco@ietf.org Cc: Eli.Liluz@veraznetworks.com; Benny.Lavi@veraznetworks.com; Ilana.Leibovitch@veraznetworks.com; Meir.Leshem@veraznetworks.com; Artur.Karaev@veraznetworks.com; Oded.Katz@veraznetworks.com; Serge.Stepansky@ecitele.com; Izabella.Itskovitch@veraznetworks.com Subject: [Megaco] Subtracting a termination when EBC = LockStep Hello, When EBC = LockStep, there are three triggers for the MG to clean all accumulated events from the buffer: - The MGC sends an empty Events descriptor - The MGC sends an empty Events buffer descriptor - The MGC sends a Termination State descriptor with EBC = OFF. Suppose there is a physical termination within a specific context, the EBC = Lockstep, and there are accumulated events in the buffer. If the MGC sends Subtract command without any request (of the 3 above) to clean the buffer, there is a possibility that historic irrelevant events will be notified to the MGC. How can I avoid this situation? Should the MG put the EBC back to default (OFF) in each Subtract command, even if MGC hasn't ordered to clean the buffer? Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Feb 13 13:12:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20651 for ; Thu, 13 Feb 2003 13:12:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DIFO607937 for megaco-archive@odin.ietf.org; Thu, 13 Feb 2003 13:15:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DIFOp07933 for ; Thu, 13 Feb 2003 13:15:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20634 for ; Thu, 13 Feb 2003 13:11:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DIEHp07839; Thu, 13 Feb 2003 13:14:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DIDCp07787 for ; Thu, 13 Feb 2003 13:13:12 -0500 Received: from syndeocorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20563 for ; Thu, 13 Feb 2003 13:09:22 -0500 (EST) Received: from madhupc (madhu-pc.syndeocorp.com [4.21.35.182]) by syndeocorp.com (Switch-2.0.1/Switch-2.0.1) with SMTP id h1DIClm22598; Thu, 13 Feb 2003 10:12:47 -0800 (PST) Reply-To: From: "Madhu Babu Brahmanapally" To: , Cc: , , , , , , , Subject: RE: [Megaco] Subtracting a termination when EBC = LockStep Date: Thu, 13 Feb 2003 10:11:56 -0800 Message-ID: <008b01c2d38b$65750d40$b6231504@madhupc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit HI Dana, A subtract command reverts the property values to thier default value (unless overridden by provisioning). The subtract from MGC implicitly indicates EBC=OFF. Hope this helps. Regards Madhubabu -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of Dana.Herskowitz@veraznetworks.com Sent: Thursday, February 13, 2003 6:55 AM To: megaco@ietf.org Cc: Eli.Liluz@veraznetworks.com; Benny.Lavi@veraznetworks.com; Ilana.Leibovitch@veraznetworks.com; Meir.Leshem@veraznetworks.com; Artur.Karaev@veraznetworks.com; Oded.Katz@veraznetworks.com; Serge.Stepansky@ecitele.com; Izabella.Itskovitch@veraznetworks.com Subject: [Megaco] Subtracting a termination when EBC = LockStep Hello, When EBC = LockStep, there are three triggers for the MG to clean all accumulated events from the buffer: - The MGC sends an empty Events descriptor - The MGC sends an empty Events buffer descriptor - The MGC sends a Termination State descriptor with EBC = OFF. Suppose there is a physical termination within a specific context, the EBC = Lockstep, and there are accumulated events in the buffer. If the MGC sends Subtract command without any request (of the 3 above) to clean the buffer, there is a possibility that historic irrelevant events will be notified to the MGC. How can I avoid this situation? Should the MG put the EBC back to default (OFF) in each Subtract command, even if MGC hasn't ordered to clean the buffer? Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Feb 13 13:33:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21237 for ; Thu, 13 Feb 2003 13:33:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DIaGp09153; Thu, 13 Feb 2003 13:36:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DIVvp08970 for ; Thu, 13 Feb 2003 13:31:57 -0500 Received: from exchange.td-soft.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21046 for ; Thu, 13 Feb 2003 13:28:10 -0500 (EST) Received: through eSafe SMTP Relay 1045149801; Thu Feb 13 20:30:39 2003 Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id <1SWY7GF4>; Thu, 13 Feb 2003 20:28:50 +0200 Message-ID: From: Raphael Tryster To: "'Dana.Herskowitz@veraznetworks.com'" , megaco@ietf.org Subject: RE: [Megaco] Subtracting a termination when EBC = LockStep Date: Thu, 13 Feb 2003 20:28:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D38D.BC0DB6A0" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D38D.BC0DB6A0 Content-Type: text/plain; charset="iso-8859-1" "If not provisioned otherwise, the properties in all descriptors except TerminationState and LocalControl default to empty/"no value" when a Termination is first created or returned to the null Context". I think that covers the Subtract case. Raphael Tryster -----Original Message----- From: Dana.Herskowitz@veraznetworks.com [mailto:Dana.Herskowitz@veraznetworks.com] Sent: Thursday, February 13, 2003 4:55 PM To: megaco@ietf.org Cc: Eli.Liluz@veraznetworks.com; Benny.Lavi@veraznetworks.com; Ilana.Leibovitch@veraznetworks.com; Meir.Leshem@veraznetworks.com; Artur.Karaev@veraznetworks.com; Oded.Katz@veraznetworks.com; Serge.Stepansky@ecitele.com; Izabella.Itskovitch@veraznetworks.com Subject: [Megaco] Subtracting a termination when EBC = LockStep Hello, When EBC = LockStep, there are three triggers for the MG to clean all accumulated events from the buffer: - The MGC sends an empty Events descriptor - The MGC sends an empty Events buffer descriptor - The MGC sends a Termination State descriptor with EBC = OFF. Suppose there is a physical termination within a specific context, the EBC = Lockstep, and there are accumulated events in the buffer. If the MGC sends Subtract command without any request (of the 3 above) to clean the buffer, there is a possibility that historic irrelevant events will be notified to the MGC. How can I avoid this situation? Should the MG put the EBC back to default (OFF) in each Subtract command, even if MGC hasn't ordered to clean the buffer? Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C2D38D.BC0DB6A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] Subtracting a termination when EBC =3D LockStep</TITL= E> </HEAD> <BODY> <P><FONT SIZE=3D2>"If not provisioned otherwise, the properties in a= ll descriptors except TerminationState and LocalControl default to empty/= "no value" when a Termination is first created or returned to t= he null Context".</FONT></P> <P><FONT SIZE=3D2>I think that covers the Subtract case.</FONT> </P> <P><FONT SIZE=3D2>Raphael Tryster</FONT> </P> <BR> <P><FONT SIZE=3D2>-----Original Message-----</FONT> <BR><FONT SIZE=3D2>From: Dana.Herskowitz@veraznetworks.com</FONT> <BR><FONT SIZE=3D2>[<A HREF=3D"mailto:Dana.Herskowitz@veraznetworks.com">= mailto:Dana.Herskowitz@veraznetworks.com</A>]</FONT> <BR><FONT SIZE=3D2>Sent: Thursday, February 13, 2003 4:55 PM</FONT> <BR><FONT SIZE=3D2>To: megaco@ietf.org</FONT> <BR><FONT SIZE=3D2>Cc: Eli.Liluz@veraznetworks.com; Benny.Lavi@veraznetwo= rks.com;</FONT> <BR><FONT SIZE=3D2>Ilana.Leibovitch@veraznetworks.com; Meir.Leshem@verazn= etworks.com;</FONT> <BR><FONT SIZE=3D2>Artur.Karaev@veraznetworks.com; Oded.Katz@veraznetwork= s.com;</FONT> <BR><FONT SIZE=3D2>Serge.Stepansky@ecitele.com; Izabella.Itskovitch@veraz= networks.com</FONT> <BR><FONT SIZE=3D2>Subject: [Megaco] Subtracting a termination when EBC =3D= LockStep</FONT> </P> <BR> <P><FONT SIZE=3D2>Hello,</FONT> <BR><FONT SIZE=3D2>When EBC =3D LockStep, there are three triggers for th= e MG to clean all</FONT> <BR><FONT SIZE=3D2>accumulated events from the buffer:</FONT> <BR><FONT SIZE=3D2>- The MGC sends an empty Events descriptor</FONT> <BR><FONT SIZE=3D2>- The MGC sends an empty Events buffer descriptor</FON= T> <BR><FONT SIZE=3D2>- The MGC sends a Termination State descriptor with EB= C =3D OFF.</FONT> </P> <BR> <P><FONT SIZE=3D2>Suppose there is a physical termination within a specif= ic context, the EBC</FONT> <BR><FONT SIZE=3D2>=3D Lockstep, and there are accumulated events in the = buffer.</FONT> <BR><FONT SIZE=3D2>If the MGC sends Subtract command without any request = (of the 3 above) to</FONT> <BR><FONT SIZE=3D2>clean the buffer, there is a possibility that historic= irrelevant events</FONT> <BR><FONT SIZE=3D2>will be notified to the MGC.</FONT> </P> <P><FONT SIZE=3D2>How can I avoid this situation? Should the MG put the E= BC back to default</FONT> <BR><FONT SIZE=3D2>(OFF) in each Subtract command, even if MGC hasn't ord= ered to clean the</FONT> <BR><FONT SIZE=3D2>buffer?</FONT> </P> <P><FONT SIZE=3D2>Regards,</FONT> <BR><FONT SIZE=3D2>Dana H.</FONT> </P> <BR> <P><FONT SIZE=3D2>_______________________________________________</FONT> <BR><FONT SIZE=3D2>Megaco mailing list</FONT> <BR><FONT SIZE=3D2>Megaco@ietf.org</FONT> <BR><FONT SIZE=3D2><A HREF=3D"https://www1.ietf.org/mailman/listinfo/mega= co" TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/megaco</A></= FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C2D38D.BC0DB6A0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Feb 13 13:34:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21285 for <megaco-archive@odin.ietf.org>; Thu, 13 Feb 2003 13:34:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DIbUX09650 for megaco-archive@odin.ietf.org; Thu, 13 Feb 2003 13:37:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DIbUp09639 for <megaco-web-archive@optimus.ietf.org>; Thu, 13 Feb 2003 13:37:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21247 for <megaco-web-archive@ietf.org>; Thu, 13 Feb 2003 13:33:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DIaGp09153; Thu, 13 Feb 2003 13:36:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DIVvp08970 for <megaco@optimus.ietf.org>; Thu, 13 Feb 2003 13:31:57 -0500 Received: from exchange.td-soft.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21046 for <megaco@ietf.org>; Thu, 13 Feb 2003 13:28:10 -0500 (EST) Received: through eSafe SMTP Relay 1045149801; Thu Feb 13 20:30:39 2003 Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id <1SWY7GF4>; Thu, 13 Feb 2003 20:28:50 +0200 Message-ID: <B1584457374ED211B7A90008C7242DEF451502@EXCHANGE> From: Raphael Tryster <raphael@tdsoft.com> To: "'Dana.Herskowitz@veraznetworks.com'" <Dana.Herskowitz@veraznetworks.com>, megaco@ietf.org Subject: RE: [Megaco] Subtracting a termination when EBC = LockStep Date: Thu, 13 Feb 2003 20:28:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D38D.BC0DB6A0" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=unsubscribe> List-Id: Media Gateway Control <megaco.ietf.org> List-Post: <mailto:megaco@ietf.org> List-Help: <mailto:megaco-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=subscribe> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D38D.BC0DB6A0 Content-Type: text/plain; charset="iso-8859-1" "If not provisioned otherwise, the properties in all descriptors except TerminationState and LocalControl default to empty/"no value" when a Termination is first created or returned to the null Context". I think that covers the Subtract case. Raphael Tryster -----Original Message----- From: Dana.Herskowitz@veraznetworks.com [mailto:Dana.Herskowitz@veraznetworks.com] Sent: Thursday, February 13, 2003 4:55 PM To: megaco@ietf.org Cc: Eli.Liluz@veraznetworks.com; Benny.Lavi@veraznetworks.com; Ilana.Leibovitch@veraznetworks.com; Meir.Leshem@veraznetworks.com; Artur.Karaev@veraznetworks.com; Oded.Katz@veraznetworks.com; Serge.Stepansky@ecitele.com; Izabella.Itskovitch@veraznetworks.com Subject: [Megaco] Subtracting a termination when EBC = LockStep Hello, When EBC = LockStep, there are three triggers for the MG to clean all accumulated events from the buffer: - The MGC sends an empty Events descriptor - The MGC sends an empty Events buffer descriptor - The MGC sends a Termination State descriptor with EBC = OFF. Suppose there is a physical termination within a specific context, the EBC = Lockstep, and there are accumulated events in the buffer. If the MGC sends Subtract command without any request (of the 3 above) to clean the buffer, there is a possibility that historic irrelevant events will be notified to the MGC. How can I avoid this situation? Should the MG put the EBC back to default (OFF) in each Subtract command, even if MGC hasn't ordered to clean the buffer? Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C2D38D.BC0DB6A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-885= 9-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 5.5.2653.1= 2"> <TITLE>RE: [Megaco] Subtracting a termination when EBC =3D LockStep</TITL= E> </HEAD> <BODY> <P><FONT SIZE=3D2>"If not provisioned otherwise, the properties in a= ll descriptors except TerminationState and LocalControl default to empty/= "no value" when a Termination is first created or returned to t= he null Context".</FONT></P> <P><FONT SIZE=3D2>I think that covers the Subtract case.</FONT> </P> <P><FONT SIZE=3D2>Raphael Tryster</FONT> </P> <BR> <P><FONT SIZE=3D2>-----Original Message-----</FONT> <BR><FONT SIZE=3D2>From: Dana.Herskowitz@veraznetworks.com</FONT> <BR><FONT SIZE=3D2>[<A HREF=3D"mailto:Dana.Herskowitz@veraznetworks.com">= mailto:Dana.Herskowitz@veraznetworks.com</A>]</FONT> <BR><FONT SIZE=3D2>Sent: Thursday, February 13, 2003 4:55 PM</FONT> <BR><FONT SIZE=3D2>To: megaco@ietf.org</FONT> <BR><FONT SIZE=3D2>Cc: Eli.Liluz@veraznetworks.com; Benny.Lavi@veraznetwo= rks.com;</FONT> <BR><FONT SIZE=3D2>Ilana.Leibovitch@veraznetworks.com; Meir.Leshem@verazn= etworks.com;</FONT> <BR><FONT SIZE=3D2>Artur.Karaev@veraznetworks.com; Oded.Katz@veraznetwork= s.com;</FONT> <BR><FONT SIZE=3D2>Serge.Stepansky@ecitele.com; Izabella.Itskovitch@veraz= networks.com</FONT> <BR><FONT SIZE=3D2>Subject: [Megaco] Subtracting a termination when EBC =3D= LockStep</FONT> </P> <BR> <P><FONT SIZE=3D2>Hello,</FONT> <BR><FONT SIZE=3D2>When EBC =3D LockStep, there are three triggers for th= e MG to clean all</FONT> <BR><FONT SIZE=3D2>accumulated events from the buffer:</FONT> <BR><FONT SIZE=3D2>- The MGC sends an empty Events descriptor</FONT> <BR><FONT SIZE=3D2>- The MGC sends an empty Events buffer descriptor</FON= T> <BR><FONT SIZE=3D2>- The MGC sends a Termination State descriptor with EB= C =3D OFF.</FONT> </P> <BR> <P><FONT SIZE=3D2>Suppose there is a physical termination within a specif= ic context, the EBC</FONT> <BR><FONT SIZE=3D2>=3D Lockstep, and there are accumulated events in the = buffer.</FONT> <BR><FONT SIZE=3D2>If the MGC sends Subtract command without any request = (of the 3 above) to</FONT> <BR><FONT SIZE=3D2>clean the buffer, there is a possibility that historic= irrelevant events</FONT> <BR><FONT SIZE=3D2>will be notified to the MGC.</FONT> </P> <P><FONT SIZE=3D2>How can I avoid this situation? Should the MG put the E= BC back to default</FONT> <BR><FONT SIZE=3D2>(OFF) in each Subtract command, even if MGC hasn't ord= ered to clean the</FONT> <BR><FONT SIZE=3D2>buffer?</FONT> </P> <P><FONT SIZE=3D2>Regards,</FONT> <BR><FONT SIZE=3D2>Dana H.</FONT> </P> <BR> <P><FONT SIZE=3D2>_______________________________________________</FONT> <BR><FONT SIZE=3D2>Megaco mailing list</FONT> <BR><FONT SIZE=3D2>Megaco@ietf.org</FONT> <BR><FONT SIZE=3D2><A HREF=3D"https://www1.ietf.org/mailman/listinfo/mega= co" TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/megaco</A></= FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C2D38D.BC0DB6A0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Feb 19 05:08:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17733 for <megaco-archive@lists.ietf.org>; Wed, 19 Feb 2003 05:08:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JADap26473; Wed, 19 Feb 2003 05:13:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JA9sp26304 for <megaco@optimus.ietf.org>; Wed, 19 Feb 2003 05:09:54 -0500 Received: from eins.siemens.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17581 for <megaco@ietf.org>; Wed, 19 Feb 2003 05:03:20 -0500 (EST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id h1JA7Ak23099 for <megaco@ietf.org>; Wed, 19 Feb 2003 11:07:10 +0100 Received: from vies141a.sie.siemens.at (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.1/8.12.1) with ESMTP id h1JA77Wb012470 for <megaco@ietf.org>; Wed, 19 Feb 2003 11:07:08 +0100 (MET) Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id <FGB3FS3Q>; Wed, 19 Feb 2003 11:08:04 +0100 Message-ID: <D9F2B9CD7BD5D21196BC0800060D9ED607CE25CC@vies186a.sie.siemens.at> From: Kalleitner Franz <franz.kalleitner@siemens.com> To: "'megaco@ietf.org'" <megaco@ietf.org> Date: Wed, 19 Feb 2003 11:08:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D7FE.CA0649F0" Subject: [Megaco] How to set RequestID in RequestDescriptor Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=unsubscribe> List-Id: Media Gateway Control <megaco.ietf.org> List-Post: <mailto:megaco@ietf.org> List-Help: <mailto:megaco-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=subscribe> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D7FE.CA0649F0 Content-Type: text/plain; charset="iso-8859-1" Hi all, An EventsDescriptor received by a media gateway replaces any previous Events descriptor. How does this reflect on the RequestID. Shall a new RequestID assigned for the new eventdescriptor or can/shall be the "old" RequestID reused? I guess a new RequestID shall be used , could anybody confirm this assumption! Thanks in advance ------_=_NextPart_001_01C2D7FE.CA0649F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1My4xMiI+DQo8VElUTEU+SG93IHRv IHNldCBSZXF1ZXN0SUQgaW4gUmVxdWVzdERlc2NyaXB0b3I8L1RJVExFPg0KPC9IRUFEPg0KPEJP RFk+DQoNCjxQPjxGT05UIEZBQ0U9IlRpbWVzIE5ldyBSb21hbiI+SGkgYWxsLDwvRk9OVD4NCjwv UD4NCg0KPFA+PEZPTlQgRkFDRT0iVGltZXMgTmV3IFJvbWFuIj5BbiBFdmVudHNEZXNjcmlwdG9y IHJlY2VpdmVkIGJ5IGEgbWVkaWEgZ2F0ZXdheSByZXBsYWNlcyBhbnkgcHJldmlvdXMgRXZlbnRz IGRlc2NyaXB0b3IuIDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgRkFDRT0iVGltZXMgTmV3IFJv bWFuIj5Ib3cgZG9lcyB0aGlzIHJlZmxlY3Qgb24gdGhlIFJlcXVlc3RJRC4gU2hhbGwgYSBuZXcg UmVxdWVzdElEIGFzc2lnbmVkIGZvciB0aGUgbmV3IGV2ZW50ZGVzY3JpcHRvciBvciBjYW4vc2hh bGwgYmUgdGhlICZxdW90O29sZCZxdW90OyBSZXF1ZXN0SUQgcmV1c2VkPzwvRk9OVD48L1A+DQoN CjxQPjxGT05UIEZBQ0U9IlRpbWVzIE5ldyBSb21hbiI+SSBndWVzcyBhIG5ldyBSZXF1ZXN0SUQg c2hhbGwgYmUgdXNlZCAsIGNvdWxkIGFueWJvZHkgY29uZmlybSB0aGlzIGFzc3VtcHRpb24hPC9G T05UPg0KPC9QPg0KDQo8UD48Rk9OVCBGQUNFPSJUaW1lcyBOZXcgUm9tYW4iPlRoYW5rcyBpbiBh ZHZhbmNlPC9GT05UPg0KPC9QPg0KDQo8L0JPRFk+DQo8L0hUTUw+ ------_=_NextPart_001_01C2D7FE.CA0649F0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Feb 19 05:09:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17767 for <megaco-archive@odin.ietf.org>; Wed, 19 Feb 2003 05:09:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JAF9326604 for megaco-archive@odin.ietf.org; Wed, 19 Feb 2003 05:15:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JAF9p26601 for <megaco-web-archive@optimus.ietf.org>; Wed, 19 Feb 2003 05:15:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17737 for <megaco-web-archive@ietf.org>; Wed, 19 Feb 2003 05:08:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JADap26473; Wed, 19 Feb 2003 05:13:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JA9sp26304 for <megaco@optimus.ietf.org>; Wed, 19 Feb 2003 05:09:54 -0500 Received: from eins.siemens.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17581 for <megaco@ietf.org>; Wed, 19 Feb 2003 05:03:20 -0500 (EST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id h1JA7Ak23099 for <megaco@ietf.org>; Wed, 19 Feb 2003 11:07:10 +0100 Received: from vies141a.sie.siemens.at (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.1/8.12.1) with ESMTP id h1JA77Wb012470 for <megaco@ietf.org>; Wed, 19 Feb 2003 11:07:08 +0100 (MET) Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id <FGB3FS3Q>; Wed, 19 Feb 2003 11:08:04 +0100 Message-ID: <D9F2B9CD7BD5D21196BC0800060D9ED607CE25CC@vies186a.sie.siemens.at> From: Kalleitner Franz <franz.kalleitner@siemens.com> To: "'megaco@ietf.org'" <megaco@ietf.org> Date: Wed, 19 Feb 2003 11:08:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D7FE.CA0649F0" Subject: [Megaco] How to set RequestID in RequestDescriptor Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=unsubscribe> List-Id: Media Gateway Control <megaco.ietf.org> List-Post: <mailto:megaco@ietf.org> List-Help: <mailto:megaco-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=subscribe> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D7FE.CA0649F0 Content-Type: text/plain; charset="iso-8859-1" Hi all, An EventsDescriptor received by a media gateway replaces any previous Events descriptor. How does this reflect on the RequestID. Shall a new RequestID assigned for the new eventdescriptor or can/shall be the "old" RequestID reused? I guess a new RequestID shall be used , could anybody confirm this assumption! Thanks in advance ------_=_NextPart_001_01C2D7FE.CA0649F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1My4xMiI+DQo8VElUTEU+SG93IHRv IHNldCBSZXF1ZXN0SUQgaW4gUmVxdWVzdERlc2NyaXB0b3I8L1RJVExFPg0KPC9IRUFEPg0KPEJP RFk+DQoNCjxQPjxGT05UIEZBQ0U9IlRpbWVzIE5ldyBSb21hbiI+SGkgYWxsLDwvRk9OVD4NCjwv UD4NCg0KPFA+PEZPTlQgRkFDRT0iVGltZXMgTmV3IFJvbWFuIj5BbiBFdmVudHNEZXNjcmlwdG9y IHJlY2VpdmVkIGJ5IGEgbWVkaWEgZ2F0ZXdheSByZXBsYWNlcyBhbnkgcHJldmlvdXMgRXZlbnRz IGRlc2NyaXB0b3IuIDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgRkFDRT0iVGltZXMgTmV3IFJv bWFuIj5Ib3cgZG9lcyB0aGlzIHJlZmxlY3Qgb24gdGhlIFJlcXVlc3RJRC4gU2hhbGwgYSBuZXcg UmVxdWVzdElEIGFzc2lnbmVkIGZvciB0aGUgbmV3IGV2ZW50ZGVzY3JpcHRvciBvciBjYW4vc2hh bGwgYmUgdGhlICZxdW90O29sZCZxdW90OyBSZXF1ZXN0SUQgcmV1c2VkPzwvRk9OVD48L1A+DQoN CjxQPjxGT05UIEZBQ0U9IlRpbWVzIE5ldyBSb21hbiI+SSBndWVzcyBhIG5ldyBSZXF1ZXN0SUQg c2hhbGwgYmUgdXNlZCAsIGNvdWxkIGFueWJvZHkgY29uZmlybSB0aGlzIGFzc3VtcHRpb24hPC9G T05UPg0KPC9QPg0KDQo8UD48Rk9OVCBGQUNFPSJUaW1lcyBOZXcgUm9tYW4iPlRoYW5rcyBpbiBh ZHZhbmNlPC9GT05UPg0KPC9QPg0KDQo8L0JPRFk+DQo8L0hUTUw+ ------_=_NextPart_001_01C2D7FE.CA0649F0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Feb 19 05:28:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18088 for <megaco-archive@lists.ietf.org>; Wed, 19 Feb 2003 05:28:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JAYEp27516; Wed, 19 Feb 2003 05:34:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JAVsp27441 for <megaco@optimus.ietf.org>; Wed, 19 Feb 2003 05:31:54 -0500 Received: from exchange.td-soft.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA18039 for <megaco@ietf.org>; Wed, 19 Feb 2003 05:25:19 -0500 (EST) Received: through eSafe SMTP Relay 1045149801; Wed Feb 19 12:27:48 2003 Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id <1SWY7MCX>; Wed, 19 Feb 2003 12:25:32 +0200 Message-ID: <B1584457374ED211B7A90008C7242DEF451508@EXCHANGE> From: Raphael Tryster <raphael@tdsoft.com> To: "'Kalleitner Franz'" <franz.kalleitner@siemens.com>, "'megaco@ietf.org'" <megaco@ietf.org> Subject: RE: [Megaco] How to set RequestID in RequestDescriptor Date: Wed, 19 Feb 2003 12:25:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D801.3ADAF430" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=unsubscribe> List-Id: Media Gateway Control <megaco.ietf.org> List-Post: <mailto:megaco@ietf.org> List-Help: <mailto:megaco-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=subscribe> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D801.3ADAF430 Content-Type: text/plain; charset="iso-8859-1" The RequestID is a required field in the Events descriptor, therefore a new value must be supplied with a new Events descriptor. Raphael Tryster -----Original Message----- From: Kalleitner Franz [mailto:franz.kalleitner@siemens.com] Sent: Wednesday, February 19, 2003 12:08 PM To: 'megaco@ietf.org' Subject: [Megaco] How to set RequestID in RequestDescriptor Hi all, An EventsDescriptor received by a media gateway replaces any previous Events descriptor. How does this reflect on the RequestID. Shall a new RequestID assigned for the new eventdescriptor or can/shall be the "old" RequestID reused? I guess a new RequestID shall be used , could anybody confirm this assumption! Thanks in advance ------_=_NextPart_001_01C2D801.3ADAF430 Content-Type: text/html; charset="iso-8859-1" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <TITLE>How to set RequestID in RequestDescriptor
The RequestID is a required field in the Events descriptor, therefore a new value must be supplied with a new Events descriptor.
 

Raphael Tryster

-----Original Message-----
From: Kalleitner Franz [mailto:franz.kalleitner@siemens.com]
Sent: Wednesday, February 19, 2003 12:08 PM
To: 'megaco@ietf.org'
Subject: [Megaco] How to set RequestID in RequestDescriptor

Hi all,

An EventsDescriptor received by a media gateway replaces any previous Events descriptor.

How does this reflect on the RequestID. Shall a new RequestID assigned for the new eventdescriptor or can/shall be the "old" RequestID reused?

I guess a new RequestID shall be used , could anybody confirm this assumption!

Thanks in advance

------_=_NextPart_001_01C2D801.3ADAF430-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Feb 19 05:29:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18107 for ; Wed, 19 Feb 2003 05:29:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JAZSF27623 for megaco-archive@odin.ietf.org; Wed, 19 Feb 2003 05:35:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JAZSp27620 for ; Wed, 19 Feb 2003 05:35:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18096 for ; Wed, 19 Feb 2003 05:28:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JAYEp27516; Wed, 19 Feb 2003 05:34:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JAVsp27441 for ; Wed, 19 Feb 2003 05:31:54 -0500 Received: from exchange.td-soft.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA18039 for ; Wed, 19 Feb 2003 05:25:19 -0500 (EST) Received: through eSafe SMTP Relay 1045149801; Wed Feb 19 12:27:48 2003 Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id <1SWY7MCX>; Wed, 19 Feb 2003 12:25:32 +0200 Message-ID: From: Raphael Tryster To: "'Kalleitner Franz'" , "'megaco@ietf.org'" Subject: RE: [Megaco] How to set RequestID in RequestDescriptor Date: Wed, 19 Feb 2003 12:25:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D801.3ADAF430" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D801.3ADAF430 Content-Type: text/plain; charset="iso-8859-1" The RequestID is a required field in the Events descriptor, therefore a new value must be supplied with a new Events descriptor. Raphael Tryster -----Original Message----- From: Kalleitner Franz [mailto:franz.kalleitner@siemens.com] Sent: Wednesday, February 19, 2003 12:08 PM To: 'megaco@ietf.org' Subject: [Megaco] How to set RequestID in RequestDescriptor Hi all, An EventsDescriptor received by a media gateway replaces any previous Events descriptor. How does this reflect on the RequestID. Shall a new RequestID assigned for the new eventdescriptor or can/shall be the "old" RequestID reused? I guess a new RequestID shall be used , could anybody confirm this assumption! Thanks in advance ------_=_NextPart_001_01C2D801.3ADAF430 Content-Type: text/html; charset="iso-8859-1" How to set RequestID in RequestDescriptor
The RequestID is a required field in the Events descriptor, therefore a new value must be supplied with a new Events descriptor.
 

Raphael Tryster

-----Original Message-----
From: Kalleitner Franz [mailto:franz.kalleitner@siemens.com]
Sent: Wednesday, February 19, 2003 12:08 PM
To: 'megaco@ietf.org'
Subject: [Megaco] How to set RequestID in RequestDescriptor

Hi all,

An EventsDescriptor received by a media gateway replaces any previous Events descriptor.

How does this reflect on the RequestID. Shall a new RequestID assigned for the new eventdescriptor or can/shall be the "old" RequestID reused?

I guess a new RequestID shall be used , could anybody confirm this assumption!

Thanks in advance

------_=_NextPart_001_01C2D801.3ADAF430-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Feb 19 09:10:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25354 for ; Wed, 19 Feb 2003 09:10:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JEFwp12676; Wed, 19 Feb 2003 09:15:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JEAxp12454 for ; Wed, 19 Feb 2003 09:10:59 -0500 Received: from bos-exch01.winphoria.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25217 for ; Wed, 19 Feb 2003 09:04:22 -0500 (EST) Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Feb 2003 09:08:10 -0500 Message-Id: <5.2.0.9.0.20030219090432.02b0f008@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 19 Feb 2003 09:07:06 -0500 To: "'Kalleitner Franz'" , Raphael Tryster From: Aleksandr Ryabin Subject: RE: [Megaco] How to set RequestID in RequestDescriptor Cc: "'megaco@ietf.org'" In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1223834881==.ALT" X-OriginalArrivalTime: 19 Feb 2003 14:08:10.0276 (UTC) FILETIME=[5560DE40:01C2D820] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --=====================_1223834881==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed ... which can be equal to the old/previous value. That is you don't have to generate new value, instead you can reuse previous one. Aleks At 05:25 AM 2/19/2003, Raphael Tryster wrote: >The RequestID is a required field in the Events descriptor, therefore a >new value must be supplied with a new Events descriptor. > > >Raphael Tryster >-----Original Message----- >From: Kalleitner Franz [mailto:franz.kalleitner@siemens.com] >Sent: Wednesday, February 19, 2003 12:08 PM >To: 'megaco@ietf.org' >Subject: [Megaco] How to set RequestID in RequestDescriptor > >Hi all, > >An EventsDescriptor received by a media gateway replaces any previous >Events descriptor. > >How does this reflect on the RequestID. Shall a new RequestID assigned for >the new eventdescriptor or can/shall be the "old" RequestID reused? > >I guess a new RequestID shall be used , could anybody confirm this >assumption! > >Thanks in advance --=====================_1223834881==.ALT Content-Type: text/html; charset="us-ascii" ... which can be equal to the old/previous value.
That is you don't have to generate new value, instead you can reuse previous one.
        Aleks

At 05:25 AM 2/19/2003, Raphael Tryster wrote:
The RequestID is a required field in the Events descriptor, therefore a new value must be supplied with a new Events descriptor.
 

Raphael Tryster
-----Original Message-----
From: Kalleitner Franz [mailto:franz.kalleitner@siemens.com]
Sent: Wednesday, February 19, 2003 12:08 PM
To: 'megaco@ietf.org'
Subject: [Megaco] How to set RequestID in RequestDescriptor

Hi all,

An EventsDescriptor received by a media gateway replaces any previous Events descriptor.

How does this reflect on the RequestID. Shall a new RequestID assigned for the new eventdescriptor or can/shall be the "old" RequestID reused?

I guess a new RequestID shall be used , could anybody confirm this assumption!

Thanks in advance
--=====================_1223834881==.ALT-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Feb 19 09:11:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25382 for ; Wed, 19 Feb 2003 09:11:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JEHNQ12740 for megaco-archive@odin.ietf.org; Wed, 19 Feb 2003 09:17:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JEHNp12737 for ; Wed, 19 Feb 2003 09:17:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25358 for ; Wed, 19 Feb 2003 09:10:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JEFwp12676; Wed, 19 Feb 2003 09:15:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JEAxp12454 for ; Wed, 19 Feb 2003 09:10:59 -0500 Received: from bos-exch01.winphoria.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25217 for ; Wed, 19 Feb 2003 09:04:22 -0500 (EST) Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Feb 2003 09:08:10 -0500 Message-Id: <5.2.0.9.0.20030219090432.02b0f008@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 19 Feb 2003 09:07:06 -0500 To: "'Kalleitner Franz'" , Raphael Tryster From: Aleksandr Ryabin Subject: RE: [Megaco] How to set RequestID in RequestDescriptor Cc: "'megaco@ietf.org'" In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1223834881==.ALT" X-OriginalArrivalTime: 19 Feb 2003 14:08:10.0276 (UTC) FILETIME=[5560DE40:01C2D820] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --=====================_1223834881==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed ... which can be equal to the old/previous value. That is you don't have to generate new value, instead you can reuse previous one. Aleks At 05:25 AM 2/19/2003, Raphael Tryster wrote: >The RequestID is a required field in the Events descriptor, therefore a >new value must be supplied with a new Events descriptor. > > >Raphael Tryster >-----Original Message----- >From: Kalleitner Franz [mailto:franz.kalleitner@siemens.com] >Sent: Wednesday, February 19, 2003 12:08 PM >To: 'megaco@ietf.org' >Subject: [Megaco] How to set RequestID in RequestDescriptor > >Hi all, > >An EventsDescriptor received by a media gateway replaces any previous >Events descriptor. > >How does this reflect on the RequestID. Shall a new RequestID assigned for >the new eventdescriptor or can/shall be the "old" RequestID reused? > >I guess a new RequestID shall be used , could anybody confirm this >assumption! > >Thanks in advance --=====================_1223834881==.ALT Content-Type: text/html; charset="us-ascii" ... which can be equal to the old/previous value.
That is you don't have to generate new value, instead you can reuse previous one.
        Aleks

At 05:25 AM 2/19/2003, Raphael Tryster wrote:
The RequestID is a required field in the Events descriptor, therefore a new value must be supplied with a new Events descriptor.
 

Raphael Tryster
-----Original Message-----
From: Kalleitner Franz [mailto:franz.kalleitner@siemens.com]
Sent: Wednesday, February 19, 2003 12:08 PM
To: 'megaco@ietf.org'
Subject: [Megaco] How to set RequestID in RequestDescriptor

Hi all,

An EventsDescriptor received by a media gateway replaces any previous Events descriptor.

How does this reflect on the RequestID. Shall a new RequestID assigned for the new eventdescriptor or can/shall be the "old" RequestID reused?

I guess a new RequestID shall be used , could anybody confirm this assumption!

Thanks in advance
--=====================_1223834881==.ALT-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Feb 28 07:35:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23702 for ; Fri, 28 Feb 2003 07:35:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCjhp23695; Fri, 28 Feb 2003 07:45:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCbPp22954 for ; Fri, 28 Feb 2003 07:37: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 HAA22930; Fri, 28 Feb 2003 07:26:26 -0500 (EST) Message-Id: <200302281226.HAA22930@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: megaco@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 28 Feb 2003 07:26:26 -0500 Subject: [Megaco] I-D ACTION:draft-ietf-megaco-r2package-03.txt Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --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 R2 Package Author(s) : K. Laha, V. Nair Filename : draft-ietf-megaco-r2package-03.txt Pages : 19 Date : 2003-2-27 This document is work in progress and defines the R2 package for the Megaco/H.248 Protocol that can be used to exchange call setup supervisory and control information between a Media Gateway (MG) and a Media Gateway Controller (MGC) to realize Signaling System R2 at a VoIP Gateway. It is intended to satisfy the requirements in section 12 of the Megaco/H.248 protocol [2]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-r2package-03.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-r2package-03.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: <2003-2-27133026.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-megaco-r2package-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-megaco-r2package-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-27133026.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Feb 28 07:37:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23757 for ; Fri, 28 Feb 2003 07:37:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SClU823951 for megaco-archive@odin.ietf.org; Fri, 28 Feb 2003 07:47:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SClUp23948 for ; Fri, 28 Feb 2003 07:47:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23725 for ; Fri, 28 Feb 2003 07:36:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCjhp23695; Fri, 28 Feb 2003 07:45:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCbPp22954 for ; Fri, 28 Feb 2003 07:37: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 HAA22930; Fri, 28 Feb 2003 07:26:26 -0500 (EST) Message-Id: <200302281226.HAA22930@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: megaco@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 28 Feb 2003 07:26:26 -0500 Subject: [Megaco] I-D ACTION:draft-ietf-megaco-r2package-03.txt Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --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 R2 Package Author(s) : K. Laha, V. Nair Filename : draft-ietf-megaco-r2package-03.txt Pages : 19 Date : 2003-2-27 This document is work in progress and defines the R2 package for the Megaco/H.248 Protocol that can be used to exchange call setup supervisory and control information between a Media Gateway (MG) and a Media Gateway Controller (MGC) to realize Signaling System R2 at a VoIP Gateway. It is intended to satisfy the requirements in section 12 of the Megaco/H.248 protocol [2]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-r2package-03.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-r2package-03.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: <2003-2-27133026.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-megaco-r2package-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-megaco-r2package-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-27133026.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Feb 28 11:11:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02948 for ; Fri, 28 Feb 2003 11:11:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SFG2p02896; Fri, 28 Feb 2003 10:16:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SFCup02757 for ; Fri, 28 Feb 2003 10:12:56 -0500 Received: from bos-exch01.winphoria.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00841 for ; Fri, 28 Feb 2003 10:01:54 -0500 (EST) Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 28 Feb 2003 10:05:49 -0500 Message-Id: <5.2.0.9.0.20030228100406.02ade0d0@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 28 Feb 2003 10:05:49 -0500 To: megaco@ietf.org From: Aleksandr Ryabin Subject: Re: [Megaco] I-D ACTION:draft-ietf-megaco-r2package-03.txt In-Reply-To: <200302281226.HAA22930@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 28 Feb 2003 15:05:49.0772 (UTC) FILETIME=[E11DD0C0:01C2DF3A] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, Could the authors of the draft provide differences between previous revision of the draft and this one? The draft itself seems to be missing the paragraph with that info. Thanks Aleks At 07:26 AM 2/28/2003, 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/H.248 R2 Package > Author(s) : K. Laha, V. Nair > Filename : draft-ietf-megaco-r2package-03.txt > Pages : 19 > Date : 2003-2-27 > >This document is work in progress and defines the R2 package for the >Megaco/H.248 Protocol that can be used to exchange call setup supervisory >and control information between a Media Gateway (MG) and a Media Gateway >Controller (MGC) to realize Signaling System R2 at a VoIP Gateway. It is >intended to satisfy the requirements in section 12 of the Megaco/H.248 >protocol [2]. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >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-r2package-03.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-r2package-03.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: <2003-2-27133026.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-megaco-r2package-03.txt _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Feb 28 11:12:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03151 for ; Fri, 28 Feb 2003 11:12:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SGMnR07796 for megaco-archive@odin.ietf.org; Fri, 28 Feb 2003 11:22:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SGMnp07793 for ; Fri, 28 Feb 2003 11:22:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03087 for ; Fri, 28 Feb 2003 11:11:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SFG2p02896; Fri, 28 Feb 2003 10:16:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SFCup02757 for ; Fri, 28 Feb 2003 10:12:56 -0500 Received: from bos-exch01.winphoria.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00841 for ; Fri, 28 Feb 2003 10:01:54 -0500 (EST) Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 28 Feb 2003 10:05:49 -0500 Message-Id: <5.2.0.9.0.20030228100406.02ade0d0@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 28 Feb 2003 10:05:49 -0500 To: megaco@ietf.org From: Aleksandr Ryabin Subject: Re: [Megaco] I-D ACTION:draft-ietf-megaco-r2package-03.txt In-Reply-To: <200302281226.HAA22930@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 28 Feb 2003 15:05:49.0772 (UTC) FILETIME=[E11DD0C0:01C2DF3A] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, Could the authors of the draft provide differences between previous revision of the draft and this one? The draft itself seems to be missing the paragraph with that info. Thanks Aleks At 07:26 AM 2/28/2003, 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/H.248 R2 Package > Author(s) : K. Laha, V. Nair > Filename : draft-ietf-megaco-r2package-03.txt > Pages : 19 > Date : 2003-2-27 > >This document is work in progress and defines the R2 package for the >Megaco/H.248 Protocol that can be used to exchange call setup supervisory >and control information between a Media Gateway (MG) and a Media Gateway >Controller (MGC) to realize Signaling System R2 at a VoIP Gateway. It is >intended to satisfy the requirements in section 12 of the Megaco/H.248 >protocol [2]. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >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-r2package-03.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-r2package-03.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: <2003-2-27133026.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-megaco-r2package-03.txt _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Feb 28 12:22:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05479 for ; Fri, 28 Feb 2003 12:22:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SHWmp13475; Fri, 28 Feb 2003 12:32:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SHTTp13311 for ; Fri, 28 Feb 2003 12:29:29 -0500 Received: from syndeocorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05272 for ; Fri, 28 Feb 2003 12:18:18 -0500 (EST) Received: from madhupc (madhu-pc.syndeocorp.com [4.21.35.182]) by syndeocorp.com (Switch-2.0.1/Switch-2.0.1) with SMTP id h1SHMAJ09101 for ; Fri, 28 Feb 2003 09:22:10 -0800 (PST) Reply-To: From: "Madhu Babu Brahmanapally" To: Subject: RE: [Megaco] I-D ACTION:draft-ietf-megaco-r2package-03.txt Date: Fri, 28 Feb 2003 09:22:20 -0800 Message-ID: <00cf01c2df4d$f4340180$b6231504@madhupc> 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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200302281226.HAA22930@ietf.org> Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, Earlier I remember that decision was taken to merge R2 package in CAS packages (by foster) and a "manyfolks" draft was submitted. Now it is appearing as a seperate draft?? Regards Madhubabu Brahmanapally -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Friday, February 28, 2003 4:26 AM To: IETF-Announce: Cc: megaco@ietf.org Subject: [Megaco] I-D ACTION:draft-ietf-megaco-r2package-03.txt 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 R2 Package Author(s) : K. Laha, V. Nair Filename : draft-ietf-megaco-r2package-03.txt Pages : 19 Date : 2003-2-27 This document is work in progress and defines the R2 package for the Megaco/H.248 Protocol that can be used to exchange call setup supervisory and control information between a Media Gateway (MG) and a Media Gateway Controller (MGC) to realize Signaling System R2 at a VoIP Gateway. It is intended to satisfy the requirements in section 12 of the Megaco/H.248 protocol [2]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-r2package-03.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-r2package-03.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. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Feb 28 12:23:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05500 for ; Fri, 28 Feb 2003 12:23:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SHYNW13524 for megaco-archive@odin.ietf.org; Fri, 28 Feb 2003 12:34:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SHYNp13521 for ; Fri, 28 Feb 2003 12:34:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05495 for ; Fri, 28 Feb 2003 12:23:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SHWmp13475; Fri, 28 Feb 2003 12:32:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SHTTp13311 for ; Fri, 28 Feb 2003 12:29:29 -0500 Received: from syndeocorp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05272 for ; Fri, 28 Feb 2003 12:18:18 -0500 (EST) Received: from madhupc (madhu-pc.syndeocorp.com [4.21.35.182]) by syndeocorp.com (Switch-2.0.1/Switch-2.0.1) with SMTP id h1SHMAJ09101 for ; Fri, 28 Feb 2003 09:22:10 -0800 (PST) Reply-To: From: "Madhu Babu Brahmanapally" To: Subject: RE: [Megaco] I-D ACTION:draft-ietf-megaco-r2package-03.txt Date: Fri, 28 Feb 2003 09:22:20 -0800 Message-ID: <00cf01c2df4d$f4340180$b6231504@madhupc> 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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200302281226.HAA22930@ietf.org> Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, Earlier I remember that decision was taken to merge R2 package in CAS packages (by foster) and a "manyfolks" draft was submitted. Now it is appearing as a seperate draft?? Regards Madhubabu Brahmanapally -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Friday, February 28, 2003 4:26 AM To: IETF-Announce: Cc: megaco@ietf.org Subject: [Megaco] I-D ACTION:draft-ietf-megaco-r2package-03.txt 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 R2 Package Author(s) : K. Laha, V. Nair Filename : draft-ietf-megaco-r2package-03.txt Pages : 19 Date : 2003-2-27 This document is work in progress and defines the R2 package for the Megaco/H.248 Protocol that can be used to exchange call setup supervisory and control information between a Media Gateway (MG) and a Media Gateway Controller (MGC) to realize Signaling System R2 at a VoIP Gateway. It is intended to satisfy the requirements in section 12 of the Megaco/H.248 protocol [2]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-r2package-03.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-r2package-03.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. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Feb 28 12:54:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07348 for ; Fri, 28 Feb 2003 12:54:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SI4Ip15628; Fri, 28 Feb 2003 13:04:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SI1sp15489 for ; Fri, 28 Feb 2003 13:01:54 -0500 Received: from zrtps06s.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07240 for ; Fri, 28 Feb 2003 12:50:48 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1SHsi828111 for ; Fri, 28 Feb 2003 12:54:44 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Feb 2003 12:54:45 -0500 Message-ID: From: "Kevin Boyle" To: madhu@syndeocorp.com, megaco@ietf.org Subject: RE: [Megaco] I-D ACTION:draft-ietf-megaco-r2package-03.txt Date: Fri, 28 Feb 2003 12:54:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , The CAS packages never contained R2. The CAS packages draft is expired. It has been submitted to the ITU as a proposed work item. Also, the H.248 CAS packages were not written by Bill Foster. He was one of several authors that collaborated on the design. Kevin -----Original Message----- From: Madhu Babu Brahmanapally [mailto:madhu@syndeocorp.com] Sent: Friday, February 28, 2003 12:22 PM To: megaco@ietf.org Subject: RE: [Megaco] I-D ACTION:draft-ietf-megaco-r2package-03.txt Hi all, Earlier I remember that decision was taken to merge R2 package in CAS packages (by foster) and a "manyfolks" draft was submitted. Now it is appearing as a seperate draft?? Regards Madhubabu Brahmanapally -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Friday, February 28, 2003 4:26 AM To: IETF-Announce: Cc: megaco@ietf.org Subject: [Megaco] I-D ACTION:draft-ietf-megaco-r2package-03.txt 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 R2 Package Author(s) : K. Laha, V. Nair Filename : draft-ietf-megaco-r2package-03.txt Pages : 19 Date : 2003-2-27 This document is work in progress and defines the R2 package for the Megaco/H.248 Protocol that can be used to exchange call setup supervisory and control information between a Media Gateway (MG) and a Media Gateway Controller (MGC) to realize Signaling System R2 at a VoIP Gateway. It is intended to satisfy the requirements in section 12 of the Megaco/H.248 protocol [2]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-r2package-03.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-r2package-03.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. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Feb 28 12:55:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07380 for ; Fri, 28 Feb 2003 12:55:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SI5ta15712 for megaco-archive@odin.ietf.org; Fri, 28 Feb 2003 13:05:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SI5tp15709 for ; Fri, 28 Feb 2003 13:05:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07369 for ; Fri, 28 Feb 2003 12:54:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SI4Ip15628; Fri, 28 Feb 2003 13:04:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SI1sp15489 for ; Fri, 28 Feb 2003 13:01:54 -0500 Received: from zrtps06s.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07240 for ; Fri, 28 Feb 2003 12:50:48 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1SHsi828111 for ; Fri, 28 Feb 2003 12:54:44 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Feb 2003 12:54:45 -0500 Message-ID: From: "Kevin Boyle" To: madhu@syndeocorp.com, megaco@ietf.org Subject: RE: [Megaco] I-D ACTION:draft-ietf-megaco-r2package-03.txt Date: Fri, 28 Feb 2003 12:54:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , The CAS packages never contained R2. The CAS packages draft is expired. It has been submitted to the ITU as a proposed work item. Also, the H.248 CAS packages were not written by Bill Foster. He was one of several authors that collaborated on the design. Kevin -----Original Message----- From: Madhu Babu Brahmanapally [mailto:madhu@syndeocorp.com] Sent: Friday, February 28, 2003 12:22 PM To: megaco@ietf.org Subject: RE: [Megaco] I-D ACTION:draft-ietf-megaco-r2package-03.txt Hi all, Earlier I remember that decision was taken to merge R2 package in CAS packages (by foster) and a "manyfolks" draft was submitted. Now it is appearing as a seperate draft?? Regards Madhubabu Brahmanapally -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Friday, February 28, 2003 4:26 AM To: IETF-Announce: Cc: megaco@ietf.org Subject: [Megaco] I-D ACTION:draft-ietf-megaco-r2package-03.txt 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 R2 Package Author(s) : K. Laha, V. Nair Filename : draft-ietf-megaco-r2package-03.txt Pages : 19 Date : 2003-2-27 This document is work in progress and defines the R2 package for the Megaco/H.248 Protocol that can be used to exchange call setup supervisory and control information between a Media Gateway (MG) and a Media Gateway Controller (MGC) to realize Signaling System R2 at a VoIP Gateway. It is intended to satisfy the requirements in section 12 of the Megaco/H.248 protocol [2]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-r2package-03.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-r2package-03.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. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco