From mailman-admin@ietf.org Sat May 1 11:03:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23565 for ; Sat, 1 May 2004 11:03:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJuOT-0005TU-En for megaco-archive@lists.ietf.org; Sat, 01 May 2004 09:19:01 -0400 Date: Sat, 01 May 2004 09:19:01 -0400 Message-ID: <20040501131901.27207.39441.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 May 3 01:42:02 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24233 for ; Mon, 3 May 2004 01:42:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKW6X-0002uT-Jv; Mon, 03 May 2004 01:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKW4t-0002Hm-Cu for megaco@optimus.ietf.org; Mon, 03 May 2004 01:33:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23966 for ; Mon, 3 May 2004 01:33:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKW4q-0005Dy-8X for megaco@ietf.org; Mon, 03 May 2004 01:33:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKW1x-0004kl-00 for megaco@ietf.org; Mon, 03 May 2004 01:30:18 -0400 Received: from [203.199.83.147] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 1BKVzz-0004Ox-00 for megaco@ietf.org; Mon, 03 May 2004 01:28:15 -0400 Received: (qmail 20617 invoked by uid 510); 3 May 2004 05:28:12 -0000 Date: 3 May 2004 05:28:12 -0000 Message-ID: <20040503052812.20616.qmail@webmail25.rediffmail.com> Received: from unknown (137.71.23.54) by rediffmail.com via HTTP; 03 may 2004 05:28:12 -0000 MIME-Version: 1.0 From: "kumar" Reply-To: "kumar" To: megaco@ietf.org Content-type: multipart/alternative; boundary="Next_1083562092---0-203.199.83.147-20613" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.9 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_20_30,HTML_IMAGE_ONLY_06,HTML_MESSAGE,MSGID_FROM_MTA_HEADER, REPLY_TO_ULINE_NUMS autolearn=no version=2.60 Subject: [Megaco] In deployment which type of encoding will be used? Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multipart mime message --Next_1083562092---0-203.199.83.147-20613 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0A  Hi All,
=0A    As per H.248 , the MG should suppo= rt either TEXT or BINARY encoding. In MG's deployment , which encoding(TEXT= /BER) will be generally used?. While browsing I saw some MGs which suppot o= nly  TEXT encoding. Can anyone help me in clarrifying this?
=0A
= =0AThanks & Regards,
=0AKumar
=0A=0A

=0A

=0A=0A --Next_1083562092---0-203.199.83.147-20613 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =A0Hi All,=0A As per H.248 , the MG should support either TEXT or BINAR= Y encoding. In MG's deployment , which encoding(TEXT/BER) will be generally= used?. While browsing I saw some MGs which suppot only TEXT encoding. Can= anyone help me in clarrifying this?=0A=0AThanks & Regards,=0AKumar=0A --Next_1083562092---0-203.199.83.147-20613-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon May 3 02:52:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10161 for ; Mon, 3 May 2004 02:52:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKXC5-0007fb-Ft for megaco-archive@odin.ietf.org; Mon, 03 May 2004 02:44:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i436in5e029387 for megaco-archive@odin.ietf.org; Mon, 3 May 2004 02:44:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKX2u-0004NF-8w for megaco-web-archive@optimus.ietf.org; Mon, 03 May 2004 02:35:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24419 for ; Mon, 3 May 2004 01:47:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKWIi-0007dl-K4 for megaco-web-archive@ietf.org; Mon, 03 May 2004 01:47:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKWFl-000782-00 for megaco-web-archive@ietf.org; Mon, 03 May 2004 01:44:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKWDD-0006hk-00 for megaco-web-archive@ietf.org; Mon, 03 May 2004 01:41:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKW6X-0002uT-Jv; Mon, 03 May 2004 01:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKW4t-0002Hm-Cu for megaco@optimus.ietf.org; Mon, 03 May 2004 01:33:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23966 for ; Mon, 3 May 2004 01:33:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKW4q-0005Dy-8X for megaco@ietf.org; Mon, 03 May 2004 01:33:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKW1x-0004kl-00 for megaco@ietf.org; Mon, 03 May 2004 01:30:18 -0400 Received: from [203.199.83.147] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 1BKVzz-0004Ox-00 for megaco@ietf.org; Mon, 03 May 2004 01:28:15 -0400 Received: (qmail 20617 invoked by uid 510); 3 May 2004 05:28:12 -0000 Date: 3 May 2004 05:28:12 -0000 Message-ID: <20040503052812.20616.qmail@webmail25.rediffmail.com> Received: from unknown (137.71.23.54) by rediffmail.com via HTTP; 03 may 2004 05:28:12 -0000 MIME-Version: 1.0 From: "kumar" Reply-To: "kumar" To: megaco@ietf.org Content-type: multipart/alternative; boundary="Next_1083562092---0-203.199.83.147-20613" Subject: [Megaco] In deployment which type of encoding will be used? 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.6 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_20_30,HTML_IMAGE_ONLY_08,HTML_MESSAGE,MSGID_FROM_MTA_HEADER, REPLY_TO_ULINE_NUMS autolearn=no version=2.60 This is a multipart mime message --Next_1083562092---0-203.199.83.147-20613 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0A  Hi All,
=0A    As per H.248 , the MG should suppo= rt either TEXT or BINARY encoding. In MG's deployment , which encoding(TEXT= /BER) will be generally used?. While browsing I saw some MGs which suppot o= nly  TEXT encoding. Can anyone help me in clarrifying this?
=0A
= =0AThanks & Regards,
=0AKumar
=0A=0A

=0A

=0A=0A --Next_1083562092---0-203.199.83.147-20613 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =A0Hi All,=0A As per H.248 , the MG should support either TEXT or BINAR= Y encoding. In MG's deployment , which encoding(TEXT/BER) will be generally= used?. While browsing I saw some MGs which suppot only TEXT encoding. Can= anyone help me in clarrifying this?=0A=0AThanks & Regards,=0AKumar=0A --Next_1083562092---0-203.199.83.147-20613-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon May 3 09:40:45 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28691 for ; Mon, 3 May 2004 09:40:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKd48-0006Nt-ID; Mon, 03 May 2004 09:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKXEl-0008P7-4u for megaco@optimus.ietf.org; Mon, 03 May 2004 02:47:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09848 for ; Mon, 3 May 2004 02:47:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKXEh-00020J-7t for megaco@ietf.org; Mon, 03 May 2004 02:47:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKXBf-0001UY-00 for megaco@ietf.org; Mon, 03 May 2004 02:44:25 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BKX8j-00010d-00 for megaco@ietf.org; Mon, 03 May 2004 02:41:21 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i436fLPA003484 for ; Mon, 3 May 2004 08:41:21 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 May 2004 08:41:21 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 3 May 2004 08:41:21 +0200 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5630A39@ESEALNT442.al.sw.ericsson.se> From: "Alf Heidermark (AS/EAB)" To: "'Aleksandr Ryabin'" , "Christian Groves (MC/EPA)" , megaco@ietf.org Cc: Kevin Boyle , Tom-PT Taylor Subject: RE: [Megaco] Continuity tests Date: Mon, 3 May 2004 08:41:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 03 May 2004 06:41:21.0261 (UTC) FILETIME=[A54E11D0:01C430D9] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Alexandr Continuity check is in service on many old exchanges. Do you really mean that they shall change their impleentations to be able to interwork with the dumb switch. Normally it is up to new equipment to interwork existing network nodes. From this resoning I cannot see any reason to change anything in H.248 to continuity check. alf -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of Aleksandr Ryabin Sent: den 30 april 2004 16:39 To: Christian Groves (MC/EPA); megaco@ietf.org Cc: Kevin Boyle; Tom-PT Taylor Subject: Re: [Megaco] Continuity tests Hi Christian, There could be "dumb" switches in the middle of the path (for example DACS) which are not capable of any testing/signalling. Their only role is to split/redirect links and as such the nature of a circuit can change, and thus the type of COT test. Regards, Aleks At 08:17 PM 4/29/2004, Christian Groves wrote: >Hello Aleksandr, > >Is this really a problem? The Continuity test is a link by link procedure >not an end to end procedure. I tend to support Kevin and Tom on this one. > >Regards, Christian > >Aleksandr Ryabin wrote: >>Kevin, exactly, the type of COT test does not only depend on the physical >>details of a termination the MGC controls, but also on physical >>details of circuit which *eventually* is connected to that termination. >>My point is that the final far-end *final* connection can change without >>a change to immediate connection to MG termination and only MGC >>would know about it. >>For example, if MG is digital trunking gateway, it does not mean that >>only pure 4-wire tests will be used all the time. If the other side connected >>trough set of intermediate switches and finally lands at the time of the test >>say on analog 2-wire circuit then the test to be executed is 2-wire test. >>I guess it is possible to somehow tie up configuration of MG termination >>dynamically to changes which happens to those intermediate switches, >>but it does not seem right. On the contrary, that information would come to >>MGC naturally, since it is a controlling element. >>Also putting a burden of configuring of a test type per every single >>termination seems to be too much for MG, especially if we are talking >>about high density MGs which handle hundred thousands terminations. >>BTW This is a real problem we run into in our MGC implementation and >>are trying to solve. I thought that instead of having a proprietary package >>I might as well give it a shot to see if there is any interest to make the >>solution public instead. >>Thanks. >> Aleks >>At 11:23 AM 4/29/2004, Kevin Boyle wrote: >> >>>I agree with Tom. The fact that the circuit is connected to a single >>>entity means that only a single type of continuity test is actually >>>valid. MGs are expected to know how to handle their terminations. >>>Who the termination is connected to is certainly part of that >>>handling. Because the far-end connection changes the nature of the >>>termination, this becomes an MG-knowledge problem. >>> >>>I believe the package is fine as it stands, and the MG should know what >>>"run a continuity test" means for its terminations. >>> >>>Kevin >>> >>>-----Original Message----- >>>From: Taylor, Tom-PT [CAR:5N00:EXCH] >>>Sent: Thursday, April 29, 2004 11:19 AM >>>To: Aleksandr Ryabin >>>Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >>>Subject: Re: [Megaco] Continuity tests >>> >>>I for one disagree with your philosophy. I think the physical details >>>of the termination should be provisioned in the MG rather than the the >>>MGC. However, I have no direct implementation responsibility, so I >>>should let those who do speak up. >>> >>>Aleksandr Ryabin wrote: >>> >>> > Packages defined in H.248.17 do not cover continuity tests. >>> > >>> > If the experts agree that MGC should be able to control type of >>> > continuity test then ether basic ct package needs to be amended to >>> > include new functionality, or H.248.17 needs to be amended to include >>> > new "extended" continuity package Commends? Suggestions? >>> > >>> > Aleks >>> > >>> > At 01:14 AM 4/29/2004, Zhao Bo wrote: >>> > >>> >> Can H.248.17 "line test packages" be used to test these circuits? >>> >> >>> >> ----- Original Message ----- >>> >> From: Aleksandr Ryabin >>> >> To: Kevin Boyle ; >>> >> megaco@ietf.org >>> >> Sent: Thursday, April 29, 2004 2:11 AM >>> >> Subject: RE: [Megaco] Continuity tests >>> >> >>> >> Yes, the type of test depends on what a circuit is connected to. >>> >> >>> >> But, I was actually coming from the view that MGC "controls" MG >>> >> and as such only MGC should have knowledge on what test to execute >>> >> (i.e. what is connected to the other side of a circuit). >>> >> >>> >> If this information is left in MG, then each circuit has to be >>> >> provisioned >>> >> with that information such that MG can make intelligent decision >>> >> on what >>> >> type of test to execute. Thus every time a circuit connection is >>> >> changed, >>> >> directly or indirectly, MG circuit needs to be re-provisioned. >>> >> >>> >> I think that configuration should be kept on MGC and the decision >>> >> should >>> >> come from MGC instead. >>> >> >>> >> Aleks >>> >> >>> >> At 02:30 PM 4/28/2004, Kevin Boyle wrote: >>> >> >>> >>> Is it possible to run more than one kind of continuity test >>> >>> on a particular circuit? If no, then the provisioning model >>> >>> holds and there is no need for a change. If yes, then we may >>> >>> need to add something to the package to allow selection of a >>> >>> ct test type. >>> >>> >>> >>> Kevin >>> >>> >>> >>> -----Original Message----- >>> >>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>> >>> Sent: Wednesday, April 28, 2004 1:21 PM >>> >>> To: megaco@ietf.org >>> >>> Subject: [Megaco] Continuity tests >>> >>> >>> >>> Hi, >>> >>> >>> >>> There are several continuity test types (i.e 2-wire, 4-wire, >>> >>> etc) While provisioning of physical test parameters (i.e. >>> >>> frequencies, sequence, timeouts, etc) in MG makes sense, IMHO >>> >>> choosing a type of continuity test seem logical to be left to >>> >>> MGC. >>> >>> >>> >>> Basic Continuity Package (ct) does not allow to choose the >>> >>> type of a test. >>> >>> It implies that type of a test is provisioned on MG (per >>> >>> termination?) >>> >>> >>> >>> Is there another (extended) continuity test package which >>> >>> allows MGC to choose the type of a continuity test to be >>> >>> performed? >>> >>> >>> >>> If not, does anyone see a need to have such a package? >>> >>> Comments? >>> >>> >>> >>> Thanks >>> >>> Aleks >>> >>> >>> >>> _______________________________________________ >>> >>> Megaco mailing list >>> >>> Megaco@ietf.org >>> >>> https://www1.ietf.org/mailman/listinfo/megaco >>> >> _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon May 3 10:42:01 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05661 for ; Mon, 3 May 2004 10:42:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKeNk-0001zu-Ci; Mon, 03 May 2004 10:25:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKeKn-0000iN-Fl for megaco@optimus.ietf.org; Mon, 03 May 2004 10:22:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04343 for ; Mon, 3 May 2004 10:22:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKeKl-0004aV-3S for megaco@ietf.org; Mon, 03 May 2004 10:22:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKeHz-00048L-00 for megaco@ietf.org; Mon, 03 May 2004 10:19:24 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1BKeCg-0003Ep-00 for megaco@ietf.org; Mon, 03 May 2004 10:13:54 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id i43EDokh006107; Mon, 3 May 2004 07:13:50 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i43ECKTW003165; Mon, 3 May 2004 09:12:28 -0500 Message-Id: <5.2.1.1.0.20040503100320.00b13420@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 03 May 2004 10:11:21 -0400 To: "Alf Heidermark (AS/EAB)" , megaco@ietf.org From: Aleksandr Ryabin Subject: RE: [Megaco] Continuity tests In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5630A39@ESEALNT442.al.sw.er icsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 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 Alf, I'm not talking about old networks. With old networks everything stays the same. In order to maintain backward compatibility there always will be "intelligent" switches sitting on border with old networks, which are capable of doing COT. But new networks can utilize new (cheap) solutions and as such new "intelligent" switches need to be capable of the functionality in question. Regards, Aleks At 02:41 AM 5/3/2004, Alf Heidermark (AS/EAB) wrote: >Hello Alexandr > >Continuity check is in service on many old exchanges. Do you really mean >that they shall change their impleentations to be able to interwork with >the dumb switch. Normally it is up to new equipment to interwork existing >network nodes. From this resoning I cannot see any reason to change >anything in H.248 to continuity check. > >alf > >-----Original Message----- >From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of >Aleksandr Ryabin >Sent: den 30 april 2004 16:39 >To: Christian Groves (MC/EPA); megaco@ietf.org >Cc: Kevin Boyle; Tom-PT Taylor >Subject: Re: [Megaco] Continuity tests > > >Hi Christian, > >There could be "dumb" switches in the middle of the path >(for example DACS) which are not capable of any testing/signalling. >Their only role is to split/redirect links and as such the nature >of a circuit can change, and thus the type of COT test. > >Regards, > Aleks > >At 08:17 PM 4/29/2004, Christian Groves wrote: > >Hello Aleksandr, > > > >Is this really a problem? The Continuity test is a link by link procedure > >not an end to end procedure. I tend to support Kevin and Tom on this one. > > > >Regards, Christian > > > >Aleksandr Ryabin wrote: > >>Kevin, exactly, the type of COT test does not only depend on the physical > >>details of a termination the MGC controls, but also on physical > >>details of circuit which *eventually* is connected to that termination. > >>My point is that the final far-end *final* connection can change without > >>a change to immediate connection to MG termination and only MGC > >>would know about it. > >>For example, if MG is digital trunking gateway, it does not mean that > >>only pure 4-wire tests will be used all the time. If the other side > connected > >>trough set of intermediate switches and finally lands at the time of > the test > >>say on analog 2-wire circuit then the test to be executed is 2-wire test. > >>I guess it is possible to somehow tie up configuration of MG termination > >>dynamically to changes which happens to those intermediate switches, > >>but it does not seem right. On the contrary, that information would come to > >>MGC naturally, since it is a controlling element. > >>Also putting a burden of configuring of a test type per every single > >>termination seems to be too much for MG, especially if we are talking > >>about high density MGs which handle hundred thousands terminations. > >>BTW This is a real problem we run into in our MGC implementation and > >>are trying to solve. I thought that instead of having a proprietary package > >>I might as well give it a shot to see if there is any interest to make the > >>solution public instead. > >>Thanks. > >> Aleks > >>At 11:23 AM 4/29/2004, Kevin Boyle wrote: > >> > >>>I agree with Tom. The fact that the circuit is connected to a single > >>>entity means that only a single type of continuity test is actually > >>>valid. MGs are expected to know how to handle their terminations. > >>>Who the termination is connected to is certainly part of that > >>>handling. Because the far-end connection changes the nature of the > >>>termination, this becomes an MG-knowledge problem. > >>> > >>>I believe the package is fine as it stands, and the MG should know what > >>>"run a continuity test" means for its terminations. > >>> > >>>Kevin > >>> > >>>-----Original Message----- > >>>From: Taylor, Tom-PT [CAR:5N00:EXCH] > >>>Sent: Thursday, April 29, 2004 11:19 AM > >>>To: Aleksandr Ryabin > >>>Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org > >>>Subject: Re: [Megaco] Continuity tests > >>> > >>>I for one disagree with your philosophy. I think the physical details > >>>of the termination should be provisioned in the MG rather than the the > >>>MGC. However, I have no direct implementation responsibility, so I > >>>should let those who do speak up. > >>> > >>>Aleksandr Ryabin wrote: > >>> > >>> > Packages defined in H.248.17 do not cover continuity tests. > >>> > > >>> > If the experts agree that MGC should be able to control type of > >>> > continuity test then ether basic ct package needs to be amended to > >>> > include new functionality, or H.248.17 needs to be amended to include > >>> > new "extended" continuity package Commends? Suggestions? > >>> > > >>> > Aleks > >>> > > >>> > At 01:14 AM 4/29/2004, Zhao Bo wrote: > >>> > > >>> >> Can H.248.17 "line test packages" be used to test these circuits? > >>> >> > >>> >> ----- Original Message ----- > >>> >> From: Aleksandr Ryabin > >>> >> To: Kevin Boyle ; > >>> >> megaco@ietf.org > >>> >> Sent: Thursday, April 29, 2004 2:11 AM > >>> >> Subject: RE: [Megaco] Continuity tests > >>> >> > >>> >> Yes, the type of test depends on what a circuit is connected to. > >>> >> > >>> >> But, I was actually coming from the view that MGC "controls" MG > >>> >> and as such only MGC should have knowledge on what test to execute > >>> >> (i.e. what is connected to the other side of a circuit). > >>> >> > >>> >> If this information is left in MG, then each circuit has to be > >>> >> provisioned > >>> >> with that information such that MG can make intelligent decision > >>> >> on what > >>> >> type of test to execute. Thus every time a circuit connection is > >>> >> changed, > >>> >> directly or indirectly, MG circuit needs to be re-provisioned. > >>> >> > >>> >> I think that configuration should be kept on MGC and the decision > >>> >> should > >>> >> come from MGC instead. > >>> >> > >>> >> Aleks > >>> >> > >>> >> At 02:30 PM 4/28/2004, Kevin Boyle wrote: > >>> >> > >>> >>> Is it possible to run more than one kind of continuity test > >>> >>> on a particular circuit? If no, then the provisioning model > >>> >>> holds and there is no need for a change. If yes, then we may > >>> >>> need to add something to the package to allow selection of a > >>> >>> ct test type. > >>> >>> > >>> >>> Kevin > >>> >>> > >>> >>> -----Original Message----- > >>> >>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] > >>> >>> Sent: Wednesday, April 28, 2004 1:21 PM > >>> >>> To: megaco@ietf.org > >>> >>> Subject: [Megaco] Continuity tests > >>> >>> > >>> >>> Hi, > >>> >>> > >>> >>> There are several continuity test types (i.e 2-wire, 4-wire, > >>> >>> etc) While provisioning of physical test parameters (i.e. > >>> >>> frequencies, sequence, timeouts, etc) in MG makes sense, IMHO > >>> >>> choosing a type of continuity test seem logical to be left to > >>> >>> MGC. > >>> >>> > >>> >>> Basic Continuity Package (ct) does not allow to choose the > >>> >>> type of a test. > >>> >>> It implies that type of a test is provisioned on MG (per > >>> >>> termination?) > >>> >>> > >>> >>> Is there another (extended) continuity test package which > >>> >>> allows MGC to choose the type of a continuity test to be > >>> >>> performed? > >>> >>> > >>> >>> If not, does anyone see a need to have such a package? > >>> >>> Comments? > >>> >>> > >>> >>> Thanks > >>> >>> Aleks > >>> >>> > >>> >>> _______________________________________________ > >>> >>> Megaco mailing list > >>> >>> Megaco@ietf.org > >>> >>> https://www1.ietf.org/mailman/listinfo/megaco > >>> >> > > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon May 3 10:53:33 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06259 for ; Mon, 3 May 2004 10:53:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKeiS-0007Vc-Po for megaco-archive@odin.ietf.org; Mon, 03 May 2004 10:46:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43Ekite028864 for megaco-archive@odin.ietf.org; Mon, 3 May 2004 10:46:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKecI-0005tX-Gj for megaco-web-archive@optimus.ietf.org; Mon, 03 May 2004 10:40:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29467 for ; Mon, 3 May 2004 09:50:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKdqG-0007gH-NE for megaco-web-archive@ietf.org; Mon, 03 May 2004 09:50:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKdk3-0006cP-00 for megaco-web-archive@ietf.org; Mon, 03 May 2004 09:44:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKdg9-0005rk-00 for megaco-web-archive@ietf.org; Mon, 03 May 2004 09:40:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKd48-0006Nt-ID; Mon, 03 May 2004 09:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKXEl-0008P7-4u for megaco@optimus.ietf.org; Mon, 03 May 2004 02:47:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09848 for ; Mon, 3 May 2004 02:47:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKXEh-00020J-7t for megaco@ietf.org; Mon, 03 May 2004 02:47:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKXBf-0001UY-00 for megaco@ietf.org; Mon, 03 May 2004 02:44:25 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BKX8j-00010d-00 for megaco@ietf.org; Mon, 03 May 2004 02:41:21 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i436fLPA003484 for ; Mon, 3 May 2004 08:41:21 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 May 2004 08:41:21 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 3 May 2004 08:41:21 +0200 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5630A39@ESEALNT442.al.sw.ericsson.se> From: "Alf Heidermark (AS/EAB)" To: "'Aleksandr Ryabin'" , "Christian Groves (MC/EPA)" , megaco@ietf.org Cc: Kevin Boyle , Tom-PT Taylor Subject: RE: [Megaco] Continuity tests Date: Mon, 3 May 2004 08:41:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 03 May 2004 06:41:21.0261 (UTC) FILETIME=[A54E11D0:01C430D9] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hello Alexandr Continuity check is in service on many old exchanges. Do you really mean that they shall change their impleentations to be able to interwork with the dumb switch. Normally it is up to new equipment to interwork existing network nodes. From this resoning I cannot see any reason to change anything in H.248 to continuity check. alf -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of Aleksandr Ryabin Sent: den 30 april 2004 16:39 To: Christian Groves (MC/EPA); megaco@ietf.org Cc: Kevin Boyle; Tom-PT Taylor Subject: Re: [Megaco] Continuity tests Hi Christian, There could be "dumb" switches in the middle of the path (for example DACS) which are not capable of any testing/signalling. Their only role is to split/redirect links and as such the nature of a circuit can change, and thus the type of COT test. Regards, Aleks At 08:17 PM 4/29/2004, Christian Groves wrote: >Hello Aleksandr, > >Is this really a problem? The Continuity test is a link by link procedure >not an end to end procedure. I tend to support Kevin and Tom on this one. > >Regards, Christian > >Aleksandr Ryabin wrote: >>Kevin, exactly, the type of COT test does not only depend on the physical >>details of a termination the MGC controls, but also on physical >>details of circuit which *eventually* is connected to that termination. >>My point is that the final far-end *final* connection can change without >>a change to immediate connection to MG termination and only MGC >>would know about it. >>For example, if MG is digital trunking gateway, it does not mean that >>only pure 4-wire tests will be used all the time. If the other side connected >>trough set of intermediate switches and finally lands at the time of the test >>say on analog 2-wire circuit then the test to be executed is 2-wire test. >>I guess it is possible to somehow tie up configuration of MG termination >>dynamically to changes which happens to those intermediate switches, >>but it does not seem right. On the contrary, that information would come to >>MGC naturally, since it is a controlling element. >>Also putting a burden of configuring of a test type per every single >>termination seems to be too much for MG, especially if we are talking >>about high density MGs which handle hundred thousands terminations. >>BTW This is a real problem we run into in our MGC implementation and >>are trying to solve. I thought that instead of having a proprietary package >>I might as well give it a shot to see if there is any interest to make the >>solution public instead. >>Thanks. >> Aleks >>At 11:23 AM 4/29/2004, Kevin Boyle wrote: >> >>>I agree with Tom. The fact that the circuit is connected to a single >>>entity means that only a single type of continuity test is actually >>>valid. MGs are expected to know how to handle their terminations. >>>Who the termination is connected to is certainly part of that >>>handling. Because the far-end connection changes the nature of the >>>termination, this becomes an MG-knowledge problem. >>> >>>I believe the package is fine as it stands, and the MG should know what >>>"run a continuity test" means for its terminations. >>> >>>Kevin >>> >>>-----Original Message----- >>>From: Taylor, Tom-PT [CAR:5N00:EXCH] >>>Sent: Thursday, April 29, 2004 11:19 AM >>>To: Aleksandr Ryabin >>>Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >>>Subject: Re: [Megaco] Continuity tests >>> >>>I for one disagree with your philosophy. I think the physical details >>>of the termination should be provisioned in the MG rather than the the >>>MGC. However, I have no direct implementation responsibility, so I >>>should let those who do speak up. >>> >>>Aleksandr Ryabin wrote: >>> >>> > Packages defined in H.248.17 do not cover continuity tests. >>> > >>> > If the experts agree that MGC should be able to control type of >>> > continuity test then ether basic ct package needs to be amended to >>> > include new functionality, or H.248.17 needs to be amended to include >>> > new "extended" continuity package Commends? Suggestions? >>> > >>> > Aleks >>> > >>> > At 01:14 AM 4/29/2004, Zhao Bo wrote: >>> > >>> >> Can H.248.17 "line test packages" be used to test these circuits? >>> >> >>> >> ----- Original Message ----- >>> >> From: Aleksandr Ryabin >>> >> To: Kevin Boyle ; >>> >> megaco@ietf.org >>> >> Sent: Thursday, April 29, 2004 2:11 AM >>> >> Subject: RE: [Megaco] Continuity tests >>> >> >>> >> Yes, the type of test depends on what a circuit is connected to. >>> >> >>> >> But, I was actually coming from the view that MGC "controls" MG >>> >> and as such only MGC should have knowledge on what test to execute >>> >> (i.e. what is connected to the other side of a circuit). >>> >> >>> >> If this information is left in MG, then each circuit has to be >>> >> provisioned >>> >> with that information such that MG can make intelligent decision >>> >> on what >>> >> type of test to execute. Thus every time a circuit connection is >>> >> changed, >>> >> directly or indirectly, MG circuit needs to be re-provisioned. >>> >> >>> >> I think that configuration should be kept on MGC and the decision >>> >> should >>> >> come from MGC instead. >>> >> >>> >> Aleks >>> >> >>> >> At 02:30 PM 4/28/2004, Kevin Boyle wrote: >>> >> >>> >>> Is it possible to run more than one kind of continuity test >>> >>> on a particular circuit? If no, then the provisioning model >>> >>> holds and there is no need for a change. If yes, then we may >>> >>> need to add something to the package to allow selection of a >>> >>> ct test type. >>> >>> >>> >>> Kevin >>> >>> >>> >>> -----Original Message----- >>> >>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>> >>> Sent: Wednesday, April 28, 2004 1:21 PM >>> >>> To: megaco@ietf.org >>> >>> Subject: [Megaco] Continuity tests >>> >>> >>> >>> Hi, >>> >>> >>> >>> There are several continuity test types (i.e 2-wire, 4-wire, >>> >>> etc) While provisioning of physical test parameters (i.e. >>> >>> frequencies, sequence, timeouts, etc) in MG makes sense, IMHO >>> >>> choosing a type of continuity test seem logical to be left to >>> >>> MGC. >>> >>> >>> >>> Basic Continuity Package (ct) does not allow to choose the >>> >>> type of a test. >>> >>> It implies that type of a test is provisioned on MG (per >>> >>> termination?) >>> >>> >>> >>> Is there another (extended) continuity test package which >>> >>> allows MGC to choose the type of a continuity test to be >>> >>> performed? >>> >>> >>> >>> If not, does anyone see a need to have such a package? >>> >>> Comments? >>> >>> >>> >>> Thanks >>> >>> Aleks >>> >>> >>> >>> _______________________________________________ >>> >>> Megaco mailing list >>> >>> Megaco@ietf.org >>> >>> https://www1.ietf.org/mailman/listinfo/megaco >>> >> _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon May 3 10:55:17 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06375 for ; Mon, 3 May 2004 10:55:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKej7-0007aD-JW for megaco-archive@odin.ietf.org; Mon, 03 May 2004 10:47:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43ElPah029142 for megaco-archive@odin.ietf.org; Mon, 3 May 2004 10:47:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKeef-0006MN-Bj for megaco-web-archive@optimus.ietf.org; Mon, 03 May 2004 10:42:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05740 for ; Mon, 3 May 2004 10:42:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKeec-0005mf-VJ for megaco-web-archive@ietf.org; Mon, 03 May 2004 10:42:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKedi-0005jx-00 for megaco-web-archive@ietf.org; Mon, 03 May 2004 10:41:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKedR-0005gy-00 for megaco-web-archive@ietf.org; Mon, 03 May 2004 10:41:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKeNk-0001zu-Ci; Mon, 03 May 2004 10:25:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKeKn-0000iN-Fl for megaco@optimus.ietf.org; Mon, 03 May 2004 10:22:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04343 for ; Mon, 3 May 2004 10:22:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKeKl-0004aV-3S for megaco@ietf.org; Mon, 03 May 2004 10:22:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKeHz-00048L-00 for megaco@ietf.org; Mon, 03 May 2004 10:19:24 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1BKeCg-0003Ep-00 for megaco@ietf.org; Mon, 03 May 2004 10:13:54 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id i43EDokh006107; Mon, 3 May 2004 07:13:50 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i43ECKTW003165; Mon, 3 May 2004 09:12:28 -0500 Message-Id: <5.2.1.1.0.20040503100320.00b13420@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 03 May 2004 10:11:21 -0400 To: "Alf Heidermark (AS/EAB)" , megaco@ietf.org From: Aleksandr Ryabin Subject: RE: [Megaco] Continuity tests In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5630A39@ESEALNT442.al.sw.er icsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Hi Alf, I'm not talking about old networks. With old networks everything stays the same. In order to maintain backward compatibility there always will be "intelligent" switches sitting on border with old networks, which are capable of doing COT. But new networks can utilize new (cheap) solutions and as such new "intelligent" switches need to be capable of the functionality in question. Regards, Aleks At 02:41 AM 5/3/2004, Alf Heidermark (AS/EAB) wrote: >Hello Alexandr > >Continuity check is in service on many old exchanges. Do you really mean >that they shall change their impleentations to be able to interwork with >the dumb switch. Normally it is up to new equipment to interwork existing >network nodes. From this resoning I cannot see any reason to change >anything in H.248 to continuity check. > >alf > >-----Original Message----- >From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of >Aleksandr Ryabin >Sent: den 30 april 2004 16:39 >To: Christian Groves (MC/EPA); megaco@ietf.org >Cc: Kevin Boyle; Tom-PT Taylor >Subject: Re: [Megaco] Continuity tests > > >Hi Christian, > >There could be "dumb" switches in the middle of the path >(for example DACS) which are not capable of any testing/signalling. >Their only role is to split/redirect links and as such the nature >of a circuit can change, and thus the type of COT test. > >Regards, > Aleks > >At 08:17 PM 4/29/2004, Christian Groves wrote: > >Hello Aleksandr, > > > >Is this really a problem? The Continuity test is a link by link procedure > >not an end to end procedure. I tend to support Kevin and Tom on this one. > > > >Regards, Christian > > > >Aleksandr Ryabin wrote: > >>Kevin, exactly, the type of COT test does not only depend on the physical > >>details of a termination the MGC controls, but also on physical > >>details of circuit which *eventually* is connected to that termination. > >>My point is that the final far-end *final* connection can change without > >>a change to immediate connection to MG termination and only MGC > >>would know about it. > >>For example, if MG is digital trunking gateway, it does not mean that > >>only pure 4-wire tests will be used all the time. If the other side > connected > >>trough set of intermediate switches and finally lands at the time of > the test > >>say on analog 2-wire circuit then the test to be executed is 2-wire test. > >>I guess it is possible to somehow tie up configuration of MG termination > >>dynamically to changes which happens to those intermediate switches, > >>but it does not seem right. On the contrary, that information would come to > >>MGC naturally, since it is a controlling element. > >>Also putting a burden of configuring of a test type per every single > >>termination seems to be too much for MG, especially if we are talking > >>about high density MGs which handle hundred thousands terminations. > >>BTW This is a real problem we run into in our MGC implementation and > >>are trying to solve. I thought that instead of having a proprietary package > >>I might as well give it a shot to see if there is any interest to make the > >>solution public instead. > >>Thanks. > >> Aleks > >>At 11:23 AM 4/29/2004, Kevin Boyle wrote: > >> > >>>I agree with Tom. The fact that the circuit is connected to a single > >>>entity means that only a single type of continuity test is actually > >>>valid. MGs are expected to know how to handle their terminations. > >>>Who the termination is connected to is certainly part of that > >>>handling. Because the far-end connection changes the nature of the > >>>termination, this becomes an MG-knowledge problem. > >>> > >>>I believe the package is fine as it stands, and the MG should know what > >>>"run a continuity test" means for its terminations. > >>> > >>>Kevin > >>> > >>>-----Original Message----- > >>>From: Taylor, Tom-PT [CAR:5N00:EXCH] > >>>Sent: Thursday, April 29, 2004 11:19 AM > >>>To: Aleksandr Ryabin > >>>Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org > >>>Subject: Re: [Megaco] Continuity tests > >>> > >>>I for one disagree with your philosophy. I think the physical details > >>>of the termination should be provisioned in the MG rather than the the > >>>MGC. However, I have no direct implementation responsibility, so I > >>>should let those who do speak up. > >>> > >>>Aleksandr Ryabin wrote: > >>> > >>> > Packages defined in H.248.17 do not cover continuity tests. > >>> > > >>> > If the experts agree that MGC should be able to control type of > >>> > continuity test then ether basic ct package needs to be amended to > >>> > include new functionality, or H.248.17 needs to be amended to include > >>> > new "extended" continuity package Commends? Suggestions? > >>> > > >>> > Aleks > >>> > > >>> > At 01:14 AM 4/29/2004, Zhao Bo wrote: > >>> > > >>> >> Can H.248.17 "line test packages" be used to test these circuits? > >>> >> > >>> >> ----- Original Message ----- > >>> >> From: Aleksandr Ryabin > >>> >> To: Kevin Boyle ; > >>> >> megaco@ietf.org > >>> >> Sent: Thursday, April 29, 2004 2:11 AM > >>> >> Subject: RE: [Megaco] Continuity tests > >>> >> > >>> >> Yes, the type of test depends on what a circuit is connected to. > >>> >> > >>> >> But, I was actually coming from the view that MGC "controls" MG > >>> >> and as such only MGC should have knowledge on what test to execute > >>> >> (i.e. what is connected to the other side of a circuit). > >>> >> > >>> >> If this information is left in MG, then each circuit has to be > >>> >> provisioned > >>> >> with that information such that MG can make intelligent decision > >>> >> on what > >>> >> type of test to execute. Thus every time a circuit connection is > >>> >> changed, > >>> >> directly or indirectly, MG circuit needs to be re-provisioned. > >>> >> > >>> >> I think that configuration should be kept on MGC and the decision > >>> >> should > >>> >> come from MGC instead. > >>> >> > >>> >> Aleks > >>> >> > >>> >> At 02:30 PM 4/28/2004, Kevin Boyle wrote: > >>> >> > >>> >>> Is it possible to run more than one kind of continuity test > >>> >>> on a particular circuit? If no, then the provisioning model > >>> >>> holds and there is no need for a change. If yes, then we may > >>> >>> need to add something to the package to allow selection of a > >>> >>> ct test type. > >>> >>> > >>> >>> Kevin > >>> >>> > >>> >>> -----Original Message----- > >>> >>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] > >>> >>> Sent: Wednesday, April 28, 2004 1:21 PM > >>> >>> To: megaco@ietf.org > >>> >>> Subject: [Megaco] Continuity tests > >>> >>> > >>> >>> Hi, > >>> >>> > >>> >>> There are several continuity test types (i.e 2-wire, 4-wire, > >>> >>> etc) While provisioning of physical test parameters (i.e. > >>> >>> frequencies, sequence, timeouts, etc) in MG makes sense, IMHO > >>> >>> choosing a type of continuity test seem logical to be left to > >>> >>> MGC. > >>> >>> > >>> >>> Basic Continuity Package (ct) does not allow to choose the > >>> >>> type of a test. > >>> >>> It implies that type of a test is provisioned on MG (per > >>> >>> termination?) > >>> >>> > >>> >>> Is there another (extended) continuity test package which > >>> >>> allows MGC to choose the type of a continuity test to be > >>> >>> performed? > >>> >>> > >>> >>> If not, does anyone see a need to have such a package? > >>> >>> Comments? > >>> >>> > >>> >>> Thanks > >>> >>> Aleks > >>> >>> > >>> >>> _______________________________________________ > >>> >>> Megaco mailing list > >>> >>> Megaco@ietf.org > >>> >>> https://www1.ietf.org/mailman/listinfo/megaco > >>> >> > > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon May 3 18:45:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09461 for ; Mon, 3 May 2004 18:45:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKm0f-0001ij-4W; Mon, 03 May 2004 18:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKlt0-0008Bz-0z for megaco@optimus.ietf.org; Mon, 03 May 2004 18:26:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08621 for ; Mon, 3 May 2004 18:26:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKlsx-0005Up-06 for megaco@ietf.org; Mon, 03 May 2004 18:26:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKls1-0005Nl-00 for megaco@ietf.org; Mon, 03 May 2004 18:25:06 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BKlrT-0005Du-00 for megaco@ietf.org; Mon, 03 May 2004 18:24:31 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i43MNta03665 for ; Mon, 3 May 2004 18:23:55 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 May 2004 18:23:56 -0400 Message-ID: From: "Kevin Boyle" To: Aleksandr Ryabin , "Alf Heidermark (AS/EAB)" , megaco@ietf.org Subject: RE: [Megaco] Continuity tests Date: Mon, 3 May 2004 18:23:54 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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: , Right. New switches need to be able to provide the same function as the old switches. I am still not seeing the problem here. If the new switches need to provide the same function as the old switches, then that implies that these "middleswitches" have to do COT. Customers are not going to tolerate lack of basic function. It seems to me that the inability to do COT will limit the deployment of any of these "new cheap" boxes. Kevin -----Original Message----- From: Aleksandr Ryabin [mailto:kengr@motorola.com] Sent: Monday, May 03, 2004 10:11 AM To: Alf Heidermark (AS/EAB); megaco@ietf.org Subject: RE: [Megaco] Continuity tests Hi Alf, I'm not talking about old networks. With old networks everything stays the same. In order to maintain backward compatibility there always will be "intelligent" switches sitting on border with old networks, which are capable of doing COT. But new networks can utilize new (cheap) solutions and as such new "intelligent" switches need to be capable of the functionality in question. Regards, Aleks At 02:41 AM 5/3/2004, Alf Heidermark (AS/EAB) wrote: >Hello Alexandr > >Continuity check is in service on many old exchanges. Do you really >mean that they shall change their impleentations to be able to >interwork with the dumb switch. Normally it is up to new equipment to >interwork existing network nodes. From this resoning I cannot see any >reason to change anything in H.248 to continuity check. > >alf > >-----Original Message----- >From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of >Aleksandr Ryabin >Sent: den 30 april 2004 16:39 >To: Christian Groves (MC/EPA); megaco@ietf.org >Cc: Kevin Boyle; Tom-PT Taylor >Subject: Re: [Megaco] Continuity tests > > >Hi Christian, > >There could be "dumb" switches in the middle of the path (for example >DACS) which are not capable of any testing/signalling. >Their only role is to split/redirect links and as such the nature of a >circuit can change, and thus the type of COT test. > >Regards, > Aleks > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon May 3 18:59:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10142 for ; Mon, 3 May 2004 18:59:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKmNF-0007ga-ED for megaco-archive@odin.ietf.org; Mon, 03 May 2004 18:57:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43MvLi2029545 for megaco-archive@odin.ietf.org; Mon, 3 May 2004 18:57:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKmDK-00052u-Bu for megaco-web-archive@optimus.ietf.org; Mon, 03 May 2004 18:47:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09535 for ; Mon, 3 May 2004 18:47:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKmDH-0000Fh-At for megaco-web-archive@ietf.org; Mon, 03 May 2004 18:47:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKmCG-00007r-00 for megaco-web-archive@ietf.org; Mon, 03 May 2004 18:46:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKmBk-00000f-00 for megaco-web-archive@ietf.org; Mon, 03 May 2004 18:45:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKm0f-0001ij-4W; Mon, 03 May 2004 18:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKlt0-0008Bz-0z for megaco@optimus.ietf.org; Mon, 03 May 2004 18:26:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08621 for ; Mon, 3 May 2004 18:26:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKlsx-0005Up-06 for megaco@ietf.org; Mon, 03 May 2004 18:26:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKls1-0005Nl-00 for megaco@ietf.org; Mon, 03 May 2004 18:25:06 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BKlrT-0005Du-00 for megaco@ietf.org; Mon, 03 May 2004 18:24:31 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i43MNta03665 for ; Mon, 3 May 2004 18:23:55 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 May 2004 18:23:56 -0400 Message-ID: From: "Kevin Boyle" To: Aleksandr Ryabin , "Alf Heidermark (AS/EAB)" , megaco@ietf.org Subject: RE: [Megaco] Continuity tests Date: Mon, 3 May 2004 18:23:54 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Right. New switches need to be able to provide the same function as the old switches. I am still not seeing the problem here. If the new switches need to provide the same function as the old switches, then that implies that these "middleswitches" have to do COT. Customers are not going to tolerate lack of basic function. It seems to me that the inability to do COT will limit the deployment of any of these "new cheap" boxes. Kevin -----Original Message----- From: Aleksandr Ryabin [mailto:kengr@motorola.com] Sent: Monday, May 03, 2004 10:11 AM To: Alf Heidermark (AS/EAB); megaco@ietf.org Subject: RE: [Megaco] Continuity tests Hi Alf, I'm not talking about old networks. With old networks everything stays the same. In order to maintain backward compatibility there always will be "intelligent" switches sitting on border with old networks, which are capable of doing COT. But new networks can utilize new (cheap) solutions and as such new "intelligent" switches need to be capable of the functionality in question. Regards, Aleks At 02:41 AM 5/3/2004, Alf Heidermark (AS/EAB) wrote: >Hello Alexandr > >Continuity check is in service on many old exchanges. Do you really >mean that they shall change their impleentations to be able to >interwork with the dumb switch. Normally it is up to new equipment to >interwork existing network nodes. From this resoning I cannot see any >reason to change anything in H.248 to continuity check. > >alf > >-----Original Message----- >From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of >Aleksandr Ryabin >Sent: den 30 april 2004 16:39 >To: Christian Groves (MC/EPA); megaco@ietf.org >Cc: Kevin Boyle; Tom-PT Taylor >Subject: Re: [Megaco] Continuity tests > > >Hi Christian, > >There could be "dumb" switches in the middle of the path (for example >DACS) which are not capable of any testing/signalling. >Their only role is to split/redirect links and as such the nature of a >circuit can change, and thus the type of COT test. > >Regards, > Aleks > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue May 4 10:33:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04703 for ; Tue, 4 May 2004 10:33:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0rz-0003Lc-7q; Tue, 04 May 2004 10:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0ph-0002pT-77 for megaco@optimus.ietf.org; Tue, 04 May 2004 10:23:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04058 for ; Tue, 4 May 2004 10:23:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL0pe-0005T9-QI for megaco@ietf.org; Tue, 04 May 2004 10:23:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL0oi-0005PV-00 for megaco@ietf.org; Tue, 04 May 2004 10:22:41 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1BL0oO-0005MN-00 for megaco@ietf.org; Tue, 04 May 2004 10:22:20 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i44EMKYg023267 for ; Tue, 4 May 2004 07:22:20 -0700 (MST) Received: from il06exm13.corp.mot.com (il06exm13.corp.mot.com [10.0.111.13]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i44EKiTV007954 for ; Tue, 4 May 2004 09:21:04 -0500 Received: by il06exm13 with Internet Mail Service (5.5.2657.72) id <2A7BFMKP>; Tue, 4 May 2004 09:21:52 -0500 Message-ID: From: Ryabin Aleksandr-A19776 To: "'Kevin Boyle'" , "Alf Heidermark (AS/EAB)" , megaco@ietf.org Subject: RE: [Megaco] Continuity tests Date: Tue, 4 May 2004 09:21:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C431E3.238F255C" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.8 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TAG_BALANCE_BODY, HTML_TAG_BALANCE_HTML,MIME_BASE64_TEXT,MIME_HTML_NO_CHARSET autolearn=no version=2.60 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_01C431E3.238F255C Content-Type: text/plain New switches need to be able to provide at least the same functions as old switches. "At least" here is a key word. They also will have more functions. One of the new functions is to be able to work with "dumb" switches not capable of COT. The control protocol in use for these new switches is not there to address marketing needs, but to address functional needs. As such it has to have the ability to allow MGC to solve this functional issue. As I indicated before this is real life issue we run into and need to address. My intent here is to simply bring the issue up to standartization community such that no private extention created to address the issue. If standartization community feels that this is an implementaion issue then we will deal with it as such. Regards, Aleks -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] Sent: Monday, May 03, 2004 6:24 PM To: Aleksandr Ryabin; Alf Heidermark (AS/EAB); megaco@ietf.org Subject: RE: [Megaco] Continuity tests Right. New switches need to be able to provide the same function as the old switches. I am still not seeing the problem here. If the new switches need to provide the same function as the old switches, then that implies that these "middleswitches" have to do COT. Customers are not going to tolerate lack of basic function. It seems to me that the inability to do COT will limit the deployment of any of these "new cheap" boxes. Kevin -----Original Message----- From: Aleksandr Ryabin [ mailto:kengr@motorola.com ] Sent: Monday, May 03, 2004 10:11 AM To: Alf Heidermark (AS/EAB); megaco@ietf.org Subject: RE: [Megaco] Continuity tests Hi Alf, I'm not talking about old networks. With old networks everything stays the same. In order to maintain backward compatibility there always will be "intelligent" switches sitting on border with old networks, which are capable of doing COT. But new networks can utilize new (cheap) solutions and as such new "intelligent" switches need to be capable of the functionality in question. Regards, Aleks At 02:41 AM 5/3/2004, Alf Heidermark (AS/EAB) wrote: >Hello Alexandr > >Continuity check is in service on many old exchanges. Do you really >mean that they shall change their impleentations to be able to >interwork with the dumb switch. Normally it is up to new equipment to >interwork existing network nodes. From this resoning I cannot see any >reason to change anything in H.248 to continuity check. > >alf > >-----Original Message----- >From: megaco-admin@ietf.org [ mailto:megaco-admin@ietf.org ]On Behalf Of >Aleksandr Ryabin >Sent: den 30 april 2004 16:39 >To: Christian Groves (MC/EPA); megaco@ietf.org >Cc: Kevin Boyle; Tom-PT Taylor >Subject: Re: [Megaco] Continuity tests > > >Hi Christian, > >There could be "dumb" switches in the middle of the path (for example >DACS) which are not capable of any testing/signalling. >Their only role is to split/redirect links and as such the nature of a >circuit can change, and thus the type of COT test. > >Regards, > Aleks > ------_=_NextPart_001_01C431E3.238F255C Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPlJFOiBbTWVnYWNvXSBD b250aW51aXR5IHRlc3RzPC9USVRMRT4NCg0KPE1FVEEgY29udGVudD0iTVNIVE1MIDYuMDAuMjgw MC4xNDAwIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWT4NCjxESVY+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiBjbGFzcz04MTQzNjA3MTQtMDQwNTIwMDQ+ TmV3IA0Kc3dpdGNoZXMgbmVlZCB0byBiZSBhYmxlIHRvIHByb3ZpZGUgYXQgbGVhc3QgdGhlIHNh bWUgZnVuY3Rpb25zIGFzIG9sZCANCnN3aXRjaGVzLjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gY2xhc3M9ODE0MzYw NzE0LTA0MDUyMDA0PiJBdCANCmxlYXN0IiBoZXJlIGlzIGEga2V5IHdvcmQuIFRoZXkgYWxzbyB3 aWxsIGhhdmUgbW9yZSANCmZ1bmN0aW9ucy48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIGNsYXNzPTgxNDM2MDcxNC0w NDA1MjAwND5PbmUgb2YgDQp0aGUgbmV3IGZ1bmN0aW9ucyBpcyB0byBiZSBhYmxlIHRvIHdvcmsg d2l0aCAiZHVtYiIgc3dpdGNoZXMgPC9TUEFOPjwvRk9OVD48Rk9OVCANCmZhY2U9QXJpYWwgY29s b3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gY2xhc3M9ODE0MzYwNzE0LTA0MDUyMDA0Pm5vdCBjYXBh YmxlIG9mIA0KQ09ULjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQpjbGFzcz04MTQzNjA3MTQtMDQwNTIwMDQ+PC9T UEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAw MGZmIHNpemU9Mj48U1BBTiBjbGFzcz04MTQzNjA3MTQtMDQwNTIwMDQ+VGhlIA0KY29udHJvbCBw cm90b2NvbCBpbiB1c2UgZm9yIHRoZXNlIG5ldyBzd2l0Y2hlcyBpcyBub3QgdGhlcmUgdG8gYWRk cmVzcyBtYXJrZXRpbmcgDQpuZWVkcyw8L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIGNsYXNzPTgxNDM2MDcxNC0wNDA1 MjAwND5idXQgdG8gDQphZGRyZXNzIGZ1bmN0aW9uYWwgbmVlZHMuIEFzIHN1Y2ggaXQgaGFzIHRv IGhhdmUgdGhlIGFiaWxpdHkgdG8gYWxsb3cgTUdDIHRvIA0Kc29sdmUgPC9TUEFOPjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiBj bGFzcz04MTQzNjA3MTQtMDQwNTIwMDQ+dGhpcyANCmZ1bmN0aW9uYWwgaXNzdWUuPC9TUEFOPjwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48 U1BBTiANCmNsYXNzPTgxNDM2MDcxNC0wNDA1MjAwND48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIGNsYXNz PTgxNDM2MDcxNC0wNDA1MjAwND5BcyBJIA0KaW5kaWNhdGVkIGJlZm9yZSB0aGlzIGlzIHJlYWwg bGlmZSBpc3N1ZSB3ZSBydW4gaW50byBhbmQgbmVlZCB0byANCmFkZHJlc3MuPC9TUEFOPjwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BB TiBjbGFzcz04MTQzNjA3MTQtMDQwNTIwMDQ+TXkgDQppbnRlbnQgaGVyZSBpcyZuYnNwO3RvIHNp bXBseSBicmluZyB0aGUgaXNzdWUmbmJzcDt1cCB0byBzdGFuZGFydGl6YXRpb24gDQpjb21tdW5p dHk8L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAw ZmYgc2l6ZT0yPjxTUEFOIGNsYXNzPTgxNDM2MDcxNC0wNDA1MjAwND5zdWNoIA0KdGhhdCBubyBw cml2YXRlIGV4dGVudGlvbiBjcmVhdGVkIHRvIGFkZHJlc3MgdGhlIGlzc3VlLjwvU1BBTj48L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQ QU4gY2xhc3M9ODE0MzYwNzE0LTA0MDUyMDA0PklmIA0Kc3RhbmRhcnRpemF0aW9uIGNvbW11bml0 eSBmZWVscyB0aGF0IHRoaXMgaXMgYW4gaW1wbGVtZW50YWlvbiANCmlzc3VlPC9TUEFOPjwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BB TiBjbGFzcz04MTQzNjA3MTQtMDQwNTIwMDQ+dGhlbiANCndlIHdpbGwgZGVhbCB3aXRoIGl0IGFz IHN1Y2guPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmIHNpemU9Mj48U1BBTiANCmNsYXNzPTgxNDM2MDcxNC0wNDA1MjAwND48L1NQQU4+PC9G T05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6 ZT0yPjxTUEFOIA0KY2xhc3M9ODE0MzYwNzE0LTA0MDUyMDA0PlJlZ2FyZHMsPC9TUEFOPjwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BB TiANCmNsYXNzPTgxNDM2MDcxNC0wNDA1MjAwND4mbmJzcDsmbmJzcDsmbmJzcDsgQWxla3M8L1NQ QU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6 ZT0yPjxTUEFOIA0KY2xhc3M9ODE0MzYwNzE0LTA0MDUyMDA0PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8QkxPQ0tRVU9URSBkaXI9bHRyIHN0eWxlPSJNQVJHSU4tUklHSFQ6IDBweCI+DQog IDxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgZGlyPWx0ciBhbGlnbj1sZWZ0PjxGT05U IGZhY2U9VGFob21hIA0KICBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+PEI+ RnJvbTo8L0I+IEtldmluIEJveWxlIA0KICBbbWFpbHRvOmtib3lsZUBub3J0ZWxuZXR3b3Jrcy5j b21dPEJSPjxCPlNlbnQ6PC9CPiBNb25kYXksIE1heSAwMywgMjAwNCA2OjI0IA0KICBQTTxCUj48 Qj5Ubzo8L0I+IEFsZWtzYW5kciBSeWFiaW47IEFsZiBIZWlkZXJtYXJrIChBUy9FQUIpOyANCiAg bWVnYWNvQGlldGYub3JnPEJSPjxCPlN1YmplY3Q6PC9CPiBSRTogW01lZ2Fjb10gQ29udGludWl0 eSANCiAgdGVzdHM8QlI+PEJSPjwvRk9OVD48L0RJVj4NCiAgPFA+PEZPTlQgc2l6ZT0yPlJpZ2h0 LiZuYnNwOyBOZXcgc3dpdGNoZXMgbmVlZCB0byBiZSBhYmxlIHRvIHByb3ZpZGUgdGhlIHNhbWUg DQogIGZ1bmN0aW9uIGFzIHRoZSBvbGQgc3dpdGNoZXMuPC9GT05UPiA8L1A+DQogIDxQPjxGT05U IHNpemU9Mj5JIGFtIHN0aWxsIG5vdCBzZWVpbmcgdGhlIHByb2JsZW0gaGVyZS4gSWYgdGhlIG5l dyBzd2l0Y2hlcyANCiAgbmVlZCB0byBwcm92aWRlIHRoZSBzYW1lIGZ1bmN0aW9uIGFzIHRoZSBv bGQgc3dpdGNoZXMsIHRoZW4gdGhhdCBpbXBsaWVzIHRoYXQgDQogIHRoZXNlICJtaWRkbGVzd2l0 Y2hlcyIgaGF2ZSB0byBkbyBDT1QuJm5ic3A7IEN1c3RvbWVycyBhcmUgbm90IGdvaW5nIHRvIA0K ICB0b2xlcmF0ZSBsYWNrIG9mIGJhc2ljIGZ1bmN0aW9uLjwvRk9OVD48L1A+DQogIDxQPjxGT05U IHNpemU9Mj5JdCBzZWVtcyB0byBtZSB0aGF0IHRoZSBpbmFiaWxpdHkgdG8gZG8gQ09UIHdpbGwg bGltaXQgdGhlIA0KICBkZXBsb3ltZW50IG9mIGFueSBvZiB0aGVzZSAibmV3IGNoZWFwIiBib3hl cy48L0ZPTlQ+IDwvUD4NCiAgPFA+PEZPTlQgc2l6ZT0yPktldmluPC9GT05UPiA8L1A+DQogIDxQ PjxGT05UIHNpemU9Mj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD4gPEJSPjxGT05U IHNpemU9Mj5Gcm9tOiANCiAgQWxla3NhbmRyIFJ5YWJpbiBbPEEgDQogIGhyZWY9Im1haWx0bzpr ZW5nckBtb3Rvcm9sYS5jb20iPm1haWx0bzprZW5nckBtb3Rvcm9sYS5jb208L0E+XSANCiAgPC9G T05UPjxCUj48Rk9OVCBzaXplPTI+U2VudDogTW9uZGF5LCBNYXkgMDMsIDIwMDQgMTA6MTEgQU08 L0ZPTlQ+IDxCUj48Rk9OVCANCiAgc2l6ZT0yPlRvOiBBbGYgSGVpZGVybWFyayAoQVMvRUFCKTsg bWVnYWNvQGlldGYub3JnPC9GT05UPiA8QlI+PEZPTlQgDQogIHNpemU9Mj5TdWJqZWN0OiBSRTog W01lZ2Fjb10gQ29udGludWl0eSB0ZXN0czwvRk9OVD4gPC9QPg0KICA8UD48Rk9OVCBzaXplPTI+ SGkgQWxmLDwvRk9OVD4gPC9QPg0KICA8UD48Rk9OVCBzaXplPTI+SSdtIG5vdCB0YWxraW5nIGFi b3V0IG9sZCBuZXR3b3Jrcy4gV2l0aCBvbGQgbmV0d29ya3MgDQogIGV2ZXJ5dGhpbmcgc3RheXMg dGhlIHNhbWUuPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPkluIG9yZGVyIHRvIG1haW50YWluIA0K ICBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHRoZXJlIGFsd2F5cyB3aWxsIGJlICJpbnRlbGxpZ2Vu dCI8L0ZPTlQ+IDxCUj48Rk9OVCANCiAgc2l6ZT0yPnN3aXRjaGVzIHNpdHRpbmcgb24gYm9yZGVy IHdpdGggb2xkIG5ldHdvcmtzLCB3aGljaCBhcmUgY2FwYWJsZSBvZiANCiAgZG9pbmcgQ09ULjwv Rk9OVD4gPC9QPg0KICA8UD48Rk9OVCBzaXplPTI+QnV0IG5ldyBuZXR3b3JrcyBjYW4gdXRpbGl6 ZSBuZXcgKGNoZWFwKSBzb2x1dGlvbnMgYW5kIGFzIHN1Y2ggDQogIG5ldyAiaW50ZWxsaWdlbnQi IHN3aXRjaGVzIG5lZWQgdG8gYmUgY2FwYWJsZSBvZiB0aGUgZnVuY3Rpb25hbGl0eSBpbiANCiAg cXVlc3Rpb24uPC9GT05UPjwvUD4NCiAgPFA+PEZPTlQgc2l6ZT0yPlJlZ2FyZHMsPC9GT05UPiA8 QlI+PEZPTlQgDQogIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgQWxla3M8L0ZPTlQ+IDwvUD4NCiAgPFA+PEZPTlQgc2l6ZT0yPkF0IDAyOjQx IEFNIDUvMy8yMDA0LCBBbGYgSGVpZGVybWFyayAoQVMvRUFCKSB3cm90ZTo8L0ZPTlQ+IA0KICA8 QlI+PEZPTlQgc2l6ZT0yPiZndDtIZWxsbyBBbGV4YW5kcjwvRk9OVD4gPEJSPjxGT05UIHNpemU9 Mj4mZ3Q7PC9GT05UPiANCiAgPEJSPjxGT05UIHNpemU9Mj4mZ3Q7Q29udGludWl0eSBjaGVjayBp cyBpbiBzZXJ2aWNlIG9uIG1hbnkgb2xkIGV4Y2hhbmdlcy4gRG8gDQogIHlvdSByZWFsbHkgPC9G T05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0O21lYW4gdGhhdCB0aGV5IHNoYWxsIGNoYW5nZSB0aGVp ciANCiAgaW1wbGVlbnRhdGlvbnMgdG8gYmUgYWJsZSB0byA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9 Mj4mZ3Q7aW50ZXJ3b3JrIHdpdGggdGhlIA0KICBkdW1iIHN3aXRjaC4gTm9ybWFsbHkgaXQgaXMg dXAgdG8gbmV3IGVxdWlwbWVudCB0byA8L0ZPTlQ+PEJSPjxGT05UIA0KICBzaXplPTI+Jmd0O2lu dGVyd29yayBleGlzdGluZyBuZXR3b3JrIG5vZGVzLiBGcm9tIHRoaXMgcmVzb25pbmcgSSBjYW5u b3Qgc2VlIA0KICBhbnkgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0O3JlYXNvbiB0byBjaGFu Z2UgYW55dGhpbmcgaW4gSC4yNDggdG8gDQogIGNvbnRpbnVpdHkgY2hlY2suPC9GT05UPiA8QlI+ PEZPTlQgc2l6ZT0yPiZndDs8L0ZPTlQ+IDxCUj48Rk9OVCANCiAgc2l6ZT0yPiZndDthbGY8L0ZP TlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OzwvRk9OVD4gPEJSPjxGT05UIA0KICBzaXplPTI+Jmd0 Oy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDtG cm9tOiANCiAgbWVnYWNvLWFkbWluQGlldGYub3JnIFs8QSANCiAgaHJlZj0ibWFpbHRvOm1lZ2Fj by1hZG1pbkBpZXRmLm9yZyI+bWFpbHRvOm1lZ2Fjby1hZG1pbkBpZXRmLm9yZzwvQT5dT24gQmVo YWxmIA0KICBPZiA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7QWxla3NhbmRyIFJ5YWJpbjwv Rk9OVD4gPEJSPjxGT05UIA0KICBzaXplPTI+Jmd0O1NlbnQ6IGRlbiAzMCBhcHJpbCAyMDA0IDE2 OjM5PC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDtUbzogDQogIENocmlzdGlhbiBHcm92ZXMg KE1DL0VQQSk7IG1lZ2Fjb0BpZXRmLm9yZzwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7Q2M6 IA0KICBLZXZpbiBCb3lsZTsgVG9tLVBUIFRheWxvcjwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4m Z3Q7U3ViamVjdDogUmU6IFtNZWdhY29dIA0KICBDb250aW51aXR5IHRlc3RzPC9GT05UPiA8QlI+ PEZPTlQgc2l6ZT0yPiZndDs8L0ZPTlQ+IDxCUj48Rk9OVCANCiAgc2l6ZT0yPiZndDs8L0ZPTlQ+ IDxCUj48Rk9OVCBzaXplPTI+Jmd0O0hpIENocmlzdGlhbiw8L0ZPTlQ+IDxCUj48Rk9OVCANCiAg c2l6ZT0yPiZndDs8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0O1RoZXJlIGNvdWxkIGJlICJk dW1iIiBzd2l0Y2hlcyBpbiB0aGUgDQogIG1pZGRsZSBvZiB0aGUgcGF0aCAoZm9yIGV4YW1wbGUg PC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0O0RBQ1MpIHdoaWNoIGFyZSANCiAgbm90IGNhcGFi bGUgb2YgYW55IHRlc3Rpbmcvc2lnbmFsbGluZy48L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0 O1RoZWlyIG9ubHkgDQogIHJvbGUgaXMgdG8gc3BsaXQvcmVkaXJlY3QgbGlua3MgYW5kIGFzIHN1 Y2ggdGhlIG5hdHVyZSBvZiBhIDwvRk9OVD48QlI+PEZPTlQgDQogIHNpemU9Mj4mZ3Q7Y2lyY3Vp dCBjYW4gY2hhbmdlLCBhbmQgdGh1cyB0aGUgdHlwZSBvZiBDT1QgdGVzdC48L0ZPTlQ+IDxCUj48 Rk9OVCANCiAgc2l6ZT0yPiZndDs8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0O1JlZ2FyZHMs PC9GT05UPiA8QlI+PEZPTlQgDQogIHNpemU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFsZWtzPC9GT05UPiANCiAgPEJSPjxGT05U IHNpemU9Mj4mZ3Q7PC9GT05UPiA8L1A+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= ------_=_NextPart_001_01C431E3.238F255C-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Tue May 4 10:43:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05634 for ; Tue, 4 May 2004 10:43:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL159-0007DW-Ol for megaco-archive@odin.ietf.org; Tue, 04 May 2004 10:39:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44Eddls027742 for megaco-archive@odin.ietf.org; Tue, 4 May 2004 10:39:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL10H-0005bY-1e for megaco-web-archive@optimus.ietf.org; Tue, 04 May 2004 10:34:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04730 for ; Tue, 4 May 2004 10:34:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL10E-0006A7-Nj for megaco-web-archive@ietf.org; Tue, 04 May 2004 10:34:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL0zF-00067G-00 for megaco-web-archive@ietf.org; Tue, 04 May 2004 10:33:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL0yh-00065B-00 for megaco-web-archive@ietf.org; Tue, 04 May 2004 10:32:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0rz-0003Lc-7q; Tue, 04 May 2004 10:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0ph-0002pT-77 for megaco@optimus.ietf.org; Tue, 04 May 2004 10:23:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04058 for ; Tue, 4 May 2004 10:23:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL0pe-0005T9-QI for megaco@ietf.org; Tue, 04 May 2004 10:23:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL0oi-0005PV-00 for megaco@ietf.org; Tue, 04 May 2004 10:22:41 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1BL0oO-0005MN-00 for megaco@ietf.org; Tue, 04 May 2004 10:22:20 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i44EMKYg023267 for ; Tue, 4 May 2004 07:22:20 -0700 (MST) Received: from il06exm13.corp.mot.com (il06exm13.corp.mot.com [10.0.111.13]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i44EKiTV007954 for ; Tue, 4 May 2004 09:21:04 -0500 Received: by il06exm13 with Internet Mail Service (5.5.2657.72) id <2A7BFMKP>; Tue, 4 May 2004 09:21:52 -0500 Message-ID: From: Ryabin Aleksandr-A19776 To: "'Kevin Boyle'" , "Alf Heidermark (AS/EAB)" , megaco@ietf.org Subject: RE: [Megaco] Continuity tests Date: Tue, 4 May 2004 09:21:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C431E3.238F255C" 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TAG_BALANCE_BODY, HTML_TAG_BALANCE_HTML,MIME_BASE64_TEXT,MIME_HTML_NO_CHARSET autolearn=no version=2.60 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_01C431E3.238F255C Content-Type: text/plain New switches need to be able to provide at least the same functions as old switches. "At least" here is a key word. They also will have more functions. One of the new functions is to be able to work with "dumb" switches not capable of COT. The control protocol in use for these new switches is not there to address marketing needs, but to address functional needs. As such it has to have the ability to allow MGC to solve this functional issue. As I indicated before this is real life issue we run into and need to address. My intent here is to simply bring the issue up to standartization community such that no private extention created to address the issue. If standartization community feels that this is an implementaion issue then we will deal with it as such. Regards, Aleks -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] Sent: Monday, May 03, 2004 6:24 PM To: Aleksandr Ryabin; Alf Heidermark (AS/EAB); megaco@ietf.org Subject: RE: [Megaco] Continuity tests Right. New switches need to be able to provide the same function as the old switches. I am still not seeing the problem here. If the new switches need to provide the same function as the old switches, then that implies that these "middleswitches" have to do COT. Customers are not going to tolerate lack of basic function. It seems to me that the inability to do COT will limit the deployment of any of these "new cheap" boxes. Kevin -----Original Message----- From: Aleksandr Ryabin [ mailto:kengr@motorola.com ] Sent: Monday, May 03, 2004 10:11 AM To: Alf Heidermark (AS/EAB); megaco@ietf.org Subject: RE: [Megaco] Continuity tests Hi Alf, I'm not talking about old networks. With old networks everything stays the same. In order to maintain backward compatibility there always will be "intelligent" switches sitting on border with old networks, which are capable of doing COT. But new networks can utilize new (cheap) solutions and as such new "intelligent" switches need to be capable of the functionality in question. Regards, Aleks At 02:41 AM 5/3/2004, Alf Heidermark (AS/EAB) wrote: >Hello Alexandr > >Continuity check is in service on many old exchanges. Do you really >mean that they shall change their impleentations to be able to >interwork with the dumb switch. Normally it is up to new equipment to >interwork existing network nodes. From this resoning I cannot see any >reason to change anything in H.248 to continuity check. > >alf > >-----Original Message----- >From: megaco-admin@ietf.org [ mailto:megaco-admin@ietf.org ]On Behalf Of >Aleksandr Ryabin >Sent: den 30 april 2004 16:39 >To: Christian Groves (MC/EPA); megaco@ietf.org >Cc: Kevin Boyle; Tom-PT Taylor >Subject: Re: [Megaco] Continuity tests > > >Hi Christian, > >There could be "dumb" switches in the middle of the path (for example >DACS) which are not capable of any testing/signalling. >Their only role is to split/redirect links and as such the nature of a >circuit can change, and thus the type of COT test. > >Regards, > Aleks > ------_=_NextPart_001_01C431E3.238F255C Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPlJFOiBbTWVnYWNvXSBD b250aW51aXR5IHRlc3RzPC9USVRMRT4NCg0KPE1FVEEgY29udGVudD0iTVNIVE1MIDYuMDAuMjgw MC4xNDAwIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWT4NCjxESVY+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiBjbGFzcz04MTQzNjA3MTQtMDQwNTIwMDQ+ TmV3IA0Kc3dpdGNoZXMgbmVlZCB0byBiZSBhYmxlIHRvIHByb3ZpZGUgYXQgbGVhc3QgdGhlIHNh bWUgZnVuY3Rpb25zIGFzIG9sZCANCnN3aXRjaGVzLjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gY2xhc3M9ODE0MzYw NzE0LTA0MDUyMDA0PiJBdCANCmxlYXN0IiBoZXJlIGlzIGEga2V5IHdvcmQuIFRoZXkgYWxzbyB3 aWxsIGhhdmUgbW9yZSANCmZ1bmN0aW9ucy48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIGNsYXNzPTgxNDM2MDcxNC0w NDA1MjAwND5PbmUgb2YgDQp0aGUgbmV3IGZ1bmN0aW9ucyBpcyB0byBiZSBhYmxlIHRvIHdvcmsg d2l0aCAiZHVtYiIgc3dpdGNoZXMgPC9TUEFOPjwvRk9OVD48Rk9OVCANCmZhY2U9QXJpYWwgY29s b3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gY2xhc3M9ODE0MzYwNzE0LTA0MDUyMDA0Pm5vdCBjYXBh YmxlIG9mIA0KQ09ULjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQpjbGFzcz04MTQzNjA3MTQtMDQwNTIwMDQ+PC9T UEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAw MGZmIHNpemU9Mj48U1BBTiBjbGFzcz04MTQzNjA3MTQtMDQwNTIwMDQ+VGhlIA0KY29udHJvbCBw cm90b2NvbCBpbiB1c2UgZm9yIHRoZXNlIG5ldyBzd2l0Y2hlcyBpcyBub3QgdGhlcmUgdG8gYWRk cmVzcyBtYXJrZXRpbmcgDQpuZWVkcyw8L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIGNsYXNzPTgxNDM2MDcxNC0wNDA1 MjAwND5idXQgdG8gDQphZGRyZXNzIGZ1bmN0aW9uYWwgbmVlZHMuIEFzIHN1Y2ggaXQgaGFzIHRv IGhhdmUgdGhlIGFiaWxpdHkgdG8gYWxsb3cgTUdDIHRvIA0Kc29sdmUgPC9TUEFOPjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiBj bGFzcz04MTQzNjA3MTQtMDQwNTIwMDQ+dGhpcyANCmZ1bmN0aW9uYWwgaXNzdWUuPC9TUEFOPjwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48 U1BBTiANCmNsYXNzPTgxNDM2MDcxNC0wNDA1MjAwND48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIGNsYXNz PTgxNDM2MDcxNC0wNDA1MjAwND5BcyBJIA0KaW5kaWNhdGVkIGJlZm9yZSB0aGlzIGlzIHJlYWwg bGlmZSBpc3N1ZSB3ZSBydW4gaW50byBhbmQgbmVlZCB0byANCmFkZHJlc3MuPC9TUEFOPjwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BB TiBjbGFzcz04MTQzNjA3MTQtMDQwNTIwMDQ+TXkgDQppbnRlbnQgaGVyZSBpcyZuYnNwO3RvIHNp bXBseSBicmluZyB0aGUgaXNzdWUmbmJzcDt1cCB0byBzdGFuZGFydGl6YXRpb24gDQpjb21tdW5p dHk8L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAw ZmYgc2l6ZT0yPjxTUEFOIGNsYXNzPTgxNDM2MDcxNC0wNDA1MjAwND5zdWNoIA0KdGhhdCBubyBw cml2YXRlIGV4dGVudGlvbiBjcmVhdGVkIHRvIGFkZHJlc3MgdGhlIGlzc3VlLjwvU1BBTj48L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQ QU4gY2xhc3M9ODE0MzYwNzE0LTA0MDUyMDA0PklmIA0Kc3RhbmRhcnRpemF0aW9uIGNvbW11bml0 eSBmZWVscyB0aGF0IHRoaXMgaXMgYW4gaW1wbGVtZW50YWlvbiANCmlzc3VlPC9TUEFOPjwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BB TiBjbGFzcz04MTQzNjA3MTQtMDQwNTIwMDQ+dGhlbiANCndlIHdpbGwgZGVhbCB3aXRoIGl0IGFz IHN1Y2guPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmIHNpemU9Mj48U1BBTiANCmNsYXNzPTgxNDM2MDcxNC0wNDA1MjAwND48L1NQQU4+PC9G T05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6 ZT0yPjxTUEFOIA0KY2xhc3M9ODE0MzYwNzE0LTA0MDUyMDA0PlJlZ2FyZHMsPC9TUEFOPjwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BB TiANCmNsYXNzPTgxNDM2MDcxNC0wNDA1MjAwND4mbmJzcDsmbmJzcDsmbmJzcDsgQWxla3M8L1NQ QU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6 ZT0yPjxTUEFOIA0KY2xhc3M9ODE0MzYwNzE0LTA0MDUyMDA0PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8QkxPQ0tRVU9URSBkaXI9bHRyIHN0eWxlPSJNQVJHSU4tUklHSFQ6IDBweCI+DQog IDxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgZGlyPWx0ciBhbGlnbj1sZWZ0PjxGT05U IGZhY2U9VGFob21hIA0KICBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+PEI+ RnJvbTo8L0I+IEtldmluIEJveWxlIA0KICBbbWFpbHRvOmtib3lsZUBub3J0ZWxuZXR3b3Jrcy5j b21dPEJSPjxCPlNlbnQ6PC9CPiBNb25kYXksIE1heSAwMywgMjAwNCA2OjI0IA0KICBQTTxCUj48 Qj5Ubzo8L0I+IEFsZWtzYW5kciBSeWFiaW47IEFsZiBIZWlkZXJtYXJrIChBUy9FQUIpOyANCiAg bWVnYWNvQGlldGYub3JnPEJSPjxCPlN1YmplY3Q6PC9CPiBSRTogW01lZ2Fjb10gQ29udGludWl0 eSANCiAgdGVzdHM8QlI+PEJSPjwvRk9OVD48L0RJVj4NCiAgPFA+PEZPTlQgc2l6ZT0yPlJpZ2h0 LiZuYnNwOyBOZXcgc3dpdGNoZXMgbmVlZCB0byBiZSBhYmxlIHRvIHByb3ZpZGUgdGhlIHNhbWUg DQogIGZ1bmN0aW9uIGFzIHRoZSBvbGQgc3dpdGNoZXMuPC9GT05UPiA8L1A+DQogIDxQPjxGT05U IHNpemU9Mj5JIGFtIHN0aWxsIG5vdCBzZWVpbmcgdGhlIHByb2JsZW0gaGVyZS4gSWYgdGhlIG5l dyBzd2l0Y2hlcyANCiAgbmVlZCB0byBwcm92aWRlIHRoZSBzYW1lIGZ1bmN0aW9uIGFzIHRoZSBv bGQgc3dpdGNoZXMsIHRoZW4gdGhhdCBpbXBsaWVzIHRoYXQgDQogIHRoZXNlICJtaWRkbGVzd2l0 Y2hlcyIgaGF2ZSB0byBkbyBDT1QuJm5ic3A7IEN1c3RvbWVycyBhcmUgbm90IGdvaW5nIHRvIA0K ICB0b2xlcmF0ZSBsYWNrIG9mIGJhc2ljIGZ1bmN0aW9uLjwvRk9OVD48L1A+DQogIDxQPjxGT05U IHNpemU9Mj5JdCBzZWVtcyB0byBtZSB0aGF0IHRoZSBpbmFiaWxpdHkgdG8gZG8gQ09UIHdpbGwg bGltaXQgdGhlIA0KICBkZXBsb3ltZW50IG9mIGFueSBvZiB0aGVzZSAibmV3IGNoZWFwIiBib3hl cy48L0ZPTlQ+IDwvUD4NCiAgPFA+PEZPTlQgc2l6ZT0yPktldmluPC9GT05UPiA8L1A+DQogIDxQ PjxGT05UIHNpemU9Mj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD4gPEJSPjxGT05U IHNpemU9Mj5Gcm9tOiANCiAgQWxla3NhbmRyIFJ5YWJpbiBbPEEgDQogIGhyZWY9Im1haWx0bzpr ZW5nckBtb3Rvcm9sYS5jb20iPm1haWx0bzprZW5nckBtb3Rvcm9sYS5jb208L0E+XSANCiAgPC9G T05UPjxCUj48Rk9OVCBzaXplPTI+U2VudDogTW9uZGF5LCBNYXkgMDMsIDIwMDQgMTA6MTEgQU08 L0ZPTlQ+IDxCUj48Rk9OVCANCiAgc2l6ZT0yPlRvOiBBbGYgSGVpZGVybWFyayAoQVMvRUFCKTsg bWVnYWNvQGlldGYub3JnPC9GT05UPiA8QlI+PEZPTlQgDQogIHNpemU9Mj5TdWJqZWN0OiBSRTog W01lZ2Fjb10gQ29udGludWl0eSB0ZXN0czwvRk9OVD4gPC9QPg0KICA8UD48Rk9OVCBzaXplPTI+ SGkgQWxmLDwvRk9OVD4gPC9QPg0KICA8UD48Rk9OVCBzaXplPTI+SSdtIG5vdCB0YWxraW5nIGFi b3V0IG9sZCBuZXR3b3Jrcy4gV2l0aCBvbGQgbmV0d29ya3MgDQogIGV2ZXJ5dGhpbmcgc3RheXMg dGhlIHNhbWUuPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPkluIG9yZGVyIHRvIG1haW50YWluIA0K ICBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHRoZXJlIGFsd2F5cyB3aWxsIGJlICJpbnRlbGxpZ2Vu dCI8L0ZPTlQ+IDxCUj48Rk9OVCANCiAgc2l6ZT0yPnN3aXRjaGVzIHNpdHRpbmcgb24gYm9yZGVy IHdpdGggb2xkIG5ldHdvcmtzLCB3aGljaCBhcmUgY2FwYWJsZSBvZiANCiAgZG9pbmcgQ09ULjwv Rk9OVD4gPC9QPg0KICA8UD48Rk9OVCBzaXplPTI+QnV0IG5ldyBuZXR3b3JrcyBjYW4gdXRpbGl6 ZSBuZXcgKGNoZWFwKSBzb2x1dGlvbnMgYW5kIGFzIHN1Y2ggDQogIG5ldyAiaW50ZWxsaWdlbnQi IHN3aXRjaGVzIG5lZWQgdG8gYmUgY2FwYWJsZSBvZiB0aGUgZnVuY3Rpb25hbGl0eSBpbiANCiAg cXVlc3Rpb24uPC9GT05UPjwvUD4NCiAgPFA+PEZPTlQgc2l6ZT0yPlJlZ2FyZHMsPC9GT05UPiA8 QlI+PEZPTlQgDQogIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgQWxla3M8L0ZPTlQ+IDwvUD4NCiAgPFA+PEZPTlQgc2l6ZT0yPkF0IDAyOjQx IEFNIDUvMy8yMDA0LCBBbGYgSGVpZGVybWFyayAoQVMvRUFCKSB3cm90ZTo8L0ZPTlQ+IA0KICA8 QlI+PEZPTlQgc2l6ZT0yPiZndDtIZWxsbyBBbGV4YW5kcjwvRk9OVD4gPEJSPjxGT05UIHNpemU9 Mj4mZ3Q7PC9GT05UPiANCiAgPEJSPjxGT05UIHNpemU9Mj4mZ3Q7Q29udGludWl0eSBjaGVjayBp cyBpbiBzZXJ2aWNlIG9uIG1hbnkgb2xkIGV4Y2hhbmdlcy4gRG8gDQogIHlvdSByZWFsbHkgPC9G T05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0O21lYW4gdGhhdCB0aGV5IHNoYWxsIGNoYW5nZSB0aGVp ciANCiAgaW1wbGVlbnRhdGlvbnMgdG8gYmUgYWJsZSB0byA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9 Mj4mZ3Q7aW50ZXJ3b3JrIHdpdGggdGhlIA0KICBkdW1iIHN3aXRjaC4gTm9ybWFsbHkgaXQgaXMg dXAgdG8gbmV3IGVxdWlwbWVudCB0byA8L0ZPTlQ+PEJSPjxGT05UIA0KICBzaXplPTI+Jmd0O2lu dGVyd29yayBleGlzdGluZyBuZXR3b3JrIG5vZGVzLiBGcm9tIHRoaXMgcmVzb25pbmcgSSBjYW5u b3Qgc2VlIA0KICBhbnkgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0O3JlYXNvbiB0byBjaGFu Z2UgYW55dGhpbmcgaW4gSC4yNDggdG8gDQogIGNvbnRpbnVpdHkgY2hlY2suPC9GT05UPiA8QlI+ PEZPTlQgc2l6ZT0yPiZndDs8L0ZPTlQ+IDxCUj48Rk9OVCANCiAgc2l6ZT0yPiZndDthbGY8L0ZP TlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OzwvRk9OVD4gPEJSPjxGT05UIA0KICBzaXplPTI+Jmd0 Oy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDtG cm9tOiANCiAgbWVnYWNvLWFkbWluQGlldGYub3JnIFs8QSANCiAgaHJlZj0ibWFpbHRvOm1lZ2Fj by1hZG1pbkBpZXRmLm9yZyI+bWFpbHRvOm1lZ2Fjby1hZG1pbkBpZXRmLm9yZzwvQT5dT24gQmVo YWxmIA0KICBPZiA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7QWxla3NhbmRyIFJ5YWJpbjwv Rk9OVD4gPEJSPjxGT05UIA0KICBzaXplPTI+Jmd0O1NlbnQ6IGRlbiAzMCBhcHJpbCAyMDA0IDE2 OjM5PC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDtUbzogDQogIENocmlzdGlhbiBHcm92ZXMg KE1DL0VQQSk7IG1lZ2Fjb0BpZXRmLm9yZzwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7Q2M6 IA0KICBLZXZpbiBCb3lsZTsgVG9tLVBUIFRheWxvcjwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4m Z3Q7U3ViamVjdDogUmU6IFtNZWdhY29dIA0KICBDb250aW51aXR5IHRlc3RzPC9GT05UPiA8QlI+ PEZPTlQgc2l6ZT0yPiZndDs8L0ZPTlQ+IDxCUj48Rk9OVCANCiAgc2l6ZT0yPiZndDs8L0ZPTlQ+ IDxCUj48Rk9OVCBzaXplPTI+Jmd0O0hpIENocmlzdGlhbiw8L0ZPTlQ+IDxCUj48Rk9OVCANCiAg c2l6ZT0yPiZndDs8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0O1RoZXJlIGNvdWxkIGJlICJk dW1iIiBzd2l0Y2hlcyBpbiB0aGUgDQogIG1pZGRsZSBvZiB0aGUgcGF0aCAoZm9yIGV4YW1wbGUg PC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0O0RBQ1MpIHdoaWNoIGFyZSANCiAgbm90IGNhcGFi bGUgb2YgYW55IHRlc3Rpbmcvc2lnbmFsbGluZy48L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0 O1RoZWlyIG9ubHkgDQogIHJvbGUgaXMgdG8gc3BsaXQvcmVkaXJlY3QgbGlua3MgYW5kIGFzIHN1 Y2ggdGhlIG5hdHVyZSBvZiBhIDwvRk9OVD48QlI+PEZPTlQgDQogIHNpemU9Mj4mZ3Q7Y2lyY3Vp dCBjYW4gY2hhbmdlLCBhbmQgdGh1cyB0aGUgdHlwZSBvZiBDT1QgdGVzdC48L0ZPTlQ+IDxCUj48 Rk9OVCANCiAgc2l6ZT0yPiZndDs8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0O1JlZ2FyZHMs PC9GT05UPiA8QlI+PEZPTlQgDQogIHNpemU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFsZWtzPC9GT05UPiANCiAgPEJSPjxGT05U IHNpemU9Mj4mZ3Q7PC9GT05UPiA8L1A+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= ------_=_NextPart_001_01C431E3.238F255C-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue May 4 10:58:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06548 for ; Tue, 4 May 2004 10:58:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL1H9-000290-1N; Tue, 04 May 2004 10:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL1E5-0001I4-9o for megaco@optimus.ietf.org; Tue, 04 May 2004 10:48:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06125 for ; Tue, 4 May 2004 10:48:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL1E2-0007gk-SH for megaco@ietf.org; Tue, 04 May 2004 10:48:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL1D9-0007c0-00 for megaco@ietf.org; Tue, 04 May 2004 10:47:55 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BL1Cb-0007Vj-00 for megaco@ietf.org; Tue, 04 May 2004 10:47:21 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i44Eko225866 for ; Tue, 4 May 2004 10:46:50 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 May 2004 10:46:51 -0400 Message-ID: From: "Kevin Boyle" To: Ryabin Aleksandr-A19776 , "Alf Heidermark (AS/EAB)" , megaco@ietf.org Subject: RE: [Megaco] Continuity tests Date: Tue, 4 May 2004 10:46:48 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , I think my key point has been misunderstood. New switches include these "dumb switches". So, it seems to me that the "dumb switches" have a compatibility requirement to support COT -- especially if they are changing the physical aspects of the connections, which you have stated that they do. This is not a marketing position -- this is an engineering position. Telcos that deploy equipment that make COT stop working will quickly remove that equipment from their network as detrimental. If we condone such behavior, what is next? Should we develop workarounds for all deficient equipment, just on the position that it is "cheap" or "dumb" and therefore it is our problem to solve? COT has always been link-by-link. Introducing a new "dumb" link does not absolve that equipment of its responsibility to perform the same basic function as every other link in the network. Kevin _____ From: Ryabin Aleksandr-A19776 [mailto:kengr@motorola.com] Sent: Tuesday, May 04, 2004 10:22 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Alf Heidermark (AS/EAB); megaco@ietf.org Subject: RE: [Megaco] Continuity tests New switches need to be able to provide at least the same functions as old switches. "At least" here is a key word. They also will have more functions. One of the new functions is to be able to work with "dumb" switches not capable of COT. The control protocol in use for these new switches is not there to address marketing needs, but to address functional needs. As such it has to have the ability to allow MGC to solve this functional issue. As I indicated before this is real life issue we run into and need to address. My intent here is to simply bring the issue up to standartization community such that no private extention created to address the issue. If standartization community feels that this is an implementaion issue then we will deal with it as such. Regards, Aleks -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] Sent: Monday, May 03, 2004 6:24 PM To: Aleksandr Ryabin; Alf Heidermark (AS/EAB); megaco@ietf.org Subject: RE: [Megaco] Continuity tests Right. New switches need to be able to provide the same function as the old switches. I am still not seeing the problem here. If the new switches need to provide the same function as the old switches, then that implies that these "middleswitches" have to do COT. Customers are not going to tolerate lack of basic function. It seems to me that the inability to do COT will limit the deployment of any of these "new cheap" boxes. Kevin -----Original Message----- From: Aleksandr Ryabin [mailto:kengr@motorola.com ] Sent: Monday, May 03, 2004 10:11 AM To: Alf Heidermark (AS/EAB); megaco@ietf.org Subject: RE: [Megaco] Continuity tests Hi Alf, I'm not talking about old networks. With old networks everything stays the same. In order to maintain backward compatibility there always will be "intelligent" switches sitting on border with old networks, which are capable of doing COT. But new networks can utilize new (cheap) solutions and as such new "intelligent" switches need to be capable of the functionality in question. Regards, Aleks At 02:41 AM 5/3/2004, Alf Heidermark (AS/EAB) wrote: >Hello Alexandr > >Continuity check is in service on many old exchanges. Do you really >mean that they shall change their impleentations to be able to >interwork with the dumb switch. Normally it is up to new equipment to >interwork existing network nodes. From this resoning I cannot see any >reason to change anything in H.248 to continuity check. > >alf > >-----Original Message----- >From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org ]On Behalf Of >Aleksandr Ryabin >Sent: den 30 april 2004 16:39 >To: Christian Groves (MC/EPA); megaco@ietf.org >Cc: Kevin Boyle; Tom-PT Taylor >Subject: Re: [Megaco] Continuity tests > > >Hi Christian, > >There could be "dumb" switches in the middle of the path (for example >DACS) which are not capable of any testing/signalling. >Their only role is to split/redirect links and as such the nature of a >circuit can change, and thus the type of COT test. > >Regards, > Aleks > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Tue May 4 11:06:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06984 for ; Tue, 4 May 2004 11:06:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL1PK-0004vv-5S for megaco-archive@odin.ietf.org; Tue, 04 May 2004 11:00:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44F0U3R018959 for megaco-archive@odin.ietf.org; Tue, 4 May 2004 11:00:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL1Of-0004cC-Gi for megaco-web-archive@optimus.ietf.org; Tue, 04 May 2004 10:59:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06609 for ; Tue, 4 May 2004 10:59:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL1Od-0000ha-1Z for megaco-web-archive@ietf.org; Tue, 04 May 2004 10:59:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL1Nb-0000dq-00 for megaco-web-archive@ietf.org; Tue, 04 May 2004 10:58:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL1N3-0000aO-00 for megaco-web-archive@ietf.org; Tue, 04 May 2004 10:58:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL1H9-000290-1N; Tue, 04 May 2004 10:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL1E5-0001I4-9o for megaco@optimus.ietf.org; Tue, 04 May 2004 10:48:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06125 for ; Tue, 4 May 2004 10:48:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL1E2-0007gk-SH for megaco@ietf.org; Tue, 04 May 2004 10:48:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL1D9-0007c0-00 for megaco@ietf.org; Tue, 04 May 2004 10:47:55 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BL1Cb-0007Vj-00 for megaco@ietf.org; Tue, 04 May 2004 10:47:21 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i44Eko225866 for ; Tue, 4 May 2004 10:46:50 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 May 2004 10:46:51 -0400 Message-ID: From: "Kevin Boyle" To: Ryabin Aleksandr-A19776 , "Alf Heidermark (AS/EAB)" , megaco@ietf.org Subject: RE: [Megaco] Continuity tests Date: Tue, 4 May 2004 10:46:48 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 I think my key point has been misunderstood. New switches include these "dumb switches". So, it seems to me that the "dumb switches" have a compatibility requirement to support COT -- especially if they are changing the physical aspects of the connections, which you have stated that they do. This is not a marketing position -- this is an engineering position. Telcos that deploy equipment that make COT stop working will quickly remove that equipment from their network as detrimental. If we condone such behavior, what is next? Should we develop workarounds for all deficient equipment, just on the position that it is "cheap" or "dumb" and therefore it is our problem to solve? COT has always been link-by-link. Introducing a new "dumb" link does not absolve that equipment of its responsibility to perform the same basic function as every other link in the network. Kevin _____ From: Ryabin Aleksandr-A19776 [mailto:kengr@motorola.com] Sent: Tuesday, May 04, 2004 10:22 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Alf Heidermark (AS/EAB); megaco@ietf.org Subject: RE: [Megaco] Continuity tests New switches need to be able to provide at least the same functions as old switches. "At least" here is a key word. They also will have more functions. One of the new functions is to be able to work with "dumb" switches not capable of COT. The control protocol in use for these new switches is not there to address marketing needs, but to address functional needs. As such it has to have the ability to allow MGC to solve this functional issue. As I indicated before this is real life issue we run into and need to address. My intent here is to simply bring the issue up to standartization community such that no private extention created to address the issue. If standartization community feels that this is an implementaion issue then we will deal with it as such. Regards, Aleks -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] Sent: Monday, May 03, 2004 6:24 PM To: Aleksandr Ryabin; Alf Heidermark (AS/EAB); megaco@ietf.org Subject: RE: [Megaco] Continuity tests Right. New switches need to be able to provide the same function as the old switches. I am still not seeing the problem here. If the new switches need to provide the same function as the old switches, then that implies that these "middleswitches" have to do COT. Customers are not going to tolerate lack of basic function. It seems to me that the inability to do COT will limit the deployment of any of these "new cheap" boxes. Kevin -----Original Message----- From: Aleksandr Ryabin [mailto:kengr@motorola.com ] Sent: Monday, May 03, 2004 10:11 AM To: Alf Heidermark (AS/EAB); megaco@ietf.org Subject: RE: [Megaco] Continuity tests Hi Alf, I'm not talking about old networks. With old networks everything stays the same. In order to maintain backward compatibility there always will be "intelligent" switches sitting on border with old networks, which are capable of doing COT. But new networks can utilize new (cheap) solutions and as such new "intelligent" switches need to be capable of the functionality in question. Regards, Aleks At 02:41 AM 5/3/2004, Alf Heidermark (AS/EAB) wrote: >Hello Alexandr > >Continuity check is in service on many old exchanges. Do you really >mean that they shall change their impleentations to be able to >interwork with the dumb switch. Normally it is up to new equipment to >interwork existing network nodes. From this resoning I cannot see any >reason to change anything in H.248 to continuity check. > >alf > >-----Original Message----- >From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org ]On Behalf Of >Aleksandr Ryabin >Sent: den 30 april 2004 16:39 >To: Christian Groves (MC/EPA); megaco@ietf.org >Cc: Kevin Boyle; Tom-PT Taylor >Subject: Re: [Megaco] Continuity tests > > >Hi Christian, > >There could be "dumb" switches in the middle of the path (for example >DACS) which are not capable of any testing/signalling. >Their only role is to split/redirect links and as such the nature of a >circuit can change, and thus the type of COT test. > >Regards, > Aleks > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue May 4 14:00:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16142 for ; Tue, 4 May 2004 14:00:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL48D-0003Qy-SC; Tue, 04 May 2004 13:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL3yD-0000wd-Dz for megaco@optimus.ietf.org; Tue, 04 May 2004 13:44:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15318 for ; Tue, 4 May 2004 13:44:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL3yB-0007jk-7g for megaco@ietf.org; Tue, 04 May 2004 13:44:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL3xC-0007ch-00 for megaco@ietf.org; Tue, 04 May 2004 13:43:39 -0400 Received: from frogman.motivity.ca ([64.235.96.70]) by ietf-mx with esmtp (Exim 4.12) id 1BL3wH-0007RC-00 for megaco@ietf.org; Tue, 04 May 2004 13:42:42 -0400 Received: from frogman.motivity.ca (localhost.motivity.ca [127.0.0.1]) by frogman.motivity.ca (8.12.11/8.12.11) with ESMTP id i44Hga0w026800; Tue, 4 May 2004 13:42:36 -0400 (EDT) (envelope-from vances@frogman.motivity.ca) Received: (from vances@localhost) by frogman.motivity.ca (8.12.11/8.12.11/Submit) id i44HgZB3026799; Tue, 4 May 2004 13:42:36 -0400 (EDT) (envelope-from vances) Date: Tue, 4 May 2004 13:42:35 -0400 From: Vance Shipley To: Aleksandr Ryabin Cc: megaco@ietf.org Subject: Re: [Megaco] Continuity tests Message-ID: <20040504174235.GK18911@frogman.motivity.ca> References: <5.2.1.1.0.20040429114553.01e149b8@IL06EXM13.corp.mot.com> <5.2.1.1.0.20040429114553.01e149b8@IL06EXM13.corp.mot.com> <5.2.1.1.0.20040430103240.04d9b250@IL06EXM13.corp.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.1.1.0.20040430103240.04d9b250@IL06EXM13.corp.mot.com> Organization: Motivity Telecom Inc. User-Agent: Mutt/1.5.1i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: , On Fri, Apr 30, 2004 at 10:39:14AM -0400, Aleksandr Ryabin wrote: } } There could be "dumb" switches in the middle of the path } (for example DACS) which are not capable of any testing/signalling. } Their only role is to split/redirect links and as such the nature } of a circuit can change, and thus the type of COT test. The reason COT was included in ISUP is because of the possible presence of DSO level DACS. If all interconnections were at the E1 or DS1 level you would need only to monitor alarms and performance reports at the span level to know about the integrity of those circuits. If the bearer channels have been processed through a DSO DACS or something similiar you can't use the span level alarming/reporting. Even more importantly the likelyhood of a problem is increased. A common problem is that the mapping was done in error. COT testing tests this by requesting a loopback and checking that what is sent is received while the loopback is in place. The COT request and response is binary. There is no need or opportunity to request the type of test as the type of test is provisioned with the circuits. -Vance _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Tue May 4 14:17:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17254 for ; Tue, 4 May 2004 14:17:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4Os-0002rZ-3r for megaco-archive@odin.ietf.org; Tue, 04 May 2004 14:12:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44ICEH0010997 for megaco-archive@odin.ietf.org; Tue, 4 May 2004 14:12:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4El-0007da-OH for megaco-web-archive@optimus.ietf.org; Tue, 04 May 2004 14:01:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16190 for ; Tue, 4 May 2004 14:01:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL4Ej-0001dG-EF for megaco-web-archive@ietf.org; Tue, 04 May 2004 14:01:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL4Do-0001YJ-00 for megaco-web-archive@ietf.org; Tue, 04 May 2004 14:00:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL4DE-0001TQ-00 for megaco-web-archive@ietf.org; Tue, 04 May 2004 14:00:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL48D-0003Qy-SC; Tue, 04 May 2004 13:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL3yD-0000wd-Dz for megaco@optimus.ietf.org; Tue, 04 May 2004 13:44:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15318 for ; Tue, 4 May 2004 13:44:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL3yB-0007jk-7g for megaco@ietf.org; Tue, 04 May 2004 13:44:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL3xC-0007ch-00 for megaco@ietf.org; Tue, 04 May 2004 13:43:39 -0400 Received: from frogman.motivity.ca ([64.235.96.70]) by ietf-mx with esmtp (Exim 4.12) id 1BL3wH-0007RC-00 for megaco@ietf.org; Tue, 04 May 2004 13:42:42 -0400 Received: from frogman.motivity.ca (localhost.motivity.ca [127.0.0.1]) by frogman.motivity.ca (8.12.11/8.12.11) with ESMTP id i44Hga0w026800; Tue, 4 May 2004 13:42:36 -0400 (EDT) (envelope-from vances@frogman.motivity.ca) Received: (from vances@localhost) by frogman.motivity.ca (8.12.11/8.12.11/Submit) id i44HgZB3026799; Tue, 4 May 2004 13:42:36 -0400 (EDT) (envelope-from vances) Date: Tue, 4 May 2004 13:42:35 -0400 From: Vance Shipley To: Aleksandr Ryabin Cc: megaco@ietf.org Subject: Re: [Megaco] Continuity tests Message-ID: <20040504174235.GK18911@frogman.motivity.ca> References: <5.2.1.1.0.20040429114553.01e149b8@IL06EXM13.corp.mot.com> <5.2.1.1.0.20040429114553.01e149b8@IL06EXM13.corp.mot.com> <5.2.1.1.0.20040430103240.04d9b250@IL06EXM13.corp.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.1.1.0.20040430103240.04d9b250@IL06EXM13.corp.mot.com> Organization: Motivity Telecom Inc. User-Agent: Mutt/1.5.1i 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Fri, Apr 30, 2004 at 10:39:14AM -0400, Aleksandr Ryabin wrote: } } There could be "dumb" switches in the middle of the path } (for example DACS) which are not capable of any testing/signalling. } Their only role is to split/redirect links and as such the nature } of a circuit can change, and thus the type of COT test. The reason COT was included in ISUP is because of the possible presence of DSO level DACS. If all interconnections were at the E1 or DS1 level you would need only to monitor alarms and performance reports at the span level to know about the integrity of those circuits. If the bearer channels have been processed through a DSO DACS or something similiar you can't use the span level alarming/reporting. Even more importantly the likelyhood of a problem is increased. A common problem is that the mapping was done in error. COT testing tests this by requesting a loopback and checking that what is sent is received while the loopback is in place. The COT request and response is binary. There is no need or opportunity to request the type of test as the type of test is provisioned with the circuits. -Vance _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue May 4 15:57:40 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25704 for ; Tue, 4 May 2004 15:57:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL5wW-0004dJ-QW; Tue, 04 May 2004 15:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL5rp-0003EF-Fm for megaco@optimus.ietf.org; Tue, 04 May 2004 15:46:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25059 for ; Tue, 4 May 2004 15:46:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL5rn-0006Cb-GV for megaco@ietf.org; Tue, 04 May 2004 15:46:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL5r4-00065M-00 for megaco@ietf.org; Tue, 04 May 2004 15:45:27 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1BL5qI-0005w9-00 for megaco@ietf.org; Tue, 04 May 2004 15:44:38 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i44JicfS028884; Tue, 4 May 2004 12:44:38 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i44Ji2Uh029959; Tue, 4 May 2004 14:44:07 -0500 Message-Id: <5.2.1.1.0.20040504153325.01dfce68@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 04 May 2004 15:41:36 -0400 To: Vance Shipley, From: Aleksandr Ryabin Subject: Re: [Megaco] Continuity tests In-Reply-To: <20040504174235.GK18911@frogman.motivity.ca> References: <5.2.1.1.0.20040430103240.04d9b250@IL06EXM13.corp.mot.com> <5.2.1.1.0.20040429114553.01e149b8@IL06EXM13.corp.mot.com> <5.2.1.1.0.20040429114553.01e149b8@IL06EXM13.corp.mot.com> <5.2.1.1.0.20040430103240.04d9b250@IL06EXM13.corp.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 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: , ISUP COT request and response are coming to/from MGC and not to/from MG. Yes ISUP does not have a need, or opportunity to request the type of test, but MGC does. My point was that the type of test is provisioned with MGC and not MG as MGC and not MG is an ultimate entry that has information of where MG circuit (ds0) is eventually connected to. As such MGC has to be able to tell MG which COT test to perform. Aleks At 01:42 PM 5/4/2004, Vance Shipley wrote: >On Fri, Apr 30, 2004 at 10:39:14AM -0400, Aleksandr Ryabin wrote: >} >} There could be "dumb" switches in the middle of the path >} (for example DACS) which are not capable of any testing/signalling. >} Their only role is to split/redirect links and as such the nature >} of a circuit can change, and thus the type of COT test. > >The reason COT was included in ISUP is because of the possible >presence of DSO level DACS. If all interconnections were at the >E1 or DS1 level you would need only to monitor alarms and performance >reports at the span level to know about the integrity of those >circuits. If the bearer channels have been processed through a >DSO DACS or something similiar you can't use the span level >alarming/reporting. Even more importantly the likelyhood of a >problem is increased. A common problem is that the mapping was >done in error. COT testing tests this by requesting a loopback >and checking that what is sent is received while the loopback is >in place. > >The COT request and response is binary. There is no need or >opportunity to request the type of test as the type of test is >provisioned with the circuits. > > -Vance _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Tue May 4 16:08:48 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26199 for ; Tue, 4 May 2004 16:08:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL66c-0006ZJ-AL for megaco-archive@odin.ietf.org; Tue, 04 May 2004 16:01:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44K1U3U025250 for megaco-archive@odin.ietf.org; Tue, 4 May 2004 16:01:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL645-0006B0-4Q for megaco-web-archive@optimus.ietf.org; Tue, 04 May 2004 15:58:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25768 for ; Tue, 4 May 2004 15:58:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL643-0007gL-D8 for megaco-web-archive@ietf.org; Tue, 04 May 2004 15:58:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL637-0007aD-00 for megaco-web-archive@ietf.org; Tue, 04 May 2004 15:57:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL62R-0007U8-00 for megaco-web-archive@ietf.org; Tue, 04 May 2004 15:57:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL5wW-0004dJ-QW; Tue, 04 May 2004 15:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL5rp-0003EF-Fm for megaco@optimus.ietf.org; Tue, 04 May 2004 15:46:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25059 for ; Tue, 4 May 2004 15:46:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL5rn-0006Cb-GV for megaco@ietf.org; Tue, 04 May 2004 15:46:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL5r4-00065M-00 for megaco@ietf.org; Tue, 04 May 2004 15:45:27 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1BL5qI-0005w9-00 for megaco@ietf.org; Tue, 04 May 2004 15:44:38 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i44JicfS028884; Tue, 4 May 2004 12:44:38 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i44Ji2Uh029959; Tue, 4 May 2004 14:44:07 -0500 Message-Id: <5.2.1.1.0.20040504153325.01dfce68@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 04 May 2004 15:41:36 -0400 To: Vance Shipley, From: Aleksandr Ryabin Subject: Re: [Megaco] Continuity tests In-Reply-To: <20040504174235.GK18911@frogman.motivity.ca> References: <5.2.1.1.0.20040430103240.04d9b250@IL06EXM13.corp.mot.com> <5.2.1.1.0.20040429114553.01e149b8@IL06EXM13.corp.mot.com> <5.2.1.1.0.20040429114553.01e149b8@IL06EXM13.corp.mot.com> <5.2.1.1.0.20040430103240.04d9b250@IL06EXM13.corp.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 ISUP COT request and response are coming to/from MGC and not to/from MG. Yes ISUP does not have a need, or opportunity to request the type of test, but MGC does. My point was that the type of test is provisioned with MGC and not MG as MGC and not MG is an ultimate entry that has information of where MG circuit (ds0) is eventually connected to. As such MGC has to be able to tell MG which COT test to perform. Aleks At 01:42 PM 5/4/2004, Vance Shipley wrote: >On Fri, Apr 30, 2004 at 10:39:14AM -0400, Aleksandr Ryabin wrote: >} >} There could be "dumb" switches in the middle of the path >} (for example DACS) which are not capable of any testing/signalling. >} Their only role is to split/redirect links and as such the nature >} of a circuit can change, and thus the type of COT test. > >The reason COT was included in ISUP is because of the possible >presence of DSO level DACS. If all interconnections were at the >E1 or DS1 level you would need only to monitor alarms and performance >reports at the span level to know about the integrity of those >circuits. If the bearer channels have been processed through a >DSO DACS or something similiar you can't use the span level >alarming/reporting. Even more importantly the likelyhood of a >problem is increased. A common problem is that the mapping was >done in error. COT testing tests this by requesting a loopback >and checking that what is sent is received while the loopback is >in place. > >The COT request and response is binary. There is no need or >opportunity to request the type of test as the type of test is >provisioned with the circuits. > > -Vance _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed May 5 10:07:41 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14208 for ; Wed, 5 May 2004 10:07:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLN0D-0002Ex-Lx; Wed, 05 May 2004 10:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLMv0-0006n4-B1 for megaco@optimus.ietf.org; Wed, 05 May 2004 09:58:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13576 for ; Wed, 5 May 2004 09:58:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLMuy-0000PI-5J for megaco@ietf.org; Wed, 05 May 2004 09:58:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLMtz-0000Bg-00 for megaco@ietf.org; Wed, 05 May 2004 09:57:36 -0400 Received: from cpe.atm2-0-52168.0x50c7e75e.arcnxx12.customer.tele.dk ([80.199.231.94] helo=ECT-SERVER.ECT) by ietf-mx with esmtp (Exim 4.12) id 1BLMtS-0007ly-00 for megaco@ietf.org; Wed, 05 May 2004 09:57:02 -0400 Date: Wed, 5 May 2004 15:58:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: What can megaco do that H.450 can't??? Thread-Index: AcQyqL7cBG+UYrPxTpyyvxCGZBYbvA== From: "Michael Steen Ebbesen" content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Megaco] What can megaco do that H.450 can't??? Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi people. I am just starting on a new project with the OpenH323 framework. When I = see products that offer analouge phone to VoIP (MTA / ATA) they support = megaco. Why is that??? From what I can see the H.450 can do the same = things(call transfer, conferance and so on). Hope some of you can clear this up for me.=20 Thanks upfront Michal E --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.675 / Virus Database: 437 - Release Date: 5/2/2004 =20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed May 5 10:23:27 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15716 for ; Wed, 5 May 2004 10:23:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNFx-00029s-DC for megaco-archive@odin.ietf.org; Wed, 05 May 2004 10:20:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45EKHak008284 for megaco-archive@odin.ietf.org; Wed, 5 May 2004 10:20:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLN9B-00079f-H7 for megaco-web-archive@optimus.ietf.org; Wed, 05 May 2004 10:13:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14776 for ; Wed, 5 May 2004 10:13:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLN99-0003b3-5o for megaco-web-archive@ietf.org; Wed, 05 May 2004 10:13:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLN7e-0003Fb-00 for megaco-web-archive@ietf.org; Wed, 05 May 2004 10:11:42 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BLN7K-00031T-02 for megaco-web-archive@ietf.org; Wed, 05 May 2004 10:11:22 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BLN3K-0003Pb-Km for megaco-web-archive@ietf.org; Wed, 05 May 2004 10:07:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLN0D-0002Ex-Lx; Wed, 05 May 2004 10:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLMv0-0006n4-B1 for megaco@optimus.ietf.org; Wed, 05 May 2004 09:58:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13576 for ; Wed, 5 May 2004 09:58:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLMuy-0000PI-5J for megaco@ietf.org; Wed, 05 May 2004 09:58:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLMtz-0000Bg-00 for megaco@ietf.org; Wed, 05 May 2004 09:57:36 -0400 Received: from cpe.atm2-0-52168.0x50c7e75e.arcnxx12.customer.tele.dk ([80.199.231.94] helo=ECT-SERVER.ECT) by ietf-mx with esmtp (Exim 4.12) id 1BLMtS-0007ly-00 for megaco@ietf.org; Wed, 05 May 2004 09:57:02 -0400 Date: Wed, 5 May 2004 15:58:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: What can megaco do that H.450 can't??? Thread-Index: AcQyqL7cBG+UYrPxTpyyvxCGZBYbvA== From: "Michael Steen Ebbesen" content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 To: Content-Transfer-Encoding: quoted-printable Subject: [Megaco] What can megaco do that H.450 can't??? 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi people. I am just starting on a new project with the OpenH323 framework. When I = see products that offer analouge phone to VoIP (MTA / ATA) they support = megaco. Why is that??? From what I can see the H.450 can do the same = things(call transfer, conferance and so on). Hope some of you can clear this up for me.=20 Thanks upfront Michal E --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.675 / Virus Database: 437 - Release Date: 5/2/2004 =20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed May 5 10:34:50 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16462 for ; Wed, 5 May 2004 10:34:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNGs-0002Vm-C3; Wed, 05 May 2004 10:21:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNFO-0001pT-D2 for megaco@optimus.ietf.org; Wed, 05 May 2004 10:19:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15567 for ; Wed, 5 May 2004 10:19:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLNFL-0005Ji-0a for megaco@ietf.org; Wed, 05 May 2004 10:19:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLNEN-00055u-00 for megaco@ietf.org; Wed, 05 May 2004 10:18:40 -0400 Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com) by ietf-mx with smtp (Exim 4.12) id 1BLNDv-0004sV-00 for megaco@ietf.org; Wed, 05 May 2004 10:18:11 -0400 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1083610850; Wed May 5 17:26:57 2004 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id ; Wed, 5 May 2004 17:16:24 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F3810166F4@MAILSERVER> From: Raphael Tryster To: "'Kevin Boyle'" , Fernando Vallejo Lazaro , Dan Elbert Cc: megaco@ietf.org Subject: RE: [Megaco] Caller Id signal Date: Wed, 5 May 2004 17:16:21 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C432B3.EBE9A830" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 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_01C432B3.EBE9A830 Content-Type: text/plain Can andisp/dwa be used for any services other than caller id? By comparison, andisp/data maps to more than one MGCP signal type. Is there a one-to-one mapping between andisp/dwa and MGCP L/ci, execpt that the data is in a different format, or does andisp/dwa have a wider scope? Raphael Tryster -----Original Message----- From: Kevin Boyle [SMTP:kboyle@nortelnetworks.com] Sent: Friday, 25 October 2002 10:01 To: Fernando Vallejo Lazaro; Dan Elbert Cc: megaco@ietf.org Subject: RE: [Megaco] Caller Id signal To clarify, andisp/dwa is specifically meant for display services with integrated alerting (Caller ID, Caller ID on Call Waiting), and andisp/data is meant for data transfer that is not associated with alerting (Message Waiting, Short Message Service, ADSI, etc.) Kevin -----Original Message----- From: Fernando Vallejo Lazaro [mailto:Fernando.Vallejo_Lazaro@alcatel.es] Sent: Friday, October 25, 2002 2:57 AM To: Dan Elbert Cc: megaco@ietf.org Subject: Re: [Megaco] Caller Id signal Hi, You can use the andisp package with the data and dwa parameters. Regards Fernando Dan Elbert wrote: Hi Is there a signal defined for Caller Id for an analog phone ? Thanks Dan Elbert RADVISION _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco -- Fernando Vallejo Lazaro Phone: +34 91 330 8279 SW Wireline ASD-Madrid ALCATEL _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C432B3.EBE9A830 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Megaco] Caller Id signal

Can andisp/dwa be used for any services = other than caller id?  By comparison, andisp/data maps to more than = one MGCP signal type.  Is there a one-to-one mapping between andisp/= dwa and MGCP L/ci, execpt that the data is in a different format, or does= andisp/dwa have a wider scope?

Raphael Tryster

    -----Original Mess= age-----
    From:   Kevin Boyle [SMTP:= kboyle@nortelnetworks.com]
    Sent:   Friday, 25 October 2002 10:01
    To:     Fernando Vallejo Lazaro; Dan Elbert
    Cc:     megaco@ietf.org
    Subject:    &nbs= p;   RE: [Megaco] Call= er Id signal

    To clarify, andisp/dwa is specific= ally meant for display services with
    integrated alerting (Caller ID, C= aller ID on Call Waiting), and andisp/data
    is meant for data transfer that i= s not associated with alerting (Message
    Waiting, Short Message Service, A= DSI, etc.)
     
    Kevin

    -----Original Message-----
    From: Fernando Vallejo Lazaro [mailto:Fernando.Valle= jo_Lazaro@alcatel.es]
    Sent: Friday, October 25, 2002 2:= 57 AM
    To: Dan Elbert
    Cc: megaco@ietf.org
    Subject: Re: [Megaco] Caller Id s= ignal


    Hi,

    You can use the andisp package
    with the data and dwa parameters.=


    Regards
    Fernando


    Dan Elbert wrote:


    Hi
    Is there a signal defined for Cal= ler Id for an analog phone ?
    Thanks

    Dan Elbert
    RADVISION
    _________________________________= ______________
    Megaco mailing list
    Megaco@ietf.org
    https://www1.ietf.org/mailman/= listinfo/megaco
    <https://www1.ietf.org/mail= man/listinfo/megaco>

    --

    Fernando Vallejo Lazaro

    Phone:  +34 91 330 8279

    SW  Wireline ASD-Madrid

         &nbs= p; ALCATEL
     

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

------_=_NextPart_001_01C432B3.EBE9A830-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed May 5 11:00:25 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18368 for ; Wed, 5 May 2004 11:00:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNb1-0000l6-9j for megaco-archive@odin.ietf.org; Wed, 05 May 2004 10:42:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45Eg3SM002911 for megaco-archive@odin.ietf.org; Wed, 5 May 2004 10:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNV3-00071h-I2 for megaco-web-archive@optimus.ietf.org; Wed, 05 May 2004 10:35:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16609 for ; Wed, 5 May 2004 10:35:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLNV1-0001OH-73 for megaco-web-archive@ietf.org; Wed, 05 May 2004 10:35:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLNUE-00019I-00 for megaco-web-archive@ietf.org; Wed, 05 May 2004 10:35:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLNTa-0000t9-00 for megaco-web-archive@ietf.org; Wed, 05 May 2004 10:34:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNGs-0002Vm-C3; Wed, 05 May 2004 10:21:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNFO-0001pT-D2 for megaco@optimus.ietf.org; Wed, 05 May 2004 10:19:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15567 for ; Wed, 5 May 2004 10:19:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLNFL-0005Ji-0a for megaco@ietf.org; Wed, 05 May 2004 10:19:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLNEN-00055u-00 for megaco@ietf.org; Wed, 05 May 2004 10:18:40 -0400 Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com) by ietf-mx with smtp (Exim 4.12) id 1BLNDv-0004sV-00 for megaco@ietf.org; Wed, 05 May 2004 10:18:11 -0400 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1083610850; Wed May 5 17:26:57 2004 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id ; Wed, 5 May 2004 17:16:24 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F3810166F4@MAILSERVER> From: Raphael Tryster To: "'Kevin Boyle'" , Fernando Vallejo Lazaro , Dan Elbert Cc: megaco@ietf.org Subject: RE: [Megaco] Caller Id signal Date: Wed, 5 May 2004 17:16:21 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C432B3.EBE9A830" 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 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_01C432B3.EBE9A830 Content-Type: text/plain Can andisp/dwa be used for any services other than caller id? By comparison, andisp/data maps to more than one MGCP signal type. Is there a one-to-one mapping between andisp/dwa and MGCP L/ci, execpt that the data is in a different format, or does andisp/dwa have a wider scope? Raphael Tryster -----Original Message----- From: Kevin Boyle [SMTP:kboyle@nortelnetworks.com] Sent: Friday, 25 October 2002 10:01 To: Fernando Vallejo Lazaro; Dan Elbert Cc: megaco@ietf.org Subject: RE: [Megaco] Caller Id signal To clarify, andisp/dwa is specifically meant for display services with integrated alerting (Caller ID, Caller ID on Call Waiting), and andisp/data is meant for data transfer that is not associated with alerting (Message Waiting, Short Message Service, ADSI, etc.) Kevin -----Original Message----- From: Fernando Vallejo Lazaro [mailto:Fernando.Vallejo_Lazaro@alcatel.es] Sent: Friday, October 25, 2002 2:57 AM To: Dan Elbert Cc: megaco@ietf.org Subject: Re: [Megaco] Caller Id signal Hi, You can use the andisp package with the data and dwa parameters. Regards Fernando Dan Elbert wrote: Hi Is there a signal defined for Caller Id for an analog phone ? Thanks Dan Elbert RADVISION _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco -- Fernando Vallejo Lazaro Phone: +34 91 330 8279 SW Wireline ASD-Madrid ALCATEL _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C432B3.EBE9A830 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Megaco] Caller Id signal

Can andisp/dwa be used for any services = other than caller id?  By comparison, andisp/data maps to more than = one MGCP signal type.  Is there a one-to-one mapping between andisp/= dwa and MGCP L/ci, execpt that the data is in a different format, or does= andisp/dwa have a wider scope?

Raphael Tryster

    -----Original Mess= age-----
    From:   Kevin Boyle [SMTP:= kboyle@nortelnetworks.com]
    Sent:   Friday, 25 October 2002 10:01
    To:     Fernando Vallejo Lazaro; Dan Elbert
    Cc:     megaco@ietf.org
    Subject:    &nbs= p;   RE: [Megaco] Call= er Id signal

    To clarify, andisp/dwa is specific= ally meant for display services with
    integrated alerting (Caller ID, C= aller ID on Call Waiting), and andisp/data
    is meant for data transfer that i= s not associated with alerting (Message
    Waiting, Short Message Service, A= DSI, etc.)
     
    Kevin

    -----Original Message-----
    From: Fernando Vallejo Lazaro [mailto:Fernando.Valle= jo_Lazaro@alcatel.es]
    Sent: Friday, October 25, 2002 2:= 57 AM
    To: Dan Elbert
    Cc: megaco@ietf.org
    Subject: Re: [Megaco] Caller Id s= ignal


    Hi,

    You can use the andisp package
    with the data and dwa parameters.=


    Regards
    Fernando


    Dan Elbert wrote:


    Hi
    Is there a signal defined for Cal= ler Id for an analog phone ?
    Thanks

    Dan Elbert
    RADVISION
    _________________________________= ______________
    Megaco mailing list
    Megaco@ietf.org
    https://www1.ietf.org/mailman/= listinfo/megaco
    <https://www1.ietf.org/mail= man/listinfo/megaco>

    --

    Fernando Vallejo Lazaro

    Phone:  +34 91 330 8279

    SW  Wireline ASD-Madrid

         &nbs= p; ALCATEL
     

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

------_=_NextPart_001_01C432B3.EBE9A830-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed May 5 11:12:54 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19953 for ; Wed, 5 May 2004 11:12:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNvL-0000rE-NX; Wed, 05 May 2004 11:03:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNiQ-0003GZ-Is for megaco@optimus.ietf.org; Wed, 05 May 2004 10:49:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17406 for ; Wed, 5 May 2004 10:49:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLNiO-0004vy-2d for megaco@ietf.org; Wed, 05 May 2004 10:49:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLNhM-0004fy-00 for megaco@ietf.org; Wed, 05 May 2004 10:48:37 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1BLNgN-0004DR-00 for megaco@ietf.org; Wed, 05 May 2004 10:47:35 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i45El3811725 for ; Wed, 5 May 2004 10:47:03 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 May 2004 10:47:04 -0400 Message-ID: From: "Kevin Boyle" To: Raphael Tryster , Fernando Vallejo Lazaro , Dan Elbert Cc: megaco@ietf.org Subject: RE: [Megaco] Caller Id signal Date: Wed, 5 May 2004 10:47:01 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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: , dwa is intended to be used for any analog data signalling that is associated with alerting. Generally speaking, this is limited to callerID, but if there are other applications that fit the signal, then I don't see any need to limit the applicability of the package. I would note that the MGCP caller ID signal has significant problems if you want to get beyond simple name and number. The H.248 signal was designed without taking any consideration of the MGCP signal, other than the fact that the MGCP signal is entirely inadequate for the full functionality of callerID. Kevin _____ From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Wednesday, May 05, 2004 11:16 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Fernando Vallejo Lazaro; Dan Elbert Cc: megaco@ietf.org Subject: RE: [Megaco] Caller Id signal Can andisp/dwa be used for any services other than caller id? By comparison, andisp/data maps to more than one MGCP signal type. Is there a one-to-one mapping between andisp/dwa and MGCP L/ci, execpt that the data is in a different format, or does andisp/dwa have a wider scope? Raphael Tryster BM__MailData-----Original Message----- From: Kevin Boyle [SMTP:kboyle@nortelnetworks.com] Sent: Friday, 25 October 2002 10:01 To: Fernando Vallejo Lazaro; Dan Elbert Cc: megaco@ietf.org Subject: RE: [Megaco] Caller Id signal To clarify, andisp/dwa is specifically meant for display services with integrated alerting (Caller ID, Caller ID on Call Waiting), and andisp/data is meant for data transfer that is not associated with alerting (Message Waiting, Short Message Service, ADSI, etc.) Kevin -----Original Message----- From: Fernando Vallejo Lazaro [mailto:Fernando.Vallejo_Lazaro@alcatel.es ] Sent: Friday, October 25, 2002 2:57 AM To: Dan Elbert Cc: megaco@ietf.org Subject: Re: [Megaco] Caller Id signal Hi, You can use the andisp package with the data and dwa parameters. Regards Fernando Dan Elbert wrote: Hi Is there a signal defined for Caller Id for an analog phone ? Thanks Dan Elbert RADVISION _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > -- Fernando Vallejo Lazaro Phone: +34 91 330 8279 SW Wireline ASD-Madrid ALCATEL _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed May 5 11:35:27 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21333 for ; Wed, 5 May 2004 11:35:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLOFK-0002eT-EB for megaco-archive@odin.ietf.org; Wed, 05 May 2004 11:23:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45FNgtZ010194 for megaco-archive@odin.ietf.org; Wed, 5 May 2004 11:23:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLO61-0007W9-Rx for megaco-web-archive@optimus.ietf.org; Wed, 05 May 2004 11:14:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20073 for ; Wed, 5 May 2004 11:14:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLO61-0004Xt-6O for megaco-web-archive@ietf.org; Wed, 05 May 2004 11:14:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLO55-0004HR-00 for megaco-web-archive@ietf.org; Wed, 05 May 2004 11:13:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLO4Q-0003zB-00 for megaco-web-archive@ietf.org; Wed, 05 May 2004 11:12:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNvL-0000rE-NX; Wed, 05 May 2004 11:03:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNiQ-0003GZ-Is for megaco@optimus.ietf.org; Wed, 05 May 2004 10:49:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17406 for ; Wed, 5 May 2004 10:49:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLNiO-0004vy-2d for megaco@ietf.org; Wed, 05 May 2004 10:49:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLNhM-0004fy-00 for megaco@ietf.org; Wed, 05 May 2004 10:48:37 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1BLNgN-0004DR-00 for megaco@ietf.org; Wed, 05 May 2004 10:47:35 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i45El3811725 for ; Wed, 5 May 2004 10:47:03 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 May 2004 10:47:04 -0400 Message-ID: From: "Kevin Boyle" To: Raphael Tryster , Fernando Vallejo Lazaro , Dan Elbert Cc: megaco@ietf.org Subject: RE: [Megaco] Caller Id signal Date: Wed, 5 May 2004 10:47:01 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 dwa is intended to be used for any analog data signalling that is associated with alerting. Generally speaking, this is limited to callerID, but if there are other applications that fit the signal, then I don't see any need to limit the applicability of the package. I would note that the MGCP caller ID signal has significant problems if you want to get beyond simple name and number. The H.248 signal was designed without taking any consideration of the MGCP signal, other than the fact that the MGCP signal is entirely inadequate for the full functionality of callerID. Kevin _____ From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Wednesday, May 05, 2004 11:16 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Fernando Vallejo Lazaro; Dan Elbert Cc: megaco@ietf.org Subject: RE: [Megaco] Caller Id signal Can andisp/dwa be used for any services other than caller id? By comparison, andisp/data maps to more than one MGCP signal type. Is there a one-to-one mapping between andisp/dwa and MGCP L/ci, execpt that the data is in a different format, or does andisp/dwa have a wider scope? Raphael Tryster BM__MailData-----Original Message----- From: Kevin Boyle [SMTP:kboyle@nortelnetworks.com] Sent: Friday, 25 October 2002 10:01 To: Fernando Vallejo Lazaro; Dan Elbert Cc: megaco@ietf.org Subject: RE: [Megaco] Caller Id signal To clarify, andisp/dwa is specifically meant for display services with integrated alerting (Caller ID, Caller ID on Call Waiting), and andisp/data is meant for data transfer that is not associated with alerting (Message Waiting, Short Message Service, ADSI, etc.) Kevin -----Original Message----- From: Fernando Vallejo Lazaro [mailto:Fernando.Vallejo_Lazaro@alcatel.es ] Sent: Friday, October 25, 2002 2:57 AM To: Dan Elbert Cc: megaco@ietf.org Subject: Re: [Megaco] Caller Id signal Hi, You can use the andisp package with the data and dwa parameters. Regards Fernando Dan Elbert wrote: Hi Is there a signal defined for Caller Id for an analog phone ? Thanks Dan Elbert RADVISION _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > -- Fernando Vallejo Lazaro Phone: +34 91 330 8279 SW Wireline ASD-Madrid ALCATEL _______________________________________________ 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 May 5 13:37:53 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28144 for ; Wed, 5 May 2004 13:37:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQDb-0001Yf-8i; Wed, 05 May 2004 13:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQ9n-0007cF-IS for megaco@optimus.ietf.org; Wed, 05 May 2004 13:26:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27559 for ; Wed, 5 May 2004 13:26:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLQ9l-0000sN-G1 for megaco@ietf.org; Wed, 05 May 2004 13:26:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLQ8s-0000b9-00 for megaco@ietf.org; Wed, 05 May 2004 13:25:10 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1BLQ87-0000Gj-00 for megaco@ietf.org; Wed, 05 May 2004 13:24:23 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i45HNnx12353; Wed, 5 May 2004 13:23:49 -0400 (EDT) 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 JCT8PJ8Q; Wed, 5 May 2004 13:23:50 -0400 Received: from nortelnetworks.com (acart1cz.ca.nortel.com [47.129.129.75]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCVF1NKA; Wed, 5 May 2004 13:23:50 -0400 Message-ID: <40992324.4000006@nortelnetworks.com> Date: Wed, 05 May 2004 13:23:48 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Steen Ebbesen CC: megaco@ietf.org Subject: Re: [Megaco] What can megaco do that H.450 can't??? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 key point you're missing is the idea of the decomposed gateway. There's an adapter between the analogue phones and the IP network. In the Megaco view, this adapter carries stimulus signalling from the phones to the call processing element on the IP side, while adapting the voice content to IP (i.e., by encoding it and encapsulating it in RTP). The call processing element may well be the call control part of an H.323 gateway, using H.450 to the other end once it has resolved the stimulus signalling to requests for service. Aside from capturing the signalling events, Megaco allows the call processing element to control the flow of media between the network and the phone -- a necessary part of services such as call transfer and the like. Michael Steen Ebbesen wrote: > Hi people. > > I am just starting on a new project with the OpenH323 framework. When I see products that offer analouge phone to VoIP (MTA / ATA) they support megaco. Why is that??? From what I can see the H.450 can do the same things(call transfer, conferance and so on). > Hope some of you can clear this up for me. > > Thanks upfront > > Michal E > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.675 / Virus Database: 437 - Release Date: 5/2/2004 > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed May 5 13:52:40 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29499 for ; Wed, 5 May 2004 13:52:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQRJ-0001cr-CN for megaco-archive@odin.ietf.org; Wed, 05 May 2004 13:44:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45HiD67006250 for megaco-archive@odin.ietf.org; Wed, 5 May 2004 13:44:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQMG-0007m2-RX for megaco-web-archive@optimus.ietf.org; Wed, 05 May 2004 13:39:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28241 for ; Wed, 5 May 2004 13:38:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLQME-0004VV-Nr for megaco-web-archive@ietf.org; Wed, 05 May 2004 13:38:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLQLO-0004Eb-00 for megaco-web-archive@ietf.org; Wed, 05 May 2004 13:38:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLQKh-0003x9-00 for megaco-web-archive@ietf.org; Wed, 05 May 2004 13:37:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQDb-0001Yf-8i; Wed, 05 May 2004 13:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQ9n-0007cF-IS for megaco@optimus.ietf.org; Wed, 05 May 2004 13:26:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27559 for ; Wed, 5 May 2004 13:26:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLQ9l-0000sN-G1 for megaco@ietf.org; Wed, 05 May 2004 13:26:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLQ8s-0000b9-00 for megaco@ietf.org; Wed, 05 May 2004 13:25:10 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1BLQ87-0000Gj-00 for megaco@ietf.org; Wed, 05 May 2004 13:24:23 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i45HNnx12353; Wed, 5 May 2004 13:23:49 -0400 (EDT) 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 JCT8PJ8Q; Wed, 5 May 2004 13:23:50 -0400 Received: from nortelnetworks.com (acart1cz.ca.nortel.com [47.129.129.75]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCVF1NKA; Wed, 5 May 2004 13:23:50 -0400 Message-ID: <40992324.4000006@nortelnetworks.com> Date: Wed, 05 May 2004 13:23:48 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Steen Ebbesen CC: megaco@ietf.org Subject: Re: [Megaco] What can megaco do that H.450 can't??? 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The key point you're missing is the idea of the decomposed gateway. There's an adapter between the analogue phones and the IP network. In the Megaco view, this adapter carries stimulus signalling from the phones to the call processing element on the IP side, while adapting the voice content to IP (i.e., by encoding it and encapsulating it in RTP). The call processing element may well be the call control part of an H.323 gateway, using H.450 to the other end once it has resolved the stimulus signalling to requests for service. Aside from capturing the signalling events, Megaco allows the call processing element to control the flow of media between the network and the phone -- a necessary part of services such as call transfer and the like. Michael Steen Ebbesen wrote: > Hi people. > > I am just starting on a new project with the OpenH323 framework. When I see products that offer analouge phone to VoIP (MTA / ATA) they support megaco. Why is that??? From what I can see the H.450 can do the same things(call transfer, conferance and so on). > Hope some of you can clear this up for me. > > Thanks upfront > > Michal E > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.675 / Virus Database: 437 - Release Date: 5/2/2004 > > > _______________________________________________ > 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 May 6 02:35:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22108 for ; Thu, 6 May 2004 02:35:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLcPR-0003UM-B9; Thu, 06 May 2004 02:31:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLcNo-0002dR-Vk for megaco@optimus.ietf.org; Thu, 06 May 2004 02:29:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21745 for ; Thu, 6 May 2004 02:29:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLcNl-0000Pr-Bi for megaco@ietf.org; Thu, 06 May 2004 02:29:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLcMm-00004y-00 for megaco@ietf.org; Thu, 06 May 2004 02:28:20 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BLcLt-0007YL-00 for megaco@ietf.org; Thu, 06 May 2004 02:27:25 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i466RPPA021800 for ; Thu, 6 May 2004 08:27:25 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 May 2004 08:27:25 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id KGJBBM5V; Thu, 6 May 2004 08:27:25 +0200 Received: from ericsson.com (sealwa04-238.sw.ericsson.se [130.100.249.238]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JRYY85ZT; Thu, 6 May 2004 16:27:00 +1000 Message-ID: <4099DAC4.4040304@ericsson.com> Date: Thu, 06 May 2004 16:27:16 +1000 X-Sybari-Trust: fedf6336 08d63d2e d46d19c5 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco ietf Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 May 2004 06:27:25.0853 (UTC) FILETIME=[329A2CD0:01C43333] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Megaco] H.248 Related ITU SG16 Contributions Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello all, As Q.3 Rapporteur I like to inform you that the H.248 related contributions to the upcoming ITU SG16 meeting can be found at: http://ftp3.itu.int/av-arch/avc-site/0405_Bei/ ftp://avguest:Avguest@ftp3.itu.int/avc-site/0405_Bei/ The file: ftp://avguest:Avguest@ftp3.itu.int/0405_Bei/0504_Bei.html contains the list of documents. Some documents contained in the list have yet to be uploaded. Regards, Christian _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu May 6 02:39:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22403 for ; Thu, 6 May 2004 02:39:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLcWJ-0006Pg-Np for megaco-archive@odin.ietf.org; Thu, 06 May 2004 02:38:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i466cB2P024645 for megaco-archive@odin.ietf.org; Thu, 6 May 2004 02:38:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLcUt-0005SW-25 for megaco-web-archive@optimus.ietf.org; Thu, 06 May 2004 02:36:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22202 for ; Thu, 6 May 2004 02:36:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLcUp-0002ym-Dp for megaco-web-archive@ietf.org; Thu, 06 May 2004 02:36:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLcTp-0002bu-00 for megaco-web-archive@ietf.org; Thu, 06 May 2004 02:35:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLcTI-0002Fv-00 for megaco-web-archive@ietf.org; Thu, 06 May 2004 02:35:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLcPR-0003UM-B9; Thu, 06 May 2004 02:31:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLcNo-0002dR-Vk for megaco@optimus.ietf.org; Thu, 06 May 2004 02:29:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21745 for ; Thu, 6 May 2004 02:29:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLcNl-0000Pr-Bi for megaco@ietf.org; Thu, 06 May 2004 02:29:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLcMm-00004y-00 for megaco@ietf.org; Thu, 06 May 2004 02:28:20 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BLcLt-0007YL-00 for megaco@ietf.org; Thu, 06 May 2004 02:27:25 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i466RPPA021800 for ; Thu, 6 May 2004 08:27:25 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 May 2004 08:27:25 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id KGJBBM5V; Thu, 6 May 2004 08:27:25 +0200 Received: from ericsson.com (sealwa04-238.sw.ericsson.se [130.100.249.238]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JRYY85ZT; Thu, 6 May 2004 16:27:00 +1000 Message-ID: <4099DAC4.4040304@ericsson.com> Date: Thu, 06 May 2004 16:27:16 +1000 X-Sybari-Trust: fedf6336 08d63d2e d46d19c5 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco ietf Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 May 2004 06:27:25.0853 (UTC) FILETIME=[329A2CD0:01C43333] Content-Transfer-Encoding: 7bit Subject: [Megaco] H.248 Related ITU SG16 Contributions 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello all, As Q.3 Rapporteur I like to inform you that the H.248 related contributions to the upcoming ITU SG16 meeting can be found at: http://ftp3.itu.int/av-arch/avc-site/0405_Bei/ ftp://avguest:Avguest@ftp3.itu.int/avc-site/0405_Bei/ The file: ftp://avguest:Avguest@ftp3.itu.int/0405_Bei/0504_Bei.html contains the list of documents. Some documents contained in the list have yet to be uploaded. Regards, Christian _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu May 6 09:23:24 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11651 for ; Thu, 6 May 2004 09:23:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLiiN-0007bg-Ur; Thu, 06 May 2004 09:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLig8-0006bg-6I for megaco@optimus.ietf.org; Thu, 06 May 2004 09:12:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11110 for ; Thu, 6 May 2004 09:12:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLig6-0006pN-K1 for megaco@ietf.org; Thu, 06 May 2004 09:12:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLifB-0006RP-00 for megaco@ietf.org; Thu, 06 May 2004 09:11:45 -0400 Received: from web41812.mail.yahoo.com ([66.218.93.146]) by ietf-mx with smtp (Exim 4.12) id 1BLiep-00063L-00 for megaco@ietf.org; Thu, 06 May 2004 09:11:23 -0400 Message-ID: <20040506131050.57777.qmail@web41812.mail.yahoo.com> Received: from [128.107.253.41] by web41812.mail.yahoo.com via HTTP; Thu, 06 May 2004 06:10:50 PDT Date: Thu, 6 May 2004 06:10:50 -0700 (PDT) From: megaco learner To: megaco ietf MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-682913668-1083849050=:56879" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Subject: [Megaco] Call Progress Tones. 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-682913668-1083849050=:56879 Content-Type: text/plain; charset=us-ascii Hi, May sound novice, but want to know what is the difference between the call progress tones(CPT) being played onTDM terminitaions vis-a-vis RTP termination. Is it a mere redundant way(CPT on RTP Terms) to tell the GW to play the Tones, because anyway the tones can be heard on TDM side when played on RTP Termination(???) . Thanks in Advance, Learner. --------------------------------- Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs --0-682913668-1083849050=:56879 Content-Type: text/html; charset=us-ascii
Hi,
 
May sound novice, but want to know what is the difference between the call progress tones(CPT) being played onTDM terminitaions vis-a-vis RTP termination.
Is it a mere redundant way(CPT on RTP Terms) to tell the GW to play the Tones,
because anyway the tones can be heard on TDM side when played on RTP Termination(???) .
 
 
Thanks in Advance,
Learner.
 
 
 

Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs --0-682913668-1083849050=:56879-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu May 6 09:33:39 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12119 for ; Thu, 6 May 2004 09:33:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLizJ-0004Z2-8Z for megaco-archive@odin.ietf.org; Thu, 06 May 2004 09:32:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46DWXgO017540 for megaco-archive@odin.ietf.org; Thu, 6 May 2004 09:32:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLirn-0002N5-16 for megaco-web-archive@optimus.ietf.org; Thu, 06 May 2004 09:24:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11714 for ; Thu, 6 May 2004 09:24:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLirl-0003rN-Bo for megaco-web-archive@ietf.org; Thu, 06 May 2004 09:24:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLiqn-0003T1-00 for megaco-web-archive@ietf.org; Thu, 06 May 2004 09:23:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLipz-00035J-00 for megaco-web-archive@ietf.org; Thu, 06 May 2004 09:22:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLiiN-0007bg-Ur; Thu, 06 May 2004 09:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLig8-0006bg-6I for megaco@optimus.ietf.org; Thu, 06 May 2004 09:12:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11110 for ; Thu, 6 May 2004 09:12:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLig6-0006pN-K1 for megaco@ietf.org; Thu, 06 May 2004 09:12:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLifB-0006RP-00 for megaco@ietf.org; Thu, 06 May 2004 09:11:45 -0400 Received: from web41812.mail.yahoo.com ([66.218.93.146]) by ietf-mx with smtp (Exim 4.12) id 1BLiep-00063L-00 for megaco@ietf.org; Thu, 06 May 2004 09:11:23 -0400 Message-ID: <20040506131050.57777.qmail@web41812.mail.yahoo.com> Received: from [128.107.253.41] by web41812.mail.yahoo.com via HTTP; Thu, 06 May 2004 06:10:50 PDT Date: Thu, 6 May 2004 06:10:50 -0700 (PDT) From: megaco learner To: megaco ietf MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-682913668-1083849050=:56879" Subject: [Megaco] Call Progress Tones. 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 --0-682913668-1083849050=:56879 Content-Type: text/plain; charset=us-ascii Hi, May sound novice, but want to know what is the difference between the call progress tones(CPT) being played onTDM terminitaions vis-a-vis RTP termination. Is it a mere redundant way(CPT on RTP Terms) to tell the GW to play the Tones, because anyway the tones can be heard on TDM side when played on RTP Termination(???) . Thanks in Advance, Learner. --------------------------------- Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs --0-682913668-1083849050=:56879 Content-Type: text/html; charset=us-ascii
Hi,
 
May sound novice, but want to know what is the difference between the call progress tones(CPT) being played onTDM terminitaions vis-a-vis RTP termination.
Is it a mere redundant way(CPT on RTP Terms) to tell the GW to play the Tones,
because anyway the tones can be heard on TDM side when played on RTP Termination(???) .
 
 
Thanks in Advance,
Learner.
 
 
 

Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs --0-682913668-1083849050=:56879-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu May 6 09:52:48 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13485 for ; Thu, 6 May 2004 09:52:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjBO-0000r0-Jx; Thu, 06 May 2004 09:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLj4O-0007FQ-OC for megaco@optimus.ietf.org; Thu, 06 May 2004 09:37:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12376 for ; Thu, 6 May 2004 09:37:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLj4M-0001KJ-KT for megaco@ietf.org; Thu, 06 May 2004 09:37:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLj3b-0000w6-00 for megaco@ietf.org; Thu, 06 May 2004 09:36:59 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BLj2d-00007F-00 for megaco@ietf.org; Thu, 06 May 2004 09:35:59 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i46DZRE08688 for ; Thu, 6 May 2004 09:35:27 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 May 2004 09:35:28 -0400 Message-ID: From: "Kevin Boyle" To: megaco learner , megaco ietf Subject: RE: [Megaco] Call Progress Tones. Date: Thu, 6 May 2004 09:35:24 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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: , Remember that signals progress toward the EXTERIOR of the context, unless specified otherwise. So, playing a tone on an ephemeral plays the tone toward the packet network, not the TDM circuit. There are many different call scenarios that could make use of this kind of function. Kevin _____ From: megaco learner [mailto:megaco_learner@yahoo.com] Sent: Thursday, May 06, 2004 9:11 AM To: megaco ietf Subject: [Megaco] Call Progress Tones. Hi, May sound novice, but want to know what is the difference between the call progress tones(CPT) being played onTDM terminitaions vis-a-vis RTP termination. Is it a mere redundant way(CPT on RTP Terms) to tell the GW to play the Tones, because anyway the tones can be heard on TDM side when played on RTP Termination(???) . Thanks in Advance, Learner. _____ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu May 6 10:10:10 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15020 for ; Thu, 6 May 2004 10:10:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjSc-0001l5-PR for megaco-archive@odin.ietf.org; Thu, 06 May 2004 10:02:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46E2owD006760 for megaco-archive@odin.ietf.org; Thu, 6 May 2004 10:02:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjJp-0003nY-Lv for megaco-web-archive@optimus.ietf.org; Thu, 06 May 2004 09:53:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13529 for ; Thu, 6 May 2004 09:53:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLjJn-0000fY-IB for megaco-web-archive@ietf.org; Thu, 06 May 2004 09:53:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLjIv-0000H1-00 for megaco-web-archive@ietf.org; Thu, 06 May 2004 09:52:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLjIR-0007fS-00 for megaco-web-archive@ietf.org; Thu, 06 May 2004 09:52:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjBO-0000r0-Jx; Thu, 06 May 2004 09:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLj4O-0007FQ-OC for megaco@optimus.ietf.org; Thu, 06 May 2004 09:37:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12376 for ; Thu, 6 May 2004 09:37:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLj4M-0001KJ-KT for megaco@ietf.org; Thu, 06 May 2004 09:37:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLj3b-0000w6-00 for megaco@ietf.org; Thu, 06 May 2004 09:36:59 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BLj2d-00007F-00 for megaco@ietf.org; Thu, 06 May 2004 09:35:59 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i46DZRE08688 for ; Thu, 6 May 2004 09:35:27 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 May 2004 09:35:28 -0400 Message-ID: From: "Kevin Boyle" To: megaco learner , megaco ietf Subject: RE: [Megaco] Call Progress Tones. Date: Thu, 6 May 2004 09:35:24 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Remember that signals progress toward the EXTERIOR of the context, unless specified otherwise. So, playing a tone on an ephemeral plays the tone toward the packet network, not the TDM circuit. There are many different call scenarios that could make use of this kind of function. Kevin _____ From: megaco learner [mailto:megaco_learner@yahoo.com] Sent: Thursday, May 06, 2004 9:11 AM To: megaco ietf Subject: [Megaco] Call Progress Tones. Hi, May sound novice, but want to know what is the difference between the call progress tones(CPT) being played onTDM terminitaions vis-a-vis RTP termination. Is it a mere redundant way(CPT on RTP Terms) to tell the GW to play the Tones, because anyway the tones can be heard on TDM side when played on RTP Termination(???) . Thanks in Advance, Learner. _____ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri May 7 01:17:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11875 for ; Fri, 7 May 2004 01:17:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLxeU-0004nQ-PF; Fri, 07 May 2004 01:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLxVP-0001Ux-Gq for megaco@optimus.ietf.org; Fri, 07 May 2004 01:02:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11436 for ; Fri, 7 May 2004 01:02:37 -0400 (EDT) From: bvswamy@hss.hns.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLxVM-0000YB-NZ for megaco@ietf.org; Fri, 07 May 2004 01:02:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLxUQ-00007P-00 for megaco@ietf.org; Fri, 07 May 2004 01:01:39 -0400 Received: from spark.hss.co.in ([203.200.71.140]) by ietf-mx with esmtp (Exim 4.12) id 1BLxTl-0007TF-00 for megaco@ietf.org; Fri, 07 May 2004 01:00:57 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id i474x7X4017063; Fri, 7 May 2004 10:29:07 +0530 (IST) Subject: RE: [Megaco] Call Progress Tones. To: megaco learner Cc: megaco ietf Date: Fri, 7 May 2004 10:26:14 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 07/05/2004 10:19:30 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 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 example call scenario where you need to play the signal on the RTP termination is the Call waiting case where suppose A is currently talking to B(remote packet side subscriber) and another subscriber C calls A. Then A will be getting Call waiting tone on the TDM corresponding to A. On accepting the call waiting call by putting B on hold , MGC might play a Call Hold tone on the ephemeral termination corresponding to the subscriber B. Regards Venkat Hughes Software Systems www.hssworld.com "Kevin Boyle" @ietf.org on 05/06/2004 07:05:24 PM Sent by: megaco-admin@ietf.org To: megaco learner , megaco ietf cc: Subject: RE: [Megaco] Call Progress Tones. Remember that signals progress toward the EXTERIOR of the context, unless specified otherwise. So, playing a tone on an ephemeral plays the tone toward the packet network, not the TDM circuit. There are many different call scenarios that could make use of this kind of function. Kevin _____ From: megaco learner [mailto:megaco_learner@yahoo.com] Sent: Thursday, May 06, 2004 9:11 AM To: megaco ietf Subject: [Megaco] Call Progress Tones. Hi, May sound novice, but want to know what is the difference between the call progress tones(CPT) being played onTDM terminitaions vis-a-vis RTP termination. Is it a mere redundant way(CPT on RTP Terms) to tell the GW to play the Tones, because anyway the tones can be heard on TDM side when played on RTP Termination(???) . Thanks in Advance, Learner. _____ Do you Yahoo!? Win < http://pa.yahoo.com/*http://us.rd.yahoo.com/hotjobs/hotjobs_mail_signature_ footer_textlink/evt=23983/*http://hotjobs.sweepstakes.yahoo.com/careermakeov er> a $20,000 Career Makeover at Yahoo! HotJobs _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri May 7 01:23:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12119 for ; Fri, 7 May 2004 01:23:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLxng-0007GG-54 for megaco-archive@odin.ietf.org; Fri, 07 May 2004 01:21:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i475LW88027908 for megaco-archive@odin.ietf.org; Fri, 7 May 2004 01:21:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLxkq-0006IC-Bj for megaco-web-archive@optimus.ietf.org; Fri, 07 May 2004 01:18:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11966 for ; Fri, 7 May 2004 01:18:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLxkn-00075M-E5 for megaco-web-archive@ietf.org; Fri, 07 May 2004 01:18:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLxju-0006fy-00 for megaco-web-archive@ietf.org; Fri, 07 May 2004 01:17:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLxj7-0006Fu-00 for megaco-web-archive@ietf.org; Fri, 07 May 2004 01:16:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLxeU-0004nQ-PF; Fri, 07 May 2004 01:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLxVP-0001Ux-Gq for megaco@optimus.ietf.org; Fri, 07 May 2004 01:02:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11436 for ; Fri, 7 May 2004 01:02:37 -0400 (EDT) From: bvswamy@hss.hns.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLxVM-0000YB-NZ for megaco@ietf.org; Fri, 07 May 2004 01:02:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLxUQ-00007P-00 for megaco@ietf.org; Fri, 07 May 2004 01:01:39 -0400 Received: from spark.hss.co.in ([203.200.71.140]) by ietf-mx with esmtp (Exim 4.12) id 1BLxTl-0007TF-00 for megaco@ietf.org; Fri, 07 May 2004 01:00:57 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id i474x7X4017063; Fri, 7 May 2004 10:29:07 +0530 (IST) Subject: RE: [Megaco] Call Progress Tones. To: megaco learner Cc: megaco ietf Date: Fri, 7 May 2004 10:26:14 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 07/05/2004 10:19:30 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.4 required=5.0 tests=AWL,NO_REAL_NAME, ROUND_THE_WORLD_LOCAL autolearn=no version=2.60 Hi An example call scenario where you need to play the signal on the RTP termination is the Call waiting case where suppose A is currently talking to B(remote packet side subscriber) and another subscriber C calls A. Then A will be getting Call waiting tone on the TDM corresponding to A. On accepting the call waiting call by putting B on hold , MGC might play a Call Hold tone on the ephemeral termination corresponding to the subscriber B. Regards Venkat Hughes Software Systems www.hssworld.com "Kevin Boyle" @ietf.org on 05/06/2004 07:05:24 PM Sent by: megaco-admin@ietf.org To: megaco learner , megaco ietf cc: Subject: RE: [Megaco] Call Progress Tones. Remember that signals progress toward the EXTERIOR of the context, unless specified otherwise. So, playing a tone on an ephemeral plays the tone toward the packet network, not the TDM circuit. There are many different call scenarios that could make use of this kind of function. Kevin _____ From: megaco learner [mailto:megaco_learner@yahoo.com] Sent: Thursday, May 06, 2004 9:11 AM To: megaco ietf Subject: [Megaco] Call Progress Tones. Hi, May sound novice, but want to know what is the difference between the call progress tones(CPT) being played onTDM terminitaions vis-a-vis RTP termination. Is it a mere redundant way(CPT on RTP Terms) to tell the GW to play the Tones, because anyway the tones can be heard on TDM side when played on RTP Termination(???) . Thanks in Advance, Learner. _____ Do you Yahoo!? Win < http://pa.yahoo.com/*http://us.rd.yahoo.com/hotjobs/hotjobs_mail_signature_ footer_textlink/evt=23983/*http://hotjobs.sweepstakes.yahoo.com/careermakeov er> a $20,000 Career Makeover at Yahoo! HotJobs _______________________________________________ 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 Sun May 9 04:39:54 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23557 for ; Sun, 9 May 2004 04:39:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMjm2-0004ZW-OG; Sun, 09 May 2004 04:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMjjh-0004Nx-3t for megaco@optimus.ietf.org; Sun, 09 May 2004 04:32:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23359 for ; Sun, 9 May 2004 04:32:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMjjc-00051f-VU for megaco@ietf.org; Sun, 09 May 2004 04:32:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMjie-0004gB-00 for megaco@ietf.org; Sun, 09 May 2004 04:31:36 -0400 Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com) by ietf-mx with smtp (Exim 4.12) id 1BMji7-0004JN-00 for megaco@ietf.org; Sun, 09 May 2004 04:31:00 -0400 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1083837800; Sun May 9 11:40:38 2004 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id ; Sun, 9 May 2004 11:28:47 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F3810166FC@MAILSERVER> From: Raphael Tryster To: "'Kevin Boyle'" , Christian Groves , bvswamy@hss.hns.com, anilj@cisco.com Cc: Tom-PT Taylor , megaco@ietf.org Subject: RE: [Megaco] Descriptor processing on Termination OOS Date: Sun, 9 May 2004 11:28:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C435A8.0573A7A0" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 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_01C435A8.0573A7A0 Content-Type: text/plain; charset="iso-8859-1" Two questions related to the discussion below: Firstly, the quote below from H.248.1 6.2.4 seems to contradict section 7.1.11, which states: "Production of a Signal on a Termination is stopped by application of a new SignalsDescriptor, or detection of an Event on the Termination". What about returning to the null context? According to 6.2.4, the signal should stop, whereas according to 7.1.11, it should not stop. Unless the resetting of descriptors to default values when returning to the null context is considered to be a case of application of a new SignalsDescriptor? But then what do we do about on/off type signals, e.g. visual message waiting indicator? Surely they are meant to survive subtraction from a context? My second question concerns the requirement that the MG maintain terminations in contexts until the MGC explicitly subtracts them. Consider a distributed MG, in which the part that talks to the MGC does not completely control the part that allocates resources such as IP address and UDP port for local descriptors. Suppose some administrative action or fault causes these resources to become physically unavailable to the termination with which they were associated. The MG informs the MGC (or fails to do so if the MGC didn't request the event), but for some reason the MGC does not issue a Subtract. The front end of the MG has no problem complying with Megaco rules: it will accept any commands it can on that context, and send a proper rejection if the cleanup that has taken place in the back end makes it impossible to comply with a request. However, if the MGC audits the local descriptor, the MG front end will send an IP address and UDP port that the back end may already be reusing for another call. The MGC can then presumably do bad things with this outdated information. Which of the following are legitimate solutions to this problem? a) The MGC is at fault for ignoring indications from the MG that something went wrong. b) The MG is at fault for being schizophrenic. It must prevent reuse of all resources associated with the context until it receives Subtract. c) The MG can sidestep the problem. It is only required to keep the termination in the context, but it can clear the local descriptor. (And what if the MGC doesn't audit but relies on its memory?) d) There is no problem. The MGC cannot do anything bad with the information. Raphael Tryster -----Original Message----- From: Kevin Boyle [SMTP:kboyle@nortelnetworks.com] Sent: Wednesday, 17 December 2003 18:19 To: Christian Groves; bvswamy@hss.hns.com; anilj@cisco.com Cc: megaco_maillist@hss.hns.com; Tom-PT Taylor; megaco@ietf.org Subject: RE: [Megaco] Descriptor processing on Termination OOS Right. I just wanted to ensure that everyone understands that the reset of the descriptors is a result of the SUBTRACT, and not a result of the SERVICECHANGE. Subtle, but important, difference. Kevin -----Original Message----- From: Christian Groves [ mailto:Christian.Groves@ericsson.com ] Sent: Tuesday, December 16, 2003 6:05 PM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; bvswamy@hss.hns.com; anilj@cisco.com Cc: megaco_maillist@hss.hns.com; Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org Subject: Re: [Megaco] Descriptor processing on Termination OOS Hello, OOS Service by its nature must be reported by a ServiceChange, this can be through Forced which states: At a minimum, the Termination shall be subtracted from the Context. Graceful is similar that the MGC is expected to "clean up" the termination ultimately by subtracting the termination. So for ephemeral terminations there's no discussion as they'll disappear the MGC won't be able to do anything to them. For physical terminations the following rule applies: H.248.1 6.2.4 Termination properties and descriptors .... 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. ... This text is very clear when a termination goes back to the NULL context which for TDM terminations is the result of going "out of service" the descriptors ARE changed. I can remember that this behaviour caused quite a bit of discussion at the time (I think Tom drafted the text) and it was felt that this was the best behaviour because it left terminations in a known state both for the MG and MGC. Regards, Christian Kevin Boyle wrote: > Comments inline [KJBII] > > Kevin > > -----Original Message----- > From: bvswamy@hss.hns.com [ mailto:bvswamy@hss.hns.com ] > Sent: Tuesday, December 16, 2003 9:03 AM > To: anilj@cisco.com > Cc: megaco_maillist@hss.hns.com; Taylor, Tom-PT [CAR:5N00:EXCH]; > megaco@ietf.org > Subject: RE: [Megaco] Descriptor processing on Termination OOS > > > > > > Hi > Please find my comments embedded.[BVS]. > Regards > Venkat > > > > > > "Anil Jangam \(anilj\)" @ietf.org on 12/16/2003 > 01:33:27 PM > > Please respond to > > Sent by: megaco-admin@ietf.org > > > To: megaco_maillist@HSS, "'Tom Taylor'" > cc: > > Subject: RE: [Megaco] Descriptor processing on Termination OOS > > > > > > -----Original Message----- > > From: megaco-admin@ietf.org [ mailto:megaco-admin@ietf.org ] On > Behalf > Of megaco_maillist@hss.hns.com > Sent: Tuesday, December > 16, 2003 11:53 AM > To: Tom Taylor > Cc: megaco@ietf.org > Subject: > Re: [Megaco] Descriptor processing on Termination OOS > > > > > > > > Hi > > In my opinion keeping the descriptors alive and enabled for a > > termination which is in Out of Service state does not seems to be a > > valid behaviour of MG. For example if the card containing the > > termination is jacked out of the chasis then definately at the > > hardware level all the events and signals get disabled. There would > > be a major disconnect wrt descriptors state if MGC does not audit > the > termination since if MGC were to audit the termination then > > MG would be returning empty descriptors in this particular > > case. Now in > > this condition if the card is jacked-in and termination is made > > in-service then the exact state of original descriptors no more holds > > good and mgc needs to apply the descriptors again. > > > > Hence for a termination which is in Out-of-Service state MGC can > > fairly assume that all descriptors are no more valid and whenever > the > termination comes up will reapply the descriptors afresh. This > > assumption holds true whether or not termination is involved in a > > call. > > First thing, there is no provision for the MG to change the state of > the descriptor by its own. If we see the commands that can change the > descriptor state, these are commands which MGC initiate. > > [BVS] I agree with you from the protocol perspective. But, if you > analyse the actual scenario, service change (to out-of-service) for a > termination would mean disabling operations such as signals/ events/ > streams. Further, this would mean that MG does take some action on its > own when it generates a Service Change (or MGC sends a service change) > on the termination. > > If MG returns the descriptors in Audit response it would mean > incorrect representation of facts to MGC. > > [KJBII] The MG may not take action on its own, whether we are talking > about a hardware failure or some other occurrence. The text is > explicit: the MG may not reset those descriptors. If the MGC wanted > to audit, it may very well be to collect diagnostic data. If the MG > wipes them out, then that data is lost. > > In the SVC with SVCMethod = forced, its mentioned that MGC is going to > clean up the context, in which case it is to subtract the termination > from the cotext. At this point MGC can reset the descriptor state to > the default if necessary. Same logic can be applied when the SVCMethod > is graceful. > > [BVS] Cleaning up the context using subtract is OK for terminations in > a valid context. But, what about the terminations which are already in > the null context. > > [KJBII] What about them? Modifies are allowed on OOS terminations. > The MGC could very well send a modify to empty the descriptors. > > > In the call flows as well, when the termination is coming back into > the service, normally a Modify is sent to MG initializing the term. > > > [BVS] Based upon our experience in the interop events, this MODIFY is > applicable to only certain call scenarios (e.g. POTS call) and not for > other scenarios (like Trunkling). > > Moreover, it is not used for clean up operations (like empty Signal > descriptor, empty media descriptor etc.), but for the call setup (like > event descriptor with OffHook). > > [KJBII] MGCs that do not reset the state of the descriptors upon > return to service will be subject to its own problems. It seems to me > that the MGC would want to make sure the descriptors are in a > particular state by explicitly making them that way. Further, I know > of several implementations that send empty descriptors in Modify > commands. Any assumption that they are not used for normal call > processing operations is deficient. > > > So given this, IMO we don't have to make any assumption about the > descriptor state once its taken OOS. > > > > > Regards > > Venkat > > > > > > > > > > > > Tom Taylor @ietf.org on 12/01/2003 > > 11:52:03 PM > > > Sent by: megaco-admin@ietf.org > > > > > > To: Sampath Komanduri > > cc: megaco@ietf.org > > > > Subject: Re: [Megaco] Descriptor processing on Termination OOS > > > > > > The descriptors (aside from TerminationState) remain unchanged > until > either the MGC changes them or the MG undergoes a cold restart. > > > > Sampath Komanduri wrote: > > > ------_=_NextPart_001_01C435A8.0573A7A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] Descriptor processing on Termination OOS

Two questions related to the discussion = below:

Firstly, the quote below from H.248.1 6.2.4 seems to contradict section 7.1.11, which states:

"Pr= oduction of a Signal on a Termination is stopped by application of a new = SignalsDescriptor, or detection of an Event on the Termination".

What about returning to the null context= ?  According to 6.2.4, the signal should stop, whereas according to = 7.1.11, it should not stop.  Unless the resetting of descriptors to = default values when returning to the null context is considered to be a c= ase of application of a new SignalsD= escriptor?  But then what do we= do about on/off type signals, e.g. = visual message waiting indicator?&nb= sp; Surely they are meant to survive subtraction from a context?

My second question concerns the requirem= ent that the MG maintain terminations in contexts until the MGC explicitl= y subtracts them.  Consider a distributed MG, in which the part that= talks to the MGC does not completely control the part that allocates res= ources such as IP address and UDP port for local descriptors.  Suppo= se some administrative action or fault causes these resources to become p= hysically unavailable to the termination with which they were associated.=   The MG informs the MGC (or fails to do so if the MGC didn't reques= t the event), but for some reason the MGC does not issue a Subtract. = ; The front end of the MG has no problem complying with Megaco rules: it = will accept any commands it can on that context, and send a proper rejection if the cleanup that has taken place in= the back end makes it impossible to comply with a request.  However= , if the MGC audits the local descriptor, the MG front end will send an I= P address and UDP port that the back end may already be reusing for anoth= er call.  The MGC can then presumably do bad things with this outdat= ed information.  Which of the following are legitimate solutions to = this problem?

  1. The MGC is at fault for ig= noring indications from the MG that something went wrong.

  2. The MG is at fault for being schizophre= nic.  It must prevent reuse of all resources associated with the con= text until it receives Subtract.

  3. The MG can sidestep the problem.  = It is only required to keep the termination in the context, but it can cl= ear the local descriptor.  (And what if the MGC doesn't audit but re= lies on its memory?)

  4. There is no problem.  The MGC cann= ot do anything bad with the information.

Raphael Tryster


------_=_NextPart_001_01C435A8.0573A7A0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Sun May 9 04:44:27 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23659 for ; Sun, 9 May 2004 04:44:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMjte-0005VA-VQ for megaco-archive@odin.ietf.org; Sun, 09 May 2004 04:42:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i498gsnZ021149 for megaco-archive@odin.ietf.org; Sun, 9 May 2004 04:42:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMjsK-0005Mj-HC for megaco-web-archive@optimus.ietf.org; Sun, 09 May 2004 04:41:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23632 for ; Sun, 9 May 2004 04:41:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMjsH-0000Q8-Ij for megaco-web-archive@ietf.org; Sun, 09 May 2004 04:41:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMjrI-000049-00 for megaco-web-archive@ietf.org; Sun, 09 May 2004 04:40:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMjqG-0007LQ-00 for megaco-web-archive@ietf.org; Sun, 09 May 2004 04:39:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMjm2-0004ZW-OG; Sun, 09 May 2004 04:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMjjh-0004Nx-3t for megaco@optimus.ietf.org; Sun, 09 May 2004 04:32:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23359 for ; Sun, 9 May 2004 04:32:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMjjc-00051f-VU for megaco@ietf.org; Sun, 09 May 2004 04:32:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMjie-0004gB-00 for megaco@ietf.org; Sun, 09 May 2004 04:31:36 -0400 Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com) by ietf-mx with smtp (Exim 4.12) id 1BMji7-0004JN-00 for megaco@ietf.org; Sun, 09 May 2004 04:31:00 -0400 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1083837800; Sun May 9 11:40:38 2004 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id ; Sun, 9 May 2004 11:28:47 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F3810166FC@MAILSERVER> From: Raphael Tryster To: "'Kevin Boyle'" , Christian Groves , bvswamy@hss.hns.com, anilj@cisco.com Cc: Tom-PT Taylor , megaco@ietf.org Subject: RE: [Megaco] Descriptor processing on Termination OOS Date: Sun, 9 May 2004 11:28:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C435A8.0573A7A0" 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 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_01C435A8.0573A7A0 Content-Type: text/plain; charset="iso-8859-1" Two questions related to the discussion below: Firstly, the quote below from H.248.1 6.2.4 seems to contradict section 7.1.11, which states: "Production of a Signal on a Termination is stopped by application of a new SignalsDescriptor, or detection of an Event on the Termination". What about returning to the null context? According to 6.2.4, the signal should stop, whereas according to 7.1.11, it should not stop. Unless the resetting of descriptors to default values when returning to the null context is considered to be a case of application of a new SignalsDescriptor? But then what do we do about on/off type signals, e.g. visual message waiting indicator? Surely they are meant to survive subtraction from a context? My second question concerns the requirement that the MG maintain terminations in contexts until the MGC explicitly subtracts them. Consider a distributed MG, in which the part that talks to the MGC does not completely control the part that allocates resources such as IP address and UDP port for local descriptors. Suppose some administrative action or fault causes these resources to become physically unavailable to the termination with which they were associated. The MG informs the MGC (or fails to do so if the MGC didn't request the event), but for some reason the MGC does not issue a Subtract. The front end of the MG has no problem complying with Megaco rules: it will accept any commands it can on that context, and send a proper rejection if the cleanup that has taken place in the back end makes it impossible to comply with a request. However, if the MGC audits the local descriptor, the MG front end will send an IP address and UDP port that the back end may already be reusing for another call. The MGC can then presumably do bad things with this outdated information. Which of the following are legitimate solutions to this problem? a) The MGC is at fault for ignoring indications from the MG that something went wrong. b) The MG is at fault for being schizophrenic. It must prevent reuse of all resources associated with the context until it receives Subtract. c) The MG can sidestep the problem. It is only required to keep the termination in the context, but it can clear the local descriptor. (And what if the MGC doesn't audit but relies on its memory?) d) There is no problem. The MGC cannot do anything bad with the information. Raphael Tryster -----Original Message----- From: Kevin Boyle [SMTP:kboyle@nortelnetworks.com] Sent: Wednesday, 17 December 2003 18:19 To: Christian Groves; bvswamy@hss.hns.com; anilj@cisco.com Cc: megaco_maillist@hss.hns.com; Tom-PT Taylor; megaco@ietf.org Subject: RE: [Megaco] Descriptor processing on Termination OOS Right. I just wanted to ensure that everyone understands that the reset of the descriptors is a result of the SUBTRACT, and not a result of the SERVICECHANGE. Subtle, but important, difference. Kevin -----Original Message----- From: Christian Groves [ mailto:Christian.Groves@ericsson.com ] Sent: Tuesday, December 16, 2003 6:05 PM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; bvswamy@hss.hns.com; anilj@cisco.com Cc: megaco_maillist@hss.hns.com; Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org Subject: Re: [Megaco] Descriptor processing on Termination OOS Hello, OOS Service by its nature must be reported by a ServiceChange, this can be through Forced which states: At a minimum, the Termination shall be subtracted from the Context. Graceful is similar that the MGC is expected to "clean up" the termination ultimately by subtracting the termination. So for ephemeral terminations there's no discussion as they'll disappear the MGC won't be able to do anything to them. For physical terminations the following rule applies: H.248.1 6.2.4 Termination properties and descriptors .... 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. ... This text is very clear when a termination goes back to the NULL context which for TDM terminations is the result of going "out of service" the descriptors ARE changed. I can remember that this behaviour caused quite a bit of discussion at the time (I think Tom drafted the text) and it was felt that this was the best behaviour because it left terminations in a known state both for the MG and MGC. Regards, Christian Kevin Boyle wrote: > Comments inline [KJBII] > > Kevin > > -----Original Message----- > From: bvswamy@hss.hns.com [ mailto:bvswamy@hss.hns.com ] > Sent: Tuesday, December 16, 2003 9:03 AM > To: anilj@cisco.com > Cc: megaco_maillist@hss.hns.com; Taylor, Tom-PT [CAR:5N00:EXCH]; > megaco@ietf.org > Subject: RE: [Megaco] Descriptor processing on Termination OOS > > > > > > Hi > Please find my comments embedded.[BVS]. > Regards > Venkat > > > > > > "Anil Jangam \(anilj\)" @ietf.org on 12/16/2003 > 01:33:27 PM > > Please respond to > > Sent by: megaco-admin@ietf.org > > > To: megaco_maillist@HSS, "'Tom Taylor'" > cc: > > Subject: RE: [Megaco] Descriptor processing on Termination OOS > > > > > > -----Original Message----- > > From: megaco-admin@ietf.org [ mailto:megaco-admin@ietf.org ] On > Behalf > Of megaco_maillist@hss.hns.com > Sent: Tuesday, December > 16, 2003 11:53 AM > To: Tom Taylor > Cc: megaco@ietf.org > Subject: > Re: [Megaco] Descriptor processing on Termination OOS > > > > > > > > Hi > > In my opinion keeping the descriptors alive and enabled for a > > termination which is in Out of Service state does not seems to be a > > valid behaviour of MG. For example if the card containing the > > termination is jacked out of the chasis then definately at the > > hardware level all the events and signals get disabled. There would > > be a major disconnect wrt descriptors state if MGC does not audit > the > termination since if MGC were to audit the termination then > > MG would be returning empty descriptors in this particular > > case. Now in > > this condition if the card is jacked-in and termination is made > > in-service then the exact state of original descriptors no more holds > > good and mgc needs to apply the descriptors again. > > > > Hence for a termination which is in Out-of-Service state MGC can > > fairly assume that all descriptors are no more valid and whenever > the > termination comes up will reapply the descriptors afresh. This > > assumption holds true whether or not termination is involved in a > > call. > > First thing, there is no provision for the MG to change the state of > the descriptor by its own. If we see the commands that can change the > descriptor state, these are commands which MGC initiate. > > [BVS] I agree with you from the protocol perspective. But, if you > analyse the actual scenario, service change (to out-of-service) for a > termination would mean disabling operations such as signals/ events/ > streams. Further, this would mean that MG does take some action on its > own when it generates a Service Change (or MGC sends a service change) > on the termination. > > If MG returns the descriptors in Audit response it would mean > incorrect representation of facts to MGC. > > [KJBII] The MG may not take action on its own, whether we are talking > about a hardware failure or some other occurrence. The text is > explicit: the MG may not reset those descriptors. If the MGC wanted > to audit, it may very well be to collect diagnostic data. If the MG > wipes them out, then that data is lost. > > In the SVC with SVCMethod = forced, its mentioned that MGC is going to > clean up the context, in which case it is to subtract the termination > from the cotext. At this point MGC can reset the descriptor state to > the default if necessary. Same logic can be applied when the SVCMethod > is graceful. > > [BVS] Cleaning up the context using subtract is OK for terminations in > a valid context. But, what about the terminations which are already in > the null context. > > [KJBII] What about them? Modifies are allowed on OOS terminations. > The MGC could very well send a modify to empty the descriptors. > > > In the call flows as well, when the termination is coming back into > the service, normally a Modify is sent to MG initializing the term. > > > [BVS] Based upon our experience in the interop events, this MODIFY is > applicable to only certain call scenarios (e.g. POTS call) and not for > other scenarios (like Trunkling). > > Moreover, it is not used for clean up operations (like empty Signal > descriptor, empty media descriptor etc.), but for the call setup (like > event descriptor with OffHook). > > [KJBII] MGCs that do not reset the state of the descriptors upon > return to service will be subject to its own problems. It seems to me > that the MGC would want to make sure the descriptors are in a > particular state by explicitly making them that way. Further, I know > of several implementations that send empty descriptors in Modify > commands. Any assumption that they are not used for normal call > processing operations is deficient. > > > So given this, IMO we don't have to make any assumption about the > descriptor state once its taken OOS. > > > > > Regards > > Venkat > > > > > > > > > > > > Tom Taylor @ietf.org on 12/01/2003 > > 11:52:03 PM > > > Sent by: megaco-admin@ietf.org > > > > > > To: Sampath Komanduri > > cc: megaco@ietf.org > > > > Subject: Re: [Megaco] Descriptor processing on Termination OOS > > > > > > The descriptors (aside from TerminationState) remain unchanged > until > either the MGC changes them or the MG undergoes a cold restart. > > > > Sampath Komanduri wrote: > > > ------_=_NextPart_001_01C435A8.0573A7A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] Descriptor processing on Termination OOS

Two questions related to the discussion = below:

Firstly, the quote below from H.248.1 6.2.4 seems to contradict section 7.1.11, which states:

"Pr= oduction of a Signal on a Termination is stopped by application of a new = SignalsDescriptor, or detection of an Event on the Termination".

What about returning to the null context= ?  According to 6.2.4, the signal should stop, whereas according to = 7.1.11, it should not stop.  Unless the resetting of descriptors to = default values when returning to the null context is considered to be a c= ase of application of a new SignalsD= escriptor?  But then what do we= do about on/off type signals, e.g. = visual message waiting indicator?&nb= sp; Surely they are meant to survive subtraction from a context?

My second question concerns the requirem= ent that the MG maintain terminations in contexts until the MGC explicitl= y subtracts them.  Consider a distributed MG, in which the part that= talks to the MGC does not completely control the part that allocates res= ources such as IP address and UDP port for local descriptors.  Suppo= se some administrative action or fault causes these resources to become p= hysically unavailable to the termination with which they were associated.=   The MG informs the MGC (or fails to do so if the MGC didn't reques= t the event), but for some reason the MGC does not issue a Subtract. = ; The front end of the MG has no problem complying with Megaco rules: it = will accept any commands it can on that context, and send a proper rejection if the cleanup that has taken place in= the back end makes it impossible to comply with a request.  However= , if the MGC audits the local descriptor, the MG front end will send an I= P address and UDP port that the back end may already be reusing for anoth= er call.  The MGC can then presumably do bad things with this outdat= ed information.  Which of the following are legitimate solutions to = this problem?

  1. The MGC is at fault for ig= noring indications from the MG that something went wrong.

  2. The MG is at fault for being schizophre= nic.  It must prevent reuse of all resources associated with the con= text until it receives Subtract.

  3. The MG can sidestep the problem.  = It is only required to keep the termination in the context, but it can cl= ear the local descriptor.  (And what if the MGC doesn't audit but re= lies on its memory?)

  4. There is no problem.  The MGC cann= ot do anything bad with the information.

Raphael Tryster


------_=_NextPart_001_01C435A8.0573A7A0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue May 11 07:22:33 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19690 for ; Tue, 11 May 2004 07:22:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNVEw-0004j4-Cl; Tue, 11 May 2004 07:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNV6t-0003oT-Io for megaco@optimus.ietf.org; Tue, 11 May 2004 07:07:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19200 for ; Tue, 11 May 2004 07:07:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNV6p-00041c-6O for megaco@ietf.org; Tue, 11 May 2004 07:07:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNV5p-0003eq-00 for megaco@ietf.org; Tue, 11 May 2004 07:06:38 -0400 Received: from [203.199.83.248] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 1BNV4n-0002wf-00 for megaco@ietf.org; Tue, 11 May 2004 07:05:34 -0400 Received: (qmail 13728 invoked by uid 510); 11 May 2004 11:05:25 -0000 Date: 11 May 2004 11:05:25 -0000 Message-ID: <20040511110525.13727.qmail@webmail36.rediffmail.com> Received: from unknown (194.133.58.60) by rediffmail.com via HTTP; 11 may 2004 11:05:25 -0000 MIME-Version: 1.0 From: "kumar" Reply-To: "kumar" To: megaco@ietf.org Content-type: multipart/alternative; boundary="Next_1084273525---0-203.199.83.248-13725" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.2 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_30_40,HTML_IMAGE_ONLY_04,HTML_MESSAGE,MSGID_FROM_MTA_HEADER, REPLY_TO_ULINE_NUMS autolearn=no version=2.60 Subject: [Megaco] Under what condition the MGC sends error 402 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multipart mime message --Next_1084273525---0-203.199.83.248-13725 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0A 
=0AHi All,
=0A  Can any one explain me the condit= ion in which MGC sends ServiceChange reply with error code "402 Unauth= orised Gateway".
=0A
=0AThanks,
=0AKumar=0A

=0A

=0A= =0A --Next_1084273525---0-203.199.83.248-13725 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =A0=0AHi All,=0A Can any one explain me the condition in which MGC sends= ServiceChange reply with error code "402 Unauthorised Gateway".=0A=0AThank= s,=0AKumar --Next_1084273525---0-203.199.83.248-13725-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Tue May 11 07:31:37 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20095 for ; Tue, 11 May 2004 07:31:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNVNs-0006rD-4e for megaco-archive@odin.ietf.org; Tue, 11 May 2004 07:25:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BBPGQm026359 for megaco-archive@odin.ietf.org; Tue, 11 May 2004 07:25:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNVMW-0006Yf-6i for megaco-web-archive@optimus.ietf.org; Tue, 11 May 2004 07:23:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19742 for ; Tue, 11 May 2004 07:23:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNVMV-0002Hx-Mf for megaco-web-archive@ietf.org; Tue, 11 May 2004 07:23:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNVLT-0001tN-00 for megaco-web-archive@ietf.org; Tue, 11 May 2004 07:22:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNVKm-0001WX-00 for megaco-web-archive@ietf.org; Tue, 11 May 2004 07:22:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNVEw-0004j4-Cl; Tue, 11 May 2004 07:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNV6t-0003oT-Io for megaco@optimus.ietf.org; Tue, 11 May 2004 07:07:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19200 for ; Tue, 11 May 2004 07:07:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNV6p-00041c-6O for megaco@ietf.org; Tue, 11 May 2004 07:07:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNV5p-0003eq-00 for megaco@ietf.org; Tue, 11 May 2004 07:06:38 -0400 Received: from [203.199.83.248] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 1BNV4n-0002wf-00 for megaco@ietf.org; Tue, 11 May 2004 07:05:34 -0400 Received: (qmail 13728 invoked by uid 510); 11 May 2004 11:05:25 -0000 Date: 11 May 2004 11:05:25 -0000 Message-ID: <20040511110525.13727.qmail@webmail36.rediffmail.com> Received: from unknown (194.133.58.60) by rediffmail.com via HTTP; 11 may 2004 11:05:25 -0000 MIME-Version: 1.0 From: "kumar" Reply-To: "kumar" To: megaco@ietf.org Content-type: multipart/alternative; boundary="Next_1084273525---0-203.199.83.248-13725" Subject: [Megaco] Under what condition the MGC sends error 402 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.4 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_30_40,HTML_IMAGE_ONLY_06,HTML_MESSAGE,MSGID_FROM_MTA_HEADER, REPLY_TO_ULINE_NUMS autolearn=no version=2.60 This is a multipart mime message --Next_1084273525---0-203.199.83.248-13725 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0A 
=0AHi All,
=0A  Can any one explain me the condit= ion in which MGC sends ServiceChange reply with error code "402 Unauth= orised Gateway".
=0A
=0AThanks,
=0AKumar=0A

=0A

=0A= =0A --Next_1084273525---0-203.199.83.248-13725 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =A0=0AHi All,=0A Can any one explain me the condition in which MGC sends= ServiceChange reply with error code "402 Unauthorised Gateway".=0A=0AThank= s,=0AKumar --Next_1084273525---0-203.199.83.248-13725-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue May 11 11:10:25 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02566 for ; Tue, 11 May 2004 11:10:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNYjp-0005cQ-20; Tue, 11 May 2004 11:00:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNPxL-0006rF-0J for megaco@optimus.ietf.org; Tue, 11 May 2004 01:37:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03239 for ; Tue, 11 May 2004 01:37:28 -0400 (EDT) From: hong.yanxia@zte.com.cn Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNPxH-0005Wq-RF for megaco@ietf.org; Tue, 11 May 2004 01:37:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNPwL-0005BK-00 for megaco@ietf.org; Tue, 11 May 2004 01:36:30 -0400 Received: from [210.21.227.66] (helo=mail2.zte.com.cn) by ietf-mx with esmtp (Exim 4.12) id 1BNPvQ-0004UU-00 for megaco@ietf.org; Tue, 11 May 2004 01:35:33 -0400 To: megaco@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 11 May 2004 13:34:22 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 5.0.10 |March 22, 2002) at 2004-05-11 13:38:16 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Subject: [Megaco] (no subject) 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: There are some questions about R2 signaling puzzling me and I hope your advice. Question1: Under the consideration that which backward signal to be sent depends on the analysis result of received digitals, who will control and decide the sending of the backward group signals such as A1, A3 and A6 ? If MGC does it, the MF event seems to be sent one by one from MG to MGC; else if MGW performs it, the mgw seems to be provisioned some necessary information to analyse numbers received? Q2: Now the document status of R2package-dratf? Thanks very much. Hong _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Tue May 11 11:27:39 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03751 for ; Tue, 11 May 2004 11:27:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNZ4I-0001wA-Tz for megaco-archive@odin.ietf.org; Tue, 11 May 2004 11:21:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BFLICe007431 for megaco-archive@odin.ietf.org; Tue, 11 May 2004 11:21:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNYvC-0007yC-ER for megaco-web-archive@optimus.ietf.org; Tue, 11 May 2004 11:11:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02650 for ; Tue, 11 May 2004 11:11:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNYv9-0007eS-Qw for megaco-web-archive@ietf.org; Tue, 11 May 2004 11:11:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNYuC-0007FE-00 for megaco-web-archive@ietf.org; Tue, 11 May 2004 11:10:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNYtJ-0006pI-00 for megaco-web-archive@ietf.org; Tue, 11 May 2004 11:09:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNYjp-0005cQ-20; Tue, 11 May 2004 11:00:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNPxL-0006rF-0J for megaco@optimus.ietf.org; Tue, 11 May 2004 01:37:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03239 for ; Tue, 11 May 2004 01:37:28 -0400 (EDT) From: hong.yanxia@zte.com.cn Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNPxH-0005Wq-RF for megaco@ietf.org; Tue, 11 May 2004 01:37:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNPwL-0005BK-00 for megaco@ietf.org; Tue, 11 May 2004 01:36:30 -0400 Received: from [210.21.227.66] (helo=mail2.zte.com.cn) by ietf-mx with esmtp (Exim 4.12) id 1BNPvQ-0004UU-00 for megaco@ietf.org; Tue, 11 May 2004 01:35:33 -0400 To: megaco@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 11 May 2004 13:34:22 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 5.0.10 |March 22, 2002) at 2004-05-11 13:38:16 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Megaco] (no subject) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Hi list: There are some questions about R2 signaling puzzling me and I hope your advice. Question1: Under the consideration that which backward signal to be sent depends on the analysis result of received digitals, who will control and decide the sending of the backward group signals such as A1, A3 and A6 ? If MGC does it, the MF event seems to be sent one by one from MG to MGC; else if MGW performs it, the mgw seems to be provisioned some necessary information to analyse numbers received? Q2: Now the document status of R2package-dratf? Thanks very much. Hong _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed May 12 04:47:46 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17958 for ; Wed, 12 May 2004 04:47:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNpLP-0002Pp-Ru; Wed, 12 May 2004 04:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNp5s-0006xK-9k for megaco@optimus.ietf.org; Wed, 12 May 2004 04:28:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16793 for ; Wed, 12 May 2004 04:27:57 -0400 (EDT) From: narendrakumar.vuppuluri@wipro.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNp5p-0000Re-7L for megaco@ietf.org; Wed, 12 May 2004 04:27:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNp4l-0007gw-00 for megaco@ietf.org; Wed, 12 May 2004 04:26:51 -0400 Received: from wiproecmx1.wipro.com ([164.164.31.5]) by ietf-mx with esmtp (Exim 4.12) id 1BNp3j-0006dk-00 for megaco@ietf.org; Wed, 12 May 2004 04:25:48 -0400 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i4C8PBI2015319 for ; Wed, 12 May 2004 13:55:11 +0530 (IST) Received: from blr-ec-bh1.wipro.com ([10.200.50.91]) by ec-vwall-wd with InterScan Messaging Security Suite; Wed, 12 May 2004 13:55:10 +0530 Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 12 May 2004 13:55:09 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C437FA.A323EF66" Date: Wed, 12 May 2004 13:55:09 +0530 Message-ID: <72001BBBF6CB124BA1C40E415914E2130160D5@blr-ec-msg04.wipro.com> Thread-Topic: COT test in softswitch Thread-Index: AcQ3+m4KI/v1LKBzQXS0/Lj6WN0ziQ== To: X-OriginalArrivalTime: 12 May 2004 08:25:09.0842 (UTC) FILETIME=[A38BDB20:01C437FA] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_60_70,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 Subject: [Megaco] COT test in softswitch Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C437FA.A323EF66 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Can anybody explain me how the continuity test is performed in softswitch environment? =20 Thanks in advance, -Narendra. ------_=_NextPart_001_01C437FA.A323EF66 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
Can = anybody explain=20 me how the continuity test is performed in softswitch=20 environment?
 
Thanks = in=20 advance,
-Narendra.
=00 ------_=_NextPart_001_01C437FA.A323EF66-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed May 12 05:05:11 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18819 for ; Wed, 12 May 2004 05:05:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNpYA-0007D4-7X for megaco-archive@odin.ietf.org; Wed, 12 May 2004 04:57:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C8vEcp027715 for megaco-archive@odin.ietf.org; Wed, 12 May 2004 04:57:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNpQ2-0003YK-4f for megaco-web-archive@optimus.ietf.org; Wed, 12 May 2004 04:48:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18006 for ; Wed, 12 May 2004 04:48:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNpPz-0003Ik-2h for megaco-web-archive@ietf.org; Wed, 12 May 2004 04:48:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNpP6-0002oT-00 for megaco-web-archive@ietf.org; Wed, 12 May 2004 04:47:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNpOV-0002Jy-00 for megaco-web-archive@ietf.org; Wed, 12 May 2004 04:47:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNpLP-0002Pp-Ru; Wed, 12 May 2004 04:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNp5s-0006xK-9k for megaco@optimus.ietf.org; Wed, 12 May 2004 04:28:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16793 for ; Wed, 12 May 2004 04:27:57 -0400 (EDT) From: narendrakumar.vuppuluri@wipro.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNp5p-0000Re-7L for megaco@ietf.org; Wed, 12 May 2004 04:27:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNp4l-0007gw-00 for megaco@ietf.org; Wed, 12 May 2004 04:26:51 -0400 Received: from wiproecmx1.wipro.com ([164.164.31.5]) by ietf-mx with esmtp (Exim 4.12) id 1BNp3j-0006dk-00 for megaco@ietf.org; Wed, 12 May 2004 04:25:48 -0400 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i4C8PBI2015319 for ; Wed, 12 May 2004 13:55:11 +0530 (IST) Received: from blr-ec-bh1.wipro.com ([10.200.50.91]) by ec-vwall-wd with InterScan Messaging Security Suite; Wed, 12 May 2004 13:55:10 +0530 Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 12 May 2004 13:55:09 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C437FA.A323EF66" Date: Wed, 12 May 2004 13:55:09 +0530 Message-ID: <72001BBBF6CB124BA1C40E415914E2130160D5@blr-ec-msg04.wipro.com> Thread-Topic: COT test in softswitch Thread-Index: AcQ3+m4KI/v1LKBzQXS0/Lj6WN0ziQ== To: X-OriginalArrivalTime: 12 May 2004 08:25:09.0842 (UTC) FILETIME=[A38BDB20:01C437FA] Subject: [Megaco] COT test in softswitch 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C437FA.A323EF66 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Can anybody explain me how the continuity test is performed in softswitch environment? =20 Thanks in advance, -Narendra. ------_=_NextPart_001_01C437FA.A323EF66 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
Can = anybody explain=20 me how the continuity test is performed in softswitch=20 environment?
 
Thanks = in=20 advance,
-Narendra.
=00 ------_=_NextPart_001_01C437FA.A323EF66-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed May 12 07:04:47 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24007 for ; Wed, 12 May 2004 07:04:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNrT2-0006gN-If; Wed, 12 May 2004 07:00:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNrNx-0005mO-3F for megaco@optimus.ietf.org; Wed, 12 May 2004 06:54:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23719 for ; Wed, 12 May 2004 06:54:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNrNt-0004mw-0g for megaco@ietf.org; Wed, 12 May 2004 06:54:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNrMt-0004G6-00 for megaco@ietf.org; Wed, 12 May 2004 06:53:44 -0400 Received: from www.pspl.co.in ([202.54.11.65] helo=smtp.pspl.co.in) by ietf-mx with esmtp (Exim 4.12) id 1BNrLs-0003ES-00 for megaco@ietf.org; Wed, 12 May 2004 06:52:40 -0400 Received: from grandin (austin.pspl.co.in [210.210.81.202]) (authenticated bits=0) by smtp.pspl.co.in (8.12.9/8.12.9) with ESMTP id i4CAqD9E010899; Wed, 12 May 2004 16:22:16 +0530 From: "Umesh Sharma" To: , Subject: RE: [Megaco] COT test in softswitch Date: Wed, 12 May 2004 16:22:03 +0530 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C4383D.42B671F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <72001BBBF6CB124BA1C40E415914E2130160D5@blr-ec-msg04.wipro.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 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_0008_01C4383D.42B671F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MessageConsider Softswitch to consist of MGC/SG/MG components. I believe when initiating the COT MGC will send an IAM with CC indicator(thru SG) to the other end. And send Add for the termination with ct/cmp to the MG, which then will Notify it of the Success/Failure of test. Then MGC sends a COT message to the terminating end. On the other hand when MGC receives the IAM with CC. It will Add the term with rsp signal desc at the MG which shall do loopback or play some specific tone then. -umesh -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of narendrakumar.vuppuluri@wipro.com Sent: Wednesday, May 12, 2004 1:55 PM To: megaco@ietf.org Subject: [Megaco] COT test in softswitch Hi, Can anybody explain me how the continuity test is performed in softswitch environment? Thanks in advance, -Narendra. ------=_NextPart_000_0008_01C4383D.42B671F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Consider Softswitch to consist of MGC/SG/MG=20 components.
 
I=20 believe when initiating the COT  MGC will = send an IAM=20 with CC indicator(thru SG) to the other end. And send Add for = the=20 termination with ct/cmp to the MG, which then will Notify it of=20 the Success/Failure of test. Then MGC sends a COT message to = the=20 terminating end. 
 
On the=20 other hand when MGC receives the IAM with CC. It will  Add the = term=20 with rsp signal desc at the MG which shall do loopback or play some = specific=20 tone then.
 
-umesh
-----Original Message-----
From: = megaco-admin@ietf.org=20 [mailto:megaco-admin@ietf.org]On Behalf Of=20 narendrakumar.vuppuluri@wipro.com
Sent: Wednesday, May = 12, 2004=20 1:55 PM
To: megaco@ietf.org
Subject: [Megaco] COT = test in=20 softswitch

Hi,
 
Can = anybody=20 explain me how the continuity test is performed in softswitch=20 environment?
 
Thanks in=20 advance,
-Narendra.
------=_NextPart_000_0008_01C4383D.42B671F0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed May 12 07:09:53 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24348 for ; Wed, 12 May 2004 07:09:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNrZU-00080O-Jc for megaco-archive@odin.ietf.org; Wed, 12 May 2004 07:06:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CB6icq030772 for megaco-archive@odin.ietf.org; Wed, 12 May 2004 07:06:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNrYg-0007gl-Lb for megaco-web-archive@optimus.ietf.org; Wed, 12 May 2004 07:05:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24069 for ; Wed, 12 May 2004 07:05:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNrYc-0002eg-E5 for megaco-web-archive@ietf.org; Wed, 12 May 2004 07:05:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNrXl-00028l-00 for megaco-web-archive@ietf.org; Wed, 12 May 2004 07:04:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNrX7-0001dU-00 for megaco-web-archive@ietf.org; Wed, 12 May 2004 07:04:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNrT2-0006gN-If; Wed, 12 May 2004 07:00:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNrNx-0005mO-3F for megaco@optimus.ietf.org; Wed, 12 May 2004 06:54:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23719 for ; Wed, 12 May 2004 06:54:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNrNt-0004mw-0g for megaco@ietf.org; Wed, 12 May 2004 06:54:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNrMt-0004G6-00 for megaco@ietf.org; Wed, 12 May 2004 06:53:44 -0400 Received: from www.pspl.co.in ([202.54.11.65] helo=smtp.pspl.co.in) by ietf-mx with esmtp (Exim 4.12) id 1BNrLs-0003ES-00 for megaco@ietf.org; Wed, 12 May 2004 06:52:40 -0400 Received: from grandin (austin.pspl.co.in [210.210.81.202]) (authenticated bits=0) by smtp.pspl.co.in (8.12.9/8.12.9) with ESMTP id i4CAqD9E010899; Wed, 12 May 2004 16:22:16 +0530 From: "Umesh Sharma" To: , Subject: RE: [Megaco] COT test in softswitch Date: Wed, 12 May 2004 16:22:03 +0530 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C4383D.42B671F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <72001BBBF6CB124BA1C40E415914E2130160D5@blr-ec-msg04.wipro.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C4383D.42B671F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MessageConsider Softswitch to consist of MGC/SG/MG components. I believe when initiating the COT MGC will send an IAM with CC indicator(thru SG) to the other end. And send Add for the termination with ct/cmp to the MG, which then will Notify it of the Success/Failure of test. Then MGC sends a COT message to the terminating end. On the other hand when MGC receives the IAM with CC. It will Add the term with rsp signal desc at the MG which shall do loopback or play some specific tone then. -umesh -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of narendrakumar.vuppuluri@wipro.com Sent: Wednesday, May 12, 2004 1:55 PM To: megaco@ietf.org Subject: [Megaco] COT test in softswitch Hi, Can anybody explain me how the continuity test is performed in softswitch environment? Thanks in advance, -Narendra. ------=_NextPart_000_0008_01C4383D.42B671F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Consider Softswitch to consist of MGC/SG/MG=20 components.
 
I=20 believe when initiating the COT  MGC will = send an IAM=20 with CC indicator(thru SG) to the other end. And send Add for = the=20 termination with ct/cmp to the MG, which then will Notify it of=20 the Success/Failure of test. Then MGC sends a COT message to = the=20 terminating end. 
 
On the=20 other hand when MGC receives the IAM with CC. It will  Add the = term=20 with rsp signal desc at the MG which shall do loopback or play some = specific=20 tone then.
 
-umesh
-----Original Message-----
From: = megaco-admin@ietf.org=20 [mailto:megaco-admin@ietf.org]On Behalf Of=20 narendrakumar.vuppuluri@wipro.com
Sent: Wednesday, May = 12, 2004=20 1:55 PM
To: megaco@ietf.org
Subject: [Megaco] COT = test in=20 softswitch

Hi,
 
Can = anybody=20 explain me how the continuity test is performed in softswitch=20 environment?
 
Thanks in=20 advance,
-Narendra.
------=_NextPart_000_0008_01C4383D.42B671F0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu May 13 09:55:19 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13080 for ; Thu, 13 May 2004 09:55:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOGb4-0005Pc-EN; Thu, 13 May 2004 09:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO4cG-0003VQ-OZ for megaco@optimus.ietf.org; Wed, 12 May 2004 21:02:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23617 for ; Wed, 12 May 2004 21:02:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO4cE-0000v4-7a for megaco@ietf.org; Wed, 12 May 2004 21:02:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO4bC-0000OS-00 for megaco@ietf.org; Wed, 12 May 2004 21:01:23 -0400 Received: from [210.105.51.2] (helo=neowave.co.kr) by ietf-mx with smtp (Exim 4.12) id 1BO4aB-0007W4-00 for megaco@ietf.org; Wed, 12 May 2004 21:00:19 -0400 Received: from LocalHost ( [210.105.51.63]) by webmail.neowave.co.kr (WBlock.psh 3.3.29) with ESMTP id <000a01c43886$35d5e580$2e0110ac@neowave.co.kr> for ; Thu, 13 May 2004 10:00:36 +0900 Message-ID: <000a01c43886$35d5e580$2e0110ac@neowave.co.kr> From: =?ks_c_5601-1987?B?wMzFwsjG?= To: Subject: [MEGACO] Conference by Move Command Date: Thu, 13 May 2004 10:04:15 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C438D1.A5ACC4A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP: 210.105.51.63 X-FROM-DOMAIN: neowave.co.kr X-FROM-EMAIL: thlee@neowave.co.kr X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=HTML_40_50,HTML_MESSAGE, MIME_BASE64_TEXT autolearn=no version=2.60 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_0007_01C438D1.A5ACC4A0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGksIEV2ZXJ5b25lLg0KDQpJbiBjYXNlIG9mIGNvbmZlcmVuY2luZyBiZXR3ZWVuIHRocmVlIHVz ZXJzLCBob3cgZG8gSSBtYWtlIGNhbGwgZmxvdyBieSBNb3ZlIENvbW1hbmQ/DQpBbmQgd2hlcmUg SSBjYW4gZmluZCBjb25mZXJlbmNlIGNhbGwgZmxvdyBkb2N1bWVudChleGNlcHQgImRyYWZ0LWll dGYtbWVnYWNvLWNhbGxmbG93cy0wMy50eHQiKT8NCg0KVGhhbmtzLg0K ------=_NextPart_000_0007_01C438D1.A5ACC4A0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTEwNiIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpLCBFdmVy eW9uZS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj5JbiBjYXNlIG9mIGNvbmZlcmVuY2luZyBiZXR3ZWVuIHRocmVl IHVzZXJzLCBob3cgZG8gSSBtYWtlIA0KY2FsbCBmbG93IGJ5IE1vdmUgQ29tbWFuZD88L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5BbmQgd2hlcmUgSSBjYW4gZmluZCZuYnNwO2NvbmZl cmVuY2UgY2FsbCANCmZsb3cmbmJzcDtkb2N1bWVudChleGNlcHQgImRyYWZ0LWlldGYtbWVnYWNv LWNhbGxmbG93cy0wMy50eHQiKT88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5UaGFua3MuPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0007_01C438D1.A5ACC4A0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu May 13 10:13:38 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14578 for ; Thu, 13 May 2004 10:13:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOGnD-0001Co-8l for megaco-archive@odin.ietf.org; Thu, 13 May 2004 10:02:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DE2ZfJ004631 for megaco-archive@odin.ietf.org; Thu, 13 May 2004 10:02:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOGhp-0006ox-05 for megaco-web-archive@optimus.ietf.org; Thu, 13 May 2004 09:57:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13123 for ; Thu, 13 May 2004 09:56:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOGhn-0001Vj-2P for megaco-web-archive@ietf.org; Thu, 13 May 2004 09:56:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOGgn-0000xr-00 for megaco-web-archive@ietf.org; Thu, 13 May 2004 09:55:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOGfj-0000Ex-00 for megaco-web-archive@ietf.org; Thu, 13 May 2004 09:54:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOGb4-0005Pc-EN; Thu, 13 May 2004 09:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO4cG-0003VQ-OZ for megaco@optimus.ietf.org; Wed, 12 May 2004 21:02:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23617 for ; Wed, 12 May 2004 21:02:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO4cE-0000v4-7a for megaco@ietf.org; Wed, 12 May 2004 21:02:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO4bC-0000OS-00 for megaco@ietf.org; Wed, 12 May 2004 21:01:23 -0400 Received: from [210.105.51.2] (helo=neowave.co.kr) by ietf-mx with smtp (Exim 4.12) id 1BO4aB-0007W4-00 for megaco@ietf.org; Wed, 12 May 2004 21:00:19 -0400 Received: from LocalHost ( [210.105.51.63]) by webmail.neowave.co.kr (WBlock.psh 3.3.29) with ESMTP id <000a01c43886$35d5e580$2e0110ac@neowave.co.kr> for ; Thu, 13 May 2004 10:00:36 +0900 Message-ID: <000a01c43886$35d5e580$2e0110ac@neowave.co.kr> From: =?ks_c_5601-1987?B?wMzFwsjG?= To: Subject: [MEGACO] Conference by Move Command Date: Thu, 13 May 2004 10:04:15 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C438D1.A5ACC4A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP: 210.105.51.63 X-FROM-DOMAIN: neowave.co.kr X-FROM-EMAIL: thlee@neowave.co.kr 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=HTML_40_50,HTML_MESSAGE, MIME_BASE64_TEXT autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C438D1.A5ACC4A0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGksIEV2ZXJ5b25lLg0KDQpJbiBjYXNlIG9mIGNvbmZlcmVuY2luZyBiZXR3ZWVuIHRocmVlIHVz ZXJzLCBob3cgZG8gSSBtYWtlIGNhbGwgZmxvdyBieSBNb3ZlIENvbW1hbmQ/DQpBbmQgd2hlcmUg SSBjYW4gZmluZCBjb25mZXJlbmNlIGNhbGwgZmxvdyBkb2N1bWVudChleGNlcHQgImRyYWZ0LWll dGYtbWVnYWNvLWNhbGxmbG93cy0wMy50eHQiKT8NCg0KVGhhbmtzLg0K ------=_NextPart_000_0007_01C438D1.A5ACC4A0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTEwNiIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpLCBFdmVy eW9uZS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj5JbiBjYXNlIG9mIGNvbmZlcmVuY2luZyBiZXR3ZWVuIHRocmVl IHVzZXJzLCBob3cgZG8gSSBtYWtlIA0KY2FsbCBmbG93IGJ5IE1vdmUgQ29tbWFuZD88L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5BbmQgd2hlcmUgSSBjYW4gZmluZCZuYnNwO2NvbmZl cmVuY2UgY2FsbCANCmZsb3cmbmJzcDtkb2N1bWVudChleGNlcHQgImRyYWZ0LWlldGYtbWVnYWNv LWNhbGxmbG93cy0wMy50eHQiKT88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5UaGFua3MuPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0007_01C438D1.A5ACC4A0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu May 13 22:40:15 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04364 for ; Thu, 13 May 2004 22:40:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOSVS-0007iP-6Y; Thu, 13 May 2004 22:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOSTG-0007GQ-H2 for megaco@optimus.ietf.org; Thu, 13 May 2004 22:30:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03604 for ; Thu, 13 May 2004 22:30:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOSTD-0006wS-74 for megaco@ietf.org; Thu, 13 May 2004 22:30:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOSRM-0006Ej-00 for megaco@ietf.org; Thu, 13 May 2004 22:28:49 -0400 Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by ietf-mx with esmtp (Exim 4.12) id 1BOSOu-0004ib-00 for megaco@ietf.org; Thu, 13 May 2004 22:26:23 -0400 Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id i4E2MxMm021024 for ; Fri, 14 May 2004 10:23:05 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Fri May 14 10:25:26 2004 +0800 Received: from sdcmail.sbell.com.cn ([172.24.222.35]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Fri, 14 May 2004 10:25:26 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 May 2004 10:25:25 +0800 Message-ID: <019D23855408764D80AAE5D51CD756CCEDF751@sdcmail.sbell.com.cn> Thread-Topic: Megaco digest, Vol 1 #1159 - 1 msg Thread-Index: AcQ5Bdmes6N3FuecTzSNySYos16/MwAU3j8A From: "FCG Jiang Yu" To: X-OriginalArrivalTime: 14 May 2004 02:25:26.0424 (UTC) FILETIME=[B7A72180:01C4395A] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Megaco] Syntax of Digitmap Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable hi, Is there any official definition of digitmap syntax in ABNF? We prepare to build a GUI to edit digitmap. And the GUI can also check whether the submitted digitmap is a valid one or not. We make a ABNF form of digitmap according to RFC3525 by ourself, but we are not sure whether it is enough. So, do you have some good ideas? Thanks, Jiang Yu _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu May 13 22:47:32 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04974 for ; Thu, 13 May 2004 22:47:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOSgu-0002TG-Fg for megaco-archive@odin.ietf.org; Thu, 13 May 2004 22:44:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E2iqNq009493 for megaco-archive@odin.ietf.org; Thu, 13 May 2004 22:44:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOSeV-0001w7-TL for megaco-web-archive@optimus.ietf.org; Thu, 13 May 2004 22:42:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04480 for ; Thu, 13 May 2004 22:42:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOSeS-0005dG-HU for megaco-web-archive@ietf.org; Thu, 13 May 2004 22:42:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOSd8-0004y2-00 for megaco-web-archive@ietf.org; Thu, 13 May 2004 22:40:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOSby-0004Q2-00 for megaco-web-archive@ietf.org; Thu, 13 May 2004 22:39:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOSVS-0007iP-6Y; Thu, 13 May 2004 22:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOSTG-0007GQ-H2 for megaco@optimus.ietf.org; Thu, 13 May 2004 22:30:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03604 for ; Thu, 13 May 2004 22:30:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOSTD-0006wS-74 for megaco@ietf.org; Thu, 13 May 2004 22:30:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOSRM-0006Ej-00 for megaco@ietf.org; Thu, 13 May 2004 22:28:49 -0400 Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by ietf-mx with esmtp (Exim 4.12) id 1BOSOu-0004ib-00 for megaco@ietf.org; Thu, 13 May 2004 22:26:23 -0400 Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id i4E2MxMm021024 for ; Fri, 14 May 2004 10:23:05 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Fri May 14 10:25:26 2004 +0800 Received: from sdcmail.sbell.com.cn ([172.24.222.35]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Fri, 14 May 2004 10:25:26 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 May 2004 10:25:25 +0800 Message-ID: <019D23855408764D80AAE5D51CD756CCEDF751@sdcmail.sbell.com.cn> Thread-Topic: Megaco digest, Vol 1 #1159 - 1 msg Thread-Index: AcQ5Bdmes6N3FuecTzSNySYos16/MwAU3j8A From: "FCG Jiang Yu" To: X-OriginalArrivalTime: 14 May 2004 02:25:26.0424 (UTC) FILETIME=[B7A72180:01C4395A] Content-Transfer-Encoding: quoted-printable Subject: [Megaco] Syntax of Digitmap 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable hi, Is there any official definition of digitmap syntax in ABNF? We prepare to build a GUI to edit digitmap. And the GUI can also check whether the submitted digitmap is a valid one or not. We make a ABNF form of digitmap according to RFC3525 by ourself, but we are not sure whether it is enough. So, do you have some good ideas? Thanks, Jiang Yu _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu May 13 22:52:59 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05199 for ; Thu, 13 May 2004 22:52:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOSk0-0003A3-QC; Thu, 13 May 2004 22:48:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOShx-0002i9-Fa for megaco@optimus.ietf.org; Thu, 13 May 2004 22:45:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04866 for ; Thu, 13 May 2004 22:45:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOShu-00006m-1b for megaco@ietf.org; Thu, 13 May 2004 22:45:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOSgr-0007L6-00 for megaco@ietf.org; Thu, 13 May 2004 22:44:50 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1BOSfp-0006B8-00 for megaco@ietf.org; Thu, 13 May 2004 22:43:45 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4E2hAJ21998 for ; Thu, 13 May 2004 22:43:10 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 May 2004 22:43:10 -0400 Message-ID: From: "Kevin Boyle" To: FCG Jiang Yu , megaco@ietf.org Subject: RE: [Megaco] Syntax of Digitmap Date: Thu, 13 May 2004 22:43:10 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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 official digitmap syntax is contained in Annex B. Note that RFC 3525 is the IETF published copy of H.248.1 Version 1. Version 1 will stop being supported once H.248.1 Version 3 is consented in ITU Study Group 16. I suggest that you use ITU-T Recommendation H.248.1 Version 2 for your syntax needs. Kevin -----Original Message----- From: FCG Jiang Yu [mailto:Yu.Jiang@alcatel-sbell.com.cn] Sent: Friday, May 14, 2004 10:25 AM To: megaco@ietf.org Subject: [Megaco] Syntax of Digitmap hi, Is there any official definition of digitmap syntax in ABNF? We prepare to build a GUI to edit digitmap. And the GUI can also check whether the submitted digitmap is a valid one or not. We make a ABNF form of digitmap according to RFC3525 by ourself, but we are not sure whether it is enough. So, do you have some good ideas? Thanks, Jiang Yu _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu May 13 23:07:58 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05689 for ; Thu, 13 May 2004 23:07:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOT0f-0007TF-59 for megaco-archive@odin.ietf.org; Thu, 13 May 2004 23:05:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E35G1d028716 for megaco-archive@odin.ietf.org; Thu, 13 May 2004 23:05:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOSqP-0005IW-J0 for megaco-web-archive@optimus.ietf.org; Thu, 13 May 2004 22:54:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05253 for ; Thu, 13 May 2004 22:54:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOSqM-00051V-4W for megaco-web-archive@ietf.org; Thu, 13 May 2004 22:54:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOSpJ-0004Rx-00 for megaco-web-archive@ietf.org; Thu, 13 May 2004 22:53:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOSoH-0003tx-00 for megaco-web-archive@ietf.org; Thu, 13 May 2004 22:52:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOSk0-0003A3-QC; Thu, 13 May 2004 22:48:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOShx-0002i9-Fa for megaco@optimus.ietf.org; Thu, 13 May 2004 22:45:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04866 for ; Thu, 13 May 2004 22:45:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOShu-00006m-1b for megaco@ietf.org; Thu, 13 May 2004 22:45:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOSgr-0007L6-00 for megaco@ietf.org; Thu, 13 May 2004 22:44:50 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1BOSfp-0006B8-00 for megaco@ietf.org; Thu, 13 May 2004 22:43:45 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4E2hAJ21998 for ; Thu, 13 May 2004 22:43:10 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 May 2004 22:43:10 -0400 Message-ID: From: "Kevin Boyle" To: FCG Jiang Yu , megaco@ietf.org Subject: RE: [Megaco] Syntax of Digitmap Date: Thu, 13 May 2004 22:43:10 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 The official digitmap syntax is contained in Annex B. Note that RFC 3525 is the IETF published copy of H.248.1 Version 1. Version 1 will stop being supported once H.248.1 Version 3 is consented in ITU Study Group 16. I suggest that you use ITU-T Recommendation H.248.1 Version 2 for your syntax needs. Kevin -----Original Message----- From: FCG Jiang Yu [mailto:Yu.Jiang@alcatel-sbell.com.cn] Sent: Friday, May 14, 2004 10:25 AM To: megaco@ietf.org Subject: [Megaco] Syntax of Digitmap hi, Is there any official definition of digitmap syntax in ABNF? We prepare to build a GUI to edit digitmap. And the GUI can also check whether the submitted digitmap is a valid one or not. We make a ABNF form of digitmap according to RFC3525 by ourself, but we are not sure whether it is enough. So, do you have some good ideas? Thanks, Jiang Yu _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri May 14 02:30:21 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29410 for ; Fri, 14 May 2004 02:30:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOW62-0002h3-IB; Fri, 14 May 2004 02:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOW1u-0000yK-D0 for megaco@optimus.ietf.org; Fri, 14 May 2004 02:18:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28633 for ; Fri, 14 May 2004 02:18:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOW1q-00017S-P4 for megaco@ietf.org; Fri, 14 May 2004 02:18:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOW0q-0000ZI-00 for megaco@ietf.org; Fri, 14 May 2004 02:17:40 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BOVzt-0007JG-00 for megaco@ietf.org; Fri, 14 May 2004 02:16:41 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4E6GBg12136 for ; Fri, 14 May 2004 02:16:11 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 May 2004 02:16:12 -0400 Message-ID: From: "Kevin Boyle" To: ??? , megaco@ietf.org Subject: RE: [MEGACO] Conference by Move Command Date: Fri, 14 May 2004 02:16:10 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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 would depend upon the MGC's architecture. I can think of ways to build a three-way call without using Move, just as I can think of ways to do it using Move. It would all depend on what state each leg was in prior to the conference. The only public H.248 callflows document is the IETF draft you mentioned. Beware, though, as several notable mistakes have been discovered in that draft. Kevin _____ From: thlee@neowave.co.kr [mailto:thlee@neowave.co.kr] Sent: Thursday, May 13, 2004 9:04 AM To: megaco@ietf.org Subject: [MEGACO] Conference by Move Command Hi, Everyone. In case of conferencing between three users, how do I make call flow by Move Command? And where I can find conference call flow document(except "draft-ietf-megaco-callflows-03.txt")? Thanks. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri May 14 02:35:22 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29720 for ; Fri, 14 May 2004 02:35:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOWFA-0006I6-Ub for megaco-archive@odin.ietf.org; Fri, 14 May 2004 02:32:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E6WSop024183 for megaco-archive@odin.ietf.org; Fri, 14 May 2004 02:32:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOWEW-000645-Bw for megaco-web-archive@optimus.ietf.org; Fri, 14 May 2004 02:31:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29484 for ; Fri, 14 May 2004 02:31:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOWES-0000QK-Nw for megaco-web-archive@ietf.org; Fri, 14 May 2004 02:31:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOWDX-0007gm-00 for megaco-web-archive@ietf.org; Fri, 14 May 2004 02:30:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOWCc-00071M-00 for megaco-web-archive@ietf.org; Fri, 14 May 2004 02:29:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOW62-0002h3-IB; Fri, 14 May 2004 02:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOW1u-0000yK-D0 for megaco@optimus.ietf.org; Fri, 14 May 2004 02:18:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28633 for ; Fri, 14 May 2004 02:18:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOW1q-00017S-P4 for megaco@ietf.org; Fri, 14 May 2004 02:18:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOW0q-0000ZI-00 for megaco@ietf.org; Fri, 14 May 2004 02:17:40 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BOVzt-0007JG-00 for megaco@ietf.org; Fri, 14 May 2004 02:16:41 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4E6GBg12136 for ; Fri, 14 May 2004 02:16:11 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 May 2004 02:16:12 -0400 Message-ID: From: "Kevin Boyle" To: ??? , megaco@ietf.org Subject: RE: [MEGACO] Conference by Move Command Date: Fri, 14 May 2004 02:16:10 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 This would depend upon the MGC's architecture. I can think of ways to build a three-way call without using Move, just as I can think of ways to do it using Move. It would all depend on what state each leg was in prior to the conference. The only public H.248 callflows document is the IETF draft you mentioned. Beware, though, as several notable mistakes have been discovered in that draft. Kevin _____ From: thlee@neowave.co.kr [mailto:thlee@neowave.co.kr] Sent: Thursday, May 13, 2004 9:04 AM To: megaco@ietf.org Subject: [MEGACO] Conference by Move Command Hi, Everyone. In case of conferencing between three users, how do I make call flow by Move Command? And where I can find conference call flow document(except "draft-ietf-megaco-callflows-03.txt")? Thanks. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri May 14 03:19:16 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01969 for ; Fri, 14 May 2004 03:19:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOWuN-00045U-Qp; Fri, 14 May 2004 03:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOWnT-0002kS-E0 for megaco@optimus.ietf.org; Fri, 14 May 2004 03:07:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01080 for ; Fri, 14 May 2004 03:07:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOWnP-0004Y3-De for megaco@ietf.org; Fri, 14 May 2004 03:07:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOWmK-00040y-00 for megaco@ietf.org; Fri, 14 May 2004 03:06:45 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BOWlV-0002y2-00 for megaco@ietf.org; Fri, 14 May 2004 03:05:53 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4E6xtg12783 for ; Fri, 14 May 2004 02:59:55 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 May 2004 02:59:56 -0400 Message-ID: From: "Kevin Boyle" To: kumar , megaco@ietf.org Subject: RE: [Megaco] Under what condition the MGC sends error 402 Date: Fri, 14 May 2004 02:59:54 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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: , As with most things, that would depend upon the MGC. Some MGCs choose not to respond to unknown or unauthorized MGs at all. Some could send a reply as you have described. Kevin -----Original Message----- From: kumar [mailto:kumar_nov20@rediffmail.com] Sent: Tuesday, May 11, 2004 7:05 PM To: megaco@ietf.org Subject: [Megaco] Under what condition the MGC sends error 402   Hi All, Can any one explain me the condition in which MGC sends ServiceChange reply with error code "402 Unauthorised Gateway". Thanks, Kumar _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri May 14 03:27:21 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03023 for ; Fri, 14 May 2004 03:27:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOX3P-0006ca-I7 for megaco-archive@odin.ietf.org; Fri, 14 May 2004 03:24:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E7ONO8025453 for megaco-archive@odin.ietf.org; Fri, 14 May 2004 03:24:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOX1z-00066I-RT for megaco-web-archive@optimus.ietf.org; Fri, 14 May 2004 03:22:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02676 for ; Fri, 14 May 2004 03:22:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOX1x-0004fA-KG for megaco-web-archive@ietf.org; Fri, 14 May 2004 03:22:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOX0P-0003xG-00 for megaco-web-archive@ietf.org; Fri, 14 May 2004 03:21:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOWxx-0002kw-00 for megaco-web-archive@ietf.org; Fri, 14 May 2004 03:18:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOWuN-00045U-Qp; Fri, 14 May 2004 03:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOWnT-0002kS-E0 for megaco@optimus.ietf.org; Fri, 14 May 2004 03:07:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01080 for ; Fri, 14 May 2004 03:07:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOWnP-0004Y3-De for megaco@ietf.org; Fri, 14 May 2004 03:07:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOWmK-00040y-00 for megaco@ietf.org; Fri, 14 May 2004 03:06:45 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BOWlV-0002y2-00 for megaco@ietf.org; Fri, 14 May 2004 03:05:53 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4E6xtg12783 for ; Fri, 14 May 2004 02:59:55 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 May 2004 02:59:56 -0400 Message-ID: From: "Kevin Boyle" To: kumar , megaco@ietf.org Subject: RE: [Megaco] Under what condition the MGC sends error 402 Date: Fri, 14 May 2004 02:59:54 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 As with most things, that would depend upon the MGC. Some MGCs choose not to respond to unknown or unauthorized MGs at all. Some could send a reply as you have described. Kevin -----Original Message----- From: kumar [mailto:kumar_nov20@rediffmail.com] Sent: Tuesday, May 11, 2004 7:05 PM To: megaco@ietf.org Subject: [Megaco] Under what condition the MGC sends error 402   Hi All, Can any one explain me the condition in which MGC sends ServiceChange reply with error code "402 Unauthorised Gateway". Thanks, Kumar _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri May 14 05:51:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10275 for ; Fri, 14 May 2004 05:51:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOZDd-0005nc-En; Fri, 14 May 2004 05:43:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOZ9a-00052o-Sl for megaco@optimus.ietf.org; Fri, 14 May 2004 05:38:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09607 for ; Fri, 14 May 2004 05:38:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOZ9X-0005cn-Cj for megaco@ietf.org; Fri, 14 May 2004 05:38:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOZ8d-00058h-00 for megaco@ietf.org; Fri, 14 May 2004 05:37:56 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1BOZ7m-0004CC-00 for megaco@ietf.org; Fri, 14 May 2004 05:37:02 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4E9aWU15929 for ; Fri, 14 May 2004 05:36:33 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 May 2004 05:36:33 -0400 Message-ID: From: "Kevin Boyle" To: hong.yanxia@zte.com.cn, megaco@ietf.org Subject: RE: [Megaco] (no subject) Date: Fri, 14 May 2004 05:36:32 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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: , 1. That would depend upon your architecture and which packages you support. There are currently two methodologies being pursued for R2 signalling systems in ITU Q3/16. See the proposed draft for H.248.29 and the proposed H.248.ICASCGEN documents which can be found in the informal FTP area. 2. The IETF R2 package draft is expired. That work evolved and was moved to the ITU, where the evolved line signalling portion became a standard in ITU-T Recommendation H.248.28. The evolved register signalling portion is contained in proposed H.248.29. Kevin -----Original Message----- From: hong.yanxia@zte.com.cn [mailto:hong.yanxia@zte.com.cn] Sent: Tuesday, May 11, 2004 1:34 PM To: megaco@ietf.org Subject: [Megaco] (no subject) Hi list: There are some questions about R2 signaling puzzling me and I hope your advice. Question1: Under the consideration that which backward signal to be sent depends on the analysis result of received digitals, who will control and decide the sending of the backward group signals such as A1, A3 and A6 ? If MGC does it, the MF event seems to be sent one by one from MG to MGC; else if MGW performs it, the mgw seems to be provisioned some necessary information to analyse numbers received? Q2: Now the document status of R2package-dratf? Thanks very much. Hong _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri May 14 05:58:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10615 for ; Fri, 14 May 2004 05:58:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOZOt-0008Mu-Ia for megaco-archive@odin.ietf.org; Fri, 14 May 2004 05:54:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E9shnP032168 for megaco-archive@odin.ietf.org; Fri, 14 May 2004 05:54:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOZN4-0007wh-Fk for megaco-web-archive@optimus.ietf.org; Fri, 14 May 2004 05:52:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10313 for ; Fri, 14 May 2004 05:52:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOZN0-0004pZ-TM for megaco-web-archive@ietf.org; Fri, 14 May 2004 05:52:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOZM2-0004M2-00 for megaco-web-archive@ietf.org; Fri, 14 May 2004 05:51:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOZL3-0003sQ-00 for megaco-web-archive@ietf.org; Fri, 14 May 2004 05:50:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOZDd-0005nc-En; Fri, 14 May 2004 05:43:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOZ9a-00052o-Sl for megaco@optimus.ietf.org; Fri, 14 May 2004 05:38:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09607 for ; Fri, 14 May 2004 05:38:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOZ9X-0005cn-Cj for megaco@ietf.org; Fri, 14 May 2004 05:38:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOZ8d-00058h-00 for megaco@ietf.org; Fri, 14 May 2004 05:37:56 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1BOZ7m-0004CC-00 for megaco@ietf.org; Fri, 14 May 2004 05:37:02 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4E9aWU15929 for ; Fri, 14 May 2004 05:36:33 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 May 2004 05:36:33 -0400 Message-ID: From: "Kevin Boyle" To: hong.yanxia@zte.com.cn, megaco@ietf.org Subject: RE: [Megaco] (no subject) Date: Fri, 14 May 2004 05:36:32 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 1. That would depend upon your architecture and which packages you support. There are currently two methodologies being pursued for R2 signalling systems in ITU Q3/16. See the proposed draft for H.248.29 and the proposed H.248.ICASCGEN documents which can be found in the informal FTP area. 2. The IETF R2 package draft is expired. That work evolved and was moved to the ITU, where the evolved line signalling portion became a standard in ITU-T Recommendation H.248.28. The evolved register signalling portion is contained in proposed H.248.29. Kevin -----Original Message----- From: hong.yanxia@zte.com.cn [mailto:hong.yanxia@zte.com.cn] Sent: Tuesday, May 11, 2004 1:34 PM To: megaco@ietf.org Subject: [Megaco] (no subject) Hi list: There are some questions about R2 signaling puzzling me and I hope your advice. Question1: Under the consideration that which backward signal to be sent depends on the analysis result of received digitals, who will control and decide the sending of the backward group signals such as A1, A3 and A6 ? If MGC does it, the MF event seems to be sent one by one from MG to MGC; else if MGW performs it, the mgw seems to be provisioned some necessary information to analyse numbers received? Q2: Now the document status of R2package-dratf? Thanks very much. Hong _______________________________________________ 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 May 17 07:39:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15169 for ; Mon, 17 May 2004 07:39:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPgMe-0005KP-QY; Mon, 17 May 2004 07:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPeyc-0001lS-TQ for megaco@optimus.ietf.org; Mon, 17 May 2004 06:04:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11055 for ; Mon, 17 May 2004 06:04:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPeyY-0004Xq-BH for megaco@ietf.org; Mon, 17 May 2004 06:04:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPexX-0004Ed-00 for megaco@ietf.org; Mon, 17 May 2004 06:03:00 -0400 Received: from web90106.mail.scd.yahoo.com ([66.218.94.77]) by ietf-mx with smtp (Exim 4.12) id 1BPewv-0003tY-00 for megaco@ietf.org; Mon, 17 May 2004 06:02:21 -0400 Message-ID: <20040517092904.30629.qmail@web90106.mail.scd.yahoo.com> Received: from [202.54.26.201] by web90106.mail.scd.yahoo.com via HTTP; Mon, 17 May 2004 02:29:04 PDT Date: Mon, 17 May 2004 02:29:04 -0700 (PDT) From: Mike Dirk To: megaco@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.5 required=5.0 tests=FORGED_YAHOO_RCVD, FROM_ENDS_IN_NUMS,FROM_HAS_ULINE_NUMS autolearn=no version=2.60 Subject: [Megaco] Megaco V1/V2/V3 ? 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 We are a small group of developers trying to develop Megaco protocol stacks. However having gone through the Megaco recommendations , we seems to be confronted with lot of options on which protocol version to start with. There are three versions of the H248.1 protocol. Therefore request Megaco gurus to provide information on general acceptibility in the market for the different versions. Any pointers to information/report on vendors supporting different megaco versions will be of great help. Also are the latest versions downward compatible. I thank you for an answer. rgds Mike Dirk __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon May 17 07:46:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15885 for ; Mon, 17 May 2004 07:46:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPgXI-00078M-87 for megaco-archive@odin.ietf.org; Mon, 17 May 2004 07:44:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HBi064027414 for megaco-archive@odin.ietf.org; Mon, 17 May 2004 07:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPgUK-0006ke-VX for megaco-web-archive@optimus.ietf.org; Mon, 17 May 2004 07:40:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15440 for ; Mon, 17 May 2004 07:40:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPgUK-0003bf-9M for megaco-web-archive@ietf.org; Mon, 17 May 2004 07:40:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPgTN-0003Fz-00 for megaco-web-archive@ietf.org; Mon, 17 May 2004 07:39:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPgST-0002sV-00 for megaco-web-archive@ietf.org; Mon, 17 May 2004 07:39:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPgMe-0005KP-QY; Mon, 17 May 2004 07:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPeyc-0001lS-TQ for megaco@optimus.ietf.org; Mon, 17 May 2004 06:04:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11055 for ; Mon, 17 May 2004 06:04:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPeyY-0004Xq-BH for megaco@ietf.org; Mon, 17 May 2004 06:04:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPexX-0004Ed-00 for megaco@ietf.org; Mon, 17 May 2004 06:03:00 -0400 Received: from web90106.mail.scd.yahoo.com ([66.218.94.77]) by ietf-mx with smtp (Exim 4.12) id 1BPewv-0003tY-00 for megaco@ietf.org; Mon, 17 May 2004 06:02:21 -0400 Message-ID: <20040517092904.30629.qmail@web90106.mail.scd.yahoo.com> Received: from [202.54.26.201] by web90106.mail.scd.yahoo.com via HTTP; Mon, 17 May 2004 02:29:04 PDT Date: Mon, 17 May 2004 02:29:04 -0700 (PDT) From: Mike Dirk To: megaco@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Megaco] Megaco V1/V2/V3 ? 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.5 required=5.0 tests=FORGED_YAHOO_RCVD, FROM_ENDS_IN_NUMS,FROM_HAS_ULINE_NUMS autolearn=no version=2.60 Hi All We are a small group of developers trying to develop Megaco protocol stacks. However having gone through the Megaco recommendations , we seems to be confronted with lot of options on which protocol version to start with. There are three versions of the H248.1 protocol. Therefore request Megaco gurus to provide information on general acceptibility in the market for the different versions. Any pointers to information/report on vendors supporting different megaco versions will be of great help. Also are the latest versions downward compatible. I thank you for an answer. rgds Mike Dirk __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed May 19 03:08:11 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17222 for ; Wed, 19 May 2004 03:08:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQL1d-00072Z-Tx; Wed, 19 May 2004 02:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQKxM-0006bK-KG for megaco@optimus.ietf.org; Wed, 19 May 2004 02:53:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16418 for ; Wed, 19 May 2004 02:53:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQKxI-0004MP-OB for megaco@ietf.org; Wed, 19 May 2004 02:53:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQKwM-0004Ej-00 for megaco@ietf.org; Wed, 19 May 2004 02:52:34 -0400 Received: from [203.199.83.248] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 1BQKvO-00047j-00 for megaco@ietf.org; Wed, 19 May 2004 02:51:34 -0400 Received: (qmail 11084 invoked by uid 510); 19 May 2004 06:20:27 -0000 Date: 19 May 2004 06:20:27 -0000 Message-ID: <20040519062027.11083.qmail@webmail36.rediffmail.com> Received: from unknown (62.23.212.60) by rediffmail.com via HTTP; 19 may 2004 06:20:27 -0000 MIME-Version: 1.0 From: "kumar" Reply-To: "kumar" To: megaco@ietf.org Content-type: multipart/alternative; boundary="Next_1084947627---0-203.199.83.248-11051" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.2 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE,MSGID_FROM_MTA_HEADER,REPLY_TO_ULINE_NUMS autolearn=no version=2.60 Subject: [Megaco] When do I stop ringing? Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multipart mime message --Next_1084947627---0-203.199.83.248-11051 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AHi All,
=0A  We are trying the following scenerio.
=0A&nb= sp;   Termination ID of A is term/1 and B is term/2.
=0A  1. A= calls B. B is ringing and A is getting Ringback tone.
=0A  2. A go= es on-hook while B is ringing.
=0A      A sends on-hook n= otification to MGC.
=0A  MEGACO/1 [192.168.1.1]
=0A Transaction = =3D 154 { Context =3D 14 { Notify =3D term/1 { ObservedEvents =3D 756 {&nbs= p; al/on { init =3D True }  }  }  }  }
=0A  <= BR>=0A  We got the following request from MGC.
=0A!/1 [192.168.1.= 2]
=0AP=3D154{C=3D14{N=3Dterm/1}}
=0AT=3D441{C=3D14{S=3D*},C=3D-{MF= =3Dterm/1{E=3D757{al/of{EM{SG{cg/dt},E=3D758{dd/ce{DigitMap=3DG_DGT_MAP},al= /on{strict=3Dexact}}},strict=3Dexact}}}}}
=0AK{440}
=0A
=0A!/1 [19= 2.168.1.2]
=0AT=3D442{C=3D15{S=3D*},C=3D-{MF=3Dterm/2{E=3D759{al/of{EM{S= G{cg/dt},E=3D760{dd/ce{DigitMap=3DG_DGT_MAP},al/on{strict=3Dexact}}},strict= =3Dexact}}}}}
=0A
=0A  Here term/2 is ringing and we got subtrac= t request with embedded signal descriptor. As of I understand , the signal = descriptor is activated only off-hook event occurs(From above request). The= ring tone on term/2 will be stopped only event occurs or new signal descri= ptor is activated(As per rfc). So when should I stop ring tone on term/2.=0A Can anyone clarify this please.
=0A
=0AThanks & Regards,=0AKumar
=0A
=0A 
=0A=0A

=0A

=0A=0A --Next_1084947627---0-203.199.83.248-11051 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi All,=0A We are trying the following scenerio.=0A Termination ID of = A is term/1 and B is term/2.=0A 1. A calls B. B is ringing and A is gettin= g Ringback tone.=0A 2. A goes on-hook while B is ringing.=0A A sends = on-hook notification to MGC.=0A MEGACO/1 [192.168.1.1]=0A Transaction =3D = 154 { Context =3D 14 { Notify =3D term/1 { ObservedEvents =3D 756 { al/on = { init =3D True } } } } } =0A =0A We got the following request from= MGC. =0A!/1 [192.168.1.2]=0AP=3D154{C=3D14{N=3Dterm/1}}=0AT=3D441{C=3D14{S= =3D*},C=3D-{MF=3Dterm/1{E=3D757{al/of{EM{SG{cg/dt},E=3D758{dd/ce{DigitMap= =3DG_DGT_MAP},al/on{strict=3Dexact}}},strict=3Dexact}}}}}=0AK{440}=0A=0A!/1= [192.168.1.2]=0AT=3D442{C=3D15{S=3D*},C=3D-{MF=3Dterm/2{E=3D759{al/of{EM{S= G{cg/dt},E=3D760{dd/ce{DigitMap=3DG_DGT_MAP},al/on{strict=3Dexact}}},strict= =3Dexact}}}}}=0A=0A Here term/2 is ringing and we got subtract request wit= h embedded signal descriptor. As of I understand , the signal descriptor is= activated only off-hook event occurs(From above request). The ring tone on= term/2 will be stopped only event occurs or new signal descriptor is activ= ated(As per rfc). So when should I stop ring tone on term/2.=0A Can anyone = clarify this please.=0A=0AThanks & Regards,=0AKumar=0A=0A =A0=0A --Next_1084947627---0-203.199.83.248-11051-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed May 19 03:15:42 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17650 for ; Wed, 19 May 2004 03:15:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQLEw-0000z1-CH for megaco-archive@odin.ietf.org; Wed, 19 May 2004 03:11:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4J7BkCr003779 for megaco-archive@odin.ietf.org; Wed, 19 May 2004 03:11:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQLCv-0000YT-7F for megaco-web-archive@optimus.ietf.org; Wed, 19 May 2004 03:09:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17348 for ; Wed, 19 May 2004 03:09:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQLCr-0006Uw-8E for megaco-web-archive@ietf.org; Wed, 19 May 2004 03:09:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQLBy-0006LC-00 for megaco-web-archive@ietf.org; Wed, 19 May 2004 03:08:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQLAz-0006C4-00 for megaco-web-archive@ietf.org; Wed, 19 May 2004 03:07:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQL1d-00072Z-Tx; Wed, 19 May 2004 02:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQKxM-0006bK-KG for megaco@optimus.ietf.org; Wed, 19 May 2004 02:53:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16418 for ; Wed, 19 May 2004 02:53:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQKxI-0004MP-OB for megaco@ietf.org; Wed, 19 May 2004 02:53:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQKwM-0004Ej-00 for megaco@ietf.org; Wed, 19 May 2004 02:52:34 -0400 Received: from [203.199.83.248] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 1BQKvO-00047j-00 for megaco@ietf.org; Wed, 19 May 2004 02:51:34 -0400 Received: (qmail 11084 invoked by uid 510); 19 May 2004 06:20:27 -0000 Date: 19 May 2004 06:20:27 -0000 Message-ID: <20040519062027.11083.qmail@webmail36.rediffmail.com> Received: from unknown (62.23.212.60) by rediffmail.com via HTTP; 19 may 2004 06:20:27 -0000 MIME-Version: 1.0 From: "kumar" Reply-To: "kumar" To: megaco@ietf.org Content-type: multipart/alternative; boundary="Next_1084947627---0-203.199.83.248-11051" Subject: [Megaco] When do I stop ringing? 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.2 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE,MSGID_FROM_MTA_HEADER,REPLY_TO_ULINE_NUMS autolearn=no version=2.60 This is a multipart mime message --Next_1084947627---0-203.199.83.248-11051 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AHi All,
=0A  We are trying the following scenerio.
=0A&nb= sp;   Termination ID of A is term/1 and B is term/2.
=0A  1. A= calls B. B is ringing and A is getting Ringback tone.
=0A  2. A go= es on-hook while B is ringing.
=0A      A sends on-hook n= otification to MGC.
=0A  MEGACO/1 [192.168.1.1]
=0A Transaction = =3D 154 { Context =3D 14 { Notify =3D term/1 { ObservedEvents =3D 756 {&nbs= p; al/on { init =3D True }  }  }  }  }
=0A  <= BR>=0A  We got the following request from MGC.
=0A!/1 [192.168.1.= 2]
=0AP=3D154{C=3D14{N=3Dterm/1}}
=0AT=3D441{C=3D14{S=3D*},C=3D-{MF= =3Dterm/1{E=3D757{al/of{EM{SG{cg/dt},E=3D758{dd/ce{DigitMap=3DG_DGT_MAP},al= /on{strict=3Dexact}}},strict=3Dexact}}}}}
=0AK{440}
=0A
=0A!/1 [19= 2.168.1.2]
=0AT=3D442{C=3D15{S=3D*},C=3D-{MF=3Dterm/2{E=3D759{al/of{EM{S= G{cg/dt},E=3D760{dd/ce{DigitMap=3DG_DGT_MAP},al/on{strict=3Dexact}}},strict= =3Dexact}}}}}
=0A
=0A  Here term/2 is ringing and we got subtrac= t request with embedded signal descriptor. As of I understand , the signal = descriptor is activated only off-hook event occurs(From above request). The= ring tone on term/2 will be stopped only event occurs or new signal descri= ptor is activated(As per rfc). So when should I stop ring tone on term/2.=0A Can anyone clarify this please.
=0A
=0AThanks & Regards,=0AKumar
=0A
=0A 
=0A=0A

=0A

=0A=0A --Next_1084947627---0-203.199.83.248-11051 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi All,=0A We are trying the following scenerio.=0A Termination ID of = A is term/1 and B is term/2.=0A 1. A calls B. B is ringing and A is gettin= g Ringback tone.=0A 2. A goes on-hook while B is ringing.=0A A sends = on-hook notification to MGC.=0A MEGACO/1 [192.168.1.1]=0A Transaction =3D = 154 { Context =3D 14 { Notify =3D term/1 { ObservedEvents =3D 756 { al/on = { init =3D True } } } } } =0A =0A We got the following request from= MGC. =0A!/1 [192.168.1.2]=0AP=3D154{C=3D14{N=3Dterm/1}}=0AT=3D441{C=3D14{S= =3D*},C=3D-{MF=3Dterm/1{E=3D757{al/of{EM{SG{cg/dt},E=3D758{dd/ce{DigitMap= =3DG_DGT_MAP},al/on{strict=3Dexact}}},strict=3Dexact}}}}}=0AK{440}=0A=0A!/1= [192.168.1.2]=0AT=3D442{C=3D15{S=3D*},C=3D-{MF=3Dterm/2{E=3D759{al/of{EM{S= G{cg/dt},E=3D760{dd/ce{DigitMap=3DG_DGT_MAP},al/on{strict=3Dexact}}},strict= =3Dexact}}}}}=0A=0A Here term/2 is ringing and we got subtract request wit= h embedded signal descriptor. As of I understand , the signal descriptor is= activated only off-hook event occurs(From above request). The ring tone on= term/2 will be stopped only event occurs or new signal descriptor is activ= ated(As per rfc). So when should I stop ring tone on term/2.=0A Can anyone = clarify this please.=0A=0AThanks & Regards,=0AKumar=0A=0A =A0=0A --Next_1084947627---0-203.199.83.248-11051-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed May 19 05:40:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24961 for ; Wed, 19 May 2004 05:40:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQN7a-0007jJ-5i; Wed, 19 May 2004 05:12:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQMKV-0001Pq-Iu for megaco@optimus.ietf.org; Wed, 19 May 2004 04:21:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21065 for ; Wed, 19 May 2004 04:21:33 -0400 (EDT) From: assingh@hss.hns.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQMKS-0000fL-PK for megaco@ietf.org; Wed, 19 May 2004 04:21:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQMJb-0000Y9-00 for megaco@ietf.org; Wed, 19 May 2004 04:20:40 -0400 Received: from spark.hss.co.in ([203.200.71.140]) by ietf-mx with esmtp (Exim 4.12) id 1BQMIp-0000H6-00 for megaco@ietf.org; Wed, 19 May 2004 04:19:51 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id i4J8HvX4010138; Wed, 19 May 2004 13:47:58 +0530 (IST) Subject: Re: [Megaco] When do I stop ringing? To: "kumar" Cc: megaco@ietf.org, assingh@hss.hns.com Date: Wed, 19 May 2004 13:45:07 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 19/05/2004 01:38:14 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 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 Kumar, T=442{C=15{S=*},C=-{MF=term/2{E=759{al/of{EM{SG{cg/dt},E=760{dd/ce{DigitMap=G_DGT_MAP},al/on{strict=exact}}},strict=exact}}}}} ThisTransaction consists of 2 commands. First command is Subtract and another command is Modify. During processing of Subtract command, MG is supposed to stop detection of all events and stop all ongoing signals as termination returns to NULL context during Subtract command processing. Pls. find below the text in BOLD from Megaco Protocol supporting above mentioned statement. 6.2.4 Termination properties and descriptors Terminations have properties. The properties have unique PropertyIDs. Most properties have default values, which are explicitly defined in this protocol specification or in a package (see clause 12) or set by provisioning. 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. The default contents of the two exceptions are described in 7.1.5 and 7.1.7. Thanks Ashish www.hssworld.com "kumar" @ietf.org on 05/19/2004 11:50:27 AM Please respond to "kumar" Sent by: megaco-admin@ietf.org To: megaco@ietf.org cc: Subject: [Megaco] When do I stop ringing? Hi All, We are trying the following scenerio. Termination ID of A is term/1 and B is term/2. 1. A calls B. B is ringing and A is getting Ringback tone. 2. A goes on-hook while B is ringing. A sends on-hook notification to MGC. MEGACO/1 [192.168.1.1] Transaction = 154 { Context = 14 { Notify = term/1 { ObservedEvents = 756 { al/on { init = True } } } } } We got the following request from MGC. !/1 [192.168.1.2] P=154{C=14{N=term/1}} T=441{C=14{S=*},C=-{MF=term/1{E=757{al/of{EM{SG{cg/dt},E=758{dd/ce{DigitMap=G_DGT_MAP},al/on{strict=exact}}},strict=exact}}}}} K{440} !/1 [192.168.1.2] T=442{C=15{S=*},C=-{MF=term/2{E=759{al/of{EM{SG{cg/dt},E=760{dd/ce{DigitMap=G_DGT_MAP},al/on{strict=exact}}},strict=exact}}}}} Here term/2 is ringing and we got subtract request with embedded signal descriptor. As of I understand , the signal descriptor is activated only off-hook event occurs(From above request). The ring tone on term/2 will be stopped only event occurs or new signal descriptor is activated(As per rfc). So when should I stop ring tone on term/2. Can anyone clarify this please. Thanks & Regards, Kumar _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed May 19 06:03:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26942 for ; Wed, 19 May 2004 06:03:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNkW-0000UO-L3 for megaco-archive@odin.ietf.org; Wed, 19 May 2004 05:52:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4J9qTxl001826 for megaco-archive@odin.ietf.org; Wed, 19 May 2004 05:52:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNb5-0005k4-JR for megaco-web-archive@optimus.ietf.org; Wed, 19 May 2004 05:42:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25171 for ; Wed, 19 May 2004 05:42:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQNax-0005Ja-4q for megaco-web-archive@ietf.org; Wed, 19 May 2004 05:42:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQNZs-00057B-00 for megaco-web-archive@ietf.org; Wed, 19 May 2004 05:41:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQNYr-0004ly-00 for megaco-web-archive@ietf.org; Wed, 19 May 2004 05:40:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQN7a-0007jJ-5i; Wed, 19 May 2004 05:12:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQMKV-0001Pq-Iu for megaco@optimus.ietf.org; Wed, 19 May 2004 04:21:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21065 for ; Wed, 19 May 2004 04:21:33 -0400 (EDT) From: assingh@hss.hns.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQMKS-0000fL-PK for megaco@ietf.org; Wed, 19 May 2004 04:21:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQMJb-0000Y9-00 for megaco@ietf.org; Wed, 19 May 2004 04:20:40 -0400 Received: from spark.hss.co.in ([203.200.71.140]) by ietf-mx with esmtp (Exim 4.12) id 1BQMIp-0000H6-00 for megaco@ietf.org; Wed, 19 May 2004 04:19:51 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id i4J8HvX4010138; Wed, 19 May 2004 13:47:58 +0530 (IST) Subject: Re: [Megaco] When do I stop ringing? To: "kumar" Cc: megaco@ietf.org, assingh@hss.hns.com Date: Wed, 19 May 2004 13:45:07 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 19/05/2004 01:38:14 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.8 required=5.0 tests=AWL,NO_REAL_NAME, ROUND_THE_WORLD_LOCAL autolearn=no version=2.60 Hi Kumar, T=442{C=15{S=*},C=-{MF=term/2{E=759{al/of{EM{SG{cg/dt},E=760{dd/ce{DigitMap=G_DGT_MAP},al/on{strict=exact}}},strict=exact}}}}} ThisTransaction consists of 2 commands. First command is Subtract and another command is Modify. During processing of Subtract command, MG is supposed to stop detection of all events and stop all ongoing signals as termination returns to NULL context during Subtract command processing. Pls. find below the text in BOLD from Megaco Protocol supporting above mentioned statement. 6.2.4 Termination properties and descriptors Terminations have properties. The properties have unique PropertyIDs. Most properties have default values, which are explicitly defined in this protocol specification or in a package (see clause 12) or set by provisioning. 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. The default contents of the two exceptions are described in 7.1.5 and 7.1.7. Thanks Ashish www.hssworld.com "kumar" @ietf.org on 05/19/2004 11:50:27 AM Please respond to "kumar" Sent by: megaco-admin@ietf.org To: megaco@ietf.org cc: Subject: [Megaco] When do I stop ringing? Hi All, We are trying the following scenerio. Termination ID of A is term/1 and B is term/2. 1. A calls B. B is ringing and A is getting Ringback tone. 2. A goes on-hook while B is ringing. A sends on-hook notification to MGC. MEGACO/1 [192.168.1.1] Transaction = 154 { Context = 14 { Notify = term/1 { ObservedEvents = 756 { al/on { init = True } } } } } We got the following request from MGC. !/1 [192.168.1.2] P=154{C=14{N=term/1}} T=441{C=14{S=*},C=-{MF=term/1{E=757{al/of{EM{SG{cg/dt},E=758{dd/ce{DigitMap=G_DGT_MAP},al/on{strict=exact}}},strict=exact}}}}} K{440} !/1 [192.168.1.2] T=442{C=15{S=*},C=-{MF=term/2{E=759{al/of{EM{SG{cg/dt},E=760{dd/ce{DigitMap=G_DGT_MAP},al/on{strict=exact}}},strict=exact}}}}} Here term/2 is ringing and we got subtract request with embedded signal descriptor. As of I understand , the signal descriptor is activated only off-hook event occurs(From above request). The ring tone on term/2 will be stopped only event occurs or new signal descriptor is activated(As per rfc). So when should I stop ring tone on term/2. Can anyone clarify this please. Thanks & Regards, Kumar _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed May 19 14:32:30 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28825 for ; Wed, 19 May 2004 14:32:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQVlS-0005tr-Dn; Wed, 19 May 2004 14:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQRmX-0005KK-U6 for megaco@optimus.ietf.org; Wed, 19 May 2004 10:10:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12938 for ; Wed, 19 May 2004 10:10:50 -0400 (EDT) From: bvswamy@hss.hns.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQRmV-0007Cy-Oz for megaco@ietf.org; Wed, 19 May 2004 10:10:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQRlX-00078U-00 for megaco@ietf.org; Wed, 19 May 2004 10:09:51 -0400 Received: from spark.hss.co.in ([203.200.71.140]) by ietf-mx with esmtp (Exim 4.12) id 1BQRl8-00073S-00 for megaco@ietf.org; Wed, 19 May 2004 10:09:27 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id i4JE7WX4009928; Wed, 19 May 2004 19:37:32 +0530 (IST) Subject: Re: [Megaco] Megaco V1/V2/V3 ? To: Mike Dirk Cc: megaco@ietf.org Date: Wed, 19 May 2004 19:34:42 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 19/05/2004 07:27:47 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 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 Mike Megaco V3 is still under developement. And as far as V2 is concerned following are some of the main differences between V1 and V2 1. limiting the number of repetitions of transaction pending 2. Parameter level auditing, i.e., properties, events, signals and statistics can be audited by the MGC. 3. Now it is possible for the Media Gateway to indicate that its Capabilities have changed ( all changes can be conveyed via descriptors) 4. Now it is possible to Play a signal on the Root Termination 5. Modem descriptor being deprecated 6. MGC can describe the topology (who hears,sees whom) can be described per stram level instead of context level. 7. Added procedures to handle the Service change profile in the service change message. 8. Added requirement that initial ServiceChange of association use version 1 message format, even if ServiceChangeVersion is different 9. Not implicit, but AH is not recommended further on So IMO most of the features except the Audit one, lie in the nice to have category. So its all depend on whether you want to build a system that is compliant to the latest protocol or to have a system which conforms to a stable and experience-rich version. As far as the downward compatibility is concerned Version Negotiation feature of the protocol ensure downward compatibility. If we go through the Megaco-mail list which is a good repositary of the Megaco related information we don't find implementors talking much on V2. However I would leave this to Megaco authors to provide more details or insight into the V2 traction in the market. Regards Venkat Hughes Software Systems www.hssworld.com Mike Dirk @ietf.org on 05/17/2004 02:59:04 PM Sent by: megaco-admin@ietf.org To: megaco@ietf.org cc: Subject: [Megaco] Megaco V1/V2/V3 ? Hi All We are a small group of developers trying to develop Megaco protocol stacks. However having gone through the Megaco recommendations , we seems to be confronted with lot of options on which protocol version to start with. There are three versions of the H248.1 protocol. Therefore request Megaco gurus to provide information on general acceptibility in the market for the different versions. Any pointers to information/report on vendors supporting different megaco versions will be of great help. Also are the latest versions downward compatible. I thank you for an answer. rgds Mike Dirk __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed May 19 15:39:57 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06744 for ; Wed, 19 May 2004 15:39:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQWkh-0007Ov-BJ for megaco-archive@odin.ietf.org; Wed, 19 May 2004 15:29:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JJTJwp028407 for megaco-archive@odin.ietf.org; Wed, 19 May 2004 15:29:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQVt8-0007bH-3F for megaco-web-archive@optimus.ietf.org; Wed, 19 May 2004 14:33:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29051 for ; Wed, 19 May 2004 14:33:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQVt5-0006SH-EZ for megaco-web-archive@ietf.org; Wed, 19 May 2004 14:33:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQVsF-0006MC-00 for megaco-web-archive@ietf.org; Wed, 19 May 2004 14:33:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQVrE-0006GS-00 for megaco-web-archive@ietf.org; Wed, 19 May 2004 14:32:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQVlS-0005tr-Dn; Wed, 19 May 2004 14:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQRmX-0005KK-U6 for megaco@optimus.ietf.org; Wed, 19 May 2004 10:10:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12938 for ; Wed, 19 May 2004 10:10:50 -0400 (EDT) From: bvswamy@hss.hns.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQRmV-0007Cy-Oz for megaco@ietf.org; Wed, 19 May 2004 10:10:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQRlX-00078U-00 for megaco@ietf.org; Wed, 19 May 2004 10:09:51 -0400 Received: from spark.hss.co.in ([203.200.71.140]) by ietf-mx with esmtp (Exim 4.12) id 1BQRl8-00073S-00 for megaco@ietf.org; Wed, 19 May 2004 10:09:27 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id i4JE7WX4009928; Wed, 19 May 2004 19:37:32 +0530 (IST) Subject: Re: [Megaco] Megaco V1/V2/V3 ? To: Mike Dirk Cc: megaco@ietf.org Date: Wed, 19 May 2004 19:34:42 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 19/05/2004 07:27:47 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.4 required=5.0 tests=AWL,NO_REAL_NAME, ROUND_THE_WORLD_LOCAL autolearn=no version=2.60 Hi Mike Megaco V3 is still under developement. And as far as V2 is concerned following are some of the main differences between V1 and V2 1. limiting the number of repetitions of transaction pending 2. Parameter level auditing, i.e., properties, events, signals and statistics can be audited by the MGC. 3. Now it is possible for the Media Gateway to indicate that its Capabilities have changed ( all changes can be conveyed via descriptors) 4. Now it is possible to Play a signal on the Root Termination 5. Modem descriptor being deprecated 6. MGC can describe the topology (who hears,sees whom) can be described per stram level instead of context level. 7. Added procedures to handle the Service change profile in the service change message. 8. Added requirement that initial ServiceChange of association use version 1 message format, even if ServiceChangeVersion is different 9. Not implicit, but AH is not recommended further on So IMO most of the features except the Audit one, lie in the nice to have category. So its all depend on whether you want to build a system that is compliant to the latest protocol or to have a system which conforms to a stable and experience-rich version. As far as the downward compatibility is concerned Version Negotiation feature of the protocol ensure downward compatibility. If we go through the Megaco-mail list which is a good repositary of the Megaco related information we don't find implementors talking much on V2. However I would leave this to Megaco authors to provide more details or insight into the V2 traction in the market. Regards Venkat Hughes Software Systems www.hssworld.com Mike Dirk @ietf.org on 05/17/2004 02:59:04 PM Sent by: megaco-admin@ietf.org To: megaco@ietf.org cc: Subject: [Megaco] Megaco V1/V2/V3 ? Hi All We are a small group of developers trying to develop Megaco protocol stacks. However having gone through the Megaco recommendations , we seems to be confronted with lot of options on which protocol version to start with. There are three versions of the H248.1 protocol. Therefore request Megaco gurus to provide information on general acceptibility in the market for the different versions. Any pointers to information/report on vendors supporting different megaco versions will be of great help. Also are the latest versions downward compatible. I thank you for an answer. rgds Mike Dirk __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ _______________________________________________ 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 May 19 20:34:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01426 for ; Wed, 19 May 2004 20:34:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQbRj-0000eV-3h; Wed, 19 May 2004 20:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQbNw-0007xn-86 for megaco@optimus.ietf.org; Wed, 19 May 2004 20:26:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00963 for ; Wed, 19 May 2004 20:26:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQbNt-0001pr-SC for megaco@ietf.org; Wed, 19 May 2004 20:26:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQbMw-0001j1-00 for megaco@ietf.org; Wed, 19 May 2004 20:25:06 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BQbM4-0001Wj-00 for megaco@ietf.org; Wed, 19 May 2004 20:24:12 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4K0NeO17192 for ; Wed, 19 May 2004 20:23:40 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 May 2004 20:23:40 -0400 Message-ID: From: "Kevin Boyle" To: bvswamy@hss.hns.com, Mike Dirk Cc: megaco@ietf.org Subject: RE: [Megaco] Megaco V1/V2/V3 ? Date: Wed, 19 May 2004 20:23:39 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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: , Keep in mind that version 1 will cease to be supported upon completion of version 3. This means that clarifications, bug fixes, etc., will NOT be made to version 1 after that point. Because H.248 versions are backward compatible, I suggest going with the latest available version. Kevin -----Original Message----- From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] Sent: Wednesday, May 19, 2004 10:05 PM To: Mike Dirk Cc: megaco@ietf.org Subject: Re: [Megaco] Megaco V1/V2/V3 ? Hi Mike Megaco V3 is still under developement. And as far as V2 is concerned following are some of the main differences between V1 and V2 1. limiting the number of repetitions of transaction pending 2. Parameter level auditing, i.e., properties, events, signals and statistics can be audited by the MGC. 3. Now it is possible for the Media Gateway to indicate that its Capabilities have changed ( all changes can be conveyed via descriptors) 4. Now it is possible to Play a signal on the Root Termination 5. Modem descriptor being deprecated 6. MGC can describe the topology (who hears,sees whom) can be described per stram level instead of context level. 7. Added procedures to handle the Service change profile in the service change message. 8. Added requirement that initial ServiceChange of association use version 1 message format, even if ServiceChangeVersion is different 9. Not implicit, but AH is not recommended further on So IMO most of the features except the Audit one, lie in the nice to have category. So its all depend on whether you want to build a system that is compliant to the latest protocol or to have a system which conforms to a stable and experience-rich version. As far as the downward compatibility is concerned Version Negotiation feature of the protocol ensure downward compatibility. If we go through the Megaco-mail list which is a good repositary of the Megaco related information we don't find implementors talking much on V2. However I would leave this to Megaco authors to provide more details or insight into the V2 traction in the market. Regards Venkat Hughes Software Systems www.hssworld.com Mike Dirk @ietf.org on 05/17/2004 02:59:04 PM Sent by: megaco-admin@ietf.org To: megaco@ietf.org cc: Subject: [Megaco] Megaco V1/V2/V3 ? Hi All We are a small group of developers trying to develop Megaco protocol stacks. However having gone through the Megaco recommendations , we seems to be confronted with lot of options on which protocol version to start with. There are three versions of the H248.1 protocol. Therefore request Megaco gurus to provide information on general acceptibility in the market for the different versions. Any pointers to information/report on vendors supporting different megaco versions will be of great help. Also are the latest versions downward compatible. I thank you for an answer. rgds Mike Dirk __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed May 19 20:38:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01673 for ; Wed, 19 May 2004 20:38:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQbXn-00023o-Ec for megaco-archive@odin.ietf.org; Wed, 19 May 2004 20:36:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K0aJ37007920 for megaco-archive@odin.ietf.org; Wed, 19 May 2004 20:36:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQbWd-0001dm-Sl for megaco-web-archive@optimus.ietf.org; Wed, 19 May 2004 20:35:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01501 for ; Wed, 19 May 2004 20:35:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQbWb-0002yD-EQ for megaco-web-archive@ietf.org; Wed, 19 May 2004 20:35:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQbVj-0002sU-00 for megaco-web-archive@ietf.org; Wed, 19 May 2004 20:34:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQbVB-0002mJ-00 for megaco-web-archive@ietf.org; Wed, 19 May 2004 20:33:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQbRj-0000eV-3h; Wed, 19 May 2004 20:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQbNw-0007xn-86 for megaco@optimus.ietf.org; Wed, 19 May 2004 20:26:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00963 for ; Wed, 19 May 2004 20:26:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQbNt-0001pr-SC for megaco@ietf.org; Wed, 19 May 2004 20:26:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQbMw-0001j1-00 for megaco@ietf.org; Wed, 19 May 2004 20:25:06 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BQbM4-0001Wj-00 for megaco@ietf.org; Wed, 19 May 2004 20:24:12 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4K0NeO17192 for ; Wed, 19 May 2004 20:23:40 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 May 2004 20:23:40 -0400 Message-ID: From: "Kevin Boyle" To: bvswamy@hss.hns.com, Mike Dirk Cc: megaco@ietf.org Subject: RE: [Megaco] Megaco V1/V2/V3 ? Date: Wed, 19 May 2004 20:23:39 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Keep in mind that version 1 will cease to be supported upon completion of version 3. This means that clarifications, bug fixes, etc., will NOT be made to version 1 after that point. Because H.248 versions are backward compatible, I suggest going with the latest available version. Kevin -----Original Message----- From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] Sent: Wednesday, May 19, 2004 10:05 PM To: Mike Dirk Cc: megaco@ietf.org Subject: Re: [Megaco] Megaco V1/V2/V3 ? Hi Mike Megaco V3 is still under developement. And as far as V2 is concerned following are some of the main differences between V1 and V2 1. limiting the number of repetitions of transaction pending 2. Parameter level auditing, i.e., properties, events, signals and statistics can be audited by the MGC. 3. Now it is possible for the Media Gateway to indicate that its Capabilities have changed ( all changes can be conveyed via descriptors) 4. Now it is possible to Play a signal on the Root Termination 5. Modem descriptor being deprecated 6. MGC can describe the topology (who hears,sees whom) can be described per stram level instead of context level. 7. Added procedures to handle the Service change profile in the service change message. 8. Added requirement that initial ServiceChange of association use version 1 message format, even if ServiceChangeVersion is different 9. Not implicit, but AH is not recommended further on So IMO most of the features except the Audit one, lie in the nice to have category. So its all depend on whether you want to build a system that is compliant to the latest protocol or to have a system which conforms to a stable and experience-rich version. As far as the downward compatibility is concerned Version Negotiation feature of the protocol ensure downward compatibility. If we go through the Megaco-mail list which is a good repositary of the Megaco related information we don't find implementors talking much on V2. However I would leave this to Megaco authors to provide more details or insight into the V2 traction in the market. Regards Venkat Hughes Software Systems www.hssworld.com Mike Dirk @ietf.org on 05/17/2004 02:59:04 PM Sent by: megaco-admin@ietf.org To: megaco@ietf.org cc: Subject: [Megaco] Megaco V1/V2/V3 ? Hi All We are a small group of developers trying to develop Megaco protocol stacks. However having gone through the Megaco recommendations , we seems to be confronted with lot of options on which protocol version to start with. There are three versions of the H248.1 protocol. Therefore request Megaco gurus to provide information on general acceptibility in the market for the different versions. Any pointers to information/report on vendors supporting different megaco versions will be of great help. Also are the latest versions downward compatible. I thank you for an answer. rgds Mike Dirk __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ _______________________________________________ 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 May 19 21:49:43 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04761 for ; Wed, 19 May 2004 21:49:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcUY-0006xw-I9; Wed, 19 May 2004 21:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcQC-00063F-5i for megaco@optimus.ietf.org; Wed, 19 May 2004 21:32:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04060 for ; Wed, 19 May 2004 21:32:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQcQ9-0002lI-BQ for megaco@ietf.org; Wed, 19 May 2004 21:32:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQcP3-0002bI-00 for megaco@ietf.org; Wed, 19 May 2004 21:31:22 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BQcOC-0002SX-00 for megaco@ietf.org; Wed, 19 May 2004 21:30:28 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i4K1URWR024801 for ; Thu, 20 May 2004 03:30:27 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 20 May 2004 03:30:27 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LFS50XPA; Thu, 20 May 2004 03:30:27 +0200 Received: from ericsson.com (EG2E500202DSEGL [146.11.135.119]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LGSRQ7KC; Thu, 20 May 2004 11:30:24 +1000 Message-ID: <40AC080F.4040403@ericsson.com> Date: Thu, 20 May 2004 11:21:19 +1000 X-Sybari-Trust: b3fd372b 08d63d2e 74a7d05a 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco ietf Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 May 2004 01:30:27.0759 (UTC) FILETIME=[07F94BF0:01C43E0A] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,USERPASS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Megaco] ITU-T Q.3/16 H.248 Results [Fwd: Outcome of the Beijing meeting]] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello all, FYI. The results of the ITU SG16 meeting are now available (see below). Q.3 is responsible for H.248 and TD-12a contains the report of the meeting. Regards, Christian -------- Original Message -------- Subject: Outcome of the Beijing meeting Date: Mon, 17 May 2004 09:26:03 -0400 (EDT) From: OKUBO Sakae To: itu-sg16@external.cisco.com CC: Pierre-Andre PROBST Dear SG16 experts. Last week we had a successful meeting Questions F,G,2-5/16 in Beijing. The reports of the meeting are contained in the following TDs: http://avguest@ftp3.itu.int/av-arch/avc-site/0405_Bei/ password: Avguest General -- TD-32c + LS(TD-50a, TD-51a) Q.F/16 --- TD-09a Q.G/16 --- TD-10b + LS(TD-49a) Q.2/16 --- TD-11a + LS(TD-38a, TD-48a) Q.3/16 --- TD-12a + LS(TD-39, TD-40a) Q.4/16 --- TD-13a + LS(TD-35) Q.5/16 --- TD-14c The document list is found at: ftp://avguest:Avguest@ftp3.itu.int/av-arch/avc-site/0405_Bei http://avguest@ftp3.itu.int/av-arch/avc-site/0405_Bei/0504_Bei.html We reviewed 90 AVD-numbered documents including 15 incoming liaisons and 51 TDs. The list of participants will be advised as soon as it has been received from the host. There were 20 delegates from organizations outside China and more than 20 local participants. Please note that TD-32c does not mention TD-50a (LS to JRG-NGN), but it was agreed to send this liaison at the closing session. All these materials will be integrated into AVD-2503. -- Best regards, OKUBO Sakae e-mail: sokubo@waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ****************************************************************** _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed May 19 22:02:07 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05317 for ; Wed, 19 May 2004 22:02:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcnc-0002bh-3V for megaco-archive@odin.ietf.org; Wed, 19 May 2004 21:56:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K1uiFA010021 for megaco-archive@odin.ietf.org; Wed, 19 May 2004 21:56:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQciK-0001uD-8q for megaco-web-archive@optimus.ietf.org; Wed, 19 May 2004 21:51:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04813 for ; Wed, 19 May 2004 21:51:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQciH-0005Nt-BQ for megaco-web-archive@ietf.org; Wed, 19 May 2004 21:51:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQchE-0005EM-00 for megaco-web-archive@ietf.org; Wed, 19 May 2004 21:50:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQcgL-00055g-00 for megaco-web-archive@ietf.org; Wed, 19 May 2004 21:49:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcUY-0006xw-I9; Wed, 19 May 2004 21:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcQC-00063F-5i for megaco@optimus.ietf.org; Wed, 19 May 2004 21:32:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04060 for ; Wed, 19 May 2004 21:32:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQcQ9-0002lI-BQ for megaco@ietf.org; Wed, 19 May 2004 21:32:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQcP3-0002bI-00 for megaco@ietf.org; Wed, 19 May 2004 21:31:22 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BQcOC-0002SX-00 for megaco@ietf.org; Wed, 19 May 2004 21:30:28 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i4K1URWR024801 for ; Thu, 20 May 2004 03:30:27 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 20 May 2004 03:30:27 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LFS50XPA; Thu, 20 May 2004 03:30:27 +0200 Received: from ericsson.com (EG2E500202DSEGL [146.11.135.119]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LGSRQ7KC; Thu, 20 May 2004 11:30:24 +1000 Message-ID: <40AC080F.4040403@ericsson.com> Date: Thu, 20 May 2004 11:21:19 +1000 X-Sybari-Trust: b3fd372b 08d63d2e 74a7d05a 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco ietf Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 May 2004 01:30:27.0759 (UTC) FILETIME=[07F94BF0:01C43E0A] Content-Transfer-Encoding: 7bit Subject: [Megaco] ITU-T Q.3/16 H.248 Results [Fwd: Outcome of the Beijing meeting]] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,USERPASS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello all, FYI. The results of the ITU SG16 meeting are now available (see below). Q.3 is responsible for H.248 and TD-12a contains the report of the meeting. Regards, Christian -------- Original Message -------- Subject: Outcome of the Beijing meeting Date: Mon, 17 May 2004 09:26:03 -0400 (EDT) From: OKUBO Sakae To: itu-sg16@external.cisco.com CC: Pierre-Andre PROBST Dear SG16 experts. Last week we had a successful meeting Questions F,G,2-5/16 in Beijing. The reports of the meeting are contained in the following TDs: http://avguest@ftp3.itu.int/av-arch/avc-site/0405_Bei/ password: Avguest General -- TD-32c + LS(TD-50a, TD-51a) Q.F/16 --- TD-09a Q.G/16 --- TD-10b + LS(TD-49a) Q.2/16 --- TD-11a + LS(TD-38a, TD-48a) Q.3/16 --- TD-12a + LS(TD-39, TD-40a) Q.4/16 --- TD-13a + LS(TD-35) Q.5/16 --- TD-14c The document list is found at: ftp://avguest:Avguest@ftp3.itu.int/av-arch/avc-site/0405_Bei http://avguest@ftp3.itu.int/av-arch/avc-site/0405_Bei/0504_Bei.html We reviewed 90 AVD-numbered documents including 15 incoming liaisons and 51 TDs. The list of participants will be advised as soon as it has been received from the host. There were 20 delegates from organizations outside China and more than 20 local participants. Please note that TD-32c does not mention TD-50a (LS to JRG-NGN), but it was agreed to send this liaison at the closing session. All these materials will be integrated into AVD-2503. -- Best regards, OKUBO Sakae e-mail: sokubo@waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ****************************************************************** _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri May 21 14:43:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20861 for ; Fri, 21 May 2004 14:43:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BREma-0006Wm-My; Fri, 21 May 2004 14:30:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BREk6-0005wv-97 for megaco@optimus.ietf.org; Fri, 21 May 2004 14:27:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19819 for ; Fri, 21 May 2004 14:27:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BREk3-0002iq-JW for megaco@ietf.org; Fri, 21 May 2004 14:27:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BREjB-0002gJ-00 for megaco@ietf.org; Fri, 21 May 2004 14:26:41 -0400 Received: from pat.telica.com ([4.19.224.196] helo=wench.telica.com) by ietf-mx with esmtp (Exim 4.12) id 1BREil-0002dl-00 for megaco@ietf.org; Fri, 21 May 2004 14:26:15 -0400 Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 May 2004 14:24:41 -0400 Message-ID: From: Brad Steinka To: megaco@ietf.org Date: Fri, 21 May 2004 14:24:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43F60.E1ED3ACC" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=HTML_70_80,HTML_MESSAGE autolearn=no version=2.60 Subject: [Megaco] Sample call flow for Voice over ATM 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_01C43F60.E1ED3ACC Content-Type: text/plain Hi, I'm looking for best current practices for establishing AAL2 VoATM connections using MEGACO. Sample call flows for backward call setup would be great. Thanks Brad ------_=_NextPart_001_01C43F60.E1ED3ACC Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Hi,

 

I’m looking for best current practices for establishing AAL2 VoATM connections using = MEGACO.

Sample call flows for backward call setup would be = great.

 

Thanks

Brad

------_=_NextPart_001_01C43F60.E1ED3ACC-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri May 21 14:58:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21685 for ; Fri, 21 May 2004 14:58:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRF5v-00027Q-3c for megaco-archive@odin.ietf.org; Fri, 21 May 2004 14:50:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LIoBbP008144 for megaco-archive@odin.ietf.org; Fri, 21 May 2004 14:50:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRF0T-00018f-PH for megaco-web-archive@optimus.ietf.org; Fri, 21 May 2004 14:44:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21050 for ; Fri, 21 May 2004 14:44:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRF0R-00041i-2g for megaco-web-archive@ietf.org; Fri, 21 May 2004 14:44:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BREzu-0003zr-00 for megaco-web-archive@ietf.org; Fri, 21 May 2004 14:43:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BREyz-0003vG-00 for megaco-web-archive@ietf.org; Fri, 21 May 2004 14:43:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BREma-0006Wm-My; Fri, 21 May 2004 14:30:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BREk6-0005wv-97 for megaco@optimus.ietf.org; Fri, 21 May 2004 14:27:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19819 for ; Fri, 21 May 2004 14:27:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BREk3-0002iq-JW for megaco@ietf.org; Fri, 21 May 2004 14:27:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BREjB-0002gJ-00 for megaco@ietf.org; Fri, 21 May 2004 14:26:41 -0400 Received: from pat.telica.com ([4.19.224.196] helo=wench.telica.com) by ietf-mx with esmtp (Exim 4.12) id 1BREil-0002dl-00 for megaco@ietf.org; Fri, 21 May 2004 14:26:15 -0400 Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 May 2004 14:24:41 -0400 Message-ID: From: Brad Steinka To: megaco@ietf.org Date: Fri, 21 May 2004 14:24:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43F60.E1ED3ACC" Subject: [Megaco] Sample call flow for Voice over ATM 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=HTML_70_80,HTML_MESSAGE autolearn=no version=2.60 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_01C43F60.E1ED3ACC Content-Type: text/plain Hi, I'm looking for best current practices for establishing AAL2 VoATM connections using MEGACO. Sample call flows for backward call setup would be great. Thanks Brad ------_=_NextPart_001_01C43F60.E1ED3ACC Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Hi,

 

I’m looking for best current practices for establishing AAL2 VoATM connections using = MEGACO.

Sample call flows for backward call setup would be = great.

 

Thanks

Brad

------_=_NextPart_001_01C43F60.E1ED3ACC-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Sun May 23 21:38:33 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19156 for ; Sun, 23 May 2004 21:38:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS4Iw-0008PF-Nt; Sun, 23 May 2004 21:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS4Ex-0007cr-02 for megaco@optimus.ietf.org; Sun, 23 May 2004 21:26:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18733 for ; Sun, 23 May 2004 21:26:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS4Eu-0005dT-AE for megaco@ietf.org; Sun, 23 May 2004 21:26:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS4E4-0005Nt-00 for megaco@ietf.org; Sun, 23 May 2004 21:26:01 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BS4DU-00057j-00 for megaco@ietf.org; Sun, 23 May 2004 21:25:24 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i4O1POAh005541 for ; Mon, 24 May 2004 03:25:24 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 May 2004 03:25:19 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LGNZVTAC; Mon, 24 May 2004 02:26:55 +0200 Received: from ericsson.com (EG2E500202DSEGL [146.11.135.25]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LGSRTJ02; Mon, 24 May 2004 10:26:52 +1000 Message-ID: <40B135FE.9060109@ericsson.com> Date: Mon, 24 May 2004 09:38:38 +1000 X-Sybari-Trust: d47c5353 08d63d2e 76e6f026 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brad Steinka CC: megaco@ietf.org Subject: Re: [Megaco] Sample call flow for Voice over ATM References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 24 May 2004 01:25:20.0078 (UTC) FILETIME=[FA3BE6E0:01C4412D] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by eagle.ericsson.se id i4O1POAh005541 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello Brad, You may want to check out ITU-T Q.1950. Regards, Christian Brad Steinka wrote: > Hi, >=20 > =20 >=20 > I=92m looking for best current practices for establishing AAL2 VoATM=20 > connections using MEGACO. >=20 > Sample call flows for backward call setup would be great. >=20 > =20 >=20 > Thanks >=20 > Brad >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Sun May 23 21:42:59 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19350 for ; Sun, 23 May 2004 21:42:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS4SK-0001hE-2k for megaco-archive@odin.ietf.org; Sun, 23 May 2004 21:40:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O1eiRm006516 for megaco-archive@odin.ietf.org; Sun, 23 May 2004 21:40:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS4Rb-0001Xu-2G for megaco-web-archive@optimus.ietf.org; Sun, 23 May 2004 21:39:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19208 for ; Sun, 23 May 2004 21:39:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS4RY-0001KT-6m for megaco-web-archive@ietf.org; Sun, 23 May 2004 21:39:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS4Qb-00013w-00 for megaco-web-archive@ietf.org; Sun, 23 May 2004 21:38:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BS4Pk-0000oM-00 for megaco-web-archive@ietf.org; Sun, 23 May 2004 21:38:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS4Iw-0008PF-Nt; Sun, 23 May 2004 21:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS4Ex-0007cr-02 for megaco@optimus.ietf.org; Sun, 23 May 2004 21:26:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18733 for ; Sun, 23 May 2004 21:26:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS4Eu-0005dT-AE for megaco@ietf.org; Sun, 23 May 2004 21:26:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS4E4-0005Nt-00 for megaco@ietf.org; Sun, 23 May 2004 21:26:01 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BS4DU-00057j-00 for megaco@ietf.org; Sun, 23 May 2004 21:25:24 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i4O1POAh005541 for ; Mon, 24 May 2004 03:25:24 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 May 2004 03:25:19 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LGNZVTAC; Mon, 24 May 2004 02:26:55 +0200 Received: from ericsson.com (EG2E500202DSEGL [146.11.135.25]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LGSRTJ02; Mon, 24 May 2004 10:26:52 +1000 Message-ID: <40B135FE.9060109@ericsson.com> Date: Mon, 24 May 2004 09:38:38 +1000 X-Sybari-Trust: d47c5353 08d63d2e 76e6f026 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brad Steinka CC: megaco@ietf.org Subject: Re: [Megaco] Sample call flow for Voice over ATM References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 24 May 2004 01:25:20.0078 (UTC) FILETIME=[FA3BE6E0:01C4412D] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by eagle.ericsson.se id i4O1POAh005541 Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Brad, You may want to check out ITU-T Q.1950. Regards, Christian Brad Steinka wrote: > Hi, >=20 > =20 >=20 > I=92m looking for best current practices for establishing AAL2 VoATM=20 > connections using MEGACO. >=20 > Sample call flows for backward call setup would be great. >=20 > =20 >=20 > Thanks >=20 > Brad >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue May 25 02:20:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16932 for ; Tue, 25 May 2004 02:20:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSVEQ-0001zf-Qx; Tue, 25 May 2004 02:16:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSMh7-0004nX-0K for megaco@megatron.ietf.org; Mon, 24 May 2004 17:09:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00886 for ; Mon, 24 May 2004 17:09:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSMh5-0006IW-O5 for megaco@ietf.org; Mon, 24 May 2004 17:09:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSMH8-0003Yv-00 for megaco@ietf.org; Mon, 24 May 2004 16:42:25 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BSLEy-0000RF-00 for megaco@ietf.org; Mon, 24 May 2004 15:36:04 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 24 May 2004 11:42:22 +0000 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4OJZV8R028696; Mon, 24 May 2004 12:35:31 -0700 (PDT) Received: from cisco.com (dhcp-171-71-9-171.cisco.com [171.71.9.171]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AQW42872; Mon, 24 May 2004 12:34:49 -0700 (PDT) Message-ID: <40B24EA5.3040808@cisco.com> Date: Mon, 24 May 2004 12:36:05 -0700 From: Steve Yeung Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=DEAR_SOMETHING autolearn=no version=2.60 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 25 May 2004 02:16:09 -0400 Cc: Steve Yeung Subject: [Megaco] Question on signal/event behaviour X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit Dear Sir/Madam: I want to confirm the following behaviour on Megaco (H.248). The following sequence of operation does not use the KeepActive option. When we have 2 sequences of commands going to MG as follow: 1. event: g/sc signal: cg/dt, duration=60 seconds, notifycompletion = timeout, intbyevent, intbysigdesc, otherreason 2. after 10 seconds 3. event: g/sc signal: cg/bt, duration= 60 seconds, notifycompletion=timeout, intbyevent, intbysigdesc, otherreason Behaviour 1: After received the 2nd signal (i.e. cg/bt), the MG wll sent notify with reason SD, then in a few millisecond, the MG will sent notify with reason EV to MGC. The 2nd signal did not play (or played for a few millisecond only). Behaviour 2: After received the 2nd signal (i.e. cg/bt), MG will sent notify with reason SD, then the 2nd signal will play for 60 seconds. After the 2nd signal timeout, the MG will sent notify with reason TO to MGC. My question is which behaviour is correct? Thank you very much! -- Steve Yeung Software Engineer 408-853-4214 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue May 25 13:39:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02575 for ; Tue, 25 May 2004 13:39:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSfYO-0006j1-P5; Tue, 25 May 2004 13:17:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSfJV-0000Vy-K6 for megaco@megatron.ietf.org; Tue, 25 May 2004 13:02:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29790 for ; Tue, 25 May 2004 13:02:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSfJU-0007Ka-J1 for megaco@ietf.org; Tue, 25 May 2004 13:02:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSfIY-0007IF-00 for megaco@ietf.org; Tue, 25 May 2004 13:01:06 -0400 Received: from pat.telica.com ([4.19.224.196] helo=wench.telica.com) by ietf-mx with esmtp (Exim 4.12) id 1BSfHy-0007Fe-00 for megaco@ietf.org; Tue, 25 May 2004 13:00:30 -0400 Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 May 2004 12:59:48 -0400 Message-ID: From: Carl Rutter To: megaco@ietf.org Date: Tue, 25 May 2004 12:59:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Megaco] Event Clarification X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org I would like to get a clarification on the following questions: 1. After a MODIFY command with an events descriptor is applied to a TDM terminator in the NULL context, if that TDM terminator is added into a real context, the events descriptor stays active right? 2. After a MODIFY command with an events descriptor is applied to a TDM terminator in a real context, if that TDM terminator is subtracted into the NULL context, would the events descriptor stay active or not? Thx, Carl _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Wed May 26 03:15:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25812 for ; Wed, 26 May 2004 03:15:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSs6b-0005xJ-6G; Wed, 26 May 2004 02:41:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSrrB-0005k7-EC for megaco@megatron.ietf.org; Wed, 26 May 2004 02:25:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18556 for ; Wed, 26 May 2004 02:25:25 -0400 (EDT) From: assingh@hss.hns.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSrqu-0001Er-6C for megaco@ietf.org; Wed, 26 May 2004 02:25:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSrqH-00018c-00 for megaco@ietf.org; Wed, 26 May 2004 02:24:46 -0400 Received: from spark.hss.co.in ([203.200.71.140]) by ietf-mx with esmtp (Exim 4.12) id 1BSrpd-0000zG-00 for megaco@ietf.org; Wed, 26 May 2004 02:24:06 -0400 Received: from ultra.hss.co.in (ultra [192.168.100.5] (may be forged)) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id i4Q6M8X4003484; Wed, 26 May 2004 11:52:09 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id i4Q6OH126989; Wed, 26 May 2004 11:54:17 +0530 (IST) Subject: Re: [Megaco] Event Clarification To: Carl Rutter Date: Wed, 26 May 2004 11:49:00 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 26/05/2004 11:42:04 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.8 required=5.0 tests=AWL,NO_REAL_NAME, ROUND_THE_WORLD_LOCAL autolearn=no version=2.60 Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hi Carl, According to Protocol, if descriptor is absent in the command, then old descriptor remains valid. In 1st case, If Add command does not contain event descriptor, then old event descriptor shall remain active on the TDM termination. In 2nd case, Subtract command processing shall reset event descriptor. Thanks Ashish. www.hssworld.com Carl Rutter @ietf.org on 05/25/2004 10:29:47 PM Sent by: megaco-bounces@ietf.org To: megaco@ietf.org cc: Subject: [Megaco] Event Clarification I would like to get a clarification on the following questions: 1. After a MODIFY command with an events descriptor is applied to a TDM terminator in the NULL context, if that TDM terminator is added into a real context, the events descriptor stays active right? 2. After a MODIFY command with an events descriptor is applied to a TDM terminator in a real context, if that TDM terminator is subtracted into the NULL context, would the events descriptor stay active or not? Thx, Carl _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu May 27 21:46:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11058 for ; Thu, 27 May 2004 21:46:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTW2J-0000wE-RY; Thu, 27 May 2004 21:19:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTVpH-00067t-9W for megaco@megatron.ietf.org; Thu, 27 May 2004 21:06:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09241 for ; Thu, 27 May 2004 21:06:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTVpF-0002Lq-KN for megaco@ietf.org; Thu, 27 May 2004 21:06:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTVoG-00023B-00 for megaco@ietf.org; Thu, 27 May 2004 21:05:21 -0400 Received: from [203.226.253.207] (helo=smtp1.nate.com) by ietf-mx with esmtp (Exim 4.12) id 1BTVnf-0001i9-00 for megaco@ietf.org; Thu, 27 May 2004 21:04:43 -0400 Received: from [10.191.60.1] (byundw@nate.com) by smtp1.nate.com (Terrace MailWatcher) with ESMTP id 2004052810:04:07:831175.28555.3050826672 for ; Fri, 28 May 2004 10:04:07 +0900 (KST) MIME-Version: 1.0 From: "=?euc-kr?B?uq+1v7/s?=" To: megaco@ietf.org Date: Fri, 28 May 2004 10:04:07 +0900 X-TERRACE-SPAMMARK: NOT spam-marked. (by Terrace) Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.1 required=5.0 tests=HTML_50_60, HTML_FONTCOLOR_UNSAFE,HTML_IMAGE_ONLY_12,HTML_MESSAGE, HTML_TITLE_EMPTY,HTML_WEB_BUGS,HTTP_WITH_EMAIL_IN_URL, MIME_BASE64_TEXT, MIME_HTML_ONLY, NO_REAL_NAME autolearn=no version=2.60 Subject: [Megaco] Bypass(hairpin?) TDM SS7 signal channel X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1611878835==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org --===============1611878835== Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: base64 PElNRyBTUkM9ICJodHRwOi8vcGNtYWlsLm5hdGUuY29tL05hdGVDb25maXJtTWdyLnBocD9hY3Q9 Y29uZmlybSZrZXk9MTA4NTcwNjI0N19tZWdhY29AaWV0Zi5vcmcmZnJvbT18Y3BkZDdfMnw5MXwx NDd8Ynl1bmR3QG5hdGUuY29tIiBoZWlnaHQ9IjAiIHdpZHRoPSIwIj48SFRNTD4NCjxIRUFEPg0K PE1FVEEgTkFNRT0iR0VORVJBVE9SIiBDb250ZW50PSJNaWNyb3NvZnQgREhUTUwgRWRpdGluZyBD b250cm9sIj4NCjxUSVRMRT48L1RJVExFPg0KPC9IRUFEPg0KPEJPRFkgDQpzdHlsZT0iRk9OVC1T SVpFOiAxM3B4OyBCT1JERVItVE9QLVNUWUxFOiBub25lOyBGT05ULUZBTUlMWTogsby4sjsgQk9S REVSLVJJR0hULVNUWUxFOiBub25lOyBCT1JERVItTEVGVC1TVFlMRTogbm9uZTsgQk9SREVSLUJP VFRPTS1TVFlMRTogbm9uZSI+DQo8UD48Rk9OVCBmYWNlPUNvdXJpZXI+SGkmbmJzcDtldmVyeW9u ZSw8L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgZmFjZT1Db3VyaWVyPkknbSB0cnlpbmcgdG8mbmJzcDt1 c2UgdGhlIFRydW5rIEdhdGV3YXkgd2l0aCBFMSANCnBvcnQuPC9GT05UPjwvUD4NCjxQPjxGT05U IGZhY2U9Q291cmllcj5JIHdhbnQgdG8gdXNlIEUxJm5ic3A7dHJ1bmsgd2hpY2ggaGFzIDMwIFBD TSBiZWFyZXIgDQpjaGFubmVscyBhbmQgMSBTUzcgc2lnbmFsIGNoYW5uZWwuIFRob3NlIGJlYXJl ciBjaGFubmVscyB3b3VsZCBiZSBjb25uZWN0ZWQgd2lodCANClBoeXNpY2FsIFRlcm1pbmF0aW9u LCBhbmQgc2lnbmFsIGNoYW5uZWwgc2hvdWxkIGJlIGJ5cGFzc2VkIHRvIGFub3RoZXIgRTEgDQps aW5rLjwvRk9OVD48L1A+DQo8UD48Rk9OVCBmYWNlPUNvdXJpZXI+VGhlIGNvbmZpZ3VyYXRpb24g aXMgYXMgYmVsb3cuPC9GT05UPjwvUD48Rk9OVCANCmZhY2U9Q291cmllcj4NCjxQPjxCUj4mbmJz cDsmbmJzcDsgDQorLS0tLS0tLS0tLS0rJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7RTEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQorLS0tLS0tLS0tLS0t LS0tLS0tKyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0UxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KKy0tLS0tLS0tLS0tKzxCUj4mbmJzcDsmbmJzcDsgfCBTUzcmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgDQp8LS0tLS0tLS0tLS0tLS0tfCBQb3J0MSZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBQb3J0MiB8LS0tLS0tLS0tLS18IA0KU1M3Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8QlI+Jm5ic3A7Jm5ic3A7IHwgT1BDIEgnMTAwIHwmbmJz cDsgDQpiZWFyZXIgMzBjaCZuYnNwOyANCnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtNRyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiZuYnNw OyB8Jm5ic3A7IFNTNyAxY2gmbmJzcDsgfCBPUEMgSCcyMDAgfDxCUj4mbmJzcDsmbmJzcDsgfCBE UEMgSCcyMDAgfCZuYnNwOyANClNTNyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxY2gmbmJzcDsg DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 IERQQyBIJzEwMCANCnw8QlI+Jm5ic3A7Jm5ic3A7IA0KKy0tLS0tLS0tLS0tKyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyANCistLS0tLS0tLS0tLS0tLS0tLS0rJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KKy0tLS0tLS0tLS0t KzxCUj48QlI+TUcmbmJzcDtzaG91bGQgbm90IGRvIGFueXRoaW5nIGFib3V0IHNpZ25hbCBjaGFu bmVsIGV4Y2VwdCANCmJ5cGFzc2luZy48L1A+DQo8UD5JJm5ic3A7dGhpbmsgaXQmbmJzcDttYXkg aGFpcnBpbiwgc28gSSBtYWRlIG1lc3NhZ2UgYXMgYmVsb3csIGJ1dCBkaWRuJ3QgDQp3b3JrLjwv UD4NCjxQPk1FR0FDTy8xIFskTUdDX0lQXToyOTQ0IFRyYW5zYWN0aW9uID0gJFRSQU5TQUNUSU9O IHsgQ29udGV4dCA9ICQgeyBBZGQgPSANCmJydGt0MGMxNiB7IE1lZGlhIHsgU3RyZWFtID0gMSB7 IExvY2FsQ29udHJvbCB7IE1vZGUgPSBTZW5kUmVjZWl2ZSwgdGRtYy9nYWluPTIsIA0KdGRtYy9l Yz1vbn0gfSB9IH0sIEFkZCA9IGJydGt0MWMxNiB7IE1lZGlhIHsgU3RyZWFtID0gMSB7IExvY2Fs Q29udHJvbCB7IE1vZGUgPSANClNlbmRSZWNlaXZlLCB0ZG1jL2dhaW49MiwgdGRtYy9lYz1vbn0g fSB9IH0gfSB9PC9QPg0KPFA+QW55b25lIGtub3cgaG93IHRvIG1ha2UgaGFpcnBpbiBvciBieXBh c3MmbmJzcDtvZiBURE0gU1M3IHNpZ25hbGxpbmcgDQpjaGFubmVsPzwvUD4NCjxQPkknbGwgYXBw cmVjaWF0ZSBpZiB5b3UgcmVwbHkuPC9QPg0KPFA+UmVnYXJkcyw8L1A+DQo8UD5Eb25nd29vIEJ5 dW4uPC9GT05UPjwvUD4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8L0JPRFk+DQo8L0hUTUw+DQo8YnI+ PGJyPjxicj4NCjxicj4NCjxsaW5rIHJlbD0ic3R5bGVzaGVldCIgaHJlZj0iaHR0cDovL21haWwu bmF0ZS5jb20vd2ViL2Zvb3Rlci9jc3MvaW50cm9jb20uY3NzIiB0eXBlPSJ0ZXh0L2NzcyI+DQo8 cD4mbmJzcDs8L3A+DQo8dGFibGUgd2lkdGg9IjYxNSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0i MCIgY2VsbHBhZGRpbmc9IjAiIGhlaWdodD0iMTAwIj4NCiAgPHRyPiANCiAgICA8dGQgYmFja2dy b3VuZD0iaHR0cDovL21haWwubmF0ZS5jb20vd2ViL2Zvb3Rlci9pbWcvYmcwMS5naWYiIGhlaWdo dD0iMSI+PC90ZD4NCiAgPC90cj4NCiAgPHRyPiANCiAgICA8dGQ+PGltZyBzcmM9Imh0dHA6Ly9t YWlsLm5hdGUuY29tL3dlYi9mb290ZXIvaW1nL25hdGVfbG9nby5naWYiIHdpZHRoPSIxOTUiIGhl aWdodD0iMzAiPjwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkIGJnY29sb3I9IkVGRUZF RiI+IA0KICAgICAgPHRhYmxlIHdpZHRoPSIxMDAlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIx IiBjZWxscGFkZGluZz0iMCI+DQogICAgICAgIDx0cj4gDQogICAgICAgICAgPHRkIGJnY29sb3I9 IkY3RjdGNyI+IA0KICAgICAgICAgICAgPHRhYmxlIHdpZHRoPSIxMDAlIiBib3JkZXI9IjAiIGNl bGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+DQogICAgICAgICAgICAgIDx0cj4gDQogICAg ICAgICAgICAgICAgPHRkIHJvd3NwYW49IjMiPiZuYnNwOzwvdGQ+DQogICAgICAgICAgICAgICAg PHRkIGhlaWdodD0iNSI+PC90ZD4NCiAgICAgICAgICAgICAgICA8dGQgaGVpZ2h0PSI1Ij48L3Rk Pg0KICAgICAgICAgICAgICAgIDx0ZCBoZWlnaHQ9IjUiPjwvdGQ+DQogICAgICAgICAgICAgICAg PHRkIGhlaWdodD0iNSI+PC90ZD4NCiAgICAgICAgICAgICAgICA8dGQgaGVpZ2h0PSI1Ij48L3Rk Pg0KICAgICAgICAgICAgICAgIDx0ZCBoZWlnaHQ9IjUiPjwvdGQ+DQogICAgICAgICAgICAgICAg PHRkIGhlaWdodD0iNSI+PC90ZD4NCiAgICAgICAgICAgICAgICA8dGQgaGVpZ2h0PSI1Ij48L3Rk Pg0KICAgICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAgICA8dHI+IA0KICAgICAgICAgICAg ICAgIDx0ZD48aW1nIHNyYz0iaHR0cDovL21haWwubmF0ZS5jb20vd2ViL2Zvb3Rlci9pbWcvMDQw NTExX2dlbGZvcy5naWYiIHdpZHRoPSI4MCIgaGVpZ2h0PSI0NSI+PC90ZD4NCiAgICAgICAgICAg ICAgICA8dGQ+Jm5ic3A7PC90ZD4NCiAgICAgICAgICAgICAgICA8dGQ+IA0KICAgICAgICAgICAg ICAgICAgPHRhYmxlIHdpZHRoPSI5NyUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxw YWRkaW5nPSIwIj4NCiAgICAgICAgICAgICAgICAgICAgPHRyPiANCiAgICAgICAgICAgICAgICAg ICAgICA8dGQ+PGEgaHJlZj0iaHR0cDovL2FkLm5hdGUuY29tL1JlYWxNZWRpYS9hZHMvY2xpY2tf bHguYWRzL21haWwubmF0ZS5jb20vcmljaC8xMDAvTWlkZGxlMy9uc19nZWxmb3NfQ2Zvb3QyXzQw MTA5L24wMS5naWYvMTAwIiB0YXJnZXQ9Il9uZXciPiANCiAgICAgICAgICAgICAgICAgICAgICAg IDxmb250IGNvbG9yPSI4NDAyN0UiIGNsYXNzPSJpbnRlcmNvbSI+v+y+xsfRIMCjuvnBtyC1x7Hi PC9mb250PjwvYT48L3RkPg0KICAgICAgICAgICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAg ICAgICAgICA8dHI+IA0KICAgICAgICAgICAgICAgICAgICAgIDx0ZCBoZWlnaHQ9IjUiPjwvdGQ+ DQogICAgICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgICAgICAgIDx0cj4gDQog ICAgICAgICAgICAgICAgICAgICAgPHRkIGNsYXNzPSJpbnRlcmNvbSI+vcXA2yC/tcitIL3Du+fI uLHuwfZ+fjwvdGQ+DQogICAgICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgICAg ICA8L3RhYmxlPg0KICAgICAgICAgICAgICAgIDwvdGQ+DQogICAgICAgICAgICAgICAgPHRkIGJh Y2tncm91bmQ9Imh0dHA6Ly9tYWlsLm5hdGUuY29tL3dlYi9mb290ZXIvaW1nL2JnMDIuZ2lmIiB3 aWR0aD0iMSI+PC90ZD4NCiAgICAgICAgICAgICAgICA8dGQ+Jm5ic3A7PC90ZD4NCiAgICAgICAg ICAgICAgICA8dGQ+PGltZyBzcmM9Imh0dHA6Ly9tYWlsLm5hdGUuY29tL3dlYi9mb290ZXIvaW1n L3BubV9ldmVudC5naWYiIHdpZHRoPSI4MCIgaGVpZ2h0PSI0NSIgYm9yZGVyPSIwIj48L3RkPg0K ICAgICAgICAgICAgICAgIDx0ZCBjbGFzcz0ibWFpbCI+Jm5ic3A7PC90ZD4NCiAgICAgICAgICAg ICAgICA8dGQgY2xhc3M9Im1haWwiPiANCiAgICAgICAgICAgICAgICAgIDx0YWJsZSB3aWR0aD0i OTclIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+DQogICAgICAg ICAgICAgICAgICAgIDx0cj4gDQogICAgICAgICAgICAgICAgICAgICAgPHRkPg0KICAgICAgICAg ICAgICAgICAgICAgIAkgIDxhIGhyZWY9Imh0dHA6Ly9tYWlsLm5hdGUuY29tL21pbl9tYWlsL2V2 ZW50LzIwMDQwNTEzL2V2ZW50X21haW4ucGhwIiB0YXJnZXQ9Il9uZXciPg0KCSAgICAgICAgICAg ICAgICAgICAgICA8Zm9udCBjb2xvcj0iODQwMjdFIiBjbGFzcz0iaW50ZXJjb20iPrq4s7ux4ri4 IMfPuOkgMTAwJSC058O3ILmrt+Eguqe80riuPzwvZm9udD48L2E+DQoJCQkJCSAgPC90ZD4NCiAg ICAgICAgICAgICAgICAgICAgPC90cj4NCiAgICAgICAgICAgICAgICAgICAgPHRyPiANCiAgICAg ICAgICAgICAgICAgICAgICA8dGQgaGVpZ2h0PSI1Ij48L3RkPg0KICAgICAgICAgICAgICAgICAg ICA8L3RyPg0KICAgICAgICAgICAgICAgICAgICA8dHI+IA0KICAgICAgICAgICAgICAgICAgICAg IDx0ZCBjbGFzcz0iaW50ZXJjb20iPklNLTcyMDC/oSC+xsDMuK659iBNUDMsIL/cvcS788ewsce1 tSC98LTZITwvdGQ+DQogICAgICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgICAg ICA8L3RhYmxlPg0KICAgICAgICAgICAgICAgIDwvdGQ+DQogICAgICAgICAgICAgIDwvdHI+DQog ICAgICAgICAgICAgIDx0cj4gDQogICAgICAgICAgICAgICAgPHRkIGhlaWdodD0iNSI+PC90ZD4N CiAgICAgICAgICAgICAgICA8dGQgaGVpZ2h0PSI1Ij48L3RkPg0KICAgICAgICAgICAgICAgIDx0 ZCBoZWlnaHQ9IjUiPjwvdGQ+DQogICAgICAgICAgICAgICAgPHRkIGhlaWdodD0iNSI+PC90ZD4N CiAgICAgICAgICAgICAgICA8dGQgaGVpZ2h0PSI1Ij48L3RkPg0KICAgICAgICAgICAgICAgIDx0 ZCBoZWlnaHQ9IjUiPjwvdGQ+DQogICAgICAgICAgICAgICAgPHRkIGhlaWdodD0iNSI+PC90ZD4N CiAgICAgICAgICAgICAgICA8dGQgaGVpZ2h0PSI1Ij48L3RkPg0KICAgICAgICAgICAgICA8L3Ry Pg0KICAgICAgICAgICAgPC90YWJsZT4NCiAgICAgICAgICA8L3RkPg0KICAgICAgICA8L3RyPg0K ICAgICAgPC90YWJsZT4NCiAgICA8L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZD4mbmJz cDs8L3RkPg0KICA8L3RyPg0KPC90YWJsZT4NCjxJTUcgU1JDPWh0dHA6Ly9hZC5uYXRlLmNvbS9S ZWFsTWVkaWEvYWRzL2Fkc3RyZWFtX254LmFkcy9tYWlsLm5hdGUuY29tL3JpY2hATWlkZGxlMz4N Cg== --===============1611878835== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1611878835==-- From megaco-bounces@ietf.org Fri May 28 01:44:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20712 for ; Fri, 28 May 2004 01:44:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTZx5-0008Cf-MJ; Fri, 28 May 2004 01:30:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTZdY-00059p-5P for megaco@megatron.ietf.org; Fri, 28 May 2004 01:10:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19439 for ; Fri, 28 May 2004 01:10:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTZdV-0006Je-QP for megaco@ietf.org; Fri, 28 May 2004 01:10:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTZca-0005yl-00 for megaco@ietf.org; Fri, 28 May 2004 01:09:34 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BTZbr-0005f6-00 for megaco@ietf.org; Fri, 28 May 2004 01:08:48 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i4S58mWR004121 for ; Fri, 28 May 2004 07:08:48 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 28 May 2004 07:08:48 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LFS6A3QC; Fri, 28 May 2004 07:08:48 +0200 Received: from ericsson.com (EG2E500202DSEGL [146.11.22.8]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LGSRW3SH; Fri, 28 May 2004 15:08:40 +1000 Message-ID: <40B6C956.1080603@ericsson.com> Date: Fri, 28 May 2004 15:08:38 +1000 X-Sybari-Trust: 07bcf017 08d63d2e d9e634ad 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Raphael Tryster Subject: Re: [Megaco] Descriptor processing on Termination OOS References: <9A64A99CD3F2BD4582BE4FB63FC1F3810166FC@MAILSERVER> In-Reply-To: <9A64A99CD3F2BD4582BE4FB63FC1F3810166FC@MAILSERVER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 May 2004 05:08:48.0584 (UTC) FILETIME=[DBFA8C80:01C44471] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: Tom-PT Taylor , anilj@cisco.com, megaco@ietf.org, bvswamy@hss.hns.com, "'Kevin Boyle'" X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello Raphael, Please see my comments below. Regards, Christian Raphael Tryster wrote: > Two questions related to the discussion below: > > Firstly, the quote below from H.248.1 6.2.4 seems to contradict section > 7.1.11, which states: > > "Production of a Signal on a Termination is stopped by application of a > new SignalsDescriptor, or detection of an Event on the Termination". > > What about returning to the null context? According to 6.2.4, the > signal should stop, whereas according to 7.1.11, it should not stop. > Unless the resetting of descriptors to default values when returning to > the null context is considered to be a case of application of a new > SignalsDescriptor? But then what do we do about on/off type signals, > e.g. visual message waiting indicator? Surely they are meant to survive > subtraction from a context? [CHG] I would assume that by returning a termination to the NULL context via a subtract results in a signal being stopped. 6.2.4 says, "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. The default contents of the two exceptions are described in 7.1.5 and 7.1.7." 7.1.11 talks about replacement SignalDescriptor which is effectively what happens when you return to the NULL context. The current descriptors are replaced by the provisioned descriptors. Also 7.1.11 is not mentioned as an exception. > > My second question concerns the requirement that the MG maintain > terminations in contexts until the MGC explicitly subtracts them. > Consider a distributed MG, in which the part that talks to the MGC does > not completely control the part that allocates resources such as IP > address and UDP port for local descriptors. Suppose some administrative > action or fault causes these resources to become physically unavailable > to the termination with which they were associated. The MG informs the > MGC (or fails to do so if the MGC didn't request the event), but for > some reason the MGC does not issue a Subtract. The front end of the MG > has no problem complying with Megaco rules: it will accept any commands > it can on that context, and send a proper rejection if the cleanup that > has taken place in the back end makes it impossible to comply with a > request. However, if the MGC audits the local descriptor, the MG front > end will send an IP address and UDP port that the back end may already > be reusing for another call. The MGC can then presumably do bad things > with this outdated information. Which of the following are legitimate > solutions to this problem? > > 1. The MGC is at fault for ignoring indications from the MG that > something went wrong. > > 2. The MG is at fault for being schizophrenic. It must prevent reuse > of all resources associated with the context until it receives > Subtract. > > 3. The MG can sidestep the problem. It is only required to keep the > termination in the context, but it can clear the local > descriptor. (And what if the MGC doesn't audit but relies on its > memory?) > > 4. There is no problem. The MGC cannot do anything bad with the > information. [CHG] I would suggest that if the MG has experienced a problem with the termination that it send a generic cause event indicating failure. It the MGC doesn't request this event then the designers must understand the consequences. Also if there is a more terminal failure a servicechange could be sent. > > Raphael Tryster > > > -----Original Message----- > From: Kevin Boyle [SMTP:kboyle@nortelnetworks.com] > Sent: Wednesday, 17 December 2003 18:19 > To: Christian Groves; bvswamy@hss.hns.com; anilj@cisco.com > Cc: megaco_maillist@hss.hns.com; Tom-PT Taylor; megaco@ietf.org > Subject: RE: [Megaco] Descriptor processing on Termination OOS > > Right. I just wanted to ensure that everyone understands that the > reset of the descriptors is a result of the SUBTRACT, and not a > result of the SERVICECHANGE. > > Subtle, but important, difference. > > Kevin > > -----Original Message----- > From: Christian Groves [ mailto:Christian.Groves@ericsson.com] > Sent: Tuesday, December 16, 2003 6:05 PM > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; bvswamy@hss.hns.com; > anilj@cisco.com > Cc: megaco_maillist@hss.hns.com; Taylor, Tom-PT [CAR:5N00:EXCH]; > megaco@ietf.org > Subject: Re: [Megaco] Descriptor processing on Termination OOS > > Hello, > > OOS Service by its nature must be reported by a ServiceChange, > this can be through Forced which states: At a minimum, the > Termination shall be subtracted from the Context. Graceful is > similar that the MGC is expected to "clean up" the termination > ultimately by subtracting the termination. > > So for ephemeral terminations there's no discussion as they'll > disappear the MGC won't be able to do anything to them. For > physical terminations the following rule applies: > > H.248.1 6.2.4 Termination properties and descriptors .... > 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. > > ... > > This text is very clear when a termination goes back to the NULL > context which for TDM terminations is the result of going "out of > service" the descriptors ARE changed. > > I can remember that this behaviour caused quite a bit of > discussion at the time (I think Tom drafted the text) and it was > felt that this was the best behaviour because it left terminations > in a known state both for the MG and MGC. > > Regards, Christian > > Kevin Boyle wrote: > > > Comments inline [KJBII] > > > > Kevin > > > > -----Original Message----- > > From: bvswamy@hss.hns.com [ mailto:bvswamy@hss.hns.com] > > Sent: Tuesday, December 16, 2003 9:03 AM > > To: anilj@cisco.com > > Cc: megaco_maillist@hss.hns.com; Taylor, Tom-PT [CAR:5N00:EXCH]; > > megaco@ietf.org > > Subject: RE: [Megaco] Descriptor processing on Termination OOS > > > > > > > > > > > > Hi > > Please find my comments embedded.[BVS]. > > Regards > > Venkat > > > > > > > > > > > > "Anil Jangam \(anilj\)" @ietf.org on 12/16/2003 > > 01:33:27 PM > > > > Please respond to > > > > Sent by: megaco-admin@ietf.org > > > > > > To: megaco_maillist@HSS, "'Tom Taylor'" > > > cc: > > > > Subject: RE: [Megaco] Descriptor processing on Termination OOS > > > > > > > > > > > -----Original Message----- > > > From: megaco-admin@ietf.org [ mailto:megaco-admin@ietf.org] On > > Behalf > Of megaco_maillist@hss.hns.com > Sent: Tuesday, December > > 16, 2003 11:53 AM > To: Tom Taylor > Cc: megaco@ietf.org > > Subject: > > Re: [Megaco] Descriptor processing on Termination OOS > > > > > > > > > > Hi > > > In my opinion keeping the descriptors alive and > enabled for a > > > termination which is in Out of Service state does not seems > to be a > > > valid behaviour of MG. For example if the card containing the > > > termination is jacked out of the chasis then definately at the > > > hardware level all the events and signals get disabled. There > would > > > be a major disconnect wrt descriptors state if MGC does not audit > > the > termination since if MGC were to audit the termination then > > > MG would be returning empty descriptors in this particular > > > case. Now in > > > this condition if the card is jacked-in and termination is > made > > > in-service then the exact state of original descriptors no more > holds > > > good and mgc needs to apply the descriptors again. > > > > > > Hence for a termination which is in Out-of-Service > state MGC can > > > fairly assume that all descriptors are no more valid and > whenever > > the > termination comes up will reapply the descriptors > afresh. This > > > assumption holds true whether or not termination is involved > in a > > > call. > > > > First thing, there is no provision for the MG to change the > state of > > the descriptor by its own. If we see the commands that can > change the > > descriptor state, these are commands which MGC initiate. > > > > [BVS] I agree with you from the protocol perspective. But, if you > > analyse the actual scenario, service change (to out-of-service) > for a > > termination would mean disabling operations such as signals/ > events/ > > streams. Further, this would mean that MG does take some action > on its > > own when it generates a Service Change (or MGC sends a service > change) > > on the termination. > > > > If MG returns the descriptors in Audit response it would mean > > incorrect representation of facts to MGC. > > > > [KJBII] The MG may not take action on its own, whether we are > talking > > about a hardware failure or some other occurrence. The text is > > explicit: the MG may not reset those descriptors. If the MGC > wanted > > to audit, it may very well be to collect diagnostic data. If > the MG > > wipes them out, then that data is lost. > > > > In the SVC with SVCMethod = forced, its mentioned that MGC is > going to > > clean up the context, in which case it is to subtract the > termination > > from the cotext. At this point MGC can reset the descriptor > state to > > the default if necessary. Same logic can be applied when the > SVCMethod > > is graceful. > > > > [BVS] Cleaning up the context using subtract is OK for > terminations in > > a valid context. But, what about the terminations which are > already in > > the null context. > > > > [KJBII] What about them? Modifies are allowed on OOS > terminations. > > The MGC could very well send a modify to empty the descriptors. > > > > > > In the call flows as well, when the termination is coming back into > > the service, normally a Modify is sent to MG initializing the term. > > > > > > [BVS] Based upon our experience in the interop events, this > MODIFY is > > applicable to only certain call scenarios (e.g. POTS call) and > not for > > other scenarios (like Trunkling). > > > > Moreover, it is not used for clean up operations (like empty Signal > > descriptor, empty media descriptor etc.), but for the call > setup (like > > event descriptor with OffHook). > > > > [KJBII] MGCs that do not reset the state of the descriptors upon > > return to service will be subject to its own problems. It > seems to me > > that the MGC would want to make sure the descriptors are in a > > particular state by explicitly making them that way. Further, > I know > > of several implementations that send empty descriptors in Modify > > commands. Any assumption that they are not used for normal call > > processing operations is deficient. > > > > > > So given this, IMO we don't have to make any assumption about the > > descriptor state once its taken OOS. > > > > > > > > Regards > > > Venkat > > > > > > > > > > > > > > > > > > Tom Taylor @ietf.org on 12/01/2003 > > > 11:52:03 PM > > > > Sent by: megaco-admin@ietf.org > > > > > > > > > To: Sampath Komanduri > > > cc: megaco@ietf.org > > > > > > Subject: Re: [Megaco] Descriptor processing on > Termination OOS > > > > > > > > > The descriptors (aside from TerminationState) remain unchanged > > until > either the MGC changes them or the MG undergoes a cold > restart. > > > > > > Sampath Komanduri wrote: > > > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri May 28 09:24:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29393 for ; Fri, 28 May 2004 09:24:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTh4l-0008SF-A6; Fri, 28 May 2004 09:07:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTgMx-00051u-Bv for megaco@megatron.ietf.org; Fri, 28 May 2004 08:21:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24427 for ; Fri, 28 May 2004 08:21:49 -0400 (EDT) From: Albrecht.Schwarz@alcatel.de Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTgMw-0004Fy-NO for megaco@ietf.org; Fri, 28 May 2004 08:21:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTgM2-0003sS-00 for megaco@ietf.org; Fri, 28 May 2004 08:20:55 -0400 Received: from mailrelay1.alcatel.de ([194.113.59.75] helo=mailrelay2.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 1BTgLD-0003Dz-00 for megaco@ietf.org; Fri, 28 May 2004 08:20:03 -0400 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.12.10/8.12.10) with ESMTP id i4SCJU4B004953; Fri, 28 May 2004 12:19:30 GMT Subject: Re: [Megaco] Bypass(hairpin?) TDM SS7 signal channel To: byundw@nate.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 28 May 2004 14:19:28 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/28/2004 14:19:30 MIME-Version: 1.0 Content-type: text/plain; charset=iso-2022-kr X-Alcanet-virus-scanned: i4SCJU4B004953 at mailrelay2.alcatel.de X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL, NO_REAL_NAME autolearn=no version=2.60 Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org $)C Hi Dongwoo, "TDM hairpinning" of a SS7 MTP2 connection (on DS0 level), - according your configuration -, requires the bearer service capability "1x64-kbit/s Unrestricted Digital Information (UDI)". Note: in your scenario are Signal Processing functions (Gain Control, EC) activated, which doesn't make sense, or is even not allowed ("because it's generating bit failures, thus , a bit error rate of zero may not guaranteed by your MG"). Technically, you may bypass your DSP device MG-internally for such specific TDM-to-TDM connections. Or, if you are looping in a DSP, then the DSP channel settings must guarantee "UDI capability" (this specific DSP operation mode is also called as "transparent channel", "clear mode", or "clear channel data"). The H.248 Context has 2 TDM Termination. The TDM Bearer Capability is defined in Annex C.9: "TMR = 64 kbit/s unrestricted". Exactly this topic was discussed under following subject some weeks ago: "Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning;Re: [Megaco] Hairpin case A/u Law conversion" See for instance: http://www1.ietf.org/mail-archive/web/megaco/current/msg05095.html http://www1.ietf.org/mail-archive/working-groups/megaco/current/msg05068.html http://www1.ietf.org/mail-archive/working-groups/megaco/current/msg05069.html => in case of binary encoding mode, see H.248.1 Annex C => in case of text encoding mode, see the outcome of recent ITU-T meeting: http://www1.ietf.org/mail-archive/web/megaco/current/msg05140.html Hope this helps, regards, Albrecht ALCATEL ":/5??l" cc: Sent by: Subject: [Megaco] Bypass(hairpin?) TDM SS7 signal channel megaco-bounces@i etf.org 28.05.2004 03:04 Hi everyone, I'm trying to use the Trunk Gateway with E1 port. I want to use E1 trunk which has 30 PCM bearer channels and 1 SS7 signal channel. Those bearer channels would be connected wiht Physical Termination, and signal channel should be bypassed to another E1 link. The configuration is as below. +-----------+ E1 +------------------+ E1 +-----------+ | SS7 |---------------| Port1 Port2 |-----------| SS7 | | OPC H'100 | bearer 30ch | MG | SS7 1ch | OPC H'200 | | DPC H'200 | SS7 1ch | | | DPC H'100 | +-----------+ +------------------+ +-----------+ MG should not do anything about signal channel except bypassing. I think it may hairpin, so I made message as below, but didn't work. MEGACO/1 [$MGC_IP]:2944 Transaction = $TRANSACTION { Context = $ { Add = brtkt0c16 { Media { Stream = 1 { LocalControl { Mode = SendReceive, tdmc/gain=2, tdmc/ec=on} } } }, Add = brtkt1c16 { Media { Stream = 1 { LocalControl { Mode = SendReceive, tdmc/gain=2, tdmc/ec=on} } } } } } Anyone know how to make hairpin or bypass of TDM SS7 signalling channel? I'll appreciate if you reply. Regards, Dongwoo Byun. 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