From mailman-admin@ietf.org Wed Jan 1 10:19:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06958 for ; Wed, 1 Jan 2003 10:19:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h01FQpJ30663 for ; Wed, 1 Jan 2003 10:26:51 -0500 Date: Wed, 01 Jan 2003 10:26:51 -0500 Message-ID: <20030101152651.32165.7701.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 Wed Jan 1 19:45:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15544 for ; Wed, 1 Jan 2003 19:45:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h020q4J02277; Wed, 1 Jan 2003 19:52:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h020n5J02197 for ; Wed, 1 Jan 2003 19:49:05 -0500 Received: from moon.mercurykr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15514 for ; Wed, 1 Jan 2003 19:40:31 -0500 (EST) Received: from LocalHost ([165.133.17.229]) by moon.mercurykr.com (8.10.0.Beta10/8.10.0.Beta10) with SMTP id h020m9v36512; Thu, 2 Jan 2003 09:48:10 +0900 Message-ID: <000f01c2b1f8$3a61f820$e51185a5@LocalHost> From: "Noh Jeong Min" To: =?ks_c_5601-1987?B?wNPA58iv?= Cc: References: <20021226170002.2547.10054.Mailman@www1.ietf.org> <001e01c2ae0d$2e119fb0$2003a8c0@jhlim2> Subject: Re: [Megaco] What profile should I comply with when I implement Trunk Gate Way? Date: Thu, 2 Jan 2003 09:45:20 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h020n6J02198 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi everybody. I wish your happy new year. I think you should refer the Multiservice Switching Forum(MSF, http://www.msforum.org )'s implement agreements and profiles. The 3 profiles for Media Gateway(TG,AG) published by the MSF. And, the technical information documents of Global MSF Interperability(GMI) are also useful to define your Trunk Gateway. Noh Jeong Min. IMT System Development Group. MERCURY Corporation. Ltd. Tel : +82 031 310 5714, +82 031 310 5718 Email : hmask@mercurykr.com ----- Original Message ----- From: "임재환" To: Sent: Saturday, December 28, 2002 10:05 AM Subject: [Megaco] What profile should I comply with when I implement Trunk Gate Way? > Hello everyone! > > What profile should I comply with when I implement Trunk Gate Way(TGW)? > > My trunk Gate Way has some E1 trunk interfaces on switch circuit Network > side and fast or giga ethernet interface on packet network side. Also, it > can have ATM interface on packet network side alternatively. > > Thank you for reading my question. > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 1 19:45:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15561 for ; Wed, 1 Jan 2003 19:45:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h020rpw02318 for megaco-archive@odin.ietf.org; Wed, 1 Jan 2003 19:53:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h020rpJ02315 for ; Wed, 1 Jan 2003 19:53:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15558 for ; Wed, 1 Jan 2003 19:45:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h020q4J02277; Wed, 1 Jan 2003 19:52:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h020n5J02197 for ; Wed, 1 Jan 2003 19:49:05 -0500 Received: from moon.mercurykr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15514 for ; Wed, 1 Jan 2003 19:40:31 -0500 (EST) Received: from LocalHost ([165.133.17.229]) by moon.mercurykr.com (8.10.0.Beta10/8.10.0.Beta10) with SMTP id h020m9v36512; Thu, 2 Jan 2003 09:48:10 +0900 Message-ID: <000f01c2b1f8$3a61f820$e51185a5@LocalHost> From: "Noh Jeong Min" To: =?ks_c_5601-1987?B?wNPA58iv?= Cc: References: <20021226170002.2547.10054.Mailman@www1.ietf.org> <001e01c2ae0d$2e119fb0$2003a8c0@jhlim2> Subject: Re: [Megaco] What profile should I comply with when I implement Trunk Gate Way? Date: Thu, 2 Jan 2003 09:45:20 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h020n6J02198 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi everybody. I wish your happy new year. I think you should refer the Multiservice Switching Forum(MSF, http://www.msforum.org )'s implement agreements and profiles. The 3 profiles for Media Gateway(TG,AG) published by the MSF. And, the technical information documents of Global MSF Interperability(GMI) are also useful to define your Trunk Gateway. Noh Jeong Min. IMT System Development Group. MERCURY Corporation. Ltd. Tel : +82 031 310 5714, +82 031 310 5718 Email : hmask@mercurykr.com ----- Original Message ----- From: "임재환" To: Sent: Saturday, December 28, 2002 10:05 AM Subject: [Megaco] What profile should I comply with when I implement Trunk Gate Way? > Hello everyone! > > What profile should I comply with when I implement Trunk Gate Way(TGW)? > > My trunk Gate Way has some E1 trunk interfaces on switch circuit Network > side and fast or giga ethernet interface on packet network side. Also, it > can have ATM interface on packet network side alternatively. > > Thank you for reading my question. > > > _______________________________________________ > 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 Jan 3 09:11:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09590 for ; Fri, 3 Jan 2003 09:11:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03EKBJ27880; Fri, 3 Jan 2003 09:20:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03AovJ15841 for ; Fri, 3 Jan 2003 05:50:57 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06492 for ; Fri, 3 Jan 2003 05:41:43 -0500 (EST) Received: from z14593 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H8400GBQWFXUB@mta0.huawei.com> for megaco@ietf.org; Fri, 03 Jan 2003 18:43:11 +0800 (CST) Date: Fri, 03 Jan 2003 18:46:18 +0800 From: zhaobo To: vnair@hss.hns.com Cc: megaco@ietf.org Message-id: <000501c2b315$59826c80$ea486e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Megaco] Doubt in usage of R2 package Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi Vikram: I have two questions: 1. What will happed if the incoming MG compells for information not availiable in outgoing MG, for examples,the signal applies to outgoing MG is "R2/address{si=2992,di=2989}",but the incoming MG compells for language/dicrimination digit? 2. When sls signal applies, some condition shall be sent in Group A backward signal, some shall be sent in Group B signals. Is the responsibility of MG to decide what kind of signal will be sent? Thanks very much, and wish you a happy new year! Zhao Bo 01/03 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Jan 3 09:12:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09612 for ; Fri, 3 Jan 2003 09:12:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03ELLe27944 for megaco-archive@odin.ietf.org; Fri, 3 Jan 2003 09:21:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03ELLJ27941 for ; Fri, 3 Jan 2003 09:21:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09604 for ; Fri, 3 Jan 2003 09:12:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03EKBJ27880; Fri, 3 Jan 2003 09:20:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03AovJ15841 for ; Fri, 3 Jan 2003 05:50:57 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06492 for ; Fri, 3 Jan 2003 05:41:43 -0500 (EST) Received: from z14593 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H8400GBQWFXUB@mta0.huawei.com> for megaco@ietf.org; Fri, 03 Jan 2003 18:43:11 +0800 (CST) Date: Fri, 03 Jan 2003 18:46:18 +0800 From: zhaobo To: vnair@hss.hns.com Cc: megaco@ietf.org Message-id: <000501c2b315$59826c80$ea486e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Megaco] Doubt in usage of R2 package Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Vikram: I have two questions: 1. What will happed if the incoming MG compells for information not availiable in outgoing MG, for examples,the signal applies to outgoing MG is "R2/address{si=2992,di=2989}",but the incoming MG compells for language/dicrimination digit? 2. When sls signal applies, some condition shall be sent in Group A backward signal, some shall be sent in Group B signals. Is the responsibility of MG to decide what kind of signal will be sent? Thanks very much, and wish you a happy new year! Zhao Bo 01/03 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Sun Jan 5 21:50:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14024 for ; Sun, 5 Jan 2003 21:50:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h062wiJ03975; Sun, 5 Jan 2003 21:58:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h062uwJ03906 for ; Sun, 5 Jan 2003 21:56:58 -0500 Received: from asbmx.sbell.com.cn (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13980 for ; Sun, 5 Jan 2003 21:46:21 -0500 (EST) Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.2+Sun/8.12.3) with SMTP id h062gjbv027570 for ; Mon, 6 Jan 2003 10:42:46 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Mon Jan 06 10:50:06 2003 +0800 Received: from BELLNET-MAIL3.sbell.com.cn ([172.24.208.23]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.5329); Mon, 6 Jan 2003 10:50:05 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B52E.51202760" Subject: RE: [Megaco] two transactions in the same message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 6 Jan 2003 10:50:05 +0800 Message-ID: <01F6E1FBEE83B543868895AE9CAB189F0BAF06@bellnet-mail3.sbell.com.cn> Thread-Topic: [Megaco] two transactions in the same message Thread-Index: AcKwmSxJo2Uj1xFKQ8uiGL+pFDIOeAElGz5Q From: "VND Wang JuLin" To: "Anil Jangam" , "Fernando Vallejo Lazaro" , "Megaco" X-OriginalArrivalTime: 06 Jan 2003 02:50:05.0843 (UTC) FILETIME=[51640E30:01C2B52E] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2B52E.51202760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HI, I think it is not strictly confined to what type of transaction in the = message.Please see the following example: =20 =20 Mar 14 2002 06:28:50.536|TRANSPORT.0|RECEIVE|MEGACO/1 [172.24.202.224] Transaction=3D2{ Context=3D-{ Notify=3Dagw_julw/1{ObservedEvents=3D1{19700101T00000855:al/of}} } } Transaction=3D3{ Context=3D-{ Notify=3Dagw_julw/2{ObservedEvents=3D1{19700101T00000855:al/of}} } } Transaction=3D4{ Context=3D-{ Notify=3Dagw_julw/3{ObservedEvents=3D1{19700101T00000855:al/of}} } } Transaction=3D5{ Context=3D-{ Notify=3Dagw_julw/4{ObservedEvents=3D1{19700101T00000855:al/of}} } } =20 Mar 14 2002 06:28:50.686|Timer Mgr|SEND|MEGACO/1 [172.24.201.125] Reply=3D2{ Context=3D-{ Notify=3Dagw_julw/1 } } Transaction=3D9{ Context=3D-{ Modify=3Dagw_julw/1{ Events=3D1{al/on, dd/ce{DigitMap=3Ddialplan0}}, Signals{cg/dt}, DigitMap=3Ddialplan0{xxx} } } } Reply=3D3{ Context=3D-{ Notify=3Dagw_julw/2 } } Transaction=3D10{ Context=3D-{ Modify=3Dagw_julw/2{ Events=3D1{al/on, dd/ce{DigitMap=3Ddialplan0}}, Signals{cg/dt}, DigitMap=3Ddialplan0{xxx} } } } Reply=3D4{ Context=3D-{ Notify=3Dagw_julw/3 } } Transaction=3D11{ Context=3D-{ Modify=3Dagw_julw/3{ Events=3D1{al/on, dd/ce{DigitMap=3Ddialplan0}}, Signals{cg/dt}, DigitMap=3Ddialplan0{xxx} } } } Reply=3D5{ Context=3D-{ Notify=3Dagw_julw/4 } } Transaction=3D12{ Context=3D-{ Modify=3Dagw_julw/4{ Events=3D1{al/on, dd/ce{DigitMap=3Ddialplan0}}, Signals{cg/dt}, DigitMap=3Ddialplan0{xxx} } } } TransactionResponseAck{1-8} best regards=20 :-)Jerry Wang=20 tel:(8621)58541240 ext 9531=20 mailto:Julin.Wang@alcatel-sbell.com.cn=20 Alcatel Shanghai Bell Co.LTD=20 -----Original Message----- From: Anil Jangam [mailto:anilj@mahindrabt.com] Sent: Tuesday, December 31, 2002 2:45 PM To: Fernando Vallejo Lazaro; Megaco Subject: [Megaco] two transactions in the same message Hi, =20 Is it possible to have differing type of the transactions in the same = message or Does the message always contains the same type of transactions and = another type of transaction (e.g. TransactionReply) goes into separate = message. =20 with regds, /anil. =20 ----- Original Message -----=20 From: Anil Jangam=20 To: Fernando Vallejo Lazaro = ; Megaco =20 Cc: Tom-PT Taylor ; Madhu Babu = Brahmanapally=20 Sent: Tuesday, November 12, 2002 2:33 PM Subject: Re: [Megaco] two transactions in the same message Hi, =20 As per the protocol encoding rule, there is NO COMMA separator between = two transactions in a message. Hence the your option-b may result into a = syntax error (400). The option-a is correct one. You have to read each = transaction with the transaction token and corresponding start and end = brace. =20 Note: What was the reason for not using any separator for multiple = transactions in a message unlike in other cases? =20 /anil. =20 ----- Original Message -----=20 From: Fernando Vallejo = Lazaro=20 To: Megaco =20 Sent: Tuesday, November 12, 2002 1:48 PM Subject: [Megaco] two transactions in the same message Hi all,=20 If I wish to send two transactions within the=20 same message which of the next two options is the right one?=20 =20 Option a)=20 MEGACO/1 [123.123.123.4]:55555=20 Transaction =3D 9999 {=20 Context =3D - {=20 Modify =3D A4444 {... }=20 }=20 }=20 Transaction =3D 10000 {=20 Context =3D - {=20 Modify =3D A4445 {... }=20 }=20 }=20 =20 Option b)=20 MEGACO/1 [123.123.123.4]:55555=20 Transaction =3D 9999 {=20 Context =3D - {=20 Modify =3D A4444 {... }=20 }=20 }, <----- Note the comma = here=20 Transaction =3D 10000 {=20 Context =3D - {=20 Modify =3D A4445 {... }=20 }=20 }=20 =20 Regards=20 Fernando=20 =20 --=20 Fernando Vallejo Lazaro Phone: +34 91 330 8279 SW Wireline ASD-Madrid ALCATEL =20 ********************************************************* Disclaimer This message (including any attachments) contains=20 confidential information intended for a specific=20 individual and purpose, and is protected by law.=20 If you are not the intended recipient, you should=20 delete this message and are hereby notified that=20 any disclosure, copying, or distribution of this message, or the taking of any action based on it,=20 is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ********************************************************* Disclaimer This message (including any attachments) contains=20 confidential information intended for a specific=20 individual and purpose, and is protected by law.=20 If you are not the intended recipient, you should=20 delete this message and are hereby notified that=20 any disclosure, copying, or distribution of this message, or the taking of any action based on it,=20 is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ------_=_NextPart_001_01C2B52E.51202760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 HI,
I think it is not strictly confined to = what type=20 of transaction in the message.Please = see the=20 following example:
 
 
Mar 14 2002=20 06:28:50.536|TRANSPORT.0|RECEIVE|MEGACO/1=20 [172.24.202.224]
Transaction=3D2{
 Context=3D-{
  = ;Notify=3Dagw_julw/1{ObservedEvents=3D1{19700101T00000855:al/of}}
&nbs= p;}
}
Transaction=3D3{
 Context=3D-{
  Notify=3D= agw_julw/2{ObservedEvents=3D1{19700101T00000855:al/of}}
 }
}Transaction=3D4{
 Context=3D-{
  Notify=3Dagw_julw= /3{ObservedEvents=3D1{19700101T00000855:al/of}}
 }
}
Transa= ction=3D5{
 Context=3D-{
  Notify=3Dagw_julw/4{Obser= vedEvents=3D1{19700101T00000855:al/of}}
 }
}
 
Mar 14 2002 = 06:28:50.686|Timer=20 Mgr|SEND|MEGACO/1=20 [172.24.201.125]
Reply=3D2{
 Context=3D-{
  Notif= y=3Dagw_julw/1
 }
}
Transaction=3D9{
 Context=3D-{<= BR>  Modify=3Dagw_julw/1{
   Events=3D1{al/on= ,=20 dd/ce{DigitMap=3Ddialplan0}},
   Signals{cg/dt},
&nb= sp;  DigitMap=3Ddialplan0{xxx}
  }
 }
}=
Reply=3D3{
 Context=3D-{
  Notify=3Dagw_julw/2 }
}
Transaction=3D10{
 Context=3D-{
  = Modify=3Dagw_julw/2{
   Events=3D1{al/on,=20 dd/ce{DigitMap=3Ddialplan0}},
   Signals{cg/dt},
&nb= sp;  DigitMap=3Ddialplan0{xxx}
  }
 }
}=
Reply=3D4{
 Context=3D-{
  Notify=3Dagw_julw/3 }
}
Transaction=3D11{
 Context=3D-{
  = Modify=3Dagw_julw/3{
   Events=3D1{al/on,=20 dd/ce{DigitMap=3Ddialplan0}},
   Signals{cg/dt},
&nb= sp;  DigitMap=3Ddialplan0{xxx}
  }
 }
}=
Reply=3D5{
 Context=3D-{
  Notify=3Dagw_julw/4 }
}
Transaction=3D12{
 Context=3D-{
  = Modify=3Dagw_julw/4{
   Events=3D1{al/on,=20 dd/ce{DigitMap=3Ddialplan0}},
   Signals{cg/dt},
&nb= sp;  DigitMap=3Ddialplan0{xxx}
  }
 }
}=
TransactionResponseAck{1-8}

 best  = regards=20
JJerry Wang
tel:(8621)58541240 ext=20 9531
mailto:Julin.Wang@alcatel= -sbell.com.cn=20
Alcatel = Shanghai Bell=20 Co.LTD

-----Original Message-----
From: Anil Jangam=20 [mailto:anilj@mahindrabt.com]
Sent: Tuesday, December 31, = 2002 2:45=20 PM
To: Fernando Vallejo Lazaro; Megaco
Subject: = [Megaco]=20 two transactions in the same message

Hi,
 
Is it possible to have differing type = of the=20 transactions in the same message
or
Does the message always contains the = same type of=20 transactions and another type of transaction (e.g. TransactionReply) = goes into=20 separate message.
 
with regds,
/anil.
 
----- Original Message -----
From:=20 Anil=20 Jangam
To: Fernando Vallejo = Lazaro=20 ; Megaco
Cc: Tom-PT Taylor ; Madhu Babu=20 Brahmanapally
Sent: Tuesday, November 12, = 2002 2:33=20 PM
Subject: Re: [Megaco] two = transactions=20 in the same message

Hi,
 
As per the protocol encoding rule, = there is NO=20 COMMA separator between two transactions in a message. Hence the = your=20 option-b may result into a syntax error (400). The option-a is = correct one.=20 You have to read each transaction with the transaction token and=20 corresponding start and end brace.
 
Note: What was the reason for not = using any=20 separator for multiple transactions in a message unlike in other=20 cases?
 
/anil.
 
----- Original Message ----- =
From:=20 Fernando = Vallejo=20 Lazaro
To: Megaco
Sent: Tuesday, November 12, = 2002 1:48=20 PM
Subject: [Megaco] two = transactions in=20 the same message

Hi all,=20

If I wish to send two transactions within the
same message = which of=20 the next two options is the right one?
 =20

Option a)=20

MEGACO/1 [123.123.123.4]:55555
   Transaction =3D = 9999 {=20
       Context =3D - {=20
           = Modify =3D=20 A4444 {... }
        } =
  }=20
   Transaction =3D 10000 {=20
       Context =3D - {=20
           = Modify =3D=20 A4445 {... }
        } =
  }=20
 =20

Option b)=20

MEGACO/1 [123.123.123.4]:55555
   Transaction =3D = 9999 {=20
       Context =3D - {=20
           = Modify =3D=20 A4444 {... }
        } =
 =20 },         &n= bsp;           &nb= sp;           &nbs= p;         =20 <----- Note the comma here
   Transaction = =3D 10000=20 {
       Context =3D - {=20
           = Modify =3D=20 A4445 {... }
        } =
  }=20
 =20

Regards
Fernando
  

-- 
Fernando Vallejo Lazaro
Phone:  +34 91 330 8279
SW  Wireline ASD-Madrid
       ALCATEL
 =20 =
********************************************************= *
Disclaimer

This=20 message (including any attachments) contains
confidential = information=20 intended for a specific
individual and purpose, and is protected = by law.=20
If you are not the intended recipient, you should
delete = this=20 message and are hereby notified that
any disclosure, copying, or = distribution of this
message, or the taking of any action based = on it,=20
is strictly=20 = prohibited.

******************************************************= ***
Visit=20 us at=20 = http://www.mahindrabt.com


***********************= **********************************
Disclaimer

This=20 message (including any attachments) contains
confidential = information=20 intended for a specific
individual and purpose, and is protected = by law.=20
If you are not the intended recipient, you should
delete this = message=20 and are hereby notified that
any disclosure, copying, or = distribution of=20 this
message, or the taking of any action based on it,
is = strictly=20 = prohibited.

******************************************************= ***
Visit=20 us at http://www.mahindrabt.com

------_=_NextPart_001_01C2B52E.51202760-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Sun Jan 5 21:50:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14076 for ; Sun, 5 Jan 2003 21:50:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0630ok04078 for megaco-archive@odin.ietf.org; Sun, 5 Jan 2003 22:00:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0630oJ04075 for ; Sun, 5 Jan 2003 22:00:50 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14027 for ; Sun, 5 Jan 2003 21:50:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h062wiJ03975; Sun, 5 Jan 2003 21:58:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h062uwJ03906 for ; Sun, 5 Jan 2003 21:56:58 -0500 Received: from asbmx.sbell.com.cn (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13980 for ; Sun, 5 Jan 2003 21:46:21 -0500 (EST) Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.2+Sun/8.12.3) with SMTP id h062gjbv027570 for ; Mon, 6 Jan 2003 10:42:46 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Mon Jan 06 10:50:06 2003 +0800 Received: from BELLNET-MAIL3.sbell.com.cn ([172.24.208.23]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.5329); Mon, 6 Jan 2003 10:50:05 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B52E.51202760" Subject: RE: [Megaco] two transactions in the same message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 6 Jan 2003 10:50:05 +0800 Message-ID: <01F6E1FBEE83B543868895AE9CAB189F0BAF06@bellnet-mail3.sbell.com.cn> Thread-Topic: [Megaco] two transactions in the same message Thread-Index: AcKwmSxJo2Uj1xFKQ8uiGL+pFDIOeAElGz5Q From: "VND Wang JuLin" To: "Anil Jangam" , "Fernando Vallejo Lazaro" , "Megaco" X-OriginalArrivalTime: 06 Jan 2003 02:50:05.0843 (UTC) FILETIME=[51640E30:01C2B52E] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2B52E.51202760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HI, I think it is not strictly confined to what type of transaction in the = message.Please see the following example: =20 =20 Mar 14 2002 06:28:50.536|TRANSPORT.0|RECEIVE|MEGACO/1 [172.24.202.224] Transaction=3D2{ Context=3D-{ Notify=3Dagw_julw/1{ObservedEvents=3D1{19700101T00000855:al/of}} } } Transaction=3D3{ Context=3D-{ Notify=3Dagw_julw/2{ObservedEvents=3D1{19700101T00000855:al/of}} } } Transaction=3D4{ Context=3D-{ Notify=3Dagw_julw/3{ObservedEvents=3D1{19700101T00000855:al/of}} } } Transaction=3D5{ Context=3D-{ Notify=3Dagw_julw/4{ObservedEvents=3D1{19700101T00000855:al/of}} } } =20 Mar 14 2002 06:28:50.686|Timer Mgr|SEND|MEGACO/1 [172.24.201.125] Reply=3D2{ Context=3D-{ Notify=3Dagw_julw/1 } } Transaction=3D9{ Context=3D-{ Modify=3Dagw_julw/1{ Events=3D1{al/on, dd/ce{DigitMap=3Ddialplan0}}, Signals{cg/dt}, DigitMap=3Ddialplan0{xxx} } } } Reply=3D3{ Context=3D-{ Notify=3Dagw_julw/2 } } Transaction=3D10{ Context=3D-{ Modify=3Dagw_julw/2{ Events=3D1{al/on, dd/ce{DigitMap=3Ddialplan0}}, Signals{cg/dt}, DigitMap=3Ddialplan0{xxx} } } } Reply=3D4{ Context=3D-{ Notify=3Dagw_julw/3 } } Transaction=3D11{ Context=3D-{ Modify=3Dagw_julw/3{ Events=3D1{al/on, dd/ce{DigitMap=3Ddialplan0}}, Signals{cg/dt}, DigitMap=3Ddialplan0{xxx} } } } Reply=3D5{ Context=3D-{ Notify=3Dagw_julw/4 } } Transaction=3D12{ Context=3D-{ Modify=3Dagw_julw/4{ Events=3D1{al/on, dd/ce{DigitMap=3Ddialplan0}}, Signals{cg/dt}, DigitMap=3Ddialplan0{xxx} } } } TransactionResponseAck{1-8} best regards=20 :-)Jerry Wang=20 tel:(8621)58541240 ext 9531=20 mailto:Julin.Wang@alcatel-sbell.com.cn=20 Alcatel Shanghai Bell Co.LTD=20 -----Original Message----- From: Anil Jangam [mailto:anilj@mahindrabt.com] Sent: Tuesday, December 31, 2002 2:45 PM To: Fernando Vallejo Lazaro; Megaco Subject: [Megaco] two transactions in the same message Hi, =20 Is it possible to have differing type of the transactions in the same = message or Does the message always contains the same type of transactions and = another type of transaction (e.g. TransactionReply) goes into separate = message. =20 with regds, /anil. =20 ----- Original Message -----=20 From: Anil Jangam=20 To: Fernando Vallejo Lazaro = ; Megaco =20 Cc: Tom-PT Taylor ; Madhu Babu = Brahmanapally=20 Sent: Tuesday, November 12, 2002 2:33 PM Subject: Re: [Megaco] two transactions in the same message Hi, =20 As per the protocol encoding rule, there is NO COMMA separator between = two transactions in a message. Hence the your option-b may result into a = syntax error (400). The option-a is correct one. You have to read each = transaction with the transaction token and corresponding start and end = brace. =20 Note: What was the reason for not using any separator for multiple = transactions in a message unlike in other cases? =20 /anil. =20 ----- Original Message -----=20 From: Fernando Vallejo = Lazaro=20 To: Megaco =20 Sent: Tuesday, November 12, 2002 1:48 PM Subject: [Megaco] two transactions in the same message Hi all,=20 If I wish to send two transactions within the=20 same message which of the next two options is the right one?=20 =20 Option a)=20 MEGACO/1 [123.123.123.4]:55555=20 Transaction =3D 9999 {=20 Context =3D - {=20 Modify =3D A4444 {... }=20 }=20 }=20 Transaction =3D 10000 {=20 Context =3D - {=20 Modify =3D A4445 {... }=20 }=20 }=20 =20 Option b)=20 MEGACO/1 [123.123.123.4]:55555=20 Transaction =3D 9999 {=20 Context =3D - {=20 Modify =3D A4444 {... }=20 }=20 }, <----- Note the comma = here=20 Transaction =3D 10000 {=20 Context =3D - {=20 Modify =3D A4445 {... }=20 }=20 }=20 =20 Regards=20 Fernando=20 =20 --=20 Fernando Vallejo Lazaro Phone: +34 91 330 8279 SW Wireline ASD-Madrid ALCATEL =20 ********************************************************* Disclaimer This message (including any attachments) contains=20 confidential information intended for a specific=20 individual and purpose, and is protected by law.=20 If you are not the intended recipient, you should=20 delete this message and are hereby notified that=20 any disclosure, copying, or distribution of this message, or the taking of any action based on it,=20 is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ********************************************************* Disclaimer This message (including any attachments) contains=20 confidential information intended for a specific=20 individual and purpose, and is protected by law.=20 If you are not the intended recipient, you should=20 delete this message and are hereby notified that=20 any disclosure, copying, or distribution of this message, or the taking of any action based on it,=20 is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ------_=_NextPart_001_01C2B52E.51202760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 HI,
I think it is not strictly confined to = what type=20 of transaction in the message.Please = see the=20 following example:
 
 
Mar 14 2002=20 06:28:50.536|TRANSPORT.0|RECEIVE|MEGACO/1=20 [172.24.202.224]
Transaction=3D2{
 Context=3D-{
  = ;Notify=3Dagw_julw/1{ObservedEvents=3D1{19700101T00000855:al/of}}
&nbs= p;}
}
Transaction=3D3{
 Context=3D-{
  Notify=3D= agw_julw/2{ObservedEvents=3D1{19700101T00000855:al/of}}
 }
}Transaction=3D4{
 Context=3D-{
  Notify=3Dagw_julw= /3{ObservedEvents=3D1{19700101T00000855:al/of}}
 }
}
Transa= ction=3D5{
 Context=3D-{
  Notify=3Dagw_julw/4{Obser= vedEvents=3D1{19700101T00000855:al/of}}
 }
}
 
Mar 14 2002 = 06:28:50.686|Timer=20 Mgr|SEND|MEGACO/1=20 [172.24.201.125]
Reply=3D2{
 Context=3D-{
  Notif= y=3Dagw_julw/1
 }
}
Transaction=3D9{
 Context=3D-{<= BR>  Modify=3Dagw_julw/1{
   Events=3D1{al/on= ,=20 dd/ce{DigitMap=3Ddialplan0}},
   Signals{cg/dt},
&nb= sp;  DigitMap=3Ddialplan0{xxx}
  }
 }
}=
Reply=3D3{
 Context=3D-{
  Notify=3Dagw_julw/2 }
}
Transaction=3D10{
 Context=3D-{
  = Modify=3Dagw_julw/2{
   Events=3D1{al/on,=20 dd/ce{DigitMap=3Ddialplan0}},
   Signals{cg/dt},
&nb= sp;  DigitMap=3Ddialplan0{xxx}
  }
 }
}=
Reply=3D4{
 Context=3D-{
  Notify=3Dagw_julw/3 }
}
Transaction=3D11{
 Context=3D-{
  = Modify=3Dagw_julw/3{
   Events=3D1{al/on,=20 dd/ce{DigitMap=3Ddialplan0}},
   Signals{cg/dt},
&nb= sp;  DigitMap=3Ddialplan0{xxx}
  }
 }
}=
Reply=3D5{
 Context=3D-{
  Notify=3Dagw_julw/4 }
}
Transaction=3D12{
 Context=3D-{
  = Modify=3Dagw_julw/4{
   Events=3D1{al/on,=20 dd/ce{DigitMap=3Ddialplan0}},
   Signals{cg/dt},
&nb= sp;  DigitMap=3Ddialplan0{xxx}
  }
 }
}=
TransactionResponseAck{1-8}

 best  = regards=20
JJerry Wang
tel:(8621)58541240 ext=20 9531
mailto:Julin.Wang@alcatel= -sbell.com.cn=20
Alcatel = Shanghai Bell=20 Co.LTD

-----Original Message-----
From: Anil Jangam=20 [mailto:anilj@mahindrabt.com]
Sent: Tuesday, December 31, = 2002 2:45=20 PM
To: Fernando Vallejo Lazaro; Megaco
Subject: = [Megaco]=20 two transactions in the same message

Hi,
 
Is it possible to have differing type = of the=20 transactions in the same message
or
Does the message always contains the = same type of=20 transactions and another type of transaction (e.g. TransactionReply) = goes into=20 separate message.
 
with regds,
/anil.
 
----- Original Message -----
From:=20 Anil=20 Jangam
To: Fernando Vallejo = Lazaro=20 ; Megaco
Cc: Tom-PT Taylor ; Madhu Babu=20 Brahmanapally
Sent: Tuesday, November 12, = 2002 2:33=20 PM
Subject: Re: [Megaco] two = transactions=20 in the same message

Hi,
 
As per the protocol encoding rule, = there is NO=20 COMMA separator between two transactions in a message. Hence the = your=20 option-b may result into a syntax error (400). The option-a is = correct one.=20 You have to read each transaction with the transaction token and=20 corresponding start and end brace.
 
Note: What was the reason for not = using any=20 separator for multiple transactions in a message unlike in other=20 cases?
 
/anil.
 
----- Original Message ----- =
From:=20 Fernando = Vallejo=20 Lazaro
To: Megaco
Sent: Tuesday, November 12, = 2002 1:48=20 PM
Subject: [Megaco] two = transactions in=20 the same message

Hi all,=20

If I wish to send two transactions within the
same message = which of=20 the next two options is the right one?
 =20

Option a)=20

MEGACO/1 [123.123.123.4]:55555
   Transaction =3D = 9999 {=20
       Context =3D - {=20
           = Modify =3D=20 A4444 {... }
        } =
  }=20
   Transaction =3D 10000 {=20
       Context =3D - {=20
           = Modify =3D=20 A4445 {... }
        } =
  }=20
 =20

Option b)=20

MEGACO/1 [123.123.123.4]:55555
   Transaction =3D = 9999 {=20
       Context =3D - {=20
           = Modify =3D=20 A4444 {... }
        } =
 =20 },         &n= bsp;           &nb= sp;           &nbs= p;         =20 <----- Note the comma here
   Transaction = =3D 10000=20 {
       Context =3D - {=20
           = Modify =3D=20 A4445 {... }
        } =
  }=20
 =20

Regards
Fernando
  

-- 
Fernando Vallejo Lazaro
Phone:  +34 91 330 8279
SW  Wireline ASD-Madrid
       ALCATEL
 =20 =
********************************************************= *
Disclaimer

This=20 message (including any attachments) contains
confidential = information=20 intended for a specific
individual and purpose, and is protected = by law.=20
If you are not the intended recipient, you should
delete = this=20 message and are hereby notified that
any disclosure, copying, or = distribution of this
message, or the taking of any action based = on it,=20
is strictly=20 = prohibited.

******************************************************= ***
Visit=20 us at=20 = http://www.mahindrabt.com


***********************= **********************************
Disclaimer

This=20 message (including any attachments) contains
confidential = information=20 intended for a specific
individual and purpose, and is protected = by law.=20
If you are not the intended recipient, you should
delete this = message=20 and are hereby notified that
any disclosure, copying, or = distribution of=20 this
message, or the taking of any action based on it,
is = strictly=20 = prohibited.

******************************************************= ***
Visit=20 us at http://www.mahindrabt.com

------_=_NextPart_001_01C2B52E.51202760-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jan 6 01:21:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17219 for ; Mon, 6 Jan 2003 01:21:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h066VJJ15054; Mon, 6 Jan 2003 01:31:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h066T9J14953 for ; Mon, 6 Jan 2003 01:29:09 -0500 Received: from cms3.etri.re.kr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17145 for ; Mon, 6 Jan 2003 01:18:31 -0500 (EST) From: hektor@etri.re.kr Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Jan 2003 15:18:28 +0900 Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A5DA4BC@cms3.etri.re.kr> To: megaco@ietf.org Date: Mon, 6 Jan 2003 15:18:22 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B54B.6A3D4490" Subject: [Megaco] misprinted in ABNF? Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2B54B.6A3D4490 Content-Type: text/plain; charset="euc-kr" Hi, All. One of SafeChars In ABNF specification may be misprinted? the character between "^" and "~" is strange. I think the character could be "_" and "`" respectively. Am I rigiht? ------_=_NextPart_001_01C2B54B.6A3D4490 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable misprinted in ABNF?

Hi, All.

One of SafeChars In ABNF specification may be = misprinted?
the character between "^" and = "~" is strange. I think the character could be "_" = and "`" respectively.
Am I rigiht?

------_=_NextPart_001_01C2B54B.6A3D4490-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jan 6 01:22:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17241 for ; Mon, 6 Jan 2003 01:22:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h066WOW15183 for megaco-archive@odin.ietf.org; Mon, 6 Jan 2003 01:32:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h066WOJ15179 for ; Mon, 6 Jan 2003 01:32:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17229 for ; Mon, 6 Jan 2003 01:21:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h066VJJ15054; Mon, 6 Jan 2003 01:31:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h066T9J14953 for ; Mon, 6 Jan 2003 01:29:09 -0500 Received: from cms3.etri.re.kr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17145 for ; Mon, 6 Jan 2003 01:18:31 -0500 (EST) From: hektor@etri.re.kr Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Jan 2003 15:18:28 +0900 Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A5DA4BC@cms3.etri.re.kr> To: megaco@ietf.org Date: Mon, 6 Jan 2003 15:18:22 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B54B.6A3D4490" Subject: [Megaco] misprinted in ABNF? Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2B54B.6A3D4490 Content-Type: text/plain; charset="euc-kr" Hi, All. One of SafeChars In ABNF specification may be misprinted? the character between "^" and "~" is strange. I think the character could be "_" and "`" respectively. Am I rigiht? ------_=_NextPart_001_01C2B54B.6A3D4490 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable misprinted in ABNF?

Hi, All.

One of SafeChars In ABNF specification may be = misprinted?
the character between "^" and = "~" is strange. I think the character could be "_" = and "`" respectively.
Am I rigiht?

------_=_NextPart_001_01C2B54B.6A3D4490-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jan 6 01:23:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17278 for ; Mon, 6 Jan 2003 01:23:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h066X5J15249; Mon, 6 Jan 2003 01:33:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h066WJJ15174 for ; Mon, 6 Jan 2003 01:32:19 -0500 Received: from cms3.etri.re.kr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17213 for ; Mon, 6 Jan 2003 01:21:41 -0500 (EST) From: hektor@etri.re.kr Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Jan 2003 15:21:38 +0900 Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A5DA4BD@cms3.etri.re.kr> To: megaco@ietf.org Date: Mon, 6 Jan 2003 15:21:33 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B54B.DC027B40" Subject: [Megaco] [re]misprinted in ABNF? Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2B54B.DC027B40 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: quoted-printable Hi, All. Oops, I'm sorry. my eyes could be just fooled. there's no problem. ^.^; =BF=F8=BA=BB =B3=BB=BF=EB: =BA=B8=B3=BD=BB=E7=B6=F7: =C0=D3=C1=BE=C3=B6 =B9=DE=B4=C2=BB=E7=B6=F7: 'megaco@ietf.org' =C1=A6=B8=F1: misprinted in ABNF? =B9=DE=C0=BA=B3=AF=C2=A5: 2003/01/06 =BF=F9 15:18 Hi, All. =20 One of SafeChars In ABNF specification may be misprinted? the character between "^" and "~" is strange. I think the character = could be "_" and "`" respectively. Am I rigiht? ------_=_NextPart_001_01C2B54B.DC027B40 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable [re]misprinted in ABNF?

Hi, All.
Oops, I'm sorry. my eyes could be just fooled. = there's no problem. ^.^;

=BF=F8=BA=BB =B3=BB=BF=EB:

=BA=B8=B3=BD=BB=E7=B6=F7: =C0=D3=C1=BE=C3=B6
=B9=DE=B4=C2=BB=E7=B6=F7: 'megaco@ietf.org'
=C1=A6=B8=F1: misprinted in ABNF?
=B9=DE=C0=BA=B3=AF=C2=A5: 2003/01/06 =BF=F9 = 15:18


Hi, All.
 
One of SafeChars In ABNF specification may be = misprinted?
the character between "^" and = "~" is strange. I think the character could be "_" = and "`" respectively.
Am I rigiht?

------_=_NextPart_001_01C2B54B.DC027B40-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jan 6 01:23:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17300 for ; Mon, 6 Jan 2003 01:23:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h066Y2x15288 for megaco-archive@odin.ietf.org; Mon, 6 Jan 2003 01:34:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h066Y1J15285 for ; Mon, 6 Jan 2003 01:34:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17292 for ; Mon, 6 Jan 2003 01:23:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h066X5J15249; Mon, 6 Jan 2003 01:33:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h066WJJ15174 for ; Mon, 6 Jan 2003 01:32:19 -0500 Received: from cms3.etri.re.kr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17213 for ; Mon, 6 Jan 2003 01:21:41 -0500 (EST) From: hektor@etri.re.kr Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Jan 2003 15:21:38 +0900 Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A5DA4BD@cms3.etri.re.kr> To: megaco@ietf.org Date: Mon, 6 Jan 2003 15:21:33 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B54B.DC027B40" Subject: [Megaco] [re]misprinted in ABNF? Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2B54B.DC027B40 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: quoted-printable Hi, All. Oops, I'm sorry. my eyes could be just fooled. there's no problem. ^.^; =BF=F8=BA=BB =B3=BB=BF=EB: =BA=B8=B3=BD=BB=E7=B6=F7: =C0=D3=C1=BE=C3=B6 =B9=DE=B4=C2=BB=E7=B6=F7: 'megaco@ietf.org' =C1=A6=B8=F1: misprinted in ABNF? =B9=DE=C0=BA=B3=AF=C2=A5: 2003/01/06 =BF=F9 15:18 Hi, All. =20 One of SafeChars In ABNF specification may be misprinted? the character between "^" and "~" is strange. I think the character = could be "_" and "`" respectively. Am I rigiht? ------_=_NextPart_001_01C2B54B.DC027B40 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable [re]misprinted in ABNF?

Hi, All.
Oops, I'm sorry. my eyes could be just fooled. = there's no problem. ^.^;

=BF=F8=BA=BB =B3=BB=BF=EB:

=BA=B8=B3=BD=BB=E7=B6=F7: =C0=D3=C1=BE=C3=B6
=B9=DE=B4=C2=BB=E7=B6=F7: 'megaco@ietf.org'
=C1=A6=B8=F1: misprinted in ABNF?
=B9=DE=C0=BA=B3=AF=C2=A5: 2003/01/06 =BF=F9 = 15:18


Hi, All.
 
One of SafeChars In ABNF specification may be = misprinted?
the character between "^" and = "~" is strange. I think the character could be "_" = and "`" respectively.
Am I rigiht?

------_=_NextPart_001_01C2B54B.DC027B40-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jan 6 05:35:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00849 for ; Mon, 6 Jan 2003 05:35:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06AiOJ07986; Mon, 6 Jan 2003 05:44:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06AgtJ07939 for ; Mon, 6 Jan 2003 05:42:55 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00830 for ; Mon, 6 Jan 2003 05:32:12 -0500 (EST) From: gsachin@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h06AYKs05494 for ; Mon, 6 Jan 2003 16:04:20 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h06AYFN05473 for ; Mon, 6 Jan 2003 16:04:15 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h06AaJm24418 for ; Mon, 6 Jan 2003 16:06:19 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CA6.00398517 ; Mon, 6 Jan 2003 15:58:16 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org cc: gsachin@hss.hns.com Message-ID: <65256CA6.00398486.00@sandesh.hss.hns.com> Date: Mon, 6 Jan 2003 16:01:00 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Stream 0 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, Stream ID 0 is speficied in the protocol as "not related to a particular media stream" for event detection and signal application. According to the Grammar, 0 is a valid Stream ID. Can somebody tell in what scenarios MGC can specify streamID as 0 and what what will it refer to (by StreamID 0) Regards Sachin Gupta DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jan 6 05:35:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00885 for ; Mon, 6 Jan 2003 05:35:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06AjkQ08049 for megaco-archive@odin.ietf.org; Mon, 6 Jan 2003 05:45:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06AjkJ08046 for ; Mon, 6 Jan 2003 05:45:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00855 for ; Mon, 6 Jan 2003 05:35:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06AiOJ07986; Mon, 6 Jan 2003 05:44:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06AgtJ07939 for ; Mon, 6 Jan 2003 05:42:55 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00830 for ; Mon, 6 Jan 2003 05:32:12 -0500 (EST) From: gsachin@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h06AYKs05494 for ; Mon, 6 Jan 2003 16:04:20 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h06AYFN05473 for ; Mon, 6 Jan 2003 16:04:15 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h06AaJm24418 for ; Mon, 6 Jan 2003 16:06:19 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CA6.00398517 ; Mon, 6 Jan 2003 15:58:16 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org cc: gsachin@hss.hns.com Message-ID: <65256CA6.00398486.00@sandesh.hss.hns.com> Date: Mon, 6 Jan 2003 16:01:00 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Stream 0 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, Stream ID 0 is speficied in the protocol as "not related to a particular media stream" for event detection and signal application. According to the Grammar, 0 is a valid Stream ID. Can somebody tell in what scenarios MGC can specify streamID as 0 and what what will it refer to (by StreamID 0) Regards Sachin Gupta DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jan 6 08:48:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03474 for ; Mon, 6 Jan 2003 08:48:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06Dw9J18096; Mon, 6 Jan 2003 08:58:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06ACUJ06437 for ; Mon, 6 Jan 2003 05:12:30 -0500 Received: from parsmtp1.rd.francetelecom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00423 for ; Mon, 6 Jan 2003 05:01:44 -0500 (EST) Received: from parmhs2.rd.francetelecom.fr ([10.193.117.61]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 6 Jan 2003 11:04:58 +0100 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="ks_c_5601-1987" Subject: RE: [Megaco] What profile should I comply with when I implement Trunk Gate Way? Date: Mon, 6 Jan 2003 11:04:58 +0100 Message-ID: <448914041F29D7499FA5F0B8ED1C708783B3CF@parmhs2.rd.francetelecom.fr> Thread-Topic: [Megaco] What profile should I comply with when I implement Trunk Gate Way? Thread-Index: AcKx+siJPl8sj+x/SE+hKmzSPjH2FgDbzVgA From: "CHATRAS Bruno FTRD/DAC/ISS" To: "Noh Jeong Min" , "???" Cc: X-OriginalArrivalTime: 06 Jan 2003 10:04:58.0931 (UTC) FILETIME=[12155030:01C2B56B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h06ACYJ06445 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit One difficulty with using the MSF profiles is that some of the packages they are referring to are no longer available. Such packages are only defined in expired Internet-Drafts (e.g.; draft-rosen-megaco-atm-package-00.txt for ATM trunking, draft-madhubabu-megaco-qospackage-00.txt for IP trunking...). > -----Message d'origine----- > De?: Noh Jeong Min [mailto:hmask@mercurykr.com] > Envoye?: jeudi 2 janvier 2003 01:45 > A?: ??? > Cc?: megaco@ietf.org > Objet?: Re: [Megaco] What profile should I comply with when I > implement Trunk Gate Way? > > > Hi everybody. I wish your happy new year. > > I think you should refer the Multiservice Switching > Forum(MSF, http://www.msforum.org )'s implement agreements > and profiles. > The 3 profiles for Media Gateway(TG,AG) published by the MSF. > > And, the technical information documents of Global MSF > Interperability(GMI) are also useful to define your Trunk Gateway. > > > Noh Jeong Min. > IMT System Development Group. > MERCURY Corporation. Ltd. > Tel : +82 031 310 5714, +82 031 310 5718 > Email : hmask@mercurykr.com > > > ----- Original Message ----- > From: "임재환" > To: > Sent: Saturday, December 28, 2002 10:05 AM > Subject: [Megaco] What profile should I comply with when I > implement Trunk Gate Way? > > > > Hello everyone! > > > > What profile should I comply with when I implement Trunk > Gate Way(TGW)? > > > > My trunk Gate Way has some E1 trunk interfaces on switch > circuit Network > > side and fast or giga ethernet interface on packet network > side. Also, it > > can have ATM interface on packet network side alternatively. > > > > Thank you for reading my question. > > > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jan 6 08:49:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03498 for ; Mon, 6 Jan 2003 08:49:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06DxRY18124 for megaco-archive@odin.ietf.org; Mon, 6 Jan 2003 08:59:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06DxRJ18121 for ; Mon, 6 Jan 2003 08:59:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03477 for ; Mon, 6 Jan 2003 08:48:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06Dw9J18096; Mon, 6 Jan 2003 08:58:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06ACUJ06437 for ; Mon, 6 Jan 2003 05:12:30 -0500 Received: from parsmtp1.rd.francetelecom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00423 for ; Mon, 6 Jan 2003 05:01:44 -0500 (EST) Received: from parmhs2.rd.francetelecom.fr ([10.193.117.61]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 6 Jan 2003 11:04:58 +0100 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="ks_c_5601-1987" Subject: RE: [Megaco] What profile should I comply with when I implement Trunk Gate Way? Date: Mon, 6 Jan 2003 11:04:58 +0100 Message-ID: <448914041F29D7499FA5F0B8ED1C708783B3CF@parmhs2.rd.francetelecom.fr> Thread-Topic: [Megaco] What profile should I comply with when I implement Trunk Gate Way? Thread-Index: AcKx+siJPl8sj+x/SE+hKmzSPjH2FgDbzVgA From: "CHATRAS Bruno FTRD/DAC/ISS" To: "Noh Jeong Min" , "???" Cc: X-OriginalArrivalTime: 06 Jan 2003 10:04:58.0931 (UTC) FILETIME=[12155030:01C2B56B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h06ACYJ06445 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit One difficulty with using the MSF profiles is that some of the packages they are referring to are no longer available. Such packages are only defined in expired Internet-Drafts (e.g.; draft-rosen-megaco-atm-package-00.txt for ATM trunking, draft-madhubabu-megaco-qospackage-00.txt for IP trunking...). > -----Message d'origine----- > De?: Noh Jeong Min [mailto:hmask@mercurykr.com] > Envoye?: jeudi 2 janvier 2003 01:45 > A?: ??? > Cc?: megaco@ietf.org > Objet?: Re: [Megaco] What profile should I comply with when I > implement Trunk Gate Way? > > > Hi everybody. I wish your happy new year. > > I think you should refer the Multiservice Switching > Forum(MSF, http://www.msforum.org )'s implement agreements > and profiles. > The 3 profiles for Media Gateway(TG,AG) published by the MSF. > > And, the technical information documents of Global MSF > Interperability(GMI) are also useful to define your Trunk Gateway. > > > Noh Jeong Min. > IMT System Development Group. > MERCURY Corporation. Ltd. > Tel : +82 031 310 5714, +82 031 310 5718 > Email : hmask@mercurykr.com > > > ----- Original Message ----- > From: "임재환" > To: > Sent: Saturday, December 28, 2002 10:05 AM > Subject: [Megaco] What profile should I comply with when I > implement Trunk Gate Way? > > > > Hello everyone! > > > > What profile should I comply with when I implement Trunk > Gate Way(TGW)? > > > > My trunk Gate Way has some E1 trunk interfaces on switch > circuit Network > > side and fast or giga ethernet interface on packet network > side. Also, it > > can have ATM interface on packet network side alternatively. > > > > Thank you for reading my question. > > > > > > _______________________________________________ > > 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 Jan 6 08:58:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03648 for ; Mon, 6 Jan 2003 08:58:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06E8OJ19101; Mon, 6 Jan 2003 09:08:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06E7iJ19056 for ; Mon, 6 Jan 2003 09:07:44 -0500 Received: from web8206.mail.in.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03628 for ; Mon, 6 Jan 2003 08:56:57 -0500 (EST) Message-ID: <20030106140007.35990.qmail@web8206.mail.in.yahoo.com> Received: from [203.200.122.31] by web8206.mail.in.yahoo.com via HTTP; Mon, 06 Jan 2003 14:00:07 GMT Date: Mon, 6 Jan 2003 14:00:07 +0000 (GMT) From: =?iso-8859-1?q?mukta=20vasudeva?= To: megaco@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1120853507-1041861607=:99983" Content-Transfer-Encoding: 8bit Subject: [Megaco] Signal Descriptor Doubts Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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-1120853507-1041861607=:99983 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hi , Hope everyone had a good Christmas and will have a wonderfull new year ahead. I have some doubts related to Signal Descriptor handling. 1. RFC Section 7.1.11 states that 밣roduction of a Signal on a Termination is stopped by application of a new Signals Descriptor, or detection of an Event on the Termination .� Also, 밃 new Signals Descriptor replaces any existing Signals Descriptor.� Q: The MG maintains the current signal descriptor until a new descriptor is not sent by the MGC. But, after the termination finishes the playout of the signal or an event is detected and the signals are stopped, the signal descriptor remains the current one with MG until new one is received as according to the rules we cannot remove it until new signal descriptor is received. But my doubt is why should we maintain this descriptor since it has already become deactivated(either by finishing playout or event stopped it) and MGC cannot instruct MG to use it further ??. Thanks , regards , Mukta Vasudeva Catch all the cricket action. Download Yahoo! Score tracker --0-1120853507-1041861607=:99983 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

hi ,

Hope everyone had a good Christmas and will have a wonderfull new year ahead.

I have some doubts related to Signal Descriptor handling.

1.

  RFC Section 7.1.11 states that

�Production of a Signal on a Termination is stopped by application of

   a new Signals Descriptor, or detection of an Event on the Termination .�

 

Also,

밃 new Signals Descriptor replaces any existing Signals Descriptor.�

 

Q: The MG maintains the current signal descriptor until a

new descriptor is not sent by the MGC. But, after the termination

finishes the  playout of the signal or an event is detected and the

 signals are stopped, the signal descriptor remains the current one

 with MG until new one is received as according to the rules we cannot remove it until new signal descriptor is received.

 But my doubt is why should we maintain this descriptor since it has already become deactivated(either by finishing playout or event stopped it) and MGC cannot instruct MG to use it further ??.

 

Thanks ,

regards ,

Mukta Vasudeva

 

Catch all the cricket action. Download Yahoo! Score tracker --0-1120853507-1041861607=:99983-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jan 6 08:59:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03666 for ; Mon, 6 Jan 2003 08:59:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06E9hc19177 for megaco-archive@odin.ietf.org; Mon, 6 Jan 2003 09:09:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06E9hJ19174 for ; Mon, 6 Jan 2003 09:09:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03651 for ; Mon, 6 Jan 2003 08:58:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06E8OJ19101; Mon, 6 Jan 2003 09:08:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06E7iJ19056 for ; Mon, 6 Jan 2003 09:07:44 -0500 Received: from web8206.mail.in.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03628 for ; Mon, 6 Jan 2003 08:56:57 -0500 (EST) Message-ID: <20030106140007.35990.qmail@web8206.mail.in.yahoo.com> Received: from [203.200.122.31] by web8206.mail.in.yahoo.com via HTTP; Mon, 06 Jan 2003 14:00:07 GMT Date: Mon, 6 Jan 2003 14:00:07 +0000 (GMT) From: =?iso-8859-1?q?mukta=20vasudeva?= To: megaco@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1120853507-1041861607=:99983" Content-Transfer-Encoding: 8bit Subject: [Megaco] Signal Descriptor Doubts Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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-1120853507-1041861607=:99983 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hi , Hope everyone had a good Christmas and will have a wonderfull new year ahead. I have some doubts related to Signal Descriptor handling. 1. RFC Section 7.1.11 states that 밣roduction of a Signal on a Termination is stopped by application of a new Signals Descriptor, or detection of an Event on the Termination .� Also, 밃 new Signals Descriptor replaces any existing Signals Descriptor.� Q: The MG maintains the current signal descriptor until a new descriptor is not sent by the MGC. But, after the termination finishes the playout of the signal or an event is detected and the signals are stopped, the signal descriptor remains the current one with MG until new one is received as according to the rules we cannot remove it until new signal descriptor is received. But my doubt is why should we maintain this descriptor since it has already become deactivated(either by finishing playout or event stopped it) and MGC cannot instruct MG to use it further ??. Thanks , regards , Mukta Vasudeva Catch all the cricket action. Download Yahoo! Score tracker --0-1120853507-1041861607=:99983 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

hi ,

Hope everyone had a good Christmas and will have a wonderfull new year ahead.

I have some doubts related to Signal Descriptor handling.

1.

  RFC Section 7.1.11 states that

�Production of a Signal on a Termination is stopped by application of

   a new Signals Descriptor, or detection of an Event on the Termination .�

 

Also,

밃 new Signals Descriptor replaces any existing Signals Descriptor.�

 

Q: The MG maintains the current signal descriptor until a

new descriptor is not sent by the MGC. But, after the termination

finishes the  playout of the signal or an event is detected and the

 signals are stopped, the signal descriptor remains the current one

 with MG until new one is received as according to the rules we cannot remove it until new signal descriptor is received.

 But my doubt is why should we maintain this descriptor since it has already become deactivated(either by finishing playout or event stopped it) and MGC cannot instruct MG to use it further ??.

 

Thanks ,

regards ,

Mukta Vasudeva

 

Catch all the cricket action. Download Yahoo! Score tracker --0-1120853507-1041861607=:99983-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jan 6 09:29:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04071 for ; Mon, 6 Jan 2003 09:29:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06EcjJ20661; Mon, 6 Jan 2003 09:38:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06EbIJ20299 for ; Mon, 6 Jan 2003 09:37:18 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04033 for ; Mon, 6 Jan 2003 09:26:31 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h06ETXY24105; Mon, 6 Jan 2003 09:29:33 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Jan 2003 09:29:34 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E0F4@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'mukta vasudeva'" , "'Alan Chou'" , megaco@ietf.org Subject: RE: [Megaco] Signal Descriptor Doubts Date: Mon, 6 Jan 2003 09:29:32 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is more or less the same question Alan Chou raised a week ago. It's not something I ever thought about, but here is the situation as I see it: -- the Signals Descriptor remains unchanged, even if the signal(s) it describes have been terminated -- the MG is required to maintain the knowledge of which signals have been terminated and which have not -- we have no way in general to indicate on audit which signals have completed and which have not. This was probably a mistake in design. -----Original Message----- From: mukta vasudeva [mailto:reachtomukta@yahoo.co.in] Sent: Monday, January 06, 2003 9:00 AM To: megaco@ietf.org Subject: [Megaco] Signal Descriptor Doubts hi , Hope everyone had a good Christmas and will have a wonderfull new year ahead. I have some doubts related to Signal Descriptor handling. 1. RFC Section 7.1.11 states that "Production of a Signal on a Termination is stopped by application of a new Signals Descriptor, or detection of an Event on the Termination ." Also, "A new Signals Descriptor replaces any existing Signals Descriptor." Q: The MG maintains the current signal descriptor until a new descriptor is not sent by the MGC. But, after the termination finishes the playout of the signal or an event is detected and the signals are stopped, the signal descriptor remains the current one with MG until new one is received as according to the rules we cannot remove it until new signal descriptor is received. But my doubt is why should we maintain this descriptor since it has already become deactivated(either by finishing playout or event stopped it) and MGC cannot instruct MG to use it further ??. Thanks , regards , Mukta Vasudeva Catch all the cricket action. Download Yahoo! Score tracker _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jan 6 09:29:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04099 for ; Mon, 6 Jan 2003 09:29:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06Ee8f20781 for megaco-archive@odin.ietf.org; Mon, 6 Jan 2003 09:40:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06Ee7J20778 for ; Mon, 6 Jan 2003 09:40:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04074 for ; Mon, 6 Jan 2003 09:29:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06EcjJ20661; Mon, 6 Jan 2003 09:38:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06EbIJ20299 for ; Mon, 6 Jan 2003 09:37:18 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04033 for ; Mon, 6 Jan 2003 09:26:31 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h06ETXY24105; Mon, 6 Jan 2003 09:29:33 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Jan 2003 09:29:34 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E0F4@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'mukta vasudeva'" , "'Alan Chou'" , megaco@ietf.org Subject: RE: [Megaco] Signal Descriptor Doubts Date: Mon, 6 Jan 2003 09:29:32 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is more or less the same question Alan Chou raised a week ago. It's not something I ever thought about, but here is the situation as I see it: -- the Signals Descriptor remains unchanged, even if the signal(s) it describes have been terminated -- the MG is required to maintain the knowledge of which signals have been terminated and which have not -- we have no way in general to indicate on audit which signals have completed and which have not. This was probably a mistake in design. -----Original Message----- From: mukta vasudeva [mailto:reachtomukta@yahoo.co.in] Sent: Monday, January 06, 2003 9:00 AM To: megaco@ietf.org Subject: [Megaco] Signal Descriptor Doubts hi , Hope everyone had a good Christmas and will have a wonderfull new year ahead. I have some doubts related to Signal Descriptor handling. 1. RFC Section 7.1.11 states that "Production of a Signal on a Termination is stopped by application of a new Signals Descriptor, or detection of an Event on the Termination ." Also, "A new Signals Descriptor replaces any existing Signals Descriptor." Q: The MG maintains the current signal descriptor until a new descriptor is not sent by the MGC. But, after the termination finishes the playout of the signal or an event is detected and the signals are stopped, the signal descriptor remains the current one with MG until new one is received as according to the rules we cannot remove it until new signal descriptor is received. But my doubt is why should we maintain this descriptor since it has already become deactivated(either by finishing playout or event stopped it) and MGC cannot instruct MG to use it further ??. Thanks , regards , Mukta Vasudeva Catch all the cricket action. Download Yahoo! Score tracker _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jan 6 09:37:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04224 for ; Mon, 6 Jan 2003 09:37:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06ElTJ21067; Mon, 6 Jan 2003 09:47:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06EkZJ21032 for ; Mon, 6 Jan 2003 09:46:35 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04202 for ; Mon, 6 Jan 2003 09:35:48 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h06EcuY25234; Mon, 6 Jan 2003 09:38:56 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Jan 2003 09:38:56 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E0F5@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Alan Chou'" , megaco@ietf.org Subject: RE: [Megaco] Qusetion: How to block analog line through the H.248 ? Date: Mon, 6 Jan 2003 09:38:54 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , It's probably a good idea to have the MGC manage longer-term timing like this. However, it could use a signal sequence like the following, while enabling the detection of an on-hook(strict) event to terminate it: {first tone or announcement (TO), second tone or announcement (TO), ... , final tone (typically) (TO), line lockout (OO)}. In the above sequence, TO means timeout, OO means on/off. In other words the line lockout would last until explicitly terminated by the MGC. -----Original Message----- From: Alan Chou [mailto:zhouzifeng@huawei.com] Sent: Sunday, December 29, 2002 12:40 AM To: megaco@ietf.org Subject: [Megaco] Qusetion: How to block analog line through the H.248? Hi all, In traditional switch, if the analog line subscriber doesn't on-hook for long time, the switch shall cut off the power supply on the user line. My question is which parameter can MGC use to implement it in H.248? If such parameter is already present, can you show me in which package and which document it has been defined? Thanks & Regards ---------------------------------------------------------------------------- Alan Chou Huawei Technologies Co, Ltd. 3rd floor Luneng Building, No. 1 Shangdi 6th Street, Haidian district, Beijing, China 100085 Fax : +86 (0)10 82882937 Phone : +86 (0)10 82882599 E-mail : zhouzifeng@huawei.com Web : http://www.huawei.com ---------------------------------------------------------------------------- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jan 6 09:38:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04260 for ; Mon, 6 Jan 2003 09:38:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06Emlm21152 for megaco-archive@odin.ietf.org; Mon, 6 Jan 2003 09:48:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06EmkJ21149 for ; Mon, 6 Jan 2003 09:48:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04243 for ; Mon, 6 Jan 2003 09:37:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06ElTJ21067; Mon, 6 Jan 2003 09:47:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06EkZJ21032 for ; Mon, 6 Jan 2003 09:46:35 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04202 for ; Mon, 6 Jan 2003 09:35:48 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h06EcuY25234; Mon, 6 Jan 2003 09:38:56 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Jan 2003 09:38:56 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E0F5@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Alan Chou'" , megaco@ietf.org Subject: RE: [Megaco] Qusetion: How to block analog line through the H.248 ? Date: Mon, 6 Jan 2003 09:38:54 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , It's probably a good idea to have the MGC manage longer-term timing like this. However, it could use a signal sequence like the following, while enabling the detection of an on-hook(strict) event to terminate it: {first tone or announcement (TO), second tone or announcement (TO), ... , final tone (typically) (TO), line lockout (OO)}. In the above sequence, TO means timeout, OO means on/off. In other words the line lockout would last until explicitly terminated by the MGC. -----Original Message----- From: Alan Chou [mailto:zhouzifeng@huawei.com] Sent: Sunday, December 29, 2002 12:40 AM To: megaco@ietf.org Subject: [Megaco] Qusetion: How to block analog line through the H.248? Hi all, In traditional switch, if the analog line subscriber doesn't on-hook for long time, the switch shall cut off the power supply on the user line. My question is which parameter can MGC use to implement it in H.248? If such parameter is already present, can you show me in which package and which document it has been defined? Thanks & Regards ---------------------------------------------------------------------------- Alan Chou Huawei Technologies Co, Ltd. 3rd floor Luneng Building, No. 1 Shangdi 6th Street, Haidian district, Beijing, China 100085 Fax : +86 (0)10 82882937 Phone : +86 (0)10 82882599 E-mail : zhouzifeng@huawei.com Web : http://www.huawei.com ---------------------------------------------------------------------------- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jan 6 09:55:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04601 for ; Mon, 6 Jan 2003 09:55:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06F4GJ21875; Mon, 6 Jan 2003 10:04:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06F1EJ21714 for ; Mon, 6 Jan 2003 10:01:14 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04512 for ; Mon, 6 Jan 2003 09:50:26 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h06Erc011557 for ; Mon, 6 Jan 2003 09:53:38 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Jan 2003 09:53:38 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E0F6@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'megaco@ietf.org'" Date: Mon, 6 Jan 2003 09:53:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B593.64C2A7F6" Subject: [Megaco] Wind-Up of Working Group? Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2B593.64C2A7F6 Content-Type: text/plain I'm wondering if it is time to wind up Megaco as a formal Working Group (but the E-mail list would remain). The implication is that all further standardization would be either by individual I-D or by working through Study Group 16. There would no longer be an official point of contact between the latter and the IETF below the IESG level. People might wish to comment. Regardless of what we decide on this point, what is a realistic timetable for completion of our current charter items? In particular: -- How close do people see the MIB to completion? -- If the NAS package is recycled specifically to address Christian's point that outgoing calls require the MG to provide bearer capability information for the MGC to use in signalling, is it ready to submit for publication? -- How much more work do we need on call flow examples? Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) ------_=_NextPart_001_01C2B593.64C2A7F6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Wind-Up of Working Group?

I'm wondering if it is time to wind up Megaco as a = formal Working Group (but the E-mail list would remain).  The = implication is that all further standardization would be either by = individual I-D or by working through Study Group 16.  There would = no longer be an official point of contact between the latter and the = IETF below the IESG level.  People might wish to = comment.

Regardless of what we decide on this point, what is a = realistic timetable for completion of our current charter items?  = In particular:

  -- How close do people see the MIB to = completion?
  -- If the NAS package is recycled = specifically to address Christian's point that outgoing calls require = the MG to provide bearer capability information for the MGC to use in = signalling, is it ready to submit for publication?

  -- How much more work do we need on call flow = examples?

Tom Taylor
taylor@nortelnetworks.com
Ph. +1 613 736 0961 (ESN 396 1490)
 

------_=_NextPart_001_01C2B593.64C2A7F6-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jan 6 09:55:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04667 for ; Mon, 6 Jan 2003 09:55:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06F5wt21954 for megaco-archive@odin.ietf.org; Mon, 6 Jan 2003 10:05:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06F5wJ21951 for ; Mon, 6 Jan 2003 10:05:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04616 for ; Mon, 6 Jan 2003 09:55:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06F4GJ21875; Mon, 6 Jan 2003 10:04:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06F1EJ21714 for ; Mon, 6 Jan 2003 10:01:14 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04512 for ; Mon, 6 Jan 2003 09:50:26 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h06Erc011557 for ; Mon, 6 Jan 2003 09:53:38 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Jan 2003 09:53:38 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E0F6@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'megaco@ietf.org'" Date: Mon, 6 Jan 2003 09:53:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B593.64C2A7F6" Subject: [Megaco] Wind-Up of Working Group? Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2B593.64C2A7F6 Content-Type: text/plain I'm wondering if it is time to wind up Megaco as a formal Working Group (but the E-mail list would remain). The implication is that all further standardization would be either by individual I-D or by working through Study Group 16. There would no longer be an official point of contact between the latter and the IETF below the IESG level. People might wish to comment. Regardless of what we decide on this point, what is a realistic timetable for completion of our current charter items? In particular: -- How close do people see the MIB to completion? -- If the NAS package is recycled specifically to address Christian's point that outgoing calls require the MG to provide bearer capability information for the MGC to use in signalling, is it ready to submit for publication? -- How much more work do we need on call flow examples? Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) ------_=_NextPart_001_01C2B593.64C2A7F6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Wind-Up of Working Group?

I'm wondering if it is time to wind up Megaco as a = formal Working Group (but the E-mail list would remain).  The = implication is that all further standardization would be either by = individual I-D or by working through Study Group 16.  There would = no longer be an official point of contact between the latter and the = IETF below the IESG level.  People might wish to = comment.

Regardless of what we decide on this point, what is a = realistic timetable for completion of our current charter items?  = In particular:

  -- How close do people see the MIB to = completion?
  -- If the NAS package is recycled = specifically to address Christian's point that outgoing calls require = the MG to provide bearer capability information for the MGC to use in = signalling, is it ready to submit for publication?

  -- How much more work do we need on call flow = examples?

Tom Taylor
taylor@nortelnetworks.com
Ph. +1 613 736 0961 (ESN 396 1490)
 

------_=_NextPart_001_01C2B593.64C2A7F6-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jan 6 13:28:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09566 for ; Mon, 6 Jan 2003 13:28:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06IbZJ03941; Mon, 6 Jan 2003 13:37:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06IZZJ03389 for ; Mon, 6 Jan 2003 13:35:35 -0500 Received: from wiprom2mx1.wipro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09515 for ; Mon, 6 Jan 2003 13:24:41 -0500 (EST) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h06IRse11599 for ; Mon, 6 Jan 2003 23:57:54 +0530 (IST) Received: from blr-ec-msg01.wipro.com ([10.200.50.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 6 Jan 2003 23:57:49 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: [Megaco] Wind-Up of Working Group? Date: Mon, 6 Jan 2003 23:57:49 +0530 Message-ID: <80E5F2986AAFC445B5BB82E4D2B0BCA602637A@blr-ec-msg01.wipro.com> Thread-Topic: [Megaco] Wind-Up of Working Group? Thread-Index: AcK1lIRgFZ+t/04+Rf+25Bxg6Yn6SAAGpJp6 From: "Ranjith Mukundan" To: "Tom-PT Taylor" , X-OriginalArrivalTime: 06 Jan 2003 18:27:49.0501 (UTC) FILETIME=[5124F2D0:01C2B5B1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h06IZZJ03390 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Tom, It will help to have the formal WG on for perhaps until may be end of this year as I feel this time can be used for progressing any additional packages that might be forthcoming. Progressing an individual I-D or working thru SG16 will make things on the standards-track, IMO, slower. In fact, we could meet in March (56th IETF) and check if there is interest in augmenting the charter with not-so-heavy work items that are closely related to the existing charter work items. I think a year's time will be good enough to have a stable set of packages with a good coverage of new device-types (user and network) that might be used in different call scenarios. Having said that, we could decide to wind-up earlier, if we find that not many packages are forthcoming during the window of time - starting now to perhaps the 56th IETF meeting; with this note of yours serving as the first check-point. - ranjith.. -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Mon 1/6/2003 8:23 PM To: 'megaco@ietf.org' Cc: Subject: [Megaco] Wind-Up of Working Group? I'm wondering if it is time to wind up Megaco as a formal Working Group (but the E-mail list would remain). The implication is that all further standardization would be either by individual I-D or by working through Study Group 16. There would no longer be an official point of contact between the latter and the IETF below the IESG level. People might wish to comment. Regardless of what we decide on this point, what is a realistic timetable for completion of our current charter items? In particular: -- How close do people see the MIB to completion? -- If the NAS package is recycled specifically to address Christian's point that outgoing calls require the MG to provide bearer capability information for the MGC to use in signalling, is it ready to submit for publication? -- How much more work do we need on call flow examples? Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jan 6 13:28:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09588 for ; Mon, 6 Jan 2003 13:28:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06Id7R04117 for megaco-archive@odin.ietf.org; Mon, 6 Jan 2003 13:39:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06Id7J04114 for ; Mon, 6 Jan 2003 13:39:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09580 for ; Mon, 6 Jan 2003 13:28:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06IbZJ03941; Mon, 6 Jan 2003 13:37:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06IZZJ03389 for ; Mon, 6 Jan 2003 13:35:35 -0500 Received: from wiprom2mx1.wipro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09515 for ; Mon, 6 Jan 2003 13:24:41 -0500 (EST) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h06IRse11599 for ; Mon, 6 Jan 2003 23:57:54 +0530 (IST) Received: from blr-ec-msg01.wipro.com ([10.200.50.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 6 Jan 2003 23:57:49 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: [Megaco] Wind-Up of Working Group? Date: Mon, 6 Jan 2003 23:57:49 +0530 Message-ID: <80E5F2986AAFC445B5BB82E4D2B0BCA602637A@blr-ec-msg01.wipro.com> Thread-Topic: [Megaco] Wind-Up of Working Group? Thread-Index: AcK1lIRgFZ+t/04+Rf+25Bxg6Yn6SAAGpJp6 From: "Ranjith Mukundan" To: "Tom-PT Taylor" , X-OriginalArrivalTime: 06 Jan 2003 18:27:49.0501 (UTC) FILETIME=[5124F2D0:01C2B5B1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h06IZZJ03390 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Tom, It will help to have the formal WG on for perhaps until may be end of this year as I feel this time can be used for progressing any additional packages that might be forthcoming. Progressing an individual I-D or working thru SG16 will make things on the standards-track, IMO, slower. In fact, we could meet in March (56th IETF) and check if there is interest in augmenting the charter with not-so-heavy work items that are closely related to the existing charter work items. I think a year's time will be good enough to have a stable set of packages with a good coverage of new device-types (user and network) that might be used in different call scenarios. Having said that, we could decide to wind-up earlier, if we find that not many packages are forthcoming during the window of time - starting now to perhaps the 56th IETF meeting; with this note of yours serving as the first check-point. - ranjith.. -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Mon 1/6/2003 8:23 PM To: 'megaco@ietf.org' Cc: Subject: [Megaco] Wind-Up of Working Group? I'm wondering if it is time to wind up Megaco as a formal Working Group (but the E-mail list would remain). The implication is that all further standardization would be either by individual I-D or by working through Study Group 16. There would no longer be an official point of contact between the latter and the IETF below the IESG level. People might wish to comment. Regardless of what we decide on this point, what is a realistic timetable for completion of our current charter items? In particular: -- How close do people see the MIB to completion? -- If the NAS package is recycled specifically to address Christian's point that outgoing calls require the MG to provide bearer capability information for the MGC to use in signalling, is it ready to submit for publication? -- How much more work do we need on call flow examples? Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jan 6 13:52:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10342 for ; Mon, 6 Jan 2003 13:52:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06J2RJ05491; Mon, 6 Jan 2003 14:02:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06J1JJ05397 for ; Mon, 6 Jan 2003 14:01:19 -0500 Received: from mail.utstar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10253 for ; Mon, 6 Jan 2003 13:50:24 -0500 (EST) Received: from balanew ([172.16.40.43]) by mail.utstar.com (8.11.3/8.11.3) with ESMTP id h06IrkO17273; Mon, 6 Jan 2003 13:53:46 -0500 (EST) Reply-To: From: "Balasubramanian Pitchandi" To: "'Tom-PT Taylor'" , Subject: RE: [Megaco] Wind-Up of Working Group? Date: Mon, 6 Jan 2003 13:53:46 -0500 Organization: UTStarcom Inc Message-ID: <003801c2b5b4$f1302440$2b2810ac@balanew> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0039_01C2B58B.085A1C40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <4D79C746863DD51197690002A52CDA000400E0F6@zcard0kc.ca.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_0039_01C2B58B.085A1C40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tom, =20 Having just released the Version 2 of the protocol and considering the = fact that there are still some unresolved issues and loose ends to tie, I = think it's really important that the WG remains active throughout this year = and beyond if needed. =20 With respect to MIB drafts, I have received few comments from selected people. I have updated the MIB draft with those comments. I am also = planning to merge in other MIB related drafts (draft-pitchandi-megaco-ringing-mib-00.txt etc) into the main MIB draft (pending Kevin's analysis of this draft). I am hoping to release an = updated MIB draft sometime around February. =20 The WG activity can be monitored continuously over this year and with a = list of remaining work items (if any other than the ones that you had = specified below), a decision on going forward could be made mid year or even at = the end of this year. =20 Thanks, Bala =20 -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of Tom-PT Taylor Sent: Monday, January 06, 2003 9:54 AM To: 'megaco@ietf.org' Subject: [Megaco] Wind-Up of Working Group? =20 I'm wondering if it is time to wind up Megaco as a formal Working Group = (but the E-mail list would remain). The implication is that all further standardization would be either by individual I-D or by working through Study Group 16. There would no longer be an official point of contact between the latter and the IETF below the IESG level. People might wish = to comment. Regardless of what we decide on this point, what is a realistic = timetable for completion of our current charter items? In particular: -- How close do people see the MIB to completion?=20 -- If the NAS package is recycled specifically to address Christian's point that outgoing calls require the MG to provide bearer capability information for the MGC to use in signalling, is it ready to submit for publication? -- How much more work do we need on call flow examples?=20 Tom Taylor=20 taylor@nortelnetworks.com=20 Ph. +1 613 736 0961 (ESN 396 1490)=20 =20 ------=_NextPart_000_0039_01C2B58B.085A1C40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Wind-Up of Working Group?

Tom,

 

Having just released the Version 2 = of the protocol and considering the fact that there are still some unresolved = issues and loose ends to tie, I think it’s really important that the WG = remains active throughout this year and beyond if needed.

 

With respect to MIB drafts, I have received few comments from selected people. I have updated the MIB draft = with those comments. I am also planning to merge in other MIB related drafts (draft-pitchandi-megaco-ringing-mib-00.txt etc) into the main MIB draft (pending Kevin’s analysis of this draft). I am hoping to release = an updated MIB draft sometime around February.

 

The WG activity can be monitored = continuously over this year and with a list of remaining work items (if any other = than the ones that you had specified below), a decision on going forward could be = made mid year or even at the end of this year.

 

Thanks,

Bala

 

-----Original = Message-----
From: = megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On = Behalf Of Tom-PT Taylor
Sent: Monday, January 06, = 2003 9:54 AM
To: 'megaco@ietf.org'
Subject: [Megaco] Wind-Up = of Working Group?

 

I'm wondering if it is time to wind up Megaco = as a formal Working Group (but the E-mail list would remain).  The = implication is that all further standardization would be either by individual I-D or = by working through Study Group 16.  There would no longer be an = official point of contact between the latter and the IETF below the IESG = level.  People might wish to comment.

Regardless of what we decide on this point, = what is a realistic timetable for completion of our current charter items?  = In particular:

  -- How close do people see the MIB to completion?
  -- If the NAS = package is recycled specifically to address Christian's point that outgoing calls = require the MG to provide bearer capability information for the MGC to use in signalling, is it ready to submit for publication?

  -- How much more work do we need on = call flow examples?

Tom Taylor
taylor@nortelnetworks.com
Ph. +1 613 736 0961 (ESN = 396 1490)
  =

------=_NextPart_000_0039_01C2B58B.085A1C40-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jan 6 13:53:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10363 for ; Mon, 6 Jan 2003 13:53:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06J3tG05631 for megaco-archive@odin.ietf.org; Mon, 6 Jan 2003 14:03:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06J3tJ05628 for ; Mon, 6 Jan 2003 14:03:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10356 for ; Mon, 6 Jan 2003 13:53:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06J2RJ05491; Mon, 6 Jan 2003 14:02:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06J1JJ05397 for ; Mon, 6 Jan 2003 14:01:19 -0500 Received: from mail.utstar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10253 for ; Mon, 6 Jan 2003 13:50:24 -0500 (EST) Received: from balanew ([172.16.40.43]) by mail.utstar.com (8.11.3/8.11.3) with ESMTP id h06IrkO17273; Mon, 6 Jan 2003 13:53:46 -0500 (EST) Reply-To: From: "Balasubramanian Pitchandi" To: "'Tom-PT Taylor'" , Subject: RE: [Megaco] Wind-Up of Working Group? Date: Mon, 6 Jan 2003 13:53:46 -0500 Organization: UTStarcom Inc Message-ID: <003801c2b5b4$f1302440$2b2810ac@balanew> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0039_01C2B58B.085A1C40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <4D79C746863DD51197690002A52CDA000400E0F6@zcard0kc.ca.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_0039_01C2B58B.085A1C40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tom, =20 Having just released the Version 2 of the protocol and considering the = fact that there are still some unresolved issues and loose ends to tie, I = think it's really important that the WG remains active throughout this year = and beyond if needed. =20 With respect to MIB drafts, I have received few comments from selected people. I have updated the MIB draft with those comments. I am also = planning to merge in other MIB related drafts (draft-pitchandi-megaco-ringing-mib-00.txt etc) into the main MIB draft (pending Kevin's analysis of this draft). I am hoping to release an = updated MIB draft sometime around February. =20 The WG activity can be monitored continuously over this year and with a = list of remaining work items (if any other than the ones that you had = specified below), a decision on going forward could be made mid year or even at = the end of this year. =20 Thanks, Bala =20 -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of Tom-PT Taylor Sent: Monday, January 06, 2003 9:54 AM To: 'megaco@ietf.org' Subject: [Megaco] Wind-Up of Working Group? =20 I'm wondering if it is time to wind up Megaco as a formal Working Group = (but the E-mail list would remain). The implication is that all further standardization would be either by individual I-D or by working through Study Group 16. There would no longer be an official point of contact between the latter and the IETF below the IESG level. People might wish = to comment. Regardless of what we decide on this point, what is a realistic = timetable for completion of our current charter items? In particular: -- How close do people see the MIB to completion?=20 -- If the NAS package is recycled specifically to address Christian's point that outgoing calls require the MG to provide bearer capability information for the MGC to use in signalling, is it ready to submit for publication? -- How much more work do we need on call flow examples?=20 Tom Taylor=20 taylor@nortelnetworks.com=20 Ph. +1 613 736 0961 (ESN 396 1490)=20 =20 ------=_NextPart_000_0039_01C2B58B.085A1C40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Wind-Up of Working Group?

Tom,

 

Having just released the Version 2 = of the protocol and considering the fact that there are still some unresolved = issues and loose ends to tie, I think it’s really important that the WG = remains active throughout this year and beyond if needed.

 

With respect to MIB drafts, I have received few comments from selected people. I have updated the MIB draft = with those comments. I am also planning to merge in other MIB related drafts (draft-pitchandi-megaco-ringing-mib-00.txt etc) into the main MIB draft (pending Kevin’s analysis of this draft). I am hoping to release = an updated MIB draft sometime around February.

 

The WG activity can be monitored = continuously over this year and with a list of remaining work items (if any other = than the ones that you had specified below), a decision on going forward could be = made mid year or even at the end of this year.

 

Thanks,

Bala

 

-----Original = Message-----
From: = megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On = Behalf Of Tom-PT Taylor
Sent: Monday, January 06, = 2003 9:54 AM
To: 'megaco@ietf.org'
Subject: [Megaco] Wind-Up = of Working Group?

 

I'm wondering if it is time to wind up Megaco = as a formal Working Group (but the E-mail list would remain).  The = implication is that all further standardization would be either by individual I-D or = by working through Study Group 16.  There would no longer be an = official point of contact between the latter and the IETF below the IESG = level.  People might wish to comment.

Regardless of what we decide on this point, = what is a realistic timetable for completion of our current charter items?  = In particular:

  -- How close do people see the MIB to completion?
  -- If the NAS = package is recycled specifically to address Christian's point that outgoing calls = require the MG to provide bearer capability information for the MGC to use in signalling, is it ready to submit for publication?

  -- How much more work do we need on = call flow examples?

Tom Taylor
taylor@nortelnetworks.com
Ph. +1 613 736 0961 (ESN = 396 1490)
  =

------=_NextPart_000_0039_01C2B58B.085A1C40-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jan 6 14:50:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12533 for ; Mon, 6 Jan 2003 14:50:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06JxtJ09294; Mon, 6 Jan 2003 14:59:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06JpaJ09030 for ; Mon, 6 Jan 2003 14:51:36 -0500 Received: from zrtps0kp.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12116 for ; Mon, 6 Jan 2003 14:40:44 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h06Jhv700340 for ; Mon, 6 Jan 2003 14:43:57 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Jan 2003 14:43:57 -0500 Message-ID: From: "Kevin Boyle" To: Ranjith Mukundan , "Tom-PT Taylor" , megaco@ietf.org Subject: RE: [Megaco] Wind-Up of Working Group? Date: Mon, 6 Jan 2003 14:43:54 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Actually, experience has shown that it is much FASTER to take packages through SG16. I'm sure there are plenty of folks around who can corroborate that. In fact, I am seriously considering reissuing the packages I have authored in the ITU, where I believe that they can become Recommendations in May. Note that packages, with very few exceptions, have never been a work item of the group (NAS comes to mind as an exception). The timing disadvantage that the ITU has is that SG16 can only produce Recommendations at full SG meetings. These are currently scheduled for May, February 2004 and November 2004. The IETF process allows the IESG to approve drafts as RFCs at any time. So at any given moment, you'll have to decide which body provides you the most benefit with regard to timing, if that is your most important concern. Kevin -----Original Message----- From: Ranjith Mukundan [mailto:ranjith.mukundan@wipro.com] Sent: Monday, January 06, 2003 1:28 PM To: Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org Subject: RE: [Megaco] Wind-Up of Working Group? Tom, It will help to have the formal WG on for perhaps until may be end of this year as I feel this time can be used for progressing any additional packages that might be forthcoming. Progressing an individual I-D or working thru SG16 will make things on the standards-track, IMO, slower. In fact, we could meet in March (56th IETF) and check if there is interest in augmenting the charter with not-so-heavy work items that are closely related to the existing charter work items. I think a year's time will be good enough to have a stable set of packages with a good coverage of new device-types (user and network) that might be used in different call scenarios. Having said that, we could decide to wind-up earlier, if we find that not many packages are forthcoming during the window of time - starting now to perhaps the 56th IETF meeting; with this note of yours serving as the first check-point. - ranjith.. -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Mon 1/6/2003 8:23 PM To: 'megaco@ietf.org' Cc: Subject: [Megaco] Wind-Up of Working Group? I'm wondering if it is time to wind up Megaco as a formal Working Group (but the E-mail list would remain). The implication is that all further standardization would be either by individual I-D or by working through Study Group 16. There would no longer be an official point of contact between the latter and the IETF below the IESG level. People might wish to comment. Regardless of what we decide on this point, what is a realistic timetable for completion of our current charter items? In particular: -- How close do people see the MIB to completion? -- If the NAS package is recycled specifically to address Christian's point that outgoing calls require the MG to provide bearer capability information for the MGC to use in signalling, is it ready to submit for publication? -- How much more work do we need on call flow examples? Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jan 6 14:51:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12617 for ; Mon, 6 Jan 2003 14:51:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06K1fq09485 for megaco-archive@odin.ietf.org; Mon, 6 Jan 2003 15:01:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06K1eJ09482 for ; Mon, 6 Jan 2003 15:01:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12537 for ; Mon, 6 Jan 2003 14:50:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06JxtJ09294; Mon, 6 Jan 2003 14:59:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06JpaJ09030 for ; Mon, 6 Jan 2003 14:51:36 -0500 Received: from zrtps0kp.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12116 for ; Mon, 6 Jan 2003 14:40:44 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h06Jhv700340 for ; Mon, 6 Jan 2003 14:43:57 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Jan 2003 14:43:57 -0500 Message-ID: From: "Kevin Boyle" To: Ranjith Mukundan , "Tom-PT Taylor" , megaco@ietf.org Subject: RE: [Megaco] Wind-Up of Working Group? Date: Mon, 6 Jan 2003 14:43:54 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Actually, experience has shown that it is much FASTER to take packages through SG16. I'm sure there are plenty of folks around who can corroborate that. In fact, I am seriously considering reissuing the packages I have authored in the ITU, where I believe that they can become Recommendations in May. Note that packages, with very few exceptions, have never been a work item of the group (NAS comes to mind as an exception). The timing disadvantage that the ITU has is that SG16 can only produce Recommendations at full SG meetings. These are currently scheduled for May, February 2004 and November 2004. The IETF process allows the IESG to approve drafts as RFCs at any time. So at any given moment, you'll have to decide which body provides you the most benefit with regard to timing, if that is your most important concern. Kevin -----Original Message----- From: Ranjith Mukundan [mailto:ranjith.mukundan@wipro.com] Sent: Monday, January 06, 2003 1:28 PM To: Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org Subject: RE: [Megaco] Wind-Up of Working Group? Tom, It will help to have the formal WG on for perhaps until may be end of this year as I feel this time can be used for progressing any additional packages that might be forthcoming. Progressing an individual I-D or working thru SG16 will make things on the standards-track, IMO, slower. In fact, we could meet in March (56th IETF) and check if there is interest in augmenting the charter with not-so-heavy work items that are closely related to the existing charter work items. I think a year's time will be good enough to have a stable set of packages with a good coverage of new device-types (user and network) that might be used in different call scenarios. Having said that, we could decide to wind-up earlier, if we find that not many packages are forthcoming during the window of time - starting now to perhaps the 56th IETF meeting; with this note of yours serving as the first check-point. - ranjith.. -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Mon 1/6/2003 8:23 PM To: 'megaco@ietf.org' Cc: Subject: [Megaco] Wind-Up of Working Group? I'm wondering if it is time to wind up Megaco as a formal Working Group (but the E-mail list would remain). The implication is that all further standardization would be either by individual I-D or by working through Study Group 16. There would no longer be an official point of contact between the latter and the IETF below the IESG level. People might wish to comment. Regardless of what we decide on this point, what is a realistic timetable for completion of our current charter items? In particular: -- How close do people see the MIB to completion? -- If the NAS package is recycled specifically to address Christian's point that outgoing calls require the MG to provide bearer capability information for the MGC to use in signalling, is it ready to submit for publication? -- How much more work do we need on call flow examples? Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 7 00:51:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24239 for ; Tue, 7 Jan 2003 00:51:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0760SJ14040; Tue, 7 Jan 2003 01:00:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h075sQJ13825 for ; Tue, 7 Jan 2003 00:54:26 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24155 for ; Tue, 7 Jan 2003 00:43:19 -0500 (EST) From: klaha@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h075jQs24980 for ; Tue, 7 Jan 2003 11:15:26 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h075jIN24969; Tue, 7 Jan 2003 11:15:19 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h075lOI14190; Tue, 7 Jan 2003 11:17:24 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CA7.001F104B ; Tue, 7 Jan 2003 11:09:17 +0530 X-Lotus-FromDomain: HSS To: zhaobo cc: vnair@hss.hns.com, megaco@ietf.org Message-ID: <65256CA7.001F1019.00@sandesh.hss.hns.com> Date: Tue, 7 Jan 2003 11:14:00 +0530 Subject: Re: [Megaco] Doubt in usage of R2 package Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , zhaobo on 01/03/2003 04:16:18 PM To: Vikram Nair/HSS@HSS cc: megaco@ietf.org (bcc: Kushanava Laha/HSS) Subject: [Megaco] Doubt in usage of R2 package Hi Vikram: I have two questions: 1. What will happed if the incoming MG compells for information not availiable in outgoing MG, for examples,the signal applies to outgoing MG is "R2/address{si=2992,di=2989}",but the incoming MG compells for language/dicrimination digit? [Kushanava] It is a standard practice in networks that peer R2 registers (incoming and outgoing gateways) are checked to be in synch wrt their compelling sequence before going live. If they are not, compelling will fail. 2. When sls signal applies, some condition shall be sent in Group A backward signal, some shall be sent in Group B signals. Is the responsibility of MG to decide what kind of signal will be sent? [Kushanava] Yes, MG hides the Compelling sequence from the MGC. MG decides based on the current compelling state what to send as Group A and Group B (or for that matter other Groups in certain national standards of R2) Thanks very much, and wish you a happy new year! Zhao Bo 01/03 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 7 00:54:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24274 for ; Tue, 7 Jan 2003 00:54:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0764xY14184 for megaco-archive@odin.ietf.org; Tue, 7 Jan 2003 01:04:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0764wJ14181 for ; Tue, 7 Jan 2003 01:04:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24242 for ; Tue, 7 Jan 2003 00:51:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0760SJ14040; Tue, 7 Jan 2003 01:00:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h075sQJ13825 for ; Tue, 7 Jan 2003 00:54:26 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24155 for ; Tue, 7 Jan 2003 00:43:19 -0500 (EST) From: klaha@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h075jQs24980 for ; Tue, 7 Jan 2003 11:15:26 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h075jIN24969; Tue, 7 Jan 2003 11:15:19 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h075lOI14190; Tue, 7 Jan 2003 11:17:24 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CA7.001F104B ; Tue, 7 Jan 2003 11:09:17 +0530 X-Lotus-FromDomain: HSS To: zhaobo cc: vnair@hss.hns.com, megaco@ietf.org Message-ID: <65256CA7.001F1019.00@sandesh.hss.hns.com> Date: Tue, 7 Jan 2003 11:14:00 +0530 Subject: Re: [Megaco] Doubt in usage of R2 package Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , zhaobo on 01/03/2003 04:16:18 PM To: Vikram Nair/HSS@HSS cc: megaco@ietf.org (bcc: Kushanava Laha/HSS) Subject: [Megaco] Doubt in usage of R2 package Hi Vikram: I have two questions: 1. What will happed if the incoming MG compells for information not availiable in outgoing MG, for examples,the signal applies to outgoing MG is "R2/address{si=2992,di=2989}",but the incoming MG compells for language/dicrimination digit? [Kushanava] It is a standard practice in networks that peer R2 registers (incoming and outgoing gateways) are checked to be in synch wrt their compelling sequence before going live. If they are not, compelling will fail. 2. When sls signal applies, some condition shall be sent in Group A backward signal, some shall be sent in Group B signals. Is the responsibility of MG to decide what kind of signal will be sent? [Kushanava] Yes, MG hides the Compelling sequence from the MGC. MG decides based on the current compelling state what to send as Group A and Group B (or for that matter other Groups in certain national standards of R2) Thanks very much, and wish you a happy new year! Zhao Bo 01/03 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 7 01:39:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24974 for ; Tue, 7 Jan 2003 01:39:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h076oSL16913 for megaco-archive@odin.ietf.org; Tue, 7 Jan 2003 01:50:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h076oSJ16910 for ; Tue, 7 Jan 2003 01:50:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24940 for ; Tue, 7 Jan 2003 01:35:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h076ixJ16696; Tue, 7 Jan 2003 01:44:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h076gSJ16593 for ; Tue, 7 Jan 2003 01:42:28 -0500 Received: from cms3.etri.re.kr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24896 for ; Tue, 7 Jan 2003 01:31:21 -0500 (EST) From: hektor@etri.re.kr Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Jan 2003 15:35:17 +0900 Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A5DA4C1@cms3.etri.re.kr> To: megaco@ietf.org Date: Tue, 7 Jan 2003 15:35:10 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B616.ED5D5DD0" Subject: [Megaco] Question about VALUE definition in ABNF? Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2B616.ED5D5DD0 Content-Type: text/plain; charset="euc-kr" Hi, All. I think the VALUE defition is too general. So When scanning, It is difficult to get the VALUE as a token. Because It looks like contain kind of dilimiters (e.g. "/", "-"). for example) when scanning "ABC/123"(this is not quoted string), the scanner may get the tokens following way. token - ABC : Name token - / : SLASH token - 123 : decimal the scanner may not get the tokens following way token-ABC/123 : Value As a result of above issue, When implementing, Grammar may lose the general syntax. For example) In case of alternativeValue, In ABNF : alternativeValue = VALUE, it is very simple. but in real implementation, we should consider all possible VALUE forms: alternativieValue : Name Slash Integer | Integer Slash Name | Name Minus Name | Name Minus Integer | .... | .... | .... (where Name, Slash, Integer, Minus are tokens returned by the scanner) It means there are chances to redfine VALUE on the fine granuality. we may get rid of kinds of delimiter(e.g. /, -) from SafeChar or we can redefine VALUE definition with giving constraints. for example) please give me your opinions. TIS. ------_=_NextPart_001_01C2B616.ED5D5DD0 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable Question about VALUE definition in ABNF?

Hi, All.

I think the VALUE defition is too general.
So When scanning, It is difficult to get the VALUE = as a token.
Because It looks like contain kind of dilimiters = (e.g. "/", "-").

for example) when scanning "ABC/123"(this = is not quoted string), 
the scanner may get the tokens following way.
token - ABC : Name
token - / : SLASH
token - 123 : decimal
the scanner may not get the tokens following = way
token-ABC/123 : Value

As a result of above issue, When implementing, = Grammar may lose the general syntax.
For example)
In case of alternativeValue,
In ABNF : alternativeValue =3D VALUE, it is very = simple.
but in real implementation, we should consider all = possible VALUE forms:
alternativieValue : Name Slash Integer
          &nb= sp;           &nb= sp;  | Integer Slash Name
          &nb= sp;           &nb= sp;  | Name Minus Name
          &nb= sp;           &nb= sp;  | Name Minus Integer
          &nb= sp;           &nb= sp;  | ....
          &nb= sp;           &nb= sp;  | ....
          &nb= sp;           &nb= sp;  | ....
(where Name, Slash, Integer, Minus are tokens = returned by the scanner)

It means there are chances to redfine VALUE on the = fine granuality.
we may get rid of kinds of delimiter(e.g. /, -) from = SafeChar or we can redefine VALUE definition with giving = constraints.

for example)

please give me your opinions.
TIS.

------_=_NextPart_001_01C2B616.ED5D5DD0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 7 01:35:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24937 for ; Tue, 7 Jan 2003 01:35:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h076ixJ16696; Tue, 7 Jan 2003 01:44:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h076gSJ16593 for ; Tue, 7 Jan 2003 01:42:28 -0500 Received: from cms3.etri.re.kr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24896 for ; Tue, 7 Jan 2003 01:31:21 -0500 (EST) From: hektor@etri.re.kr Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Jan 2003 15:35:17 +0900 Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A5DA4C1@cms3.etri.re.kr> To: megaco@ietf.org Date: Tue, 7 Jan 2003 15:35:10 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B616.ED5D5DD0" Subject: [Megaco] Question about VALUE definition in ABNF? Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2B616.ED5D5DD0 Content-Type: text/plain; charset="euc-kr" Hi, All. I think the VALUE defition is too general. So When scanning, It is difficult to get the VALUE as a token. Because It looks like contain kind of dilimiters (e.g. "/", "-"). for example) when scanning "ABC/123"(this is not quoted string), the scanner may get the tokens following way. token - ABC : Name token - / : SLASH token - 123 : decimal the scanner may not get the tokens following way token-ABC/123 : Value As a result of above issue, When implementing, Grammar may lose the general syntax. For example) In case of alternativeValue, In ABNF : alternativeValue = VALUE, it is very simple. but in real implementation, we should consider all possible VALUE forms: alternativieValue : Name Slash Integer | Integer Slash Name | Name Minus Name | Name Minus Integer | .... | .... | .... (where Name, Slash, Integer, Minus are tokens returned by the scanner) It means there are chances to redfine VALUE on the fine granuality. we may get rid of kinds of delimiter(e.g. /, -) from SafeChar or we can redefine VALUE definition with giving constraints. for example) please give me your opinions. TIS. ------_=_NextPart_001_01C2B616.ED5D5DD0 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable Question about VALUE definition in ABNF?

Hi, All.

I think the VALUE defition is too general.
So When scanning, It is difficult to get the VALUE = as a token.
Because It looks like contain kind of dilimiters = (e.g. "/", "-").

for example) when scanning "ABC/123"(this = is not quoted string), 
the scanner may get the tokens following way.
token - ABC : Name
token - / : SLASH
token - 123 : decimal
the scanner may not get the tokens following = way
token-ABC/123 : Value

As a result of above issue, When implementing, = Grammar may lose the general syntax.
For example)
In case of alternativeValue,
In ABNF : alternativeValue =3D VALUE, it is very = simple.
but in real implementation, we should consider all = possible VALUE forms:
alternativieValue : Name Slash Integer
          &nb= sp;           &nb= sp;  | Integer Slash Name
          &nb= sp;           &nb= sp;  | Name Minus Name
          &nb= sp;           &nb= sp;  | Name Minus Integer
          &nb= sp;           &nb= sp;  | ....
          &nb= sp;           &nb= sp;  | ....
          &nb= sp;           &nb= sp;  | ....
(where Name, Slash, Integer, Minus are tokens = returned by the scanner)

It means there are chances to redfine VALUE on the = fine granuality.
we may get rid of kinds of delimiter(e.g. /, -) from = SafeChar or we can redefine VALUE definition with giving = constraints.

for example)

please give me your opinions.
TIS.

------_=_NextPart_001_01C2B616.ED5D5DD0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 7 11:41:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20301 for ; Tue, 7 Jan 2003 11:41:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07GpRJ01783; Tue, 7 Jan 2003 11:51:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07GllJ01633 for ; Tue, 7 Jan 2003 11:47:47 -0500 Received: from wench.telica.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20146 for ; Tue, 7 Jan 2003 11:36:28 -0500 (EST) Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Jan 2003 11:36:33 -0500 Message-ID: From: Carl Rutter To: "'megaco@ietf.org'" Cc: Kang-Sen Lu Date: Tue, 7 Jan 2003 11:36:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Megaco] Question on Section 7.1.18 Megaco V2 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , We need some clarifcation on the following statement: (T1, T2, oneway) means that the Terminations that match T2 receive media from the Terminations matching T1, but not vice versa. In this case use of the ALL wildcard such that there are Terminations that match both T1 and T2 is not allowed. The line in question is "... such that there are Terminations that match both T1 and T2 is not allowed" The way we read it this clause disproves the use of Wildcard (*,T2,Oneway) becuase T2 will match * and T2. Hence the statement "Terminations that match both T1 and T2 is not allowed", excludes us from doing this. Is this correct? Thx, Carl Carl Rutter Telica, Inc. Building G, Suite 100 734 Forest Street Marlboro, MA 01752 Email crutter@telica.com Voice 508-480-0909 x8178 Fax 508-480-0922 www.telica.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 7 11:42:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20356 for ; Tue, 7 Jan 2003 11:42:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07Gr2C01875 for megaco-archive@odin.ietf.org; Tue, 7 Jan 2003 11:53:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07Gr1J01870 for ; Tue, 7 Jan 2003 11:53:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20305 for ; Tue, 7 Jan 2003 11:41:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07GpRJ01783; Tue, 7 Jan 2003 11:51:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07GllJ01633 for ; Tue, 7 Jan 2003 11:47:47 -0500 Received: from wench.telica.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20146 for ; Tue, 7 Jan 2003 11:36:28 -0500 (EST) Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Jan 2003 11:36:33 -0500 Message-ID: From: Carl Rutter To: "'megaco@ietf.org'" Cc: Kang-Sen Lu Date: Tue, 7 Jan 2003 11:36:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Megaco] Question on Section 7.1.18 Megaco V2 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , We need some clarifcation on the following statement: (T1, T2, oneway) means that the Terminations that match T2 receive media from the Terminations matching T1, but not vice versa. In this case use of the ALL wildcard such that there are Terminations that match both T1 and T2 is not allowed. The line in question is "... such that there are Terminations that match both T1 and T2 is not allowed" The way we read it this clause disproves the use of Wildcard (*,T2,Oneway) becuase T2 will match * and T2. Hence the statement "Terminations that match both T1 and T2 is not allowed", excludes us from doing this. Is this correct? Thx, Carl Carl Rutter Telica, Inc. Building G, Suite 100 734 Forest Street Marlboro, MA 01752 Email crutter@telica.com Voice 508-480-0909 x8178 Fax 508-480-0922 www.telica.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 7 15:12:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26948 for ; Tue, 7 Jan 2003 15:12:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07KMHJ15330; Tue, 7 Jan 2003 15:22:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07KGwJ15111 for ; Tue, 7 Jan 2003 15:16:58 -0500 Received: from genius.empirix.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26784 for ; Tue, 7 Jan 2003 15:05:35 -0500 (EST) Received: from kappa.midnight.com (kappa.empirix.com [10.4.0.10]) by genius.empirix.com (Postfix) with ESMTP id A732B110939 for ; Tue, 7 Jan 2003 15:08:51 -0500 (EST) Received: by kappa.empirix.com with Internet Mail Service (5.5.2655.55) id ; Tue, 7 Jan 2003 15:06:28 -0500 Message-ID: <5CB426A04E141C499676B19B6CF3DE571D0C88@kappa.empirix.com> From: "Garber, Zeev" To: megaco@ietf.org Date: Tue, 7 Jan 2003 15:06:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain Subject: [Megaco] Error handling on MG Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, Lets consider following scenario: MGC requests MG to Add physical and ephemeral($) terminations to newly created context($). MG realizes that physical termination is already added to another context. It responds with AddReply containing Error Descriptor . 2 questions: What is a context Id in response for the first Add command: $ or some new context Id? What if Physical termination was successfully added to the context but ephemeral wasn't (due to resource limitation for example). What should be the ephemeral termination id in response $ or some new termination Id? Thanks a lot, > Ze`ev Garber > Software Engineer > Communications Infrastructure Test Group > p| 978.661.1211 f| 978.988.0148 > email | zgarber@empirix.com > 205 Lowell Street | Wilmington, MA | 01887 > E M P I R I X > www.empirix.com > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 7 15:12:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26965 for ; Tue, 7 Jan 2003 15:12:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07KNm815407 for megaco-archive@odin.ietf.org; Tue, 7 Jan 2003 15:23:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07KNmJ15404 for ; Tue, 7 Jan 2003 15:23:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26951 for ; Tue, 7 Jan 2003 15:12:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07KMHJ15330; Tue, 7 Jan 2003 15:22:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07KGwJ15111 for ; Tue, 7 Jan 2003 15:16:58 -0500 Received: from genius.empirix.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26784 for ; Tue, 7 Jan 2003 15:05:35 -0500 (EST) Received: from kappa.midnight.com (kappa.empirix.com [10.4.0.10]) by genius.empirix.com (Postfix) with ESMTP id A732B110939 for ; Tue, 7 Jan 2003 15:08:51 -0500 (EST) Received: by kappa.empirix.com with Internet Mail Service (5.5.2655.55) id ; Tue, 7 Jan 2003 15:06:28 -0500 Message-ID: <5CB426A04E141C499676B19B6CF3DE571D0C88@kappa.empirix.com> From: "Garber, Zeev" To: megaco@ietf.org Date: Tue, 7 Jan 2003 15:06:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain Subject: [Megaco] Error handling on MG Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, Lets consider following scenario: MGC requests MG to Add physical and ephemeral($) terminations to newly created context($). MG realizes that physical termination is already added to another context. It responds with AddReply containing Error Descriptor . 2 questions: What is a context Id in response for the first Add command: $ or some new context Id? What if Physical termination was successfully added to the context but ephemeral wasn't (due to resource limitation for example). What should be the ephemeral termination id in response $ or some new termination Id? Thanks a lot, > Ze`ev Garber > Software Engineer > Communications Infrastructure Test Group > p| 978.661.1211 f| 978.988.0148 > email | zgarber@empirix.com > 205 Lowell Street | Wilmington, MA | 01887 > E M P I R I X > www.empirix.com > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 7 22:44:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11156 for ; Tue, 7 Jan 2003 22:44:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h083sPJ10031; Tue, 7 Jan 2003 22:54:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h083oJJ09950 for ; Tue, 7 Jan 2003 22:50:19 -0500 Received: from szsmtp.utstar.com.cn (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10874 for ; Tue, 7 Jan 2003 22:38:47 -0500 (EST) Received: from minliu ([172.19.18.20]) by szsmtp.utstar.com.cn (8.11.1/8.11.1) with SMTP id h083d6C09266 for ; Wed, 8 Jan 2003 11:39:06 +0800 From: "Jackson.liu" To: Subject: [Megaco] Apply for RTP termination Date: Wed, 8 Jan 2003 11:42:00 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: High In-Reply-To: <5CB426A04E141C499676B19B6CF3DE571D0C88@kappa.empirix.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h083oJJ09951 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, all: When MGC want to apply a RTP termination, which has echo cancelation and VAD or some other VOIP attributes, from MG. How can I decrible the reqirements in the command to MG? Thanks & Regards Jackson UTStarcom Ltd. SZ R&D Office. 3/F, Legend Research & Developemnt Building, High-tect Industrial Park Tel: (86-755)26983555-3599 Fax: (86-755)26983786 E-Mail: Jackson.liu@utstar.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 7 22:44:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11186 for ; Tue, 7 Jan 2003 22:44:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h083tex10066 for megaco-archive@odin.ietf.org; Tue, 7 Jan 2003 22:55:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h083teJ10063 for ; Tue, 7 Jan 2003 22:55:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11159 for ; Tue, 7 Jan 2003 22:44:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h083sPJ10031; Tue, 7 Jan 2003 22:54:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h083oJJ09950 for ; Tue, 7 Jan 2003 22:50:19 -0500 Received: from szsmtp.utstar.com.cn (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10874 for ; Tue, 7 Jan 2003 22:38:47 -0500 (EST) Received: from minliu ([172.19.18.20]) by szsmtp.utstar.com.cn (8.11.1/8.11.1) with SMTP id h083d6C09266 for ; Wed, 8 Jan 2003 11:39:06 +0800 From: "Jackson.liu" To: Subject: [Megaco] Apply for RTP termination Date: Wed, 8 Jan 2003 11:42:00 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: High In-Reply-To: <5CB426A04E141C499676B19B6CF3DE571D0C88@kappa.empirix.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h083oJJ09951 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, all: When MGC want to apply a RTP termination, which has echo cancelation and VAD or some other VOIP attributes, from MG. How can I decrible the reqirements in the command to MG? Thanks & Regards Jackson UTStarcom Ltd. SZ R&D Office. 3/F, Legend Research & Developemnt Building, High-tect Industrial Park Tel: (86-755)26983555-3599 Fax: (86-755)26983786 E-Mail: Jackson.liu@utstar.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jan 8 00:59:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15573 for ; Wed, 8 Jan 2003 00:59:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0869xJ17487; Wed, 8 Jan 2003 01:09:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0867gJ17398 for ; Wed, 8 Jan 2003 01:07:42 -0500 Received: from moon.mercurykr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15472 for ; Wed, 8 Jan 2003 00:53:55 -0500 (EST) Received: from LocalHost ([165.133.17.229]) by moon.mercurykr.com (8.10.0.Beta10/8.10.0.Beta10) with SMTP id h0860fv29724; Wed, 8 Jan 2003 15:00:45 +0900 Message-ID: <000e01c2b6da$e2423230$e51185a5@LocalHost> From: "Noh Jeong Min" To: "CHATRAS Bruno FTRD/DAC/ISS" Cc: References: <448914041F29D7499FA5F0B8ED1C708783B3CF@parmhs2.rd.francetelecom.fr> Subject: Re: [Megaco] What profile should I comply with when I implement Trunk Gate Way? Date: Wed, 8 Jan 2003 14:57:48 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h0867gJ17399 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Yes, some of the packages are no longer available. I don't know exactly about draft-rosen-megaco-atm-package-00.txt. But, ITU-T defined H.248.5 Gateway Control Protocol : Transport over ATM. And, IETF defined RFC3108 Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections. Also, AAL2 package defined in draft-barr-megaco-aal2bearer-00.txt. I think it can be use to ATM Trunking Gateway. I don't know exactly about the qos. Does qos package need to Media Gateway? I think it doesn't need the qos package. Does anybody exactly know about qos in the Media Gateway ? ----- Original Message ----- From: "CHATRAS Bruno FTRD/DAC/ISS" To: "Noh Jeong Min" ; "???" Cc: Sent: Monday, January 06, 2003 7:04 PM Subject: RE: [Megaco] What profile should I comply with when I implement Trunk Gate Way? > One difficulty with using the MSF profiles is that some of the packages they are referring to are no longer available. Such packages are only defined in expired Internet-Drafts (e.g.; draft-rosen-megaco-atm-package-00.txt for ATM trunking, draft-madhubabu-megaco-qospackage-00.txt for IP trunking...). > > > -----Message d'origine----- > > De?: Noh Jeong Min [mailto:hmask@mercurykr.com] > > Envoye?: jeudi 2 janvier 2003 01:45 > > A?: ??? > > Cc?: megaco@ietf.org > > Objet?: Re: [Megaco] What profile should I comply with when I > > implement Trunk Gate Way? > > > > > > Hi everybody. I wish your happy new year. > > > > I think you should refer the Multiservice Switching > > Forum(MSF, http://www.msforum.org )'s implement agreements > > and profiles. > > The 3 profiles for Media Gateway(TG,AG) published by the MSF. > > > > And, the technical information documents of Global MSF > > Interperability(GMI) are also useful to define your Trunk Gateway. > > > > > > Noh Jeong Min. > > IMT System Development Group. > > MERCURY Corporation. Ltd. > > Tel : +82 031 310 5714, +82 031 310 5718 > > Email : hmask@mercurykr.com > > > > > > ----- Original Message ----- > > From: "임재환" > > To: > > Sent: Saturday, December 28, 2002 10:05 AM > > Subject: [Megaco] What profile should I comply with when I > > implement Trunk Gate Way? > > > > > > > Hello everyone! > > > > > > What profile should I comply with when I implement Trunk > > Gate Way(TGW)? > > > > > > My trunk Gate Way has some E1 trunk interfaces on switch > > circuit Network > > > side and fast or giga ethernet interface on packet network > > side. Also, it > > > can have ATM interface on packet network side alternatively. > > > > > > Thank you for reading my question. > > > > > > > > > _______________________________________________ > > > Megaco mailing list > > > Megaco@ietf.org > > > https://www1.ietf.org/mailman/listinfo/megaco > > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 8 01:00:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15612 for ; Wed, 8 Jan 2003 01:00:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h086BLo17569 for megaco-archive@odin.ietf.org; Wed, 8 Jan 2003 01:11:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h086BLJ17566 for ; Wed, 8 Jan 2003 01:11:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15576 for ; Wed, 8 Jan 2003 00:59:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0869xJ17487; Wed, 8 Jan 2003 01:09:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0867gJ17398 for ; Wed, 8 Jan 2003 01:07:42 -0500 Received: from moon.mercurykr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15472 for ; Wed, 8 Jan 2003 00:53:55 -0500 (EST) Received: from LocalHost ([165.133.17.229]) by moon.mercurykr.com (8.10.0.Beta10/8.10.0.Beta10) with SMTP id h0860fv29724; Wed, 8 Jan 2003 15:00:45 +0900 Message-ID: <000e01c2b6da$e2423230$e51185a5@LocalHost> From: "Noh Jeong Min" To: "CHATRAS Bruno FTRD/DAC/ISS" Cc: References: <448914041F29D7499FA5F0B8ED1C708783B3CF@parmhs2.rd.francetelecom.fr> Subject: Re: [Megaco] What profile should I comply with when I implement Trunk Gate Way? Date: Wed, 8 Jan 2003 14:57:48 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h0867gJ17399 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Yes, some of the packages are no longer available. I don't know exactly about draft-rosen-megaco-atm-package-00.txt. But, ITU-T defined H.248.5 Gateway Control Protocol : Transport over ATM. And, IETF defined RFC3108 Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections. Also, AAL2 package defined in draft-barr-megaco-aal2bearer-00.txt. I think it can be use to ATM Trunking Gateway. I don't know exactly about the qos. Does qos package need to Media Gateway? I think it doesn't need the qos package. Does anybody exactly know about qos in the Media Gateway ? ----- Original Message ----- From: "CHATRAS Bruno FTRD/DAC/ISS" To: "Noh Jeong Min" ; "???" Cc: Sent: Monday, January 06, 2003 7:04 PM Subject: RE: [Megaco] What profile should I comply with when I implement Trunk Gate Way? > One difficulty with using the MSF profiles is that some of the packages they are referring to are no longer available. Such packages are only defined in expired Internet-Drafts (e.g.; draft-rosen-megaco-atm-package-00.txt for ATM trunking, draft-madhubabu-megaco-qospackage-00.txt for IP trunking...). > > > -----Message d'origine----- > > De?: Noh Jeong Min [mailto:hmask@mercurykr.com] > > Envoye?: jeudi 2 janvier 2003 01:45 > > A?: ??? > > Cc?: megaco@ietf.org > > Objet?: Re: [Megaco] What profile should I comply with when I > > implement Trunk Gate Way? > > > > > > Hi everybody. I wish your happy new year. > > > > I think you should refer the Multiservice Switching > > Forum(MSF, http://www.msforum.org )'s implement agreements > > and profiles. > > The 3 profiles for Media Gateway(TG,AG) published by the MSF. > > > > And, the technical information documents of Global MSF > > Interperability(GMI) are also useful to define your Trunk Gateway. > > > > > > Noh Jeong Min. > > IMT System Development Group. > > MERCURY Corporation. Ltd. > > Tel : +82 031 310 5714, +82 031 310 5718 > > Email : hmask@mercurykr.com > > > > > > ----- Original Message ----- > > From: "임재환" > > To: > > Sent: Saturday, December 28, 2002 10:05 AM > > Subject: [Megaco] What profile should I comply with when I > > implement Trunk Gate Way? > > > > > > > Hello everyone! > > > > > > What profile should I comply with when I implement Trunk > > Gate Way(TGW)? > > > > > > My trunk Gate Way has some E1 trunk interfaces on switch > > circuit Network > > > side and fast or giga ethernet interface on packet network > > side. Also, it > > > can have ATM interface on packet network side alternatively. > > > > > > Thank you for reading my question. > > > > > > > > > _______________________________________________ > > > 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 Jan 8 05:47:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16170 for ; Wed, 8 Jan 2003 05:47:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08AvRJ12440; Wed, 8 Jan 2003 05:57:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08At6J12360 for ; Wed, 8 Jan 2003 05:55:06 -0500 Received: from exchange.td-soft.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16116 for ; Wed, 8 Jan 2003 05:43:25 -0500 (EST) Received: through eSafe SMTP Relay 1041666416; Wed Jan 08 12:57:14 2003 Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 12:44:19 +0200 Message-ID: From: Raphael Tryster To: "Garber, Zeev" , megaco@ietf.org Subject: RE: [Megaco] Error handling on MG Date: Wed, 8 Jan 2003 12:44:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B702.E32F2310" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2B702.E32F2310 Content-Type: text/plain; charset="iso-8859-1" Inline. Raphael Tryster -----Original Message----- From: Garber, Zeev [SMTP:zgarber@empirix.com] Sent: Tuesday, 07 January, 2003 10:06 PM To: megaco@ietf.org Subject: [Megaco] Error handling on MG Hi All, Lets consider following scenario: MGC requests MG to Add physical and ephemeral($) terminations to newly created context($). MG realizes that physical termination is already added to another context. It responds with AddReply containing Error Descriptor . 2 questions: What is a context Id in response for the first Add command: $ or some new context Id? "The ContextID parameter must specify a value to pertain to all Responses for the action. The ContextID may be specific, all or null". Notice that "choose" is not given as an option. Now, if the MG created a context, but failed to Add any terminations to it, then the context no longer exists (did it ever exist?) We do have a precedent for returning the Id of a context that did not exist when the transaction started excuting (Add), and we also have a precedent for returning the Id of a context that did not exist when the transaction finished executing (Subtract). Your case is different, because the context exists neither at the beginning nor at the end. Does this justify returning a context Id that may have existed in the middle? I think it is reasonable to answer "yes", that the MG may return a context Id that existed at any time during the execution of the transaction. However, if the motivation is to comply with the above quote, then I must point out another case in which we cannot comply. This occurs when no more context Ids are available, and the MG returns error 412. In that case, I think the MG has no choice but to return context Id = $, and perhaps the standard should be amended. What if Physical termination was successfully added to the context but ephemeral wasn't (due to resource limitation for example). What should be the ephemeral termination id in response $ or some new termination Id? Similarly to the above, I would argue that it depends on whether the MG was able to assign an ephemeral termination Id. If it was not, $ would seem to be the only possibility. In all the scenarios, both sides need to be aware that an empty context and an ephemeral outside a context do not exist, and therefore the MGC should not issue subsequent commands using those identifiers. Thanks a lot, > Ze`ev Garber > Software Engineer > Communications Infrastructure Test Group > p| 978.661.1211 f| 978.988.0148 > email | zgarber@empirix.com > 205 Lowell Street | Wilmington, MA | 01887 > E M P I R I X > www.empirix.com > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C2B702.E32F2310 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] Error handling on MG

Inline.

Raphael Tryster

    -----Original Mess= age-----
    From:   Garber, Zeev [SMTP= :zgarber@empirix.com]
    Sent:   Tuesday, 07 January, 2003 10:06 PM
    To:     megaco@ietf.org
    Subject:    &nbs= p;   [Megaco] Error ha= ndling on MG

    Hi All,

    Lets consider following scenario:<= /FONT>

    MGC requests MG to Add physical an= d ephemeral($) terminations to newly
    created context($). MG realizes t= hat physical termination is already added
    to another context. It responds w= ith AddReply containing Error Descriptor .

    2 questions:

    What is a context Id in response f= or the first Add command: $ or some new
    context Id?

    "The ContextID parameter must specify a value to perta= in to all Responses for the action.  The ContextID may be specific, = all or null"= . 

    Notice that "choose" is not giv= en as an option.  = Now, if the MG created a context, but failed to Add any terminations to it, then the context no longer exists (did it e= ver exist?)  We do have a precedent for r= eturning the Id of a context that did not exist when the transaction started excuting (Add), and= we also have a precedent for returning the Id of a context that did not = exist when the trans action finished executing (Subtract).  Your case is different, becau= se the context exists neither at the beginning nor at the end.=   Does this justify returning= a context Id that may have existed in the middle? 

    I think it is reasonable to answer "yes= ", that= the MG may return a context Id that existed at any time during the execu= tion of the transaction.  However, if the motivation is to comply with the above quote, the= n I must point out another case in which we cannot comply.  This occurs when no more contex= t Ids are available, and the MG returns error 412.  In that case, I think the MG has no choice b= ut to return context Id =3D $, and perhaps the standard should be amended.

    What if Physical termination was s= uccessfully added to the context but
    ephemeral wasn't (due to resource= limitation for example). What should be
    the ephemeral termination id in r= esponse $ or some new termination Id?

    Similarly to the above,<= /U> I would argue that it depends on whether the MG was able to assign an epheme= ral termination Id.  If it was not, $ would seem to be the only possibility.<= /U>

    In all the scenarios, both sides need to be aware that= an empty context and an ephemeral outside a context do not exist, and th= erefore the MGC should not issue subsequent commands using those identifi= ers.

    Thanks a lot,
    > Ze`ev Garber
    > Software Engineer
    > Communications Infrastructur= e Test Group
    > p| 978.661.1211 f| 978.988.0= 148
    > email | zgarber@empirix.com =
    > 205 Lowell Street | Wilmingt= on, MA | 01887
    > E M P I R I X
    > www.empirix.com
    >


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

------_=_NextPart_001_01C2B702.E32F2310-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 8 05:47:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16190 for ; Wed, 8 Jan 2003 05:47:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08AwuJ12490 for megaco-archive@odin.ietf.org; Wed, 8 Jan 2003 05:58:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08AwuJ12487 for ; Wed, 8 Jan 2003 05:58:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16173 for ; Wed, 8 Jan 2003 05:47:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08AvRJ12440; Wed, 8 Jan 2003 05:57:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08At6J12360 for ; Wed, 8 Jan 2003 05:55:06 -0500 Received: from exchange.td-soft.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16116 for ; Wed, 8 Jan 2003 05:43:25 -0500 (EST) Received: through eSafe SMTP Relay 1041666416; Wed Jan 08 12:57:14 2003 Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 12:44:19 +0200 Message-ID: From: Raphael Tryster To: "Garber, Zeev" , megaco@ietf.org Subject: RE: [Megaco] Error handling on MG Date: Wed, 8 Jan 2003 12:44:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B702.E32F2310" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2B702.E32F2310 Content-Type: text/plain; charset="iso-8859-1" Inline. Raphael Tryster -----Original Message----- From: Garber, Zeev [SMTP:zgarber@empirix.com] Sent: Tuesday, 07 January, 2003 10:06 PM To: megaco@ietf.org Subject: [Megaco] Error handling on MG Hi All, Lets consider following scenario: MGC requests MG to Add physical and ephemeral($) terminations to newly created context($). MG realizes that physical termination is already added to another context. It responds with AddReply containing Error Descriptor . 2 questions: What is a context Id in response for the first Add command: $ or some new context Id? "The ContextID parameter must specify a value to pertain to all Responses for the action. The ContextID may be specific, all or null". Notice that "choose" is not given as an option. Now, if the MG created a context, but failed to Add any terminations to it, then the context no longer exists (did it ever exist?) We do have a precedent for returning the Id of a context that did not exist when the transaction started excuting (Add), and we also have a precedent for returning the Id of a context that did not exist when the transaction finished executing (Subtract). Your case is different, because the context exists neither at the beginning nor at the end. Does this justify returning a context Id that may have existed in the middle? I think it is reasonable to answer "yes", that the MG may return a context Id that existed at any time during the execution of the transaction. However, if the motivation is to comply with the above quote, then I must point out another case in which we cannot comply. This occurs when no more context Ids are available, and the MG returns error 412. In that case, I think the MG has no choice but to return context Id = $, and perhaps the standard should be amended. What if Physical termination was successfully added to the context but ephemeral wasn't (due to resource limitation for example). What should be the ephemeral termination id in response $ or some new termination Id? Similarly to the above, I would argue that it depends on whether the MG was able to assign an ephemeral termination Id. If it was not, $ would seem to be the only possibility. In all the scenarios, both sides need to be aware that an empty context and an ephemeral outside a context do not exist, and therefore the MGC should not issue subsequent commands using those identifiers. Thanks a lot, > Ze`ev Garber > Software Engineer > Communications Infrastructure Test Group > p| 978.661.1211 f| 978.988.0148 > email | zgarber@empirix.com > 205 Lowell Street | Wilmington, MA | 01887 > E M P I R I X > www.empirix.com > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C2B702.E32F2310 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] Error handling on MG

Inline.

Raphael Tryster

    -----Original Mess= age-----
    From:   Garber, Zeev [SMTP= :zgarber@empirix.com]
    Sent:   Tuesday, 07 January, 2003 10:06 PM
    To:     megaco@ietf.org
    Subject:    &nbs= p;   [Megaco] Error ha= ndling on MG

    Hi All,

    Lets consider following scenario:<= /FONT>

    MGC requests MG to Add physical an= d ephemeral($) terminations to newly
    created context($). MG realizes t= hat physical termination is already added
    to another context. It responds w= ith AddReply containing Error Descriptor .

    2 questions:

    What is a context Id in response f= or the first Add command: $ or some new
    context Id?

    "The ContextID parameter must specify a value to perta= in to all Responses for the action.  The ContextID may be specific, = all or null"= . 

    Notice that "choose" is not giv= en as an option.  = Now, if the MG created a context, but failed to Add any terminations to it, then the context no longer exists (did it e= ver exist?)  We do have a precedent for r= eturning the Id of a context that did not exist when the transaction started excuting (Add), and= we also have a precedent for returning the Id of a context that did not = exist when the trans action finished executing (Subtract).  Your case is different, becau= se the context exists neither at the beginning nor at the end.=   Does this justify returning= a context Id that may have existed in the middle? 

    I think it is reasonable to answer "yes= ", that= the MG may return a context Id that existed at any time during the execu= tion of the transaction.  However, if the motivation is to comply with the above quote, the= n I must point out another case in which we cannot comply.  This occurs when no more contex= t Ids are available, and the MG returns error 412.  In that case, I think the MG has no choice b= ut to return context Id =3D $, and perhaps the standard should be amended.

    What if Physical termination was s= uccessfully added to the context but
    ephemeral wasn't (due to resource= limitation for example). What should be
    the ephemeral termination id in r= esponse $ or some new termination Id?

    Similarly to the above,<= /U> I would argue that it depends on whether the MG was able to assign an epheme= ral termination Id.  If it was not, $ would seem to be the only possibility.<= /U>

    In all the scenarios, both sides need to be aware that= an empty context and an ephemeral outside a context do not exist, and th= erefore the MGC should not issue subsequent commands using those identifi= ers.

    Thanks a lot,
    > Ze`ev Garber
    > Software Engineer
    > Communications Infrastructur= e Test Group
    > p| 978.661.1211 f| 978.988.0= 148
    > email | zgarber@empirix.com =
    > 205 Lowell Street | Wilmingt= on, MA | 01887
    > E M P I R I X
    > www.empirix.com
    >


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

------_=_NextPart_001_01C2B702.E32F2310-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jan 8 09:08:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20279 for ; Wed, 8 Jan 2003 09:08:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08EIxJ24198; Wed, 8 Jan 2003 09:18:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h082jbJ06878 for ; Tue, 7 Jan 2003 21:45:37 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09236 for ; Tue, 7 Jan 2003 21:34:04 -0500 (EST) Received: from z14593 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H8D006GBJ740U@mta0.huawei.com> for megaco@ietf.org; Wed, 08 Jan 2003 10:35:31 +0800 (CST) Date: Wed, 08 Jan 2003 10:38:35 +0800 From: zhaobo To: megaco@ietf.org Message-id: <000c01c2b6bf$0b0ceb40$ea486e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Content-type: multipart/mixed; boundary="Boundary_(ID_zKBzaYkC1wTgiynSPT+DSw)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Megaco] Inconsistence of "ansto" property in bcas package Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_zKBzaYkC1wTgiynSPT+DSw) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT Hi All: The property "ansto"(answer timeout) was deleted in draft-manyfolks-megaco-caspackage- 03.txt, but it is still metioned in the same draft(page 18): "A timeout is specified for the ansto property. " and in draft "draft-ietf-megaco-r2package-02.txt"(section 7.1): I guess it's a inconsitence? Regard Zhao Bo 2003/01/08 --Boundary_(ID_zKBzaYkC1wTgiynSPT+DSw) Content-type: text/x-vcard; name="Zhao Bo.vcf" Content-disposition: attachment; filename="Zhao Bo.vcf" Content-Transfer-Encoding: 7BIT BEGIN:VCARD VERSION:2.1 N:Zhao;Bo FN:Zhao Bo ORG:Huawei Technologies Co. Ltd ADR;WORK:;;;Beijing;;;China LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Beijing=0D=0AChina URL: URL:http://www.huawei.com EMAIL;PREF;INTERNET:zbo@huawei.com EMAIL;INTERNET:zbo@huawei.com REV:20030108T023835Z END:VCARD --Boundary_(ID_zKBzaYkC1wTgiynSPT+DSw)-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 8 09:11:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20403 for ; Wed, 8 Jan 2003 09:11:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08EMVp24461 for megaco-archive@odin.ietf.org; Wed, 8 Jan 2003 09:22:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08EMVJ24458 for ; Wed, 8 Jan 2003 09:22:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20286 for ; Wed, 8 Jan 2003 09:09:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08EIxJ24198; Wed, 8 Jan 2003 09:18:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h082jbJ06878 for ; Tue, 7 Jan 2003 21:45:37 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09236 for ; Tue, 7 Jan 2003 21:34:04 -0500 (EST) Received: from z14593 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H8D006GBJ740U@mta0.huawei.com> for megaco@ietf.org; Wed, 08 Jan 2003 10:35:31 +0800 (CST) Date: Wed, 08 Jan 2003 10:38:35 +0800 From: zhaobo To: megaco@ietf.org Message-id: <000c01c2b6bf$0b0ceb40$ea486e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Content-type: multipart/mixed; boundary="Boundary_(ID_zKBzaYkC1wTgiynSPT+DSw)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Megaco] Inconsistence of "ansto" property in bcas package Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_zKBzaYkC1wTgiynSPT+DSw) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT Hi All: The property "ansto"(answer timeout) was deleted in draft-manyfolks-megaco-caspackage- 03.txt, but it is still metioned in the same draft(page 18): "A timeout is specified for the ansto property. " and in draft "draft-ietf-megaco-r2package-02.txt"(section 7.1): I guess it's a inconsitence? Regard Zhao Bo 2003/01/08 --Boundary_(ID_zKBzaYkC1wTgiynSPT+DSw) Content-type: text/x-vcard; name="Zhao Bo.vcf" Content-disposition: attachment; filename="Zhao Bo.vcf" Content-Transfer-Encoding: 7BIT BEGIN:VCARD VERSION:2.1 N:Zhao;Bo FN:Zhao Bo ORG:Huawei Technologies Co. Ltd ADR;WORK:;;;Beijing;;;China LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Beijing=0D=0AChina URL: URL:http://www.huawei.com EMAIL;PREF;INTERNET:zbo@huawei.com EMAIL;INTERNET:zbo@huawei.com REV:20030108T023835Z END:VCARD --Boundary_(ID_zKBzaYkC1wTgiynSPT+DSw)-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jan 8 09:17:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20560 for ; Wed, 8 Jan 2003 09:17:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08ES9J24802; Wed, 8 Jan 2003 09:28:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08ERNJ24768 for ; Wed, 8 Jan 2003 09:27:23 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20533 for ; Wed, 8 Jan 2003 09:15:37 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08EIku09876; Wed, 8 Jan 2003 09:18:47 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 09:18:47 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E107@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Carl Rutter'" , "'megaco@ietf.org'" Cc: Kang-Sen Lu Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 Date: Wed, 8 Jan 2003 09:18:45 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , I would agree with you. Wildcarding is only permitted in this case in the form of partially-specified names. Not sure how useful that is. > -----Original Message----- > From: Carl Rutter [mailto:crutter@telica.com] > Sent: Tuesday, January 07, 2003 11:37 AM > To: 'megaco@ietf.org' > Cc: Kang-Sen Lu > Subject: [Megaco] Question on Section 7.1.18 Megaco V2 > > > We need some clarifcation on the following statement: > > (T1, T2, oneway) means that the Terminations that match T2 > receive media from the Terminations matching T1, but not vice > versa. In this case use of the ALL wildcard such that there > are Terminations that match both T1 and T2 is not allowed. > > The line in question is "... such that there are Terminations > that match both T1 and T2 is not allowed" > > The way we read it this clause disproves the use of Wildcard > (*,T2,Oneway) becuase T2 will match * and T2. Hence the > statement "Terminations that match both T1 and T2 is not > allowed", excludes us from doing this. Is this correct? > > > Thx, > Carl > > Carl Rutter > Telica, Inc. > Building G, Suite 100 > 734 Forest Street > Marlboro, MA 01752 > Email crutter@telica.com > Voice 508-480-0909 x8178 > Fax 508-480-0922 > www.telica.com > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 8 09:18:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20685 for ; Wed, 8 Jan 2003 09:18:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08EU0Q24874 for megaco-archive@odin.ietf.org; Wed, 8 Jan 2003 09:30:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08EU0J24871 for ; Wed, 8 Jan 2003 09:30:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20574 for ; Wed, 8 Jan 2003 09:17:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08ES9J24802; Wed, 8 Jan 2003 09:28:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08ERNJ24768 for ; Wed, 8 Jan 2003 09:27:23 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20533 for ; Wed, 8 Jan 2003 09:15:37 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08EIku09876; Wed, 8 Jan 2003 09:18:47 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 09:18:47 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E107@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Carl Rutter'" , "'megaco@ietf.org'" Cc: Kang-Sen Lu Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 Date: Wed, 8 Jan 2003 09:18:45 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , I would agree with you. Wildcarding is only permitted in this case in the form of partially-specified names. Not sure how useful that is. > -----Original Message----- > From: Carl Rutter [mailto:crutter@telica.com] > Sent: Tuesday, January 07, 2003 11:37 AM > To: 'megaco@ietf.org' > Cc: Kang-Sen Lu > Subject: [Megaco] Question on Section 7.1.18 Megaco V2 > > > We need some clarifcation on the following statement: > > (T1, T2, oneway) means that the Terminations that match T2 > receive media from the Terminations matching T1, but not vice > versa. In this case use of the ALL wildcard such that there > are Terminations that match both T1 and T2 is not allowed. > > The line in question is "... such that there are Terminations > that match both T1 and T2 is not allowed" > > The way we read it this clause disproves the use of Wildcard > (*,T2,Oneway) becuase T2 will match * and T2. Hence the > statement "Terminations that match both T1 and T2 is not > allowed", excludes us from doing this. Is this correct? > > > Thx, > Carl > > Carl Rutter > Telica, Inc. > Building G, Suite 100 > 734 Forest Street > Marlboro, MA 01752 > Email crutter@telica.com > Voice 508-480-0909 x8178 > Fax 508-480-0922 > www.telica.com > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jan 8 09:25:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20916 for ; Wed, 8 Jan 2003 09:25:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08EaJJ25181; Wed, 8 Jan 2003 09:36:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08EZ3J25111 for ; Wed, 8 Jan 2003 09:35:03 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20843 for ; Wed, 8 Jan 2003 09:23:17 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08EQBu10584; Wed, 8 Jan 2003 09:26:12 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 09:26:12 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E108@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Garber, Zeev'" , megaco@ietf.org Subject: RE: [Megaco] Error handling on MG Date: Wed, 8 Jan 2003 09:26:12 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hello. See below marked with [PTT]. > -----Original Message----- > From: Garber, Zeev [mailto:zgarber@empirix.com] > Sent: Tuesday, January 07, 2003 3:06 PM > To: megaco@ietf.org > Subject: [Megaco] Error handling on MG > > > Hi All, > > Lets consider following scenario: > > MGC requests MG to Add physical and ephemeral($) terminations > to newly created context($). MG realizes that physical > termination is already added to another context. It responds > with AddReply containing Error Descriptor . > > 2 questions: > > What is a context Id in response for the first Add command: $ > or some new context Id? [PTT] I would certainly not use a specific context ID, since it is irrelevant. I am hesitating between $ for simplicity or null. We've already heard one vote for $. Any other opinions? > > What if Physical termination was successfully added to the > context but ephemeral wasn't (due to resource limitation for > example). What should be the ephemeral termination id in > response $ or some new termination Id? [PTT] Again, a specific termination ID would be irrelevant and misleading. Go with $. > > Thanks a lot, > > Ze`ev Garber > > Software Engineer > > Communications Infrastructure Test Group > > p| 978.661.1211 f| 978.988.0148 > > email | zgarber@empirix.com > > 205 Lowell Street | Wilmington, MA | 01887 > > E M P I R I X > > www.empirix.com > > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 8 09:26:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20963 for ; Wed, 8 Jan 2003 09:26:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08Ec4h25880 for megaco-archive@odin.ietf.org; Wed, 8 Jan 2003 09:38:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08Ec4J25877 for ; Wed, 8 Jan 2003 09:38:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20919 for ; Wed, 8 Jan 2003 09:25:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08EaJJ25181; Wed, 8 Jan 2003 09:36:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08EZ3J25111 for ; Wed, 8 Jan 2003 09:35:03 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20843 for ; Wed, 8 Jan 2003 09:23:17 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08EQBu10584; Wed, 8 Jan 2003 09:26:12 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 09:26:12 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E108@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Garber, Zeev'" , megaco@ietf.org Subject: RE: [Megaco] Error handling on MG Date: Wed, 8 Jan 2003 09:26:12 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hello. See below marked with [PTT]. > -----Original Message----- > From: Garber, Zeev [mailto:zgarber@empirix.com] > Sent: Tuesday, January 07, 2003 3:06 PM > To: megaco@ietf.org > Subject: [Megaco] Error handling on MG > > > Hi All, > > Lets consider following scenario: > > MGC requests MG to Add physical and ephemeral($) terminations > to newly created context($). MG realizes that physical > termination is already added to another context. It responds > with AddReply containing Error Descriptor . > > 2 questions: > > What is a context Id in response for the first Add command: $ > or some new context Id? [PTT] I would certainly not use a specific context ID, since it is irrelevant. I am hesitating between $ for simplicity or null. We've already heard one vote for $. Any other opinions? > > What if Physical termination was successfully added to the > context but ephemeral wasn't (due to resource limitation for > example). What should be the ephemeral termination id in > response $ or some new termination Id? [PTT] Again, a specific termination ID would be irrelevant and misleading. Go with $. > > Thanks a lot, > > Ze`ev Garber > > Software Engineer > > Communications Infrastructure Test Group > > p| 978.661.1211 f| 978.988.0148 > > email | zgarber@empirix.com > > 205 Lowell Street | Wilmington, MA | 01887 > > E M P I R I X > > www.empirix.com > > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jan 8 09:29:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21008 for ; Wed, 8 Jan 2003 09:29:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08Ee9J26029; Wed, 8 Jan 2003 09:40:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08EdOJ25936 for ; Wed, 8 Jan 2003 09:39:24 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20981 for ; Wed, 8 Jan 2003 09:27:38 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08EUlT05619; Wed, 8 Jan 2003 09:30:48 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 09:30:48 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E109@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Jackson.liu'" , megaco@ietf.org Subject: RE: [Megaco] Apply for RTP termination Date: Wed, 8 Jan 2003 09:30:47 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , The basic principle is that these attributes are described in Local, Remote, and possibly LocalControl. For example, VAD may be implicit in the payload type used. > -----Original Message----- > From: Jackson.liu [mailto:Jackson.liu@utstar.com] > Sent: Tuesday, January 07, 2003 10:42 PM > To: megaco@ietf.org > Subject: [Megaco] Apply for RTP termination > Importance: High > > > Hi, all: > When MGC want to apply a RTP termination, which has echo > cancelation and VAD or some other VOIP attributes, from MG. > How can I decrible the reqirements in the command to MG? > > Thanks & Regards > > Jackson > UTStarcom Ltd. SZ R&D Office. > 3/F, Legend Research & Developemnt Building, High-tect Industrial Park > Tel: (86-755)26983555-3599 > Fax: (86-755)26983786 > E-Mail: Jackson.liu@utstar.com > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 8 09:30:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21057 for ; Wed, 8 Jan 2003 09:30:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08EfeW26113 for megaco-archive@odin.ietf.org; Wed, 8 Jan 2003 09:41:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08EfdJ26110 for ; Wed, 8 Jan 2003 09:41:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21011 for ; Wed, 8 Jan 2003 09:29:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08Ee9J26029; Wed, 8 Jan 2003 09:40:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08EdOJ25936 for ; Wed, 8 Jan 2003 09:39:24 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20981 for ; Wed, 8 Jan 2003 09:27:38 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08EUlT05619; Wed, 8 Jan 2003 09:30:48 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 09:30:48 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E109@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Jackson.liu'" , megaco@ietf.org Subject: RE: [Megaco] Apply for RTP termination Date: Wed, 8 Jan 2003 09:30:47 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , The basic principle is that these attributes are described in Local, Remote, and possibly LocalControl. For example, VAD may be implicit in the payload type used. > -----Original Message----- > From: Jackson.liu [mailto:Jackson.liu@utstar.com] > Sent: Tuesday, January 07, 2003 10:42 PM > To: megaco@ietf.org > Subject: [Megaco] Apply for RTP termination > Importance: High > > > Hi, all: > When MGC want to apply a RTP termination, which has echo > cancelation and VAD or some other VOIP attributes, from MG. > How can I decrible the reqirements in the command to MG? > > Thanks & Regards > > Jackson > UTStarcom Ltd. SZ R&D Office. > 3/F, Legend Research & Developemnt Building, High-tect Industrial Park > Tel: (86-755)26983555-3599 > Fax: (86-755)26983786 > E-Mail: Jackson.liu@utstar.com > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jan 8 11:30:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23887 for ; Wed, 8 Jan 2003 11:30:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08Gf2J01790; Wed, 8 Jan 2003 11:41:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08GbrJ01515 for ; Wed, 8 Jan 2003 11:37:53 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23751 for ; Wed, 8 Jan 2003 11:26:05 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08GTDu04338; Wed, 8 Jan 2003 11:29:13 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 11:29:14 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E10D@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Kang-Sen Lu'" , Carl Rutter , "'megaco@ietf.org'" Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 Date: Wed, 8 Jan 2003 11:29:10 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Inline, marked with [PTT]. > -----Original Message----- > From: Kang-Sen Lu [mailto:ksenlu@telica.com] > Sent: Wednesday, January 08, 2003 9:48 AM > To: Taylor, Tom-PT [CAR:5N00:EXCH]; Carl Rutter; 'megaco@ietf.org' > Cc: Kang-Sen Lu > Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 > > > Dear Mr. Taylor: > > Thanks for your response. > > I have two questions for you. > > 1. If we meant to say (T1, T2, twoway), can we say (T1, T2, > oneway) and (T2, T1, oneway) instead? Since the document says > that (T1, T2, oneway) means that flow from T2 to T1 is not > allowed, I suppose we can not say (T1, T2, > oneway) and (T2, T1, oneway) at all. Right? [PTT] If you did say it, I believe the last-stated specification would prevail. > > 2. Any triplet of the form (X, X, Y), where X refers > termiantor ID(s), and Y refers association, is not very > useful and should be ignored by the MG without fear. Given > this, then (*, T2, oneway) then can be accepted to mean all > terminators, other than T2, to T2 is oneway and it is very > useful expression for describing T2 as a CALEA port. [PTT] Yes, it would be useful, but we would need agreement from the list. There is the problem that current implementations might not handle it properly. > > Any comments? > > Kang-sen > > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Wednesday, January 08, 2003 9:19 AM > To: 'Carl Rutter'; 'megaco@ietf.org' > Cc: Kang-Sen Lu > Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 > > > I would agree with you. Wildcarding is only permitted in > this case in the form of partially-specified names. Not sure > how useful that is. > > > -----Original Message----- > > From: Carl Rutter [mailto:crutter@telica.com] > > Sent: Tuesday, January 07, 2003 11:37 AM > > To: 'megaco@ietf.org' > > Cc: Kang-Sen Lu > > Subject: [Megaco] Question on Section 7.1.18 Megaco V2 > > > > > > We need some clarifcation on the following statement: > > > > (T1, T2, oneway) means that the Terminations that match T2 > > receive media from the Terminations matching T1, > but not vice > > versa. In this case use of the ALL wildcard such > that there > > are Terminations that match both T1 and T2 is not allowed. > > > > The line in question is "... such that there are Terminations > > that match both T1 and T2 is not allowed" > > > > The way we read it this clause disproves the use of Wildcard > > (*,T2,Oneway) becuase T2 will match * and T2. Hence the > > statement "Terminations that match both T1 and T2 is not > > allowed", excludes us from doing this. Is this correct? > > > > > > Thx, > > Carl > > > > Carl Rutter > > Telica, Inc. > > Building G, Suite 100 > > 734 Forest Street > > Marlboro, MA 01752 > > Email crutter@telica.com > > Voice 508-480-0909 x8178 > > Fax 508-480-0922 > > www.telica.com > > > > > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 8 11:31:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23967 for ; Wed, 8 Jan 2003 11:31:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08GgxW02024 for megaco-archive@odin.ietf.org; Wed, 8 Jan 2003 11:42:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08GgxJ02021 for ; Wed, 8 Jan 2003 11:42:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23891 for ; Wed, 8 Jan 2003 11:30:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08Gf2J01790; Wed, 8 Jan 2003 11:41:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08GbrJ01515 for ; Wed, 8 Jan 2003 11:37:53 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23751 for ; Wed, 8 Jan 2003 11:26:05 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08GTDu04338; Wed, 8 Jan 2003 11:29:13 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 11:29:14 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E10D@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Kang-Sen Lu'" , Carl Rutter , "'megaco@ietf.org'" Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 Date: Wed, 8 Jan 2003 11:29:10 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Inline, marked with [PTT]. > -----Original Message----- > From: Kang-Sen Lu [mailto:ksenlu@telica.com] > Sent: Wednesday, January 08, 2003 9:48 AM > To: Taylor, Tom-PT [CAR:5N00:EXCH]; Carl Rutter; 'megaco@ietf.org' > Cc: Kang-Sen Lu > Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 > > > Dear Mr. Taylor: > > Thanks for your response. > > I have two questions for you. > > 1. If we meant to say (T1, T2, twoway), can we say (T1, T2, > oneway) and (T2, T1, oneway) instead? Since the document says > that (T1, T2, oneway) means that flow from T2 to T1 is not > allowed, I suppose we can not say (T1, T2, > oneway) and (T2, T1, oneway) at all. Right? [PTT] If you did say it, I believe the last-stated specification would prevail. > > 2. Any triplet of the form (X, X, Y), where X refers > termiantor ID(s), and Y refers association, is not very > useful and should be ignored by the MG without fear. Given > this, then (*, T2, oneway) then can be accepted to mean all > terminators, other than T2, to T2 is oneway and it is very > useful expression for describing T2 as a CALEA port. [PTT] Yes, it would be useful, but we would need agreement from the list. There is the problem that current implementations might not handle it properly. > > Any comments? > > Kang-sen > > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Wednesday, January 08, 2003 9:19 AM > To: 'Carl Rutter'; 'megaco@ietf.org' > Cc: Kang-Sen Lu > Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 > > > I would agree with you. Wildcarding is only permitted in > this case in the form of partially-specified names. Not sure > how useful that is. > > > -----Original Message----- > > From: Carl Rutter [mailto:crutter@telica.com] > > Sent: Tuesday, January 07, 2003 11:37 AM > > To: 'megaco@ietf.org' > > Cc: Kang-Sen Lu > > Subject: [Megaco] Question on Section 7.1.18 Megaco V2 > > > > > > We need some clarifcation on the following statement: > > > > (T1, T2, oneway) means that the Terminations that match T2 > > receive media from the Terminations matching T1, > but not vice > > versa. In this case use of the ALL wildcard such > that there > > are Terminations that match both T1 and T2 is not allowed. > > > > The line in question is "... such that there are Terminations > > that match both T1 and T2 is not allowed" > > > > The way we read it this clause disproves the use of Wildcard > > (*,T2,Oneway) becuase T2 will match * and T2. Hence the > > statement "Terminations that match both T1 and T2 is not > > allowed", excludes us from doing this. Is this correct? > > > > > > Thx, > > Carl > > > > Carl Rutter > > Telica, Inc. > > Building G, Suite 100 > > 734 Forest Street > > Marlboro, MA 01752 > > Email crutter@telica.com > > Voice 508-480-0909 x8178 > > Fax 508-480-0922 > > www.telica.com > > > > > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jan 8 11:55:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24796 for ; Wed, 8 Jan 2003 11:55:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08H6aJ03738; Wed, 8 Jan 2003 12:06:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08H53J03663 for ; Wed, 8 Jan 2003 12:05:03 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24748 for ; Wed, 8 Jan 2003 11:53:15 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08GuJT20037; Wed, 8 Jan 2003 11:56:19 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 11:56:20 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E112@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Kang-Sen Lu'" , Carl Rutter , "'megaco@ietf.org'" Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 Date: Wed, 8 Jan 2003 11:56:18 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , The triplet covers only terminations currently in the context or added to it in the same action. Future terminations get bothway access to all pre-existing terminations, by default. > -----Original Message----- > From: Kang-Sen Lu [mailto:ksenlu@telica.com] > Sent: Wednesday, January 08, 2003 11:42 AM > To: Taylor, Tom-PT [CAR:5N00:EXCH]; Kang-Sen Lu; Carl Rutter; > 'megaco@ietf.org' > Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 > > > Dear Mr. Taylor: > > Thanks for the quick response. > > One more question: > > What is the current concensus about the meaning of a topology > triplet such as (*, T2, bothway)? especially the coverage of "*". > > Does it cover only the terminators currently added into the > specific context, or it can cover all the terminators current > in the context as well as ALL the termiantors to be added > into the context at later time as well? > > For example, if at the moment we have T1, T2 in the context. > Then (*, T2, > bothway) is processed by the MG. Then terminator T3 is added > to the context, then would that "*" covers T3 as well? > > Kang-sen > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Wednesday, January 08, 2003 11:29 AM > To: 'Kang-Sen Lu'; Carl Rutter; 'megaco@ietf.org' > Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 > > > Inline, marked with [PTT]. > > > -----Original Message----- > > From: Kang-Sen Lu [mailto:ksenlu@telica.com] > > Sent: Wednesday, January 08, 2003 9:48 AM > > To: Taylor, Tom-PT [CAR:5N00:EXCH]; Carl Rutter; 'megaco@ietf.org' > > Cc: Kang-Sen Lu > > Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 > > > > > > Dear Mr. Taylor: > > > > Thanks for your response. > > > > I have two questions for you. > > > > 1. If we meant to say (T1, T2, twoway), can we say (T1, T2, > > oneway) and (T2, T1, oneway) instead? Since the document says > > that (T1, T2, oneway) means that flow from T2 to T1 is not > > allowed, I suppose we can not say (T1, T2, > > oneway) and (T2, T1, oneway) at all. Right? > > [PTT] If you did say it, I believe the last-stated > specification would prevail. > > > > > 2. Any triplet of the form (X, X, Y), where X refers > > termiantor ID(s), and Y refers association, is not very > > useful and should be ignored by the MG without fear. Given > > this, then (*, T2, oneway) then can be accepted to mean all > > terminators, other than T2, to T2 is oneway and it is very > > useful expression for describing T2 as a CALEA port. > > [PTT] Yes, it would be useful, but we would need agreement > from the list. There is the problem that current > implementations might not handle it properly. > > > > > Any comments? > > > > Kang-sen > > > > > > -----Original Message----- > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > Sent: Wednesday, January 08, 2003 9:19 AM > > To: 'Carl Rutter'; 'megaco@ietf.org' > > Cc: Kang-Sen Lu > > Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 > > > > > > I would agree with you. Wildcarding is only permitted in > > this case in the form of partially-specified names. Not sure > > how useful that is. > > > > > -----Original Message----- > > > From: Carl Rutter [mailto:crutter@telica.com] > > > Sent: Tuesday, January 07, 2003 11:37 AM > > > To: 'megaco@ietf.org' > > > Cc: Kang-Sen Lu > > > Subject: [Megaco] Question on Section 7.1.18 Megaco V2 > > > > > > > > > We need some clarifcation on the following statement: > > > > > > (T1, T2, oneway) means that the Terminations that match T2 > > > receive media from the Terminations matching T1, > > but not vice > > > versa. In this case use of the ALL wildcard such > > that there > > > are Terminations that match both T1 and T2 is not allowed. > > > > > > The line in question is "... such that there are > Terminations that > > > match both T1 and T2 is not allowed" > > > > > > The way we read it this clause disproves the use of Wildcard > > > (*,T2,Oneway) becuase T2 will match * and T2. Hence the > > > statement "Terminations that match both T1 and T2 is not > > > allowed", excludes us from doing this. Is this correct? > > > > > > > > > Thx, > > > Carl > > > > > > Carl Rutter > > > Telica, Inc. > > > Building G, Suite 100 > > > 734 Forest Street > > > Marlboro, MA 01752 > > > Email crutter@telica.com > > > Voice 508-480-0909 x8178 > > > Fax 508-480-0922 > > > www.telica.com > > > > > > > > > > > > _______________________________________________ > > > Megaco mailing list > > > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > > > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 8 11:56:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24831 for ; Wed, 8 Jan 2003 11:56:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08H7kk04366 for megaco-archive@odin.ietf.org; Wed, 8 Jan 2003 12:07:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08H7kJ04363 for ; Wed, 8 Jan 2003 12:07:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24812 for ; Wed, 8 Jan 2003 11:55:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08H6aJ03738; Wed, 8 Jan 2003 12:06:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08H53J03663 for ; Wed, 8 Jan 2003 12:05:03 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24748 for ; Wed, 8 Jan 2003 11:53:15 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08GuJT20037; Wed, 8 Jan 2003 11:56:19 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 11:56:20 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E112@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Kang-Sen Lu'" , Carl Rutter , "'megaco@ietf.org'" Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 Date: Wed, 8 Jan 2003 11:56:18 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , The triplet covers only terminations currently in the context or added to it in the same action. Future terminations get bothway access to all pre-existing terminations, by default. > -----Original Message----- > From: Kang-Sen Lu [mailto:ksenlu@telica.com] > Sent: Wednesday, January 08, 2003 11:42 AM > To: Taylor, Tom-PT [CAR:5N00:EXCH]; Kang-Sen Lu; Carl Rutter; > 'megaco@ietf.org' > Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 > > > Dear Mr. Taylor: > > Thanks for the quick response. > > One more question: > > What is the current concensus about the meaning of a topology > triplet such as (*, T2, bothway)? especially the coverage of "*". > > Does it cover only the terminators currently added into the > specific context, or it can cover all the terminators current > in the context as well as ALL the termiantors to be added > into the context at later time as well? > > For example, if at the moment we have T1, T2 in the context. > Then (*, T2, > bothway) is processed by the MG. Then terminator T3 is added > to the context, then would that "*" covers T3 as well? > > Kang-sen > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Wednesday, January 08, 2003 11:29 AM > To: 'Kang-Sen Lu'; Carl Rutter; 'megaco@ietf.org' > Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 > > > Inline, marked with [PTT]. > > > -----Original Message----- > > From: Kang-Sen Lu [mailto:ksenlu@telica.com] > > Sent: Wednesday, January 08, 2003 9:48 AM > > To: Taylor, Tom-PT [CAR:5N00:EXCH]; Carl Rutter; 'megaco@ietf.org' > > Cc: Kang-Sen Lu > > Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 > > > > > > Dear Mr. Taylor: > > > > Thanks for your response. > > > > I have two questions for you. > > > > 1. If we meant to say (T1, T2, twoway), can we say (T1, T2, > > oneway) and (T2, T1, oneway) instead? Since the document says > > that (T1, T2, oneway) means that flow from T2 to T1 is not > > allowed, I suppose we can not say (T1, T2, > > oneway) and (T2, T1, oneway) at all. Right? > > [PTT] If you did say it, I believe the last-stated > specification would prevail. > > > > > 2. Any triplet of the form (X, X, Y), where X refers > > termiantor ID(s), and Y refers association, is not very > > useful and should be ignored by the MG without fear. Given > > this, then (*, T2, oneway) then can be accepted to mean all > > terminators, other than T2, to T2 is oneway and it is very > > useful expression for describing T2 as a CALEA port. > > [PTT] Yes, it would be useful, but we would need agreement > from the list. There is the problem that current > implementations might not handle it properly. > > > > > Any comments? > > > > Kang-sen > > > > > > -----Original Message----- > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > Sent: Wednesday, January 08, 2003 9:19 AM > > To: 'Carl Rutter'; 'megaco@ietf.org' > > Cc: Kang-Sen Lu > > Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 > > > > > > I would agree with you. Wildcarding is only permitted in > > this case in the form of partially-specified names. Not sure > > how useful that is. > > > > > -----Original Message----- > > > From: Carl Rutter [mailto:crutter@telica.com] > > > Sent: Tuesday, January 07, 2003 11:37 AM > > > To: 'megaco@ietf.org' > > > Cc: Kang-Sen Lu > > > Subject: [Megaco] Question on Section 7.1.18 Megaco V2 > > > > > > > > > We need some clarifcation on the following statement: > > > > > > (T1, T2, oneway) means that the Terminations that match T2 > > > receive media from the Terminations matching T1, > > but not vice > > > versa. In this case use of the ALL wildcard such > > that there > > > are Terminations that match both T1 and T2 is not allowed. > > > > > > The line in question is "... such that there are > Terminations that > > > match both T1 and T2 is not allowed" > > > > > > The way we read it this clause disproves the use of Wildcard > > > (*,T2,Oneway) becuase T2 will match * and T2. Hence the > > > statement "Terminations that match both T1 and T2 is not > > > allowed", excludes us from doing this. Is this correct? > > > > > > > > > Thx, > > > Carl > > > > > > Carl Rutter > > > Telica, Inc. > > > Building G, Suite 100 > > > 734 Forest Street > > > Marlboro, MA 01752 > > > Email crutter@telica.com > > > Voice 508-480-0909 x8178 > > > Fax 508-480-0922 > > > www.telica.com > > > > > > > > > > > > _______________________________________________ > > > Megaco mailing list > > > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > > > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jan 8 12:44:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27789 for ; Wed, 8 Jan 2003 12:44:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08HtiJ07615; Wed, 8 Jan 2003 12:55:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08ExvJ26890 for ; Wed, 8 Jan 2003 09:59:57 -0500 Received: from wench.telica.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21369 for ; Wed, 8 Jan 2003 09:48:11 -0500 (EST) Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 09:48:17 -0500 Message-ID: From: Kang-Sen Lu To: "'Tom-PT Taylor'" , Carl Rutter , "'megaco@ietf.org'" Cc: Kang-Sen Lu Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 Date: Wed, 8 Jan 2003 09:48:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Dear Mr. Taylor: Thanks for your response. I have two questions for you. 1. If we meant to say (T1, T2, twoway), can we say (T1, T2, oneway) and (T2, T1, oneway) instead? Since the document says that (T1, T2, oneway) means that flow from T2 to T1 is not allowed, I suppose we can not say (T1, T2, oneway) and (T2, T1, oneway) at all. Right? 2. Any triplet of the form (X, X, Y), where X refers termiantor ID(s), and Y refers association, is not very useful and should be ignored by the MG without fear. Given this, then (*, T2, oneway) then can be accepted to mean all terminators, other than T2, to T2 is oneway and it is very useful expression for describing T2 as a CALEA port. Any comments? Kang-sen -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Wednesday, January 08, 2003 9:19 AM To: 'Carl Rutter'; 'megaco@ietf.org' Cc: Kang-Sen Lu Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 I would agree with you. Wildcarding is only permitted in this case in the form of partially-specified names. Not sure how useful that is. > -----Original Message----- > From: Carl Rutter [mailto:crutter@telica.com] > Sent: Tuesday, January 07, 2003 11:37 AM > To: 'megaco@ietf.org' > Cc: Kang-Sen Lu > Subject: [Megaco] Question on Section 7.1.18 Megaco V2 > > > We need some clarifcation on the following statement: > > (T1, T2, oneway) means that the Terminations that match T2 > receive media from the Terminations matching T1, but not vice > versa. In this case use of the ALL wildcard such that there > are Terminations that match both T1 and T2 is not allowed. > > The line in question is "... such that there are Terminations > that match both T1 and T2 is not allowed" > > The way we read it this clause disproves the use of Wildcard > (*,T2,Oneway) becuase T2 will match * and T2. Hence the > statement "Terminations that match both T1 and T2 is not > allowed", excludes us from doing this. Is this correct? > > > Thx, > Carl > > Carl Rutter > Telica, Inc. > Building G, Suite 100 > 734 Forest Street > Marlboro, MA 01752 > Email crutter@telica.com > Voice 508-480-0909 x8178 > Fax 508-480-0922 > www.telica.com > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jan 8 12:44:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27812 for ; Wed, 8 Jan 2003 12:44:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08HtoJ07637; Wed, 8 Jan 2003 12:55:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08Gs6J02693 for ; Wed, 8 Jan 2003 11:54:06 -0500 Received: from wench.telica.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24450 for ; Wed, 8 Jan 2003 11:42:18 -0500 (EST) Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 11:42:22 -0500 Message-ID: From: Kang-Sen Lu To: "'Tom-PT Taylor'" , Kang-Sen Lu , Carl Rutter , "'megaco@ietf.org'" Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 Date: Wed, 8 Jan 2003 11:42:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Dear Mr. Taylor: Thanks for the quick response. One more question: What is the current concensus about the meaning of a topology triplet such as (*, T2, bothway)? especially the coverage of "*". Does it cover only the terminators currently added into the specific context, or it can cover all the terminators current in the context as well as ALL the termiantors to be added into the context at later time as well? For example, if at the moment we have T1, T2 in the context. Then (*, T2, bothway) is processed by the MG. Then terminator T3 is added to the context, then would that "*" covers T3 as well? Kang-sen -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Wednesday, January 08, 2003 11:29 AM To: 'Kang-Sen Lu'; Carl Rutter; 'megaco@ietf.org' Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 Inline, marked with [PTT]. > -----Original Message----- > From: Kang-Sen Lu [mailto:ksenlu@telica.com] > Sent: Wednesday, January 08, 2003 9:48 AM > To: Taylor, Tom-PT [CAR:5N00:EXCH]; Carl Rutter; 'megaco@ietf.org' > Cc: Kang-Sen Lu > Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 > > > Dear Mr. Taylor: > > Thanks for your response. > > I have two questions for you. > > 1. If we meant to say (T1, T2, twoway), can we say (T1, T2, > oneway) and (T2, T1, oneway) instead? Since the document says > that (T1, T2, oneway) means that flow from T2 to T1 is not > allowed, I suppose we can not say (T1, T2, > oneway) and (T2, T1, oneway) at all. Right? [PTT] If you did say it, I believe the last-stated specification would prevail. > > 2. Any triplet of the form (X, X, Y), where X refers > termiantor ID(s), and Y refers association, is not very > useful and should be ignored by the MG without fear. Given > this, then (*, T2, oneway) then can be accepted to mean all > terminators, other than T2, to T2 is oneway and it is very > useful expression for describing T2 as a CALEA port. [PTT] Yes, it would be useful, but we would need agreement from the list. There is the problem that current implementations might not handle it properly. > > Any comments? > > Kang-sen > > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Wednesday, January 08, 2003 9:19 AM > To: 'Carl Rutter'; 'megaco@ietf.org' > Cc: Kang-Sen Lu > Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 > > > I would agree with you. Wildcarding is only permitted in > this case in the form of partially-specified names. Not sure > how useful that is. > > > -----Original Message----- > > From: Carl Rutter [mailto:crutter@telica.com] > > Sent: Tuesday, January 07, 2003 11:37 AM > > To: 'megaco@ietf.org' > > Cc: Kang-Sen Lu > > Subject: [Megaco] Question on Section 7.1.18 Megaco V2 > > > > > > We need some clarifcation on the following statement: > > > > (T1, T2, oneway) means that the Terminations that match T2 > > receive media from the Terminations matching T1, > but not vice > > versa. In this case use of the ALL wildcard such > that there > > are Terminations that match both T1 and T2 is not allowed. > > > > The line in question is "... such that there are Terminations > > that match both T1 and T2 is not allowed" > > > > The way we read it this clause disproves the use of Wildcard > > (*,T2,Oneway) becuase T2 will match * and T2. Hence the > > statement "Terminations that match both T1 and T2 is not > > allowed", excludes us from doing this. Is this correct? > > > > > > Thx, > > Carl > > > > Carl Rutter > > Telica, Inc. > > Building G, Suite 100 > > 734 Forest Street > > Marlboro, MA 01752 > > Email crutter@telica.com > > Voice 508-480-0909 x8178 > > Fax 508-480-0922 > > www.telica.com > > > > > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 8 12:45:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27911 for ; Wed, 8 Jan 2003 12:45:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08Huib08275 for megaco-archive@odin.ietf.org; Wed, 8 Jan 2003 12:56:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08HuiJ08272 for ; Wed, 8 Jan 2003 12:56:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27795 for ; Wed, 8 Jan 2003 12:44:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08HtiJ07615; Wed, 8 Jan 2003 12:55:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08ExvJ26890 for ; Wed, 8 Jan 2003 09:59:57 -0500 Received: from wench.telica.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21369 for ; Wed, 8 Jan 2003 09:48:11 -0500 (EST) Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 09:48:17 -0500 Message-ID: From: Kang-Sen Lu To: "'Tom-PT Taylor'" , Carl Rutter , "'megaco@ietf.org'" Cc: Kang-Sen Lu Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 Date: Wed, 8 Jan 2003 09:48:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Dear Mr. Taylor: Thanks for your response. I have two questions for you. 1. If we meant to say (T1, T2, twoway), can we say (T1, T2, oneway) and (T2, T1, oneway) instead? Since the document says that (T1, T2, oneway) means that flow from T2 to T1 is not allowed, I suppose we can not say (T1, T2, oneway) and (T2, T1, oneway) at all. Right? 2. Any triplet of the form (X, X, Y), where X refers termiantor ID(s), and Y refers association, is not very useful and should be ignored by the MG without fear. Given this, then (*, T2, oneway) then can be accepted to mean all terminators, other than T2, to T2 is oneway and it is very useful expression for describing T2 as a CALEA port. Any comments? Kang-sen -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Wednesday, January 08, 2003 9:19 AM To: 'Carl Rutter'; 'megaco@ietf.org' Cc: Kang-Sen Lu Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 I would agree with you. Wildcarding is only permitted in this case in the form of partially-specified names. Not sure how useful that is. > -----Original Message----- > From: Carl Rutter [mailto:crutter@telica.com] > Sent: Tuesday, January 07, 2003 11:37 AM > To: 'megaco@ietf.org' > Cc: Kang-Sen Lu > Subject: [Megaco] Question on Section 7.1.18 Megaco V2 > > > We need some clarifcation on the following statement: > > (T1, T2, oneway) means that the Terminations that match T2 > receive media from the Terminations matching T1, but not vice > versa. In this case use of the ALL wildcard such that there > are Terminations that match both T1 and T2 is not allowed. > > The line in question is "... such that there are Terminations > that match both T1 and T2 is not allowed" > > The way we read it this clause disproves the use of Wildcard > (*,T2,Oneway) becuase T2 will match * and T2. Hence the > statement "Terminations that match both T1 and T2 is not > allowed", excludes us from doing this. Is this correct? > > > Thx, > Carl > > Carl Rutter > Telica, Inc. > Building G, Suite 100 > 734 Forest Street > Marlboro, MA 01752 > Email crutter@telica.com > Voice 508-480-0909 x8178 > Fax 508-480-0922 > www.telica.com > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 8 12:45:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27939 for ; Wed, 8 Jan 2003 12:45:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08HumZ08339 for megaco-archive@odin.ietf.org; Wed, 8 Jan 2003 12:56:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08HumJ08336 for ; Wed, 8 Jan 2003 12:56:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27840 for ; Wed, 8 Jan 2003 12:44:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08HtoJ07637; Wed, 8 Jan 2003 12:55:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08Gs6J02693 for ; Wed, 8 Jan 2003 11:54:06 -0500 Received: from wench.telica.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24450 for ; Wed, 8 Jan 2003 11:42:18 -0500 (EST) Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 11:42:22 -0500 Message-ID: From: Kang-Sen Lu To: "'Tom-PT Taylor'" , Kang-Sen Lu , Carl Rutter , "'megaco@ietf.org'" Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 Date: Wed, 8 Jan 2003 11:42:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Dear Mr. Taylor: Thanks for the quick response. One more question: What is the current concensus about the meaning of a topology triplet such as (*, T2, bothway)? especially the coverage of "*". Does it cover only the terminators currently added into the specific context, or it can cover all the terminators current in the context as well as ALL the termiantors to be added into the context at later time as well? For example, if at the moment we have T1, T2 in the context. Then (*, T2, bothway) is processed by the MG. Then terminator T3 is added to the context, then would that "*" covers T3 as well? Kang-sen -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Wednesday, January 08, 2003 11:29 AM To: 'Kang-Sen Lu'; Carl Rutter; 'megaco@ietf.org' Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 Inline, marked with [PTT]. > -----Original Message----- > From: Kang-Sen Lu [mailto:ksenlu@telica.com] > Sent: Wednesday, January 08, 2003 9:48 AM > To: Taylor, Tom-PT [CAR:5N00:EXCH]; Carl Rutter; 'megaco@ietf.org' > Cc: Kang-Sen Lu > Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 > > > Dear Mr. Taylor: > > Thanks for your response. > > I have two questions for you. > > 1. If we meant to say (T1, T2, twoway), can we say (T1, T2, > oneway) and (T2, T1, oneway) instead? Since the document says > that (T1, T2, oneway) means that flow from T2 to T1 is not > allowed, I suppose we can not say (T1, T2, > oneway) and (T2, T1, oneway) at all. Right? [PTT] If you did say it, I believe the last-stated specification would prevail. > > 2. Any triplet of the form (X, X, Y), where X refers > termiantor ID(s), and Y refers association, is not very > useful and should be ignored by the MG without fear. Given > this, then (*, T2, oneway) then can be accepted to mean all > terminators, other than T2, to T2 is oneway and it is very > useful expression for describing T2 as a CALEA port. [PTT] Yes, it would be useful, but we would need agreement from the list. There is the problem that current implementations might not handle it properly. > > Any comments? > > Kang-sen > > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Wednesday, January 08, 2003 9:19 AM > To: 'Carl Rutter'; 'megaco@ietf.org' > Cc: Kang-Sen Lu > Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 > > > I would agree with you. Wildcarding is only permitted in > this case in the form of partially-specified names. Not sure > how useful that is. > > > -----Original Message----- > > From: Carl Rutter [mailto:crutter@telica.com] > > Sent: Tuesday, January 07, 2003 11:37 AM > > To: 'megaco@ietf.org' > > Cc: Kang-Sen Lu > > Subject: [Megaco] Question on Section 7.1.18 Megaco V2 > > > > > > We need some clarifcation on the following statement: > > > > (T1, T2, oneway) means that the Terminations that match T2 > > receive media from the Terminations matching T1, > but not vice > > versa. In this case use of the ALL wildcard such > that there > > are Terminations that match both T1 and T2 is not allowed. > > > > The line in question is "... such that there are Terminations > > that match both T1 and T2 is not allowed" > > > > The way we read it this clause disproves the use of Wildcard > > (*,T2,Oneway) becuase T2 will match * and T2. Hence the > > statement "Terminations that match both T1 and T2 is not > > allowed", excludes us from doing this. Is this correct? > > > > > > Thx, > > Carl > > > > Carl Rutter > > Telica, Inc. > > Building G, Suite 100 > > 734 Forest Street > > Marlboro, MA 01752 > > Email crutter@telica.com > > Voice 508-480-0909 x8178 > > Fax 508-480-0922 > > www.telica.com > > > > > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jan 8 15:53:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06875 for ; Wed, 8 Jan 2003 15:53:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08L4fJ20893; Wed, 8 Jan 2003 16:04:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08Kt6J20550 for ; Wed, 8 Jan 2003 15:55:06 -0500 Received: from wench.telica.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06565 for ; Wed, 8 Jan 2003 15:43:12 -0500 (EST) Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 15:43:18 -0500 Message-ID: From: Carl Rutter To: "'megaco@ietf.org'" Date: Wed, 8 Jan 2003 15:43:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Megaco] Dynamic Codec Support Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Could someone direct me to the latest information on Dynamic Codec Support. Thx, Carl Carl Rutter Telica, Inc. Building G, Suite 100 734 Forest Street Marlboro, MA 01752 Email crutter@telica.com Voice 508-480-0909 x8178 Fax 508-480-0922 www.telica.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 8 15:54:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06922 for ; Wed, 8 Jan 2003 15:54:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08L64E21096 for megaco-archive@odin.ietf.org; Wed, 8 Jan 2003 16:06:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08L64J21093 for ; Wed, 8 Jan 2003 16:06:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06878 for ; Wed, 8 Jan 2003 15:53:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08L4fJ20893; Wed, 8 Jan 2003 16:04:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08Kt6J20550 for ; Wed, 8 Jan 2003 15:55:06 -0500 Received: from wench.telica.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06565 for ; Wed, 8 Jan 2003 15:43:12 -0500 (EST) Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 15:43:18 -0500 Message-ID: From: Carl Rutter To: "'megaco@ietf.org'" Date: Wed, 8 Jan 2003 15:43:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Megaco] Dynamic Codec Support Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Could someone direct me to the latest information on Dynamic Codec Support. Thx, Carl Carl Rutter Telica, Inc. Building G, Suite 100 734 Forest Street Marlboro, MA 01752 Email crutter@telica.com Voice 508-480-0909 x8178 Fax 508-480-0922 www.telica.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jan 9 11:20:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16506 for ; Thu, 9 Jan 2003 11:20:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09GVkJ03457; Thu, 9 Jan 2003 11:31:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09GTpJ03311 for ; Thu, 9 Jan 2003 11:29:51 -0500 Received: from mink.ecitele.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16374 for ; Thu, 9 Jan 2003 11:17:34 -0500 (EST) From: Dana.Herskowitz@ecitele.com Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id SAA18724 for ; Thu, 9 Jan 2003 18:15:36 +0200 (IST) To: megaco@ietf.org Cc: Eli.Liluz@ecitele.com, Ilana.Leibovitch@ecitele.com, Meir.Leshem@ecitele.com, Oded.Katz@ecitele.com, Benny.Lavi@ecitele.com X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Thu, 9 Jan 2003 18:20:47 +0200 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 01/09/2003 06:20:49 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Megaco] Events accumulating and events notification Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, 1) According to RFC3015: The EventBuffer Descriptor contains a list of events, with their parameters if any, that the MG is requested to detect and buffer when EventBufferControl equals LockStep Does it actually mean that control property Off disables the accumulating completely? 2) When control property equals LockStep, should the MG wait for Notify reply (Like in MGCP) in order to process the next accumulated event or only wait for a new eventsDescriptor? In this case, should waiting for a new eventDescriptor after sending each Notify is mandatory? Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jan 9 11:22:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16589 for ; Thu, 9 Jan 2003 11:22:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09GXra03603 for megaco-archive@odin.ietf.org; Thu, 9 Jan 2003 11:33:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09GXrJ03600 for ; Thu, 9 Jan 2003 11:33:53 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16510 for ; Thu, 9 Jan 2003 11:20:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09GVkJ03457; Thu, 9 Jan 2003 11:31:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09GTpJ03311 for ; Thu, 9 Jan 2003 11:29:51 -0500 Received: from mink.ecitele.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16374 for ; Thu, 9 Jan 2003 11:17:34 -0500 (EST) From: Dana.Herskowitz@ecitele.com Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id SAA18724 for ; Thu, 9 Jan 2003 18:15:36 +0200 (IST) To: megaco@ietf.org Cc: Eli.Liluz@ecitele.com, Ilana.Leibovitch@ecitele.com, Meir.Leshem@ecitele.com, Oded.Katz@ecitele.com, Benny.Lavi@ecitele.com X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Thu, 9 Jan 2003 18:20:47 +0200 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 01/09/2003 06:20:49 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Megaco] Events accumulating and events notification Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, 1) According to RFC3015: The EventBuffer Descriptor contains a list of events, with their parameters if any, that the MG is requested to detect and buffer when EventBufferControl equals LockStep Does it actually mean that control property Off disables the accumulating completely? 2) When control property equals LockStep, should the MG wait for Notify reply (Like in MGCP) in order to process the next accumulated event or only wait for a new eventsDescriptor? In this case, should waiting for a new eventDescriptor after sending each Notify is mandatory? Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jan 9 12:45:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18742 for ; Thu, 9 Jan 2003 12:45:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09HtHJ09547; Thu, 9 Jan 2003 12:55:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09Hk5J09235 for ; Thu, 9 Jan 2003 12:46:05 -0500 Received: from zrtps0kn.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18517 for ; Thu, 9 Jan 2003 12:33:47 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h09Hb3v02631 for ; Thu, 9 Jan 2003 12:37:03 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 12:37:03 -0500 Message-ID: From: "Kevin Boyle" To: Dana.Herskowitz@ecitele.com, megaco@ietf.org Cc: Eli.Liluz@ecitele.com, Ilana.Leibovitch@ecitele.com, Meir.Leshem@ecitele.com, Oded.Katz@ecitele.com, Benny.Lavi@ecitele.com Subject: RE: [Megaco] Events accumulating and events notification Date: Thu, 9 Jan 2003 12:37:01 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Comments inline. [KJBII] Kevin -----Original Message----- From: Dana.Herskowitz@ecitele.com [mailto:Dana.Herskowitz@ecitele.com] Sent: Thursday, January 09, 2003 11:21 AM To: megaco@ietf.org Cc: Eli.Liluz@ecitele.com; Ilana.Leibovitch@ecitele.com; Meir.Leshem@ecitele.com; Oded.Katz@ecitele.com; Benny.Lavi@ecitele.com Subject: [Megaco] Events accumulating and events notification Hello, 1) According to RFC3015: The EventBuffer Descriptor contains a list of events, with their parameters if any, that the MG is requested to detect and buffer when EventBufferControl equals LockStep Does it actually mean that control property Off disables the accumulating completely? [KJBII] Correct. 2) When control property equals LockStep, should the MG wait for Notify reply (Like in MGCP) in order to process the next accumulated event or only wait for a new eventsDescriptor? [KJBII] It must wait for a new Events Descriptor. In this case, should waiting for a new eventDescriptor after sending each Notify is mandatory? [KJBII] Yes. Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jan 9 12:49:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18866 for ; Thu, 9 Jan 2003 12:49:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09I1XC09897 for megaco-archive@odin.ietf.org; Thu, 9 Jan 2003 13:01:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09I1WJ09894 for ; Thu, 9 Jan 2003 13:01:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18747 for ; Thu, 9 Jan 2003 12:45:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09HtHJ09547; Thu, 9 Jan 2003 12:55:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09Hk5J09235 for ; Thu, 9 Jan 2003 12:46:05 -0500 Received: from zrtps0kn.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18517 for ; Thu, 9 Jan 2003 12:33:47 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h09Hb3v02631 for ; Thu, 9 Jan 2003 12:37:03 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 12:37:03 -0500 Message-ID: From: "Kevin Boyle" To: Dana.Herskowitz@ecitele.com, megaco@ietf.org Cc: Eli.Liluz@ecitele.com, Ilana.Leibovitch@ecitele.com, Meir.Leshem@ecitele.com, Oded.Katz@ecitele.com, Benny.Lavi@ecitele.com Subject: RE: [Megaco] Events accumulating and events notification Date: Thu, 9 Jan 2003 12:37:01 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Comments inline. [KJBII] Kevin -----Original Message----- From: Dana.Herskowitz@ecitele.com [mailto:Dana.Herskowitz@ecitele.com] Sent: Thursday, January 09, 2003 11:21 AM To: megaco@ietf.org Cc: Eli.Liluz@ecitele.com; Ilana.Leibovitch@ecitele.com; Meir.Leshem@ecitele.com; Oded.Katz@ecitele.com; Benny.Lavi@ecitele.com Subject: [Megaco] Events accumulating and events notification Hello, 1) According to RFC3015: The EventBuffer Descriptor contains a list of events, with their parameters if any, that the MG is requested to detect and buffer when EventBufferControl equals LockStep Does it actually mean that control property Off disables the accumulating completely? [KJBII] Correct. 2) When control property equals LockStep, should the MG wait for Notify reply (Like in MGCP) in order to process the next accumulated event or only wait for a new eventsDescriptor? [KJBII] It must wait for a new Events Descriptor. In this case, should waiting for a new eventDescriptor after sending each Notify is mandatory? [KJBII] Yes. Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jan 9 13:25:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19940 for ; Thu, 9 Jan 2003 13:25:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IaUJ12413; Thu, 9 Jan 2003 13:36:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IZWJ12369 for ; Thu, 9 Jan 2003 13:35:32 -0500 Received: from exchange.td-soft.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19892 for ; Thu, 9 Jan 2003 13:23:12 -0500 (EST) Received: through eSafe SMTP Relay 1042120120; Thu Jan 09 20:37:44 2003 Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 20:24:36 +0200 Message-ID: From: Raphael Tryster To: Kevin Boyle , Dana.Herskowitz@ecitele.com, megaco@ietf.org Subject: RE: [Megaco] Events accumulating and events notification Date: Thu, 9 Jan 2003 20:24:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B80C.5C2B38D0" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2B80C.5C2B38D0 Content-Type: text/plain Kevin, I would like to verify that Off disables accumulating in the sense that events are handled immediately according to the latest event descriptor, not in the sense that they are thrown away. Would it be fair to say that Megaco LockStep = MGCP Step, and Megaco Off = MGCP Loop? Thank you, Raphael Tryster -----Original Message----- From: Kevin Boyle [SMTP:kboyle@nortelnetworks.com] Sent: Thursday, 09 January, 2003 7:37 PM To: Dana.Herskowitz@ecitele.com; megaco@ietf.org Cc: Eli.Liluz@ecitele.com; Ilana.Leibovitch@ecitele.com; Meir.Leshem@ecitele.com; Oded.Katz@ecitele.com; Benny.Lavi@ecitele.com Subject: RE: [Megaco] Events accumulating and events notification Comments inline. [KJBII] Kevin -----Original Message----- From: Dana.Herskowitz@ecitele.com [mailto:Dana.Herskowitz@ecitele.com] Sent: Thursday, January 09, 2003 11:21 AM To: megaco@ietf.org Cc: Eli.Liluz@ecitele.com; Ilana.Leibovitch@ecitele.com; Meir.Leshem@ecitele.com; Oded.Katz@ecitele.com; Benny.Lavi@ecitele.com Subject: [Megaco] Events accumulating and events notification Hello, 1) According to RFC3015: The EventBuffer Descriptor contains a list of events, with their parameters if any, that the MG is requested to detect and buffer when EventBufferControl equals LockStep Does it actually mean that control property Off disables the accumulating completely? [KJBII] Correct. 2) When control property equals LockStep, should the MG wait for Notify reply (Like in MGCP) in order to process the next accumulated event or only wait for a new eventsDescriptor? [KJBII] It must wait for a new Events Descriptor. In this case, should waiting for a new eventDescriptor after sending each Notify is mandatory? [KJBII] Yes. Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C2B80C.5C2B38D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Megaco] Events accumulating and events notification

Kevin,

I would like to verify that Off disables= accumulating in the sense that events are handled immediately according = to the latest event descriptor, not in the sense that they are thrown awa= y.

Would it be fair to say that Megaco Lock= Step =3D MGCP Step, and Megaco Off =3D MGCP Loop?

Thank you,

Raphael Tryster

    -----Original Mess= age-----
    From:   Kevin Boyle [SMTP:= kboyle@nortelnetworks.com]
    Sent:   Thursday, 09 January, 2003 7:37 PM
    To:     Dana.Herskowitz@ecitele.com; megaco@ietf= =2Eorg
    Cc:     Eli.Liluz@ecitele.com; Ilana.Leibovitch@= ecitele.com; Meir.Leshem@ecitele.com; Oded.Katz@ecitele.com; Benny.Lavi@e= citele.com

    Subject:     = ;   RE: [Megaco] Event= s accumulating and events notification

    Comments inline. [KJBII]

    Kevin

    -----Original Message-----
    From: Dana.Herskowitz@ecitele.com= [mailto:Dana.Herskowitz@e= citele.com]
    Sent: Thursday, January 09, 2003 = 11:21 AM
    To: megaco@ietf.org
    Cc: Eli.Liluz@ecitele.com; Ilana.= Leibovitch@ecitele.com;
    Meir.Leshem@ecitele.com; Oded.Kat= z@ecitele.com; Benny.Lavi@ecitele.com
    Subject: [Megaco] Events accumula= ting and events notification



    Hello,

    1) According to RFC3015:
          Th= e EventBuffer Descriptor contains a list of events, with their
    parameters if any, that the MG is= requested to detect and buffer when
    EventBufferControl equals LockSte= p Does it actually mean that control
    property Off disables the accumul= ating completely?

    [KJBII] Correct.


    2) When control property equals Lo= ckStep, should the MG wait for Notify
    reply (Like in MGCP) in order to = process the next accumulated event or only
    wait for a new eventsDescriptor?<= /FONT>

    [KJBII] It must wait for a new Eve= nts Descriptor.
     
    In this case, should waiting for = a new eventDescriptor after sending each
    Notify is mandatory?

    [KJBII] Yes.

    Regards,

    Dana H.


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

------_=_NextPart_001_01C2B80C.5C2B38D0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jan 9 13:25:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19997 for ; Thu, 9 Jan 2003 13:25:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09Iblp13098 for megaco-archive@odin.ietf.org; Thu, 9 Jan 2003 13:37:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IblJ13095 for ; Thu, 9 Jan 2003 13:37:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19944 for ; Thu, 9 Jan 2003 13:25:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IaUJ12413; Thu, 9 Jan 2003 13:36:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IZWJ12369 for ; Thu, 9 Jan 2003 13:35:32 -0500 Received: from exchange.td-soft.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19892 for ; Thu, 9 Jan 2003 13:23:12 -0500 (EST) Received: through eSafe SMTP Relay 1042120120; Thu Jan 09 20:37:44 2003 Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 20:24:36 +0200 Message-ID: From: Raphael Tryster To: Kevin Boyle , Dana.Herskowitz@ecitele.com, megaco@ietf.org Subject: RE: [Megaco] Events accumulating and events notification Date: Thu, 9 Jan 2003 20:24:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B80C.5C2B38D0" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2B80C.5C2B38D0 Content-Type: text/plain Kevin, I would like to verify that Off disables accumulating in the sense that events are handled immediately according to the latest event descriptor, not in the sense that they are thrown away. Would it be fair to say that Megaco LockStep = MGCP Step, and Megaco Off = MGCP Loop? Thank you, Raphael Tryster -----Original Message----- From: Kevin Boyle [SMTP:kboyle@nortelnetworks.com] Sent: Thursday, 09 January, 2003 7:37 PM To: Dana.Herskowitz@ecitele.com; megaco@ietf.org Cc: Eli.Liluz@ecitele.com; Ilana.Leibovitch@ecitele.com; Meir.Leshem@ecitele.com; Oded.Katz@ecitele.com; Benny.Lavi@ecitele.com Subject: RE: [Megaco] Events accumulating and events notification Comments inline. [KJBII] Kevin -----Original Message----- From: Dana.Herskowitz@ecitele.com [mailto:Dana.Herskowitz@ecitele.com] Sent: Thursday, January 09, 2003 11:21 AM To: megaco@ietf.org Cc: Eli.Liluz@ecitele.com; Ilana.Leibovitch@ecitele.com; Meir.Leshem@ecitele.com; Oded.Katz@ecitele.com; Benny.Lavi@ecitele.com Subject: [Megaco] Events accumulating and events notification Hello, 1) According to RFC3015: The EventBuffer Descriptor contains a list of events, with their parameters if any, that the MG is requested to detect and buffer when EventBufferControl equals LockStep Does it actually mean that control property Off disables the accumulating completely? [KJBII] Correct. 2) When control property equals LockStep, should the MG wait for Notify reply (Like in MGCP) in order to process the next accumulated event or only wait for a new eventsDescriptor? [KJBII] It must wait for a new Events Descriptor. In this case, should waiting for a new eventDescriptor after sending each Notify is mandatory? [KJBII] Yes. Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C2B80C.5C2B38D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Megaco] Events accumulating and events notification

Kevin,

I would like to verify that Off disables= accumulating in the sense that events are handled immediately according = to the latest event descriptor, not in the sense that they are thrown awa= y.

Would it be fair to say that Megaco Lock= Step =3D MGCP Step, and Megaco Off =3D MGCP Loop?

Thank you,

Raphael Tryster

    -----Original Mess= age-----
    From:   Kevin Boyle [SMTP:= kboyle@nortelnetworks.com]
    Sent:   Thursday, 09 January, 2003 7:37 PM
    To:     Dana.Herskowitz@ecitele.com; megaco@ietf= =2Eorg
    Cc:     Eli.Liluz@ecitele.com; Ilana.Leibovitch@= ecitele.com; Meir.Leshem@ecitele.com; Oded.Katz@ecitele.com; Benny.Lavi@e= citele.com

    Subject:     = ;   RE: [Megaco] Event= s accumulating and events notification

    Comments inline. [KJBII]

    Kevin

    -----Original Message-----
    From: Dana.Herskowitz@ecitele.com= [mailto:Dana.Herskowitz@e= citele.com]
    Sent: Thursday, January 09, 2003 = 11:21 AM
    To: megaco@ietf.org
    Cc: Eli.Liluz@ecitele.com; Ilana.= Leibovitch@ecitele.com;
    Meir.Leshem@ecitele.com; Oded.Kat= z@ecitele.com; Benny.Lavi@ecitele.com
    Subject: [Megaco] Events accumula= ting and events notification



    Hello,

    1) According to RFC3015:
          Th= e EventBuffer Descriptor contains a list of events, with their
    parameters if any, that the MG is= requested to detect and buffer when
    EventBufferControl equals LockSte= p Does it actually mean that control
    property Off disables the accumul= ating completely?

    [KJBII] Correct.


    2) When control property equals Lo= ckStep, should the MG wait for Notify
    reply (Like in MGCP) in order to = process the next accumulated event or only
    wait for a new eventsDescriptor?<= /FONT>

    [KJBII] It must wait for a new Eve= nts Descriptor.
     
    In this case, should waiting for = a new eventDescriptor after sending each
    Notify is mandatory?

    [KJBII] Yes.

    Regards,

    Dana H.


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

------_=_NextPart_001_01C2B80C.5C2B38D0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jan 9 13:55:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21154 for ; Thu, 9 Jan 2003 13:55:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09J6fJ14900; Thu, 9 Jan 2003 14:06:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09J4sJ14758 for ; Thu, 9 Jan 2003 14:04:54 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20773 for ; Thu, 9 Jan 2003 13:52:34 -0500 (EST) Received: from cisco.com (che-vpn-cluster-1-109.cisco.com [10.86.240.109]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h09ItBjS029126; Thu, 9 Jan 2003 10:55:11 -0800 (PST) Message-ID: <3E1DC5B0.2372F757@cisco.com> Date: Thu, 09 Jan 2003 13:55:44 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Raphael Tryster CC: Kevin Boyle , Dana.Herskowitz@ecitele.com, megaco@ietf.org Subject: Re: [Megaco] Events accumulating and events notification References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Raphael Tryster wrote: > > > Kevin, > > I would like to verify that Off disables accumulating in the sense > that events are handled immediately according to the latest event > descriptor, not in the sense that they are thrown away. > > Would it be fair to say that Megaco LockStep = MGCP Step, and Megaco > Off = MGCP Loop? > Almost: Megaco LockStep = MGCP Step, Process Megaco Off = MGCP Loop, Discard -- Flemming > > Thank you, > > Raphael Tryster > > -----Original Message----- > From: Kevin Boyle [SMTP:kboyle@nortelnetworks.com] > Sent: Thursday, 09 January, 2003 7:37 PM > To: Dana.Herskowitz@ecitele.com; megaco@ietf.org > Cc: Eli.Liluz@ecitele.com; Ilana.Leibovitch@ecitele.com; > Meir.Leshem@ecitele.com; Oded.Katz@ecitele.com; > Benny.Lavi@ecitele.com > > Subject: RE: [Megaco] Events accumulating and events > notification > > Comments inline. [KJBII] > > Kevin > > -----Original Message----- > From: Dana.Herskowitz@ecitele.com > [mailto:Dana.Herskowitz@ecitele.com] > Sent: Thursday, January 09, 2003 11:21 AM > To: megaco@ietf.org > Cc: Eli.Liluz@ecitele.com; Ilana.Leibovitch@ecitele.com; > Meir.Leshem@ecitele.com; Oded.Katz@ecitele.com; > Benny.Lavi@ecitele.com > Subject: [Megaco] Events accumulating and events notification > > > Hello, > > 1) According to RFC3015: > The EventBuffer Descriptor contains a list of events, with > their > parameters if any, that the MG is requested to detect and buffer > when > EventBufferControl equals LockStep Does it actually mean that > control > property Off disables the accumulating completely? > > [KJBII] Correct. > > 2) When control property equals LockStep, should the MG wait for > Notify > reply (Like in MGCP) in order to process the next accumulated > event or only > wait for a new eventsDescriptor? > > [KJBII] It must wait for a new Events Descriptor. > > In this case, should waiting for a new eventDescriptor after > sending each > Notify is mandatory? > > [KJBII] Yes. > > Regards, > > Dana H. > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jan 9 13:56:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21238 for ; Thu, 9 Jan 2003 13:56:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09J8CA15795 for megaco-archive@odin.ietf.org; Thu, 9 Jan 2003 14:08:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09J8CJ15792 for ; Thu, 9 Jan 2003 14:08:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21179 for ; Thu, 9 Jan 2003 13:55:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09J6fJ14900; Thu, 9 Jan 2003 14:06:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09J4sJ14758 for ; Thu, 9 Jan 2003 14:04:54 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20773 for ; Thu, 9 Jan 2003 13:52:34 -0500 (EST) Received: from cisco.com (che-vpn-cluster-1-109.cisco.com [10.86.240.109]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h09ItBjS029126; Thu, 9 Jan 2003 10:55:11 -0800 (PST) Message-ID: <3E1DC5B0.2372F757@cisco.com> Date: Thu, 09 Jan 2003 13:55:44 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Raphael Tryster CC: Kevin Boyle , Dana.Herskowitz@ecitele.com, megaco@ietf.org Subject: Re: [Megaco] Events accumulating and events notification References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Raphael Tryster wrote: > > > Kevin, > > I would like to verify that Off disables accumulating in the sense > that events are handled immediately according to the latest event > descriptor, not in the sense that they are thrown away. > > Would it be fair to say that Megaco LockStep = MGCP Step, and Megaco > Off = MGCP Loop? > Almost: Megaco LockStep = MGCP Step, Process Megaco Off = MGCP Loop, Discard -- Flemming > > Thank you, > > Raphael Tryster > > -----Original Message----- > From: Kevin Boyle [SMTP:kboyle@nortelnetworks.com] > Sent: Thursday, 09 January, 2003 7:37 PM > To: Dana.Herskowitz@ecitele.com; megaco@ietf.org > Cc: Eli.Liluz@ecitele.com; Ilana.Leibovitch@ecitele.com; > Meir.Leshem@ecitele.com; Oded.Katz@ecitele.com; > Benny.Lavi@ecitele.com > > Subject: RE: [Megaco] Events accumulating and events > notification > > Comments inline. [KJBII] > > Kevin > > -----Original Message----- > From: Dana.Herskowitz@ecitele.com > [mailto:Dana.Herskowitz@ecitele.com] > Sent: Thursday, January 09, 2003 11:21 AM > To: megaco@ietf.org > Cc: Eli.Liluz@ecitele.com; Ilana.Leibovitch@ecitele.com; > Meir.Leshem@ecitele.com; Oded.Katz@ecitele.com; > Benny.Lavi@ecitele.com > Subject: [Megaco] Events accumulating and events notification > > > Hello, > > 1) According to RFC3015: > The EventBuffer Descriptor contains a list of events, with > their > parameters if any, that the MG is requested to detect and buffer > when > EventBufferControl equals LockStep Does it actually mean that > control > property Off disables the accumulating completely? > > [KJBII] Correct. > > 2) When control property equals LockStep, should the MG wait for > Notify > reply (Like in MGCP) in order to process the next accumulated > event or only > wait for a new eventsDescriptor? > > [KJBII] It must wait for a new Events Descriptor. > > In this case, should waiting for a new eventDescriptor after > sending each > Notify is mandatory? > > [KJBII] Yes. > > Regards, > > Dana H. > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jan 9 13:56:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21256 for ; Thu, 9 Jan 2003 13:56:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09J76J15191; Thu, 9 Jan 2003 14:07:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09J6GJ14860 for ; Thu, 9 Jan 2003 14:06:16 -0500 Received: from zrtps0kn.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20910 for ; Thu, 9 Jan 2003 13:53:56 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h09IvAv26121 for ; Thu, 9 Jan 2003 13:57:11 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 13:57:11 -0500 Message-ID: From: "Kevin Boyle" To: Raphael Tryster , Dana.Herskowitz@ecitele.com, megaco@ietf.org Subject: RE: [Megaco] Events accumulating and events notification Date: Thu, 9 Jan 2003 13:57:11 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Raphael, That is an excellent clarification. Note that if a Notify has been sent from the MG that is operating under LockStep and then the MGC sets EB off, that the previous Events Descriptor was "disabled" as part of the EB process, so that the MG does not have an active Events Descriptor. So, if the latest E descriptor has been satisfied and not replaced at the time that LockStep is removed, then the MG will not be actively attempting to detect any events. If the E descriptor has not been fulfilled when LockStep is removed, then that E descriptor should remain as the active descriptor, and the MG should continue to detect the events specified therein. Kevin -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Thursday, January 09, 2003 1:25 PM To: Boyle, Kevin [NCRTP:3R90:EXCH]; Dana.Herskowitz@ecitele.com; megaco@ietf.org Subject: RE: [Megaco] Events accumulating and events notification Kevin, I would like to verify that Off disables accumulating in the sense that events are handled immediately according to the latest event descriptor, not in the sense that they are thrown away. Would it be fair to say that Megaco LockStep = MGCP Step, and Megaco Off = MGCP Loop? Thank you, Raphael Tryster BM__MailData-----Original Message----- From: Kevin Boyle [SMTP:kboyle@nortelnetworks.com] Sent: Thursday, 09 January, 2003 7:37 PM To: Dana.Herskowitz@ecitele.com; megaco@ietf.org Cc: Eli.Liluz@ecitele.com; Ilana.Leibovitch@ecitele.com; Meir.Leshem@ecitele.com; Oded.Katz@ecitele.com; Benny.Lavi@ecitele.com Subject: RE: [Megaco] Events accumulating and events notification Comments inline. [KJBII] Kevin -----Original Message----- From: Dana.Herskowitz@ecitele.com [mailto:Dana.Herskowitz@ecitele.com ] Sent: Thursday, January 09, 2003 11:21 AM To: megaco@ietf.org Cc: Eli.Liluz@ecitele.com; Ilana.Leibovitch@ecitele.com; Meir.Leshem@ecitele.com; Oded.Katz@ecitele.com; Benny.Lavi@ecitele.com Subject: [Megaco] Events accumulating and events notification Hello, 1) According to RFC3015: The EventBuffer Descriptor contains a list of events, with their parameters if any, that the MG is requested to detect and buffer when EventBufferControl equals LockStep Does it actually mean that control property Off disables the accumulating completely? [KJBII] Correct. 2) When control property equals LockStep, should the MG wait for Notify reply (Like in MGCP) in order to process the next accumulated event or only wait for a new eventsDescriptor? [KJBII] It must wait for a new Events Descriptor. In this case, should waiting for a new eventDescriptor after sending each Notify is mandatory? [KJBII] Yes. Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jan 9 13:57:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21379 for ; Thu, 9 Jan 2003 13:57:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09J8p015827 for megaco-archive@odin.ietf.org; Thu, 9 Jan 2003 14:08:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09J8pJ15824 for ; Thu, 9 Jan 2003 14:08:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21280 for ; Thu, 9 Jan 2003 13:56:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09J76J15191; Thu, 9 Jan 2003 14:07:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09J6GJ14860 for ; Thu, 9 Jan 2003 14:06:16 -0500 Received: from zrtps0kn.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20910 for ; Thu, 9 Jan 2003 13:53:56 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h09IvAv26121 for ; Thu, 9 Jan 2003 13:57:11 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 13:57:11 -0500 Message-ID: From: "Kevin Boyle" To: Raphael Tryster , Dana.Herskowitz@ecitele.com, megaco@ietf.org Subject: RE: [Megaco] Events accumulating and events notification Date: Thu, 9 Jan 2003 13:57:11 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Raphael, That is an excellent clarification. Note that if a Notify has been sent from the MG that is operating under LockStep and then the MGC sets EB off, that the previous Events Descriptor was "disabled" as part of the EB process, so that the MG does not have an active Events Descriptor. So, if the latest E descriptor has been satisfied and not replaced at the time that LockStep is removed, then the MG will not be actively attempting to detect any events. If the E descriptor has not been fulfilled when LockStep is removed, then that E descriptor should remain as the active descriptor, and the MG should continue to detect the events specified therein. Kevin -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Thursday, January 09, 2003 1:25 PM To: Boyle, Kevin [NCRTP:3R90:EXCH]; Dana.Herskowitz@ecitele.com; megaco@ietf.org Subject: RE: [Megaco] Events accumulating and events notification Kevin, I would like to verify that Off disables accumulating in the sense that events are handled immediately according to the latest event descriptor, not in the sense that they are thrown away. Would it be fair to say that Megaco LockStep = MGCP Step, and Megaco Off = MGCP Loop? Thank you, Raphael Tryster BM__MailData-----Original Message----- From: Kevin Boyle [SMTP:kboyle@nortelnetworks.com] Sent: Thursday, 09 January, 2003 7:37 PM To: Dana.Herskowitz@ecitele.com; megaco@ietf.org Cc: Eli.Liluz@ecitele.com; Ilana.Leibovitch@ecitele.com; Meir.Leshem@ecitele.com; Oded.Katz@ecitele.com; Benny.Lavi@ecitele.com Subject: RE: [Megaco] Events accumulating and events notification Comments inline. [KJBII] Kevin -----Original Message----- From: Dana.Herskowitz@ecitele.com [mailto:Dana.Herskowitz@ecitele.com ] Sent: Thursday, January 09, 2003 11:21 AM To: megaco@ietf.org Cc: Eli.Liluz@ecitele.com; Ilana.Leibovitch@ecitele.com; Meir.Leshem@ecitele.com; Oded.Katz@ecitele.com; Benny.Lavi@ecitele.com Subject: [Megaco] Events accumulating and events notification Hello, 1) According to RFC3015: The EventBuffer Descriptor contains a list of events, with their parameters if any, that the MG is requested to detect and buffer when EventBufferControl equals LockStep Does it actually mean that control property Off disables the accumulating completely? [KJBII] Correct. 2) When control property equals LockStep, should the MG wait for Notify reply (Like in MGCP) in order to process the next accumulated event or only wait for a new eventsDescriptor? [KJBII] It must wait for a new Events Descriptor. In this case, should waiting for a new eventDescriptor after sending each Notify is mandatory? [KJBII] Yes. Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jan 9 22:53:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06266 for ; Thu, 9 Jan 2003 22:53:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A45OJ17411; Thu, 9 Jan 2003 23:05:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A43LJ17344 for ; Thu, 9 Jan 2003 23:03:21 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06222 for ; Thu, 9 Jan 2003 22:50:40 -0500 (EST) From: gsachin@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0A3qhs13844 for ; Fri, 10 Jan 2003 09:22:43 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0A3qgN13838 for ; Fri, 10 Jan 2003 09:22:42 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h0A3snA13647 for ; Fri, 10 Jan 2003 09:24:49 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CAA.0014BECF ; Fri, 10 Jan 2003 09:16:35 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CAA.0014BDAB.00@sandesh.hss.hns.com> Date: Fri, 10 Jan 2003 09:19:20 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Stream 0 in Media Descriptor Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi List, I have a doubt regarding the Media Descriptor. Is what scenarios MGC can specify StreamID 0 in Media Descriptor? As per Grammar this is valid. Thanks Sachin Gupta gsachin@hss.hns.com on 01/06/2003 10:31:00 AM To: megaco@ietf.org cc: Sachin Gupta-PNGN/HSS@HSS Subject: [Megaco] Stream 0 Hi List, Stream ID 0 is speficied in the protocol as "not related to a particular media stream" for event detection and signal application. According to the Grammar, 0 is a valid Stream ID. Can somebody tell in what scenarios MGC can specify streamID as 0 and what what will it refer to (by StreamID 0) Regards Sachin Gupta DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jan 9 22:54:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06320 for ; Thu, 9 Jan 2003 22:54:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A46As17466 for megaco-archive@odin.ietf.org; Thu, 9 Jan 2003 23:06:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A46AJ17463 for ; Thu, 9 Jan 2003 23:06:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06271 for ; Thu, 9 Jan 2003 22:53:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A45OJ17411; Thu, 9 Jan 2003 23:05:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A43LJ17344 for ; Thu, 9 Jan 2003 23:03:21 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06222 for ; Thu, 9 Jan 2003 22:50:40 -0500 (EST) From: gsachin@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0A3qhs13844 for ; Fri, 10 Jan 2003 09:22:43 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0A3qgN13838 for ; Fri, 10 Jan 2003 09:22:42 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h0A3snA13647 for ; Fri, 10 Jan 2003 09:24:49 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CAA.0014BECF ; Fri, 10 Jan 2003 09:16:35 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CAA.0014BDAB.00@sandesh.hss.hns.com> Date: Fri, 10 Jan 2003 09:19:20 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Stream 0 in Media Descriptor Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi List, I have a doubt regarding the Media Descriptor. Is what scenarios MGC can specify StreamID 0 in Media Descriptor? As per Grammar this is valid. Thanks Sachin Gupta gsachin@hss.hns.com on 01/06/2003 10:31:00 AM To: megaco@ietf.org cc: Sachin Gupta-PNGN/HSS@HSS Subject: [Megaco] Stream 0 Hi List, Stream ID 0 is speficied in the protocol as "not related to a particular media stream" for event detection and signal application. According to the Grammar, 0 is a valid Stream ID. Can somebody tell in what scenarios MGC can specify streamID as 0 and what what will it refer to (by StreamID 0) Regards Sachin Gupta DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jan 9 23:00:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06541 for ; Thu, 9 Jan 2003 23:00:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A4C7J18568; Thu, 9 Jan 2003 23:12:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A4BuJ18547 for ; Thu, 9 Jan 2003 23:11:56 -0500 Received: from mailout2.samsung.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06518 for ; Thu, 9 Jan 2003 22:59:24 -0500 (EST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0H8H00701CIC4F@mailout2.samsung.com> for megaco@ietf.org; Fri, 10 Jan 2003 13:01:24 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0H8H004D8CIBXB@mailout2.samsung.com> for megaco@ietf.org; Fri, 10 Jan 2003 13:01:24 +0900 (KST) Received: from Narayanam ([107.108.4.117]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0H8H00LYCD2ELH@mmp2.samsung.com> for megaco@ietf.org; Fri, 10 Jan 2003 13:13:28 +0900 (KST) Date: Fri, 10 Jan 2003 09:28:20 +0530 From: Narayana Murthy To: megaco@ietf.org Message-id: <001801c2b85c$84da0d60$75046c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/alternative; boundary="Boundary_(ID_pK1fk/6nN6ExkgeETUgZLw)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Megaco] NonStandardData - ServiceChange Descriptor Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_pK1fk/6nN6ExkgeETUgZLw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi All, Can any one please explain me the relevance and use of NonStandardData parameter in the ServiceChange descriptor. Thanks in advance, Regards, Narayana Murthy Samsung India Software Operations No . 67, Infantry Road Bangalore, India 560 001 Office 92 - 80 - 5321712 +215 Fax 92 - 80 - 5595756 email: narayana@samsung.com --Boundary_(ID_pK1fk/6nN6ExkgeETUgZLw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi All,
Can any one please explain me the relevance and use of NonStandardData parameter in
the ServiceChange descriptor.
 
Thanks in advance,
 
Regards,
Narayana Murthy
 
Samsung India Software Operations
No . 67, Infantry Road
Bangalore, India 560 001
Office 92 - 80 - 5321712 +215
Fax  92 - 80 - 5595756
email: narayana@samsung.com
--Boundary_(ID_pK1fk/6nN6ExkgeETUgZLw)-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jan 9 23:00:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06559 for ; Thu, 9 Jan 2003 23:00:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A4Cqh18597 for megaco-archive@odin.ietf.org; Thu, 9 Jan 2003 23:12:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A4CqJ18594 for ; Thu, 9 Jan 2003 23:12:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06545 for ; Thu, 9 Jan 2003 23:00:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A4C7J18568; Thu, 9 Jan 2003 23:12:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A4BuJ18547 for ; Thu, 9 Jan 2003 23:11:56 -0500 Received: from mailout2.samsung.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06518 for ; Thu, 9 Jan 2003 22:59:24 -0500 (EST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0H8H00701CIC4F@mailout2.samsung.com> for megaco@ietf.org; Fri, 10 Jan 2003 13:01:24 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0H8H004D8CIBXB@mailout2.samsung.com> for megaco@ietf.org; Fri, 10 Jan 2003 13:01:24 +0900 (KST) Received: from Narayanam ([107.108.4.117]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0H8H00LYCD2ELH@mmp2.samsung.com> for megaco@ietf.org; Fri, 10 Jan 2003 13:13:28 +0900 (KST) Date: Fri, 10 Jan 2003 09:28:20 +0530 From: Narayana Murthy To: megaco@ietf.org Message-id: <001801c2b85c$84da0d60$75046c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/alternative; boundary="Boundary_(ID_pK1fk/6nN6ExkgeETUgZLw)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Megaco] NonStandardData - ServiceChange Descriptor Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_pK1fk/6nN6ExkgeETUgZLw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi All, Can any one please explain me the relevance and use of NonStandardData parameter in the ServiceChange descriptor. Thanks in advance, Regards, Narayana Murthy Samsung India Software Operations No . 67, Infantry Road Bangalore, India 560 001 Office 92 - 80 - 5321712 +215 Fax 92 - 80 - 5595756 email: narayana@samsung.com --Boundary_(ID_pK1fk/6nN6ExkgeETUgZLw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi All,
Can any one please explain me the relevance and use of NonStandardData parameter in
the ServiceChange descriptor.
 
Thanks in advance,
 
Regards,
Narayana Murthy
 
Samsung India Software Operations
No . 67, Infantry Road
Bangalore, India 560 001
Office 92 - 80 - 5321712 +215
Fax  92 - 80 - 5595756
email: narayana@samsung.com
--Boundary_(ID_pK1fk/6nN6ExkgeETUgZLw)-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Jan 10 05:51:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24059 for ; Fri, 10 Jan 2003 05:51:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AB2SJ20477; Fri, 10 Jan 2003 06:02:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AAxcJ20206 for ; Fri, 10 Jan 2003 05:59:38 -0500 Received: from web8202.mail.in.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA23958 for ; Fri, 10 Jan 2003 05:46:56 -0500 (EST) Message-ID: <20030110105013.47768.qmail@web8202.mail.in.yahoo.com> Received: from [203.197.192.140] by web8202.mail.in.yahoo.com via HTTP; Fri, 10 Jan 2003 10:50:13 GMT Date: Fri, 10 Jan 2003 10:50:13 +0000 (GMT) From: =?iso-8859-1?q?mukta=20vasudeva?= To: megaco@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1887508152-1042195813=:47626" Content-Transfer-Encoding: 8bit Subject: [Megaco] Problem with Dgitmap event Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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-1887508152-1042195813=:47626 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, I have another problem: The RFC states that: 밒f no candidates remain, the latest event is removed from the current dial string and a completion event is generated indicating full match if one of the candidates from the previous step was fully satisfied before the latest event was detected, or partial match otherwise. The event removed from the current dial string will then be reported as per the currently active event processing mechanisms.� Please refer to the Highlighted part: Q: Lets say the MG has received Message from MGC telling it to activate detection of R2/R2Address event of the R2 Package (or it could be the DTMF Package :dd/ce completion event.). In either case when it is found that the last event is generating a Full Match,.then the Current Dial String is sent as an Observed Parameter of the Notify generated corresponding to the R2Address event. Now , the event that is mentioned in the highlighted region is the problem. How does the MG send This Event뭩 Notification? It is mentioned that MG uses the 밹urrently active event processing mechanisms.� This implies that we cannot send this event without the activation from MGC. For the DTMF Package this is ok, since the MGC would activate detection of the Digits Event 뻲ildcarded with choose. 3.But in case of R2 Package Which event would the MGC use to ask for this event뭩 notification? I could not find any event in R2 package which could be used for the purpose. Thanks, Mukta Vasudeva Catch all the cricket action. Download Yahoo! Score tracker --0-1887508152-1042195813=:47626 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit  

Hi,

I have another problem:

 

The RFC states that:

�If

      no candidates remain, the latest event is removed from the

      current dial string and a completion event is generated

      indicating full match if one of the candidates from the previous

      step was fully satisfied before the latest event was detected, or

      partial match otherwise. The event removed from the current dial

      string will then be reported as per the currently active event

      processing mechanisms.�

 

Please refer to the Highlighted part:

Q: Lets say the MG has received Message from MGC telling it to activate detection of  R2/R2Address event of the R2 Package (or it could be the DTMF Package :dd/ce completion event.).

In either case when it is found that the last event is generating a Full Match,.then the Current Dial String is sent as an Observed Parameter of the Notify generated corresponding to the R2Address event.

Now , the event that is mentioned in the highlighted region is the problem. How does the MG send This Event뭩 Notification?

It is mentioned that MG uses the �currently active event processing mechanisms.�

  1. This implies that we cannot send this event without the activation from MGC.
  2. For the DTMF Package this is ok, since the MGC would activate detection of the Digits Event 뻲ildcarded with choose.

      3.But in case of R2 Package Which event would the MGC use to ask for this event뭩 notification? I could not find any event in R2 package which could be used for the purpose.

 

Thanks,

Mukta Vasudeva

Catch all the cricket action. Download Yahoo! Score tracker --0-1887508152-1042195813=:47626-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Jan 10 05:51:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24084 for ; Fri, 10 Jan 2003 05:51:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AB41T20572 for megaco-archive@odin.ietf.org; Fri, 10 Jan 2003 06:04:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AB40J20567 for ; Fri, 10 Jan 2003 06:04:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24062 for ; Fri, 10 Jan 2003 05:51:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AB2SJ20477; Fri, 10 Jan 2003 06:02:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AAxcJ20206 for ; Fri, 10 Jan 2003 05:59:38 -0500 Received: from web8202.mail.in.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA23958 for ; Fri, 10 Jan 2003 05:46:56 -0500 (EST) Message-ID: <20030110105013.47768.qmail@web8202.mail.in.yahoo.com> Received: from [203.197.192.140] by web8202.mail.in.yahoo.com via HTTP; Fri, 10 Jan 2003 10:50:13 GMT Date: Fri, 10 Jan 2003 10:50:13 +0000 (GMT) From: =?iso-8859-1?q?mukta=20vasudeva?= To: megaco@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1887508152-1042195813=:47626" Content-Transfer-Encoding: 8bit Subject: [Megaco] Problem with Dgitmap event Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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-1887508152-1042195813=:47626 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, I have another problem: The RFC states that: 밒f no candidates remain, the latest event is removed from the current dial string and a completion event is generated indicating full match if one of the candidates from the previous step was fully satisfied before the latest event was detected, or partial match otherwise. The event removed from the current dial string will then be reported as per the currently active event processing mechanisms.� Please refer to the Highlighted part: Q: Lets say the MG has received Message from MGC telling it to activate detection of R2/R2Address event of the R2 Package (or it could be the DTMF Package :dd/ce completion event.). In either case when it is found that the last event is generating a Full Match,.then the Current Dial String is sent as an Observed Parameter of the Notify generated corresponding to the R2Address event. Now , the event that is mentioned in the highlighted region is the problem. How does the MG send This Event뭩 Notification? It is mentioned that MG uses the 밹urrently active event processing mechanisms.� This implies that we cannot send this event without the activation from MGC. For the DTMF Package this is ok, since the MGC would activate detection of the Digits Event 뻲ildcarded with choose. 3.But in case of R2 Package Which event would the MGC use to ask for this event뭩 notification? I could not find any event in R2 package which could be used for the purpose. Thanks, Mukta Vasudeva Catch all the cricket action. Download Yahoo! Score tracker --0-1887508152-1042195813=:47626 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit  

Hi,

I have another problem:

 

The RFC states that:

�If

      no candidates remain, the latest event is removed from the

      current dial string and a completion event is generated

      indicating full match if one of the candidates from the previous

      step was fully satisfied before the latest event was detected, or

      partial match otherwise. The event removed from the current dial

      string will then be reported as per the currently active event

      processing mechanisms.�

 

Please refer to the Highlighted part:

Q: Lets say the MG has received Message from MGC telling it to activate detection of  R2/R2Address event of the R2 Package (or it could be the DTMF Package :dd/ce completion event.).

In either case when it is found that the last event is generating a Full Match,.then the Current Dial String is sent as an Observed Parameter of the Notify generated corresponding to the R2Address event.

Now , the event that is mentioned in the highlighted region is the problem. How does the MG send This Event뭩 Notification?

It is mentioned that MG uses the �currently active event processing mechanisms.�

  1. This implies that we cannot send this event without the activation from MGC.
  2. For the DTMF Package this is ok, since the MGC would activate detection of the Digits Event 뻲ildcarded with choose.

      3.But in case of R2 Package Which event would the MGC use to ask for this event뭩 notification? I could not find any event in R2 package which could be used for the purpose.

 

Thanks,

Mukta Vasudeva

Catch all the cricket action. Download Yahoo! Score tracker --0-1887508152-1042195813=:47626-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Jan 10 15:23:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14965 for ; Fri, 10 Jan 2003 15:23:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AKZ7J26895; Fri, 10 Jan 2003 15:35:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AKWVJ26794 for ; Fri, 10 Jan 2003 15:32:31 -0500 Received: from topaz.3com.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14836 for ; Fri, 10 Jan 2003 15:19:40 -0500 (EST) From: John_Poplett@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0AKMeL21431 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Fri, 10 Jan 2003 12:22:40 -0800 (PST) Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79]) by opal.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0AKMuS19801 for ; Fri, 10 Jan 2003 12:22:56 -0800 (PST) To: megaco@ietf.org Date: Fri, 10 Jan 2003 14:24:16 -0600 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Megaco] Setting T.38 on a termination with ASN.1 encoding Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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. For an IP trunking gateway, after an MGC has determined that a fax call is in progress for a given context, how does it modify the packet side termination to transition from an audio codec to T.38 with ASN.1 encoding? Annex F provides a text example of programming a termination to use T.38. In this example, T.38 UDPTL is specified with the session description protocol, .e.g.: v=0 c=IN IP4 124.124.124.222 m=image 1111 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38UdpEC:t38UDPFEC Annex C provides the binary mappings for various SDP properties, including a property "acodec" for audio codecs. It seems natural to have a similar SDP to binary mapping for T.38 but I am not aware of such. For binary encoding is this termination switched from an audio codec to T.38 by setting the IPFaxTransport property of the IP Fax Package to one of the T.38 values? Thanks, John _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Jan 10 15:24:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14986 for ; Fri, 10 Jan 2003 15:24:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AKaMj26970 for megaco-archive@odin.ietf.org; Fri, 10 Jan 2003 15:36:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AKaMJ26967 for ; Fri, 10 Jan 2003 15:36:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14979 for ; Fri, 10 Jan 2003 15:23:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AKZ7J26895; Fri, 10 Jan 2003 15:35:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AKWVJ26794 for ; Fri, 10 Jan 2003 15:32:31 -0500 Received: from topaz.3com.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14836 for ; Fri, 10 Jan 2003 15:19:40 -0500 (EST) From: John_Poplett@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0AKMeL21431 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Fri, 10 Jan 2003 12:22:40 -0800 (PST) Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79]) by opal.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0AKMuS19801 for ; Fri, 10 Jan 2003 12:22:56 -0800 (PST) To: megaco@ietf.org Date: Fri, 10 Jan 2003 14:24:16 -0600 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Megaco] Setting T.38 on a termination with ASN.1 encoding Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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. For an IP trunking gateway, after an MGC has determined that a fax call is in progress for a given context, how does it modify the packet side termination to transition from an audio codec to T.38 with ASN.1 encoding? Annex F provides a text example of programming a termination to use T.38. In this example, T.38 UDPTL is specified with the session description protocol, .e.g.: v=0 c=IN IP4 124.124.124.222 m=image 1111 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38UdpEC:t38UDPFEC Annex C provides the binary mappings for various SDP properties, including a property "acodec" for audio codecs. It seems natural to have a similar SDP to binary mapping for T.38 but I am not aware of such. For binary encoding is this termination switched from an audio codec to T.38 by setting the IPFaxTransport property of the IP Fax Package to one of the T.38 values? Thanks, John _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Jan 10 16:01:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16129 for ; Fri, 10 Jan 2003 16:01:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ALCdJ29741; Fri, 10 Jan 2003 16:12:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ALBHJ29695 for ; Fri, 10 Jan 2003 16:11:17 -0500 Received: from wench.telica.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16057 for ; Fri, 10 Jan 2003 15:58:25 -0500 (EST) Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Jan 2003 15:58:29 -0500 Message-ID: From: Carl Rutter To: "'megaco@ietf.org'" Date: Fri, 10 Jan 2003 15:58:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Megaco] Reserved Value and Reserved Group as it applies to Codec Negotia tion Question Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , I have a few questions on these. I know this has been discussed before but can't remember the resolution. Does the following sound correct? 1) Reserve Group - Applies to a Group of Session Descriptors. If true reserve resources to handle say the worse case specifed codec. ie) v= . . m= audio ... 2 v= . . m= audio ... 0 Make sure we reserve for either 0 or 2. 2) Reserve Value On the media line m= audio ... 0 2 Make sure we reserve for either 0 or 2. What about the case where there is 2 or more media lines in a Session Decriptor ie) m= audio ... 2 m= audio ... 0 Is this legal? Would this quailify as a group? So if Reserved Group was True and I had 1 session descriptor with 2 m= lines would I reserve them both? Also is RFC3264 the model moving forward for codec negotiation?? Thx, Carl Carl Rutter Telica, Inc. Building G, Suite 100 734 Forest Street Marlboro, MA 01752 Email crutter@telica.com Voice 508-480-0909 x8178 Fax 508-480-0922 www.telica.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Jan 10 16:02:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16149 for ; Fri, 10 Jan 2003 16:02:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ALEZ429803 for megaco-archive@odin.ietf.org; Fri, 10 Jan 2003 16:14:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ALEZJ29800 for ; Fri, 10 Jan 2003 16:14:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16144 for ; Fri, 10 Jan 2003 16:01:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ALCdJ29741; Fri, 10 Jan 2003 16:12:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ALBHJ29695 for ; Fri, 10 Jan 2003 16:11:17 -0500 Received: from wench.telica.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16057 for ; Fri, 10 Jan 2003 15:58:25 -0500 (EST) Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Jan 2003 15:58:29 -0500 Message-ID: From: Carl Rutter To: "'megaco@ietf.org'" Date: Fri, 10 Jan 2003 15:58:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Megaco] Reserved Value and Reserved Group as it applies to Codec Negotia tion Question Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , I have a few questions on these. I know this has been discussed before but can't remember the resolution. Does the following sound correct? 1) Reserve Group - Applies to a Group of Session Descriptors. If true reserve resources to handle say the worse case specifed codec. ie) v= . . m= audio ... 2 v= . . m= audio ... 0 Make sure we reserve for either 0 or 2. 2) Reserve Value On the media line m= audio ... 0 2 Make sure we reserve for either 0 or 2. What about the case where there is 2 or more media lines in a Session Decriptor ie) m= audio ... 2 m= audio ... 0 Is this legal? Would this quailify as a group? So if Reserved Group was True and I had 1 session descriptor with 2 m= lines would I reserve them both? Also is RFC3264 the model moving forward for codec negotiation?? Thx, Carl Carl Rutter Telica, Inc. Building G, Suite 100 734 Forest Street Marlboro, MA 01752 Email crutter@telica.com Voice 508-480-0909 x8178 Fax 508-480-0922 www.telica.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Sat Jan 11 22:18:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23652 for ; Sat, 11 Jan 2003 22:18:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0C3UEJ27817; Sat, 11 Jan 2003 22:30:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0C3QGJ27742 for ; Sat, 11 Jan 2003 22:26:16 -0500 Received: from noya.bupt.edu.cn (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23604 for ; Sat, 11 Jan 2003 22:12:47 -0500 (EST) Received: from nic ([202.204.5.168]) by noya.bupt.edu.cn (8.12.2/8.12.2) with SMTP id h0C3G36d020603 for ; Sun, 12 Jan 2003 11:16:03 +0800 (CST) Message-ID: <002b01c2b9e8$bcd23840$a801010a@nic> From: "auger" To: References: Subject: Re: [Megaco] Is there Open source implementing MEGACO? Date: Sun, 12 Jan 2003 11:14:36 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h0C3QGJ27743 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit But I am not familiar with the Erlang system and Erlang programming. Is it hard to learn the new lanuage and development entironment? > On Tue, 26 Nov 2002, [ks_c_5601-1987] jhlim@newgrid.com wrote: > > jhlim> Is there Open source implementing MEGACO? > jhlim> If it exists, where can I obtain? > > Yes, a Megaco protocol stack is a part of the Erlang/OTP distribution: > > http://www.erlang.org/ > http://www.erlang.org/project/megaco > > /H�kan > > --- > H�kan Mattsson > Ericsson > High Availability Software, DBMS Internals > http://www.ericsson.com/cslab/~hakan/ > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Sat Jan 11 22:19:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23679 for ; Sat, 11 Jan 2003 22:19:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0C3WML27864 for megaco-archive@odin.ietf.org; Sat, 11 Jan 2003 22:32:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0C3WLJ27861 for ; Sat, 11 Jan 2003 22:32:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23655 for ; Sat, 11 Jan 2003 22:18:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0C3UEJ27817; Sat, 11 Jan 2003 22:30:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0C3QGJ27742 for ; Sat, 11 Jan 2003 22:26:16 -0500 Received: from noya.bupt.edu.cn (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23604 for ; Sat, 11 Jan 2003 22:12:47 -0500 (EST) Received: from nic ([202.204.5.168]) by noya.bupt.edu.cn (8.12.2/8.12.2) with SMTP id h0C3G36d020603 for ; Sun, 12 Jan 2003 11:16:03 +0800 (CST) Message-ID: <002b01c2b9e8$bcd23840$a801010a@nic> From: "auger" To: References: Subject: Re: [Megaco] Is there Open source implementing MEGACO? Date: Sun, 12 Jan 2003 11:14:36 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h0C3QGJ27743 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit But I am not familiar with the Erlang system and Erlang programming. Is it hard to learn the new lanuage and development entironment? > On Tue, 26 Nov 2002, [ks_c_5601-1987] jhlim@newgrid.com wrote: > > jhlim> Is there Open source implementing MEGACO? > jhlim> If it exists, where can I obtain? > > Yes, a Megaco protocol stack is a part of the Erlang/OTP distribution: > > http://www.erlang.org/ > http://www.erlang.org/project/megaco > > /H�kan > > --- > H�kan Mattsson > Ericsson > High Availability Software, DBMS Internals > http://www.ericsson.com/cslab/~hakan/ > > > _______________________________________________ > 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 Jan 12 23:20:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20739 for ; Sun, 12 Jan 2003 23:20:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D4XdJ12776; Sun, 12 Jan 2003 23:33:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D4UbJ12669 for ; Sun, 12 Jan 2003 23:30:37 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20682 for ; Sun, 12 Jan 2003 23:16:38 -0500 (EST) Received: from horh1.emsr.lucent.com (h135-17-1-40.lucent.com [135.17.1.40]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0D4JtX04770; Sun, 12 Jan 2003 23:19:55 -0500 (EST) Received: from new-wopr.eng.ascend.com by horh1.emsr.lucent.com (8.9.3+Sun/EMS-1.5 Solaris/emsr) id XAA25886 for ; Sun, 12 Jan 2003 23:19:54 -0500 (EST) Received: from india.ascend.com (indiamail.india.ascend.com [135.254.196.198]) by new-wopr.eng.ascend.com (8.10.2+Sun/8.10.2) with ESMTP id h0D4Jqt12411; Sun, 12 Jan 2003 20:19:52 -0800 (PST) Received: from lucent.com (coushatta.india.ascend.com [135.254.196.162]) by india.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id KAA11730; Mon, 13 Jan 2003 10:07:35 +0530 (IST) Message-ID: <3E224412.1290C0C9@lucent.com> Date: Mon, 13 Jan 2003 10:14:02 +0530 From: Shambhu Dayal Rai Organization: Infosys Technologies Ltd. X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 i86pc) X-Accept-Language: en MIME-Version: 1.0 To: Carl Rutter CC: "'megaco@ietf.org'" Subject: Re: [Megaco] Reserved Value and Reserved Group as it applies to Codec Negotiation Question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Carl, comments inline.. Carl Rutter wrote: > > I have a few questions on these. I know this has been discussed before but > can't > remember the resolution. Does the following sound correct? > > 1) Reserve Group - Applies to a Group of Session Descriptors. If true > reserve > resources to handle say the worse case specifed > codec. > ie) > v= > . > . > m= audio ... 2 > v= > . > . > m= audio ... 0 > > Make sure we reserve for either 0 or 2. [Shambhu]: I think, Here resources should be reserved to support all session descriptors. Both 0 and 2. > 2) Reserve Value > > On the media line > m= audio ... 0 2 > > Make sure we reserve for either 0 or 2. [Shambhu]: I think, Here resources should be reserved to handle flow of all mentioned types of codecs (here 0 and 2) if reserveValu is set in the request. > > What about the case where there is 2 or more media lines in a Session > Decriptor > ie) > > m= audio ... 2 > m= audio ... 0 > > Is this legal? > Would this quailify as a group? So if Reserved Group was True and I had 1 > session descriptor with 2 m= lines would I reserve them both? > [Shambhu]: Multiple "m-" lines are not legal in Megaco SDP. > Also is RFC3264 the model moving forward for codec negotiation?? > > Thx, > Carl > > Carl Rutter > Telica, Inc. > Building G, Suite 100 > 734 Forest Street > Marlboro, MA 01752 > Email crutter@telica.com > Voice 508-480-0909 x8178 > Fax 508-480-0922 > www.telica.com -- ------------------------------------------------------------------- Shambhu Dayal Rai sdrai@lucent.com Infosys - India SQA Team Phone:91-80-4166565 ------------------------------------------------------------------- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Sun Jan 12 23:23:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20801 for ; Sun, 12 Jan 2003 23:23:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0D4adc12836 for megaco-archive@odin.ietf.org; Sun, 12 Jan 2003 23:36:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D4adJ12832 for ; Sun, 12 Jan 2003 23:36:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20770 for ; Sun, 12 Jan 2003 23:22:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D4XdJ12776; Sun, 12 Jan 2003 23:33:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D4UbJ12669 for ; Sun, 12 Jan 2003 23:30:37 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20682 for ; Sun, 12 Jan 2003 23:16:38 -0500 (EST) Received: from horh1.emsr.lucent.com (h135-17-1-40.lucent.com [135.17.1.40]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0D4JtX04770; Sun, 12 Jan 2003 23:19:55 -0500 (EST) Received: from new-wopr.eng.ascend.com by horh1.emsr.lucent.com (8.9.3+Sun/EMS-1.5 Solaris/emsr) id XAA25886 for ; Sun, 12 Jan 2003 23:19:54 -0500 (EST) Received: from india.ascend.com (indiamail.india.ascend.com [135.254.196.198]) by new-wopr.eng.ascend.com (8.10.2+Sun/8.10.2) with ESMTP id h0D4Jqt12411; Sun, 12 Jan 2003 20:19:52 -0800 (PST) Received: from lucent.com (coushatta.india.ascend.com [135.254.196.162]) by india.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id KAA11730; Mon, 13 Jan 2003 10:07:35 +0530 (IST) Message-ID: <3E224412.1290C0C9@lucent.com> Date: Mon, 13 Jan 2003 10:14:02 +0530 From: Shambhu Dayal Rai Organization: Infosys Technologies Ltd. X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 i86pc) X-Accept-Language: en MIME-Version: 1.0 To: Carl Rutter CC: "'megaco@ietf.org'" Subject: Re: [Megaco] Reserved Value and Reserved Group as it applies to Codec Negotiation Question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Carl, comments inline.. Carl Rutter wrote: > > I have a few questions on these. I know this has been discussed before but > can't > remember the resolution. Does the following sound correct? > > 1) Reserve Group - Applies to a Group of Session Descriptors. If true > reserve > resources to handle say the worse case specifed > codec. > ie) > v= > . > . > m= audio ... 2 > v= > . > . > m= audio ... 0 > > Make sure we reserve for either 0 or 2. [Shambhu]: I think, Here resources should be reserved to support all session descriptors. Both 0 and 2. > 2) Reserve Value > > On the media line > m= audio ... 0 2 > > Make sure we reserve for either 0 or 2. [Shambhu]: I think, Here resources should be reserved to handle flow of all mentioned types of codecs (here 0 and 2) if reserveValu is set in the request. > > What about the case where there is 2 or more media lines in a Session > Decriptor > ie) > > m= audio ... 2 > m= audio ... 0 > > Is this legal? > Would this quailify as a group? So if Reserved Group was True and I had 1 > session descriptor with 2 m= lines would I reserve them both? > [Shambhu]: Multiple "m-" lines are not legal in Megaco SDP. > Also is RFC3264 the model moving forward for codec negotiation?? > > Thx, > Carl > > Carl Rutter > Telica, Inc. > Building G, Suite 100 > 734 Forest Street > Marlboro, MA 01752 > Email crutter@telica.com > Voice 508-480-0909 x8178 > Fax 508-480-0922 > www.telica.com -- ------------------------------------------------------------------- Shambhu Dayal Rai sdrai@lucent.com Infosys - India SQA Team Phone:91-80-4166565 ------------------------------------------------------------------- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jan 13 08:12:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10245 for ; Mon, 13 Jan 2003 08:12:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DDPLJ23565; Mon, 13 Jan 2003 08:25:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DDNjJ23497 for ; Mon, 13 Jan 2003 08:23:45 -0500 Received: from wench.telica.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10193 for ; Mon, 13 Jan 2003 08:09:35 -0500 (EST) Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Jan 2003 08:09:38 -0500 Message-ID: From: Carl Rutter To: "'Shambhu Dayal Rai'" , Carl Rutter Cc: "'megaco@ietf.org'" Subject: RE: [Megaco] Reserved Value and Reserved Group as it applies to Codec Negotiation Question Date: Mon, 13 Jan 2003 08:09:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Thx for the feedback, I wasn't sure on the multiple m= lines. I know AVD-2128 indicates that but wasn't sure if that was fully agreed on. Thx, carl -----Original Message----- From: Shambhu Dayal Rai [mailto:sdrai@lucent.com] Sent: Sunday, January 12, 2003 11:44 PM To: Carl Rutter Cc: 'megaco@ietf.org' Subject: Re: [Megaco] Reserved Value and Reserved Group as it applies to Codec Negotiation Question Hi Carl, comments inline.. Carl Rutter wrote: > > I have a few questions on these. I know this has been discussed before but > can't > remember the resolution. Does the following sound correct? > > 1) Reserve Group - Applies to a Group of Session Descriptors. If true > reserve > resources to handle say the worse case specifed > codec. > ie) > v= > . > . > m= audio ... 2 > v= > . > . > m= audio ... 0 > > Make sure we reserve for either 0 or 2. [Shambhu]: I think, Here resources should be reserved to support all session descriptors. Both 0 and 2. > 2) Reserve Value > > On the media line > m= audio ... 0 2 > > Make sure we reserve for either 0 or 2. [Shambhu]: I think, Here resources should be reserved to handle flow of all mentioned types of codecs (here 0 and 2) if reserveValu is set in the request. > > What about the case where there is 2 or more media lines in a Session > Decriptor > ie) > > m= audio ... 2 > m= audio ... 0 > > Is this legal? > Would this quailify as a group? So if Reserved Group was True and I had 1 > session descriptor with 2 m= lines would I reserve them both? > [Shambhu]: Multiple "m-" lines are not legal in Megaco SDP. > Also is RFC3264 the model moving forward for codec negotiation?? > > Thx, > Carl > > Carl Rutter > Telica, Inc. > Building G, Suite 100 > 734 Forest Street > Marlboro, MA 01752 > Email crutter@telica.com > Voice 508-480-0909 x8178 > Fax 508-480-0922 > www.telica.com -- ------------------------------------------------------------------- Shambhu Dayal Rai sdrai@lucent.com Infosys - India SQA Team Phone:91-80-4166565 ------------------------------------------------------------------- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jan 13 08:13:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10323 for ; Mon, 13 Jan 2003 08:13:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DDR4g23714 for megaco-archive@odin.ietf.org; Mon, 13 Jan 2003 08:27:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DDR3J23711 for ; Mon, 13 Jan 2003 08:27:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10259 for ; Mon, 13 Jan 2003 08:12:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DDPLJ23565; Mon, 13 Jan 2003 08:25:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DDNjJ23497 for ; Mon, 13 Jan 2003 08:23:45 -0500 Received: from wench.telica.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10193 for ; Mon, 13 Jan 2003 08:09:35 -0500 (EST) Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Jan 2003 08:09:38 -0500 Message-ID: From: Carl Rutter To: "'Shambhu Dayal Rai'" , Carl Rutter Cc: "'megaco@ietf.org'" Subject: RE: [Megaco] Reserved Value and Reserved Group as it applies to Codec Negotiation Question Date: Mon, 13 Jan 2003 08:09:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Thx for the feedback, I wasn't sure on the multiple m= lines. I know AVD-2128 indicates that but wasn't sure if that was fully agreed on. Thx, carl -----Original Message----- From: Shambhu Dayal Rai [mailto:sdrai@lucent.com] Sent: Sunday, January 12, 2003 11:44 PM To: Carl Rutter Cc: 'megaco@ietf.org' Subject: Re: [Megaco] Reserved Value and Reserved Group as it applies to Codec Negotiation Question Hi Carl, comments inline.. Carl Rutter wrote: > > I have a few questions on these. I know this has been discussed before but > can't > remember the resolution. Does the following sound correct? > > 1) Reserve Group - Applies to a Group of Session Descriptors. If true > reserve > resources to handle say the worse case specifed > codec. > ie) > v= > . > . > m= audio ... 2 > v= > . > . > m= audio ... 0 > > Make sure we reserve for either 0 or 2. [Shambhu]: I think, Here resources should be reserved to support all session descriptors. Both 0 and 2. > 2) Reserve Value > > On the media line > m= audio ... 0 2 > > Make sure we reserve for either 0 or 2. [Shambhu]: I think, Here resources should be reserved to handle flow of all mentioned types of codecs (here 0 and 2) if reserveValu is set in the request. > > What about the case where there is 2 or more media lines in a Session > Decriptor > ie) > > m= audio ... 2 > m= audio ... 0 > > Is this legal? > Would this quailify as a group? So if Reserved Group was True and I had 1 > session descriptor with 2 m= lines would I reserve them both? > [Shambhu]: Multiple "m-" lines are not legal in Megaco SDP. > Also is RFC3264 the model moving forward for codec negotiation?? > > Thx, > Carl > > Carl Rutter > Telica, Inc. > Building G, Suite 100 > 734 Forest Street > Marlboro, MA 01752 > Email crutter@telica.com > Voice 508-480-0909 x8178 > Fax 508-480-0922 > www.telica.com -- ------------------------------------------------------------------- Shambhu Dayal Rai sdrai@lucent.com Infosys - India SQA Team Phone:91-80-4166565 ------------------------------------------------------------------- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jan 13 09:31:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11850 for ; Mon, 13 Jan 2003 09:31:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DEgJJ28849; Mon, 13 Jan 2003 09:42:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DEdOJ28725 for ; Mon, 13 Jan 2003 09:39:24 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11722 for ; Mon, 13 Jan 2003 09:25:12 -0500 (EST) From: ckaushik@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0DERJj22928 for ; Mon, 13 Jan 2003 19:57:19 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0DERIM22922 for ; Mon, 13 Jan 2003 19:57:18 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h0DETTJ09115 for ; Mon, 13 Jan 2003 19:59:29 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CAD.004ED791 ; Mon, 13 Jan 2003 19:51:09 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CAD.004ED764.00@sandesh.hss.hns.com> Date: Mon, 13 Jan 2003 20:00:47 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Query regarding the transport parameters for sending responses Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, According to the protocol "Responses must be sent to the address and port from which the corresponding commands were sent." Is there similar restriction also on the address used for sending responses i.e. should the address used for sending response be the same as the one on which the indication was received. e.g. If the transport parameters of MGC are MGC_IP1(IP address) and MGC_P1(Port number) and that of MG are MG_IP1 and MG_P1. Indication from MG is received at the MGC at MGC_IP1 and MGC_P1. Is it mandated that MGC should use the same socket i.e. with transport parameters as MGC_IP1 and MGC_P1 to send the response? OR MGC can also send the response from a different socket with transport parameters MGC_IP2 and MGC_P2? Thanks and Regards, Chintan... DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jan 13 09:31:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11868 for ; Mon, 13 Jan 2003 09:31:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DEjOM28945 for megaco-archive@odin.ietf.org; Mon, 13 Jan 2003 09:45:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DEjOJ28942 for ; Mon, 13 Jan 2003 09:45:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11864 for ; Mon, 13 Jan 2003 09:31:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DEgJJ28849; Mon, 13 Jan 2003 09:42:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DEdOJ28725 for ; Mon, 13 Jan 2003 09:39:24 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11722 for ; Mon, 13 Jan 2003 09:25:12 -0500 (EST) From: ckaushik@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0DERJj22928 for ; Mon, 13 Jan 2003 19:57:19 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0DERIM22922 for ; Mon, 13 Jan 2003 19:57:18 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h0DETTJ09115 for ; Mon, 13 Jan 2003 19:59:29 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CAD.004ED791 ; Mon, 13 Jan 2003 19:51:09 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CAD.004ED764.00@sandesh.hss.hns.com> Date: Mon, 13 Jan 2003 20:00:47 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Query regarding the transport parameters for sending responses Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, According to the protocol "Responses must be sent to the address and port from which the corresponding commands were sent." Is there similar restriction also on the address used for sending responses i.e. should the address used for sending response be the same as the one on which the indication was received. e.g. If the transport parameters of MGC are MGC_IP1(IP address) and MGC_P1(Port number) and that of MG are MG_IP1 and MG_P1. Indication from MG is received at the MGC at MGC_IP1 and MGC_P1. Is it mandated that MGC should use the same socket i.e. with transport parameters as MGC_IP1 and MGC_P1 to send the response? OR MGC can also send the response from a different socket with transport parameters MGC_IP2 and MGC_P2? Thanks and Regards, Chintan... DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jan 13 10:37:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13720 for ; Mon, 13 Jan 2003 10:37:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DFnsJ00642; Mon, 13 Jan 2003 10:49:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DFkGJ00465 for ; Mon, 13 Jan 2003 10:46:16 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13420 for ; Mon, 13 Jan 2003 10:32:03 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0DFZF019821; Mon, 13 Jan 2003 10:35:15 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Jan 2003 10:35:30 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E140@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'ckaushik@hss.hns.com'" , megaco@ietf.org Subject: RE: [Megaco] Query regarding the transport parameters for sending responses Date: Mon, 13 Jan 2003 10:35:09 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Megaco doesn't impose any restriction on the source address, but other considerations such as NAT traversal may do so. > -----Original Message----- > From: ckaushik@hss.hns.com [mailto:ckaushik@hss.hns.com] > Sent: Monday, January 13, 2003 9:31 AM > To: megaco@ietf.org > Subject: [Megaco] Query regarding the transport parameters > for sending responses > > > > > > Hi, > According to the protocol "Responses must be sent to the > address and port from which the corresponding commands were > sent." Is there similar restriction also on the address used > for sending responses i.e. should the address used for > sending response be the same as the one on which the > indication was received. e.g. If the transport parameters of > MGC are MGC_IP1(IP address) and MGC_P1(Port > number) > and that of MG are MG_IP1 and MG_P1. Indication from MG is > received at the MGC at MGC_IP1 and MGC_P1. Is it mandated > that MGC should use the same socket i.e. with transport > parameters as MGC_IP1 and MGC_P1 to send the response? OR MGC > can also send the response from a different socket with > transport parameters MGC_IP2 and MGC_P2? > > Thanks and Regards, > Chintan... > > DISCLAIMER: This message is proprietary to Hughes Software > Systems Limited (HSS) and is intended solely for the use of > the individual to whom it is addressed. It may contain > privileged or confidential information and should not be > circulated or used for any purpose other than for what it is > intended. If you have received this message in error, please > notify the originator immediately. If you are not the > intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the > contents of this message. HSS accepts no responsibility for > loss or damage arising from the use of the information > transmitted by this email including damage from virus. > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jan 13 10:37:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13759 for ; Mon, 13 Jan 2003 10:37:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DFpVI00780 for megaco-archive@odin.ietf.org; Mon, 13 Jan 2003 10:51:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DFpUJ00777 for ; Mon, 13 Jan 2003 10:51:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13734 for ; Mon, 13 Jan 2003 10:37:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DFnsJ00642; Mon, 13 Jan 2003 10:49:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DFkGJ00465 for ; Mon, 13 Jan 2003 10:46:16 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13420 for ; Mon, 13 Jan 2003 10:32:03 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0DFZF019821; Mon, 13 Jan 2003 10:35:15 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Jan 2003 10:35:30 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E140@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'ckaushik@hss.hns.com'" , megaco@ietf.org Subject: RE: [Megaco] Query regarding the transport parameters for sending responses Date: Mon, 13 Jan 2003 10:35:09 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Megaco doesn't impose any restriction on the source address, but other considerations such as NAT traversal may do so. > -----Original Message----- > From: ckaushik@hss.hns.com [mailto:ckaushik@hss.hns.com] > Sent: Monday, January 13, 2003 9:31 AM > To: megaco@ietf.org > Subject: [Megaco] Query regarding the transport parameters > for sending responses > > > > > > Hi, > According to the protocol "Responses must be sent to the > address and port from which the corresponding commands were > sent." Is there similar restriction also on the address used > for sending responses i.e. should the address used for > sending response be the same as the one on which the > indication was received. e.g. If the transport parameters of > MGC are MGC_IP1(IP address) and MGC_P1(Port > number) > and that of MG are MG_IP1 and MG_P1. Indication from MG is > received at the MGC at MGC_IP1 and MGC_P1. Is it mandated > that MGC should use the same socket i.e. with transport > parameters as MGC_IP1 and MGC_P1 to send the response? OR MGC > can also send the response from a different socket with > transport parameters MGC_IP2 and MGC_P2? > > Thanks and Regards, > Chintan... > > DISCLAIMER: This message is proprietary to Hughes Software > Systems Limited (HSS) and is intended solely for the use of > the individual to whom it is addressed. It may contain > privileged or confidential information and should not be > circulated or used for any purpose other than for what it is > intended. If you have received this message in error, please > notify the originator immediately. If you are not the > intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the > contents of this message. HSS accepts no responsibility for > loss or damage arising from the use of the information > transmitted by this email including damage from virus. > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jan 13 22:40:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03636 for ; Mon, 13 Jan 2003 22:40:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3rmJ14144; Mon, 13 Jan 2003 22:53:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3ptJ14059 for ; Mon, 13 Jan 2003 22:51:55 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03518 for ; Mon, 13 Jan 2003 22:37:27 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0E3ecKV014041; Tue, 14 Jan 2003 04:40:38 +0100 (MET) Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZQ1GN56M; Tue, 14 Jan 2003 04:40:38 +0100 Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA27045; Tue, 14 Jan 2003 04:40:37 +0100 (MET) Received: from ericsson.com.au ([146.11.233.193]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA12257; Tue, 14 Jan 2003 04:40:34 +0100 (MET) Message-ID: <3E23511B.6475510E@ericsson.com.au> Date: Tue, 14 Jan 2003 10:51:55 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom-PT Taylor CC: "'Carl Rutter'" , "'megaco@ietf.org'" , Kang-Sen Lu , Kevin Boyle Subject: Re: [Megaco] Question on Section 7.1.18 Megaco V2 References: <4D79C746863DD51197690002A52CDA000400E107@zcard0kc.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit G'Day Tom and Carl, I had always read this to mean that you should not use * wilcard in both of the T1,T2 positions that refer to the same terminations. I think the construction (T*,T2,oneway) where only one of the T1,T2 positions is * wildcarded is useful. Maybe this is something for the IG? Regards, Christian Tom-PT Taylor wrote: > > I would agree with you. Wildcarding is only permitted in this case in the > form of partially-specified names. Not sure how useful that is. > > > -----Original Message----- > > From: Carl Rutter [mailto:crutter@telica.com] > > Sent: Tuesday, January 07, 2003 11:37 AM > > To: 'megaco@ietf.org' > > Cc: Kang-Sen Lu > > Subject: [Megaco] Question on Section 7.1.18 Megaco V2 > > > > > > We need some clarifcation on the following statement: > > > > (T1, T2, oneway) means that the Terminations that match T2 > > receive media from the Terminations matching T1, but not vice > > versa. In this case use of the ALL wildcard such that there > > are Terminations that match both T1 and T2 is not allowed. > > > > The line in question is "... such that there are Terminations > > that match both T1 and T2 is not allowed" > > > > The way we read it this clause disproves the use of Wildcard > > (*,T2,Oneway) becuase T2 will match * and T2. Hence the > > statement "Terminations that match both T1 and T2 is not > > allowed", excludes us from doing this. Is this correct? > > > > > > Thx, > > Carl > > > > Carl Rutter > > Telica, Inc. > > Building G, Suite 100 > > 734 Forest Street > > Marlboro, MA 01752 > > Email crutter@telica.com > > Voice 508-480-0909 x8178 > > Fax 508-480-0922 > > www.telica.com > > > > > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jan 13 22:41:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03678 for ; Mon, 13 Jan 2003 22:41:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3s9J14190; Mon, 13 Jan 2003 22:54:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3qAJ14078 for ; Mon, 13 Jan 2003 22:52:10 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03525 for ; Mon, 13 Jan 2003 22:37:43 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0E3esKV014082; Tue, 14 Jan 2003 04:40:54 +0100 (MET) Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNMNCFN; Tue, 14 Jan 2003 04:40:54 +0100 Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA27061; Tue, 14 Jan 2003 04:40:54 +0100 (MET) Received: from ericsson.com.au ([146.11.233.193]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA12273; Tue, 14 Jan 2003 04:40:52 +0100 (MET) Message-ID: <3E235518.26D531FC@ericsson.com.au> Date: Tue, 14 Jan 2003 11:08:56 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: gsachin@hss.hns.com CC: megaco@ietf.org Subject: Re: [Megaco] Stream 0 References: <65256CA6.00398486.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Please look under 7.1.9 Event Descriptor 2nd paragraph about defaults. Christian gsachin@hss.hns.com wrote: > > Hi List, > > Stream ID 0 is speficied in the protocol as > "not related to a particular media stream" for event detection and signal > application. > > According to the Grammar, 0 is a valid Stream ID. > Can somebody tell in what scenarios MGC can specify streamID as 0 and > what what will it refer to (by StreamID 0) > > Regards > Sachin Gupta > > DISCLAIMER: This message is proprietary to Hughes Software Systems > Limited (HSS) and is intended solely for the use of the individual > to whom it is addressed. It may contain privileged or confidential > information and should not be circulated or used for any purpose other > than for what it is intended. If you have received this message in error, > please notify the originator immediately. If you are not the intended > recipient, you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. HSS accepts > no responsibility for loss or damage arising from the use of the information > transmitted by this email including damage from virus. > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jan 13 22:41:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03697 for ; Mon, 13 Jan 2003 22:41:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0E3t5s14364 for megaco-archive@odin.ietf.org; Mon, 13 Jan 2003 22:55:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3t5J14361 for ; Mon, 13 Jan 2003 22:55:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03652 for ; Mon, 13 Jan 2003 22:40:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3rmJ14144; Mon, 13 Jan 2003 22:53:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3ptJ14059 for ; Mon, 13 Jan 2003 22:51:55 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03518 for ; Mon, 13 Jan 2003 22:37:27 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0E3ecKV014041; Tue, 14 Jan 2003 04:40:38 +0100 (MET) Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZQ1GN56M; Tue, 14 Jan 2003 04:40:38 +0100 Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA27045; Tue, 14 Jan 2003 04:40:37 +0100 (MET) Received: from ericsson.com.au ([146.11.233.193]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA12257; Tue, 14 Jan 2003 04:40:34 +0100 (MET) Message-ID: <3E23511B.6475510E@ericsson.com.au> Date: Tue, 14 Jan 2003 10:51:55 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom-PT Taylor CC: "'Carl Rutter'" , "'megaco@ietf.org'" , Kang-Sen Lu , Kevin Boyle Subject: Re: [Megaco] Question on Section 7.1.18 Megaco V2 References: <4D79C746863DD51197690002A52CDA000400E107@zcard0kc.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit G'Day Tom and Carl, I had always read this to mean that you should not use * wilcard in both of the T1,T2 positions that refer to the same terminations. I think the construction (T*,T2,oneway) where only one of the T1,T2 positions is * wildcarded is useful. Maybe this is something for the IG? Regards, Christian Tom-PT Taylor wrote: > > I would agree with you. Wildcarding is only permitted in this case in the > form of partially-specified names. Not sure how useful that is. > > > -----Original Message----- > > From: Carl Rutter [mailto:crutter@telica.com] > > Sent: Tuesday, January 07, 2003 11:37 AM > > To: 'megaco@ietf.org' > > Cc: Kang-Sen Lu > > Subject: [Megaco] Question on Section 7.1.18 Megaco V2 > > > > > > We need some clarifcation on the following statement: > > > > (T1, T2, oneway) means that the Terminations that match T2 > > receive media from the Terminations matching T1, but not vice > > versa. In this case use of the ALL wildcard such that there > > are Terminations that match both T1 and T2 is not allowed. > > > > The line in question is "... such that there are Terminations > > that match both T1 and T2 is not allowed" > > > > The way we read it this clause disproves the use of Wildcard > > (*,T2,Oneway) becuase T2 will match * and T2. Hence the > > statement "Terminations that match both T1 and T2 is not > > allowed", excludes us from doing this. Is this correct? > > > > > > Thx, > > Carl > > > > Carl Rutter > > Telica, Inc. > > Building G, Suite 100 > > 734 Forest Street > > Marlboro, MA 01752 > > Email crutter@telica.com > > Voice 508-480-0909 x8178 > > Fax 508-480-0922 > > www.telica.com > > > > > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jan 13 22:41:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03710 for ; Mon, 13 Jan 2003 22:41:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3sNJ14239; Mon, 13 Jan 2003 22:54:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3qIJ14089 for ; Mon, 13 Jan 2003 22:52:18 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03534 for ; Mon, 13 Jan 2003 22:37:51 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0E3f4KV014102; Tue, 14 Jan 2003 04:41:04 +0100 (MET) Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZQ1GN57N; Tue, 14 Jan 2003 04:41:04 +0100 Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA27069; Tue, 14 Jan 2003 04:41:03 +0100 (MET) Received: from ericsson.com.au ([146.11.233.193]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA12281; Tue, 14 Jan 2003 04:41:01 +0100 (MET) Message-ID: <3E2357BD.AB5A275C@ericsson.com.au> Date: Tue, 14 Jan 2003 11:20:13 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom-PT Taylor CC: "'Garber, Zeev'" , megaco@ietf.org Subject: Re: [Megaco] Error handling on MG References: <4D79C746863DD51197690002A52CDA000400E108@zcard0kc.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit G'Day, Please see my responses below marked [CHG]. Christian Tom-PT Taylor wrote: > > Hello. See below marked with [PTT]. > > > -----Original Message----- > > From: Garber, Zeev [mailto:zgarber@empirix.com] > > Sent: Tuesday, January 07, 2003 3:06 PM > > To: megaco@ietf.org > > Subject: [Megaco] Error handling on MG > > > > > > Hi All, > > > > Lets consider following scenario: > > > > MGC requests MG to Add physical and ephemeral($) terminations > > to newly created context($). MG realizes that physical > > termination is already added to another context. It responds > > with AddReply containing Error Descriptor . > > > > 2 questions: > > > > What is a context Id in response for the first Add command: $ > > or some new context Id? > > [PTT] I would certainly not use a specific context ID, since it is > irrelevant. I am hesitating between $ for simplicity or null. We've > already heard one vote for $. Any other opinions? [CHG] I would return what was in the request ie. $ H.248.8 (Annex L) "4.1.2.14 Error Code # : 433 Name: TerminationID is already in a Context" gives guidance also what ContextID to place in the error descriptor. > > > > > What if Physical termination was successfully added to the > > context but ephemeral wasn't (due to resource limitation for > > example). What should be the ephemeral termination id in > > response $ or some new termination Id? > > [PTT] Again, a specific termination ID would be irrelevant and misleading. > Go with $. [CHG] Agreed > > > > > Thanks a lot, > > > Ze`ev Garber > > > Software Engineer > > > Communications Infrastructure Test Group > > > p| 978.661.1211 f| 978.988.0148 > > > email | zgarber@empirix.com > > > 205 Lowell Street | Wilmington, MA | 01887 > > > E M P I R I X > > > www.empirix.com > > > > > > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jan 13 22:41:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03713 for ; Mon, 13 Jan 2003 22:41:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3s3J14168; Mon, 13 Jan 2003 22:54:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3q2J14073 for ; Mon, 13 Jan 2003 22:52:02 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03522 for ; Mon, 13 Jan 2003 22:37:35 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0E3ekAv001766; Tue, 14 Jan 2003 04:40:47 +0100 (MET) Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNCVXL4; Tue, 14 Jan 2003 04:40:46 +0100 Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA27053; Tue, 14 Jan 2003 04:40:45 +0100 (MET) Received: from ericsson.com.au ([146.11.233.193]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA12265; Tue, 14 Jan 2003 04:40:43 +0100 (MET) Message-ID: <3E235367.1E72F0E0@ericsson.com.au> Date: Tue, 14 Jan 2003 11:01:43 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: gokulc@future.futsoft.com CC: "'ForumMEGACO'" Subject: Re: [Megaco] Response for Fully specified parameter in request References: <001301c2ad6d$94c56480$3607020a@future.futsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Gokul, I believe the behaviour which we adoopt in Megaco is that we are conservative with what we send and liberal with what we receive. So I would say that as a MGC you should be prepared for the case where you get fully specified response and as a MG you should probably not send these fully specified responses. This is to minimise error generation. Christian gokulc wrote: > > Hi, > > As per the ABNF all the parameters in the reply are valid. Now the question > is if a Reply were received containing a parameter that was fully specified > in the corresponding request, would it be regarded as invalid reply. I do > not see any section in RFC 3015, which says so explicitly. Expecting > clarification > > Regards > gokul > > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jan 13 22:41:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03719 for ; Mon, 13 Jan 2003 22:41:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3sGJ14211; Mon, 13 Jan 2003 22:54:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3qDJ14082 for ; Mon, 13 Jan 2003 22:52:13 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03528 for ; Mon, 13 Jan 2003 22:37:46 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0E3f0KV014092; Tue, 14 Jan 2003 04:41:00 +0100 (MET) Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZQ1GN57D; Tue, 14 Jan 2003 04:40:59 +0100 Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA27065; Tue, 14 Jan 2003 04:40:59 +0100 (MET) Received: from ericsson.com.au ([146.11.233.193]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA12277; Tue, 14 Jan 2003 04:40:56 +0100 (MET) Message-ID: <3E23563E.BE65F37D@ericsson.com.au> Date: Tue, 14 Jan 2003 11:13:50 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom-PT Taylor CC: "'mukta vasudeva'" , "'Alan Chou'" , megaco@ietf.org Subject: Re: [Megaco] Signal Descriptor Doubts References: <4D79C746863DD51197690002A52CDA000400E0F4@zcard0kc.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit G'Day Tom, I pretty much see it as you have described. I don't think there is a big overhead in keeping the signal descriptor. You certainly need to be able to keep it for the period of time whilst the signal is playing. So whilst it not optimal I don't think its an error either. Regards, Christian Tom-PT Taylor wrote: > > This is more or less the same question Alan Chou raised a week ago. It's > not something I ever thought about, but here is the situation as I see it: > -- the Signals Descriptor remains unchanged, even if the signal(s) it > describes have been terminated > -- the MG is required to maintain the knowledge of which signals have been > terminated and which have not > -- we have no way in general to indicate on audit which signals have > completed and which have not. This was probably a mistake in design. > > -----Original Message----- > From: mukta vasudeva [mailto:reachtomukta@yahoo.co.in] > Sent: Monday, January 06, 2003 9:00 AM > To: megaco@ietf.org > Subject: [Megaco] Signal Descriptor Doubts > > hi , > Hope everyone had a good Christmas and will have a wonderfull new year > ahead. > I have some doubts related to Signal Descriptor handling. > 1. > RFC Section 7.1.11 states that > "Production of a Signal on a Termination is stopped by application of > a new Signals Descriptor, or detection of an Event on the Termination ." > > Also, > "A new Signals Descriptor replaces any existing Signals Descriptor." > > Q: The MG maintains the current signal descriptor until a > new descriptor is not sent by the MGC. But, after the termination > finishes the playout of the signal or an event is detected and the > signals are stopped, the signal descriptor remains the current one > with MG until new one is received as according to the rules we cannot > remove it until new signal descriptor is received. > But my doubt is why should we maintain this descriptor since it has already > become deactivated(either by finishing playout or event stopped it) and MGC > cannot instruct MG to use it further ??. > > Thanks , > regards , > Mukta Vasudeva > > Catch all the cricket action. Download Yahoo! Score tracker > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jan 13 22:41:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03762 for ; Mon, 13 Jan 2003 22:41:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3sUJ14268; Mon, 13 Jan 2003 22:54:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3qGJ14086 for ; Mon, 13 Jan 2003 22:52:16 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03531 for ; Mon, 13 Jan 2003 22:37:49 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0E3eoKV014078; Tue, 14 Jan 2003 04:40:52 +0100 (MET) Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNMNCFH; Tue, 14 Jan 2003 04:40:50 +0100 Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA27057; Tue, 14 Jan 2003 04:40:50 +0100 (MET) Received: from ericsson.com.au ([146.11.233.193]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA12269; Tue, 14 Jan 2003 04:40:47 +0100 (MET) Message-ID: <3E235403.6D20097@ericsson.com.au> Date: Tue, 14 Jan 2003 11:04:19 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Noh Jeong Min CC: =?iso-8859-1?Q?=C0=D3=C0=E7=C8=AF?= , megaco@ietf.org Subject: Re: [Megaco] What profile should I comply with when I implement Trunk Gate Way? References: <20021226170002.2547.10054.Mailman@www1.ietf.org> <001e01c2ae0d$2e119fb0$2003a8c0@jhlim2> <000f01c2b1f8$3a61f820$e51185a5@LocalHost> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by al.edt.ericsson.se id EAA27057 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0E3qKJ14094 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Given the lack of specification in the profiles and the expired drafts and specification I would rather state what packages and procedures I support rather than any particular profile. In short I don't think there is a profile that would suit your needs. Christian Noh Jeong Min wrote: > > Hi everybody. I wish your happy new year. > > I think you should refer the Multiservice Switching Forum(MSF, http://www.msforum.org )'s implement agreements and profiles. > The 3 profiles for Media Gateway(TG,AG) published by the MSF. > > And, the technical information documents of Global MSF Interperability(GMI) are also useful to define your Trunk Gateway. > > Noh Jeong Min. > IMT System Development Group. > MERCURY Corporation. Ltd. > Tel : +82 031 310 5714, +82 031 310 5718 > Email : hmask@mercurykr.com > > > ----- Original Message ----- > From: "임재환" > To: > Sent: Saturday, December 28, 2002 10:05 AM > Subject: [Megaco] What profile should I comply with when I implement Trunk Gate Way? > > > Hello everyone! > > > > What profile should I comply with when I implement Trunk Gate Way(TGW)? > > > > My trunk Gate Way has some E1 trunk interfaces on switch circuit Network > > side and fast or giga ethernet interface on packet network side. Also, it > > can have ATM interface on packet network side alternatively. > > > > Thank you for reading my question. > > > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jan 13 22:41:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03781 for ; Mon, 13 Jan 2003 22:41:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0E3tVs14405 for megaco-archive@odin.ietf.org; Mon, 13 Jan 2003 22:55:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3tVJ14402 for ; Mon, 13 Jan 2003 22:55:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03693 for ; Mon, 13 Jan 2003 22:41:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3s9J14190; Mon, 13 Jan 2003 22:54:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3qAJ14078 for ; Mon, 13 Jan 2003 22:52:10 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03525 for ; Mon, 13 Jan 2003 22:37:43 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0E3esKV014082; Tue, 14 Jan 2003 04:40:54 +0100 (MET) Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNMNCFN; Tue, 14 Jan 2003 04:40:54 +0100 Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA27061; Tue, 14 Jan 2003 04:40:54 +0100 (MET) Received: from ericsson.com.au ([146.11.233.193]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA12273; Tue, 14 Jan 2003 04:40:52 +0100 (MET) Message-ID: <3E235518.26D531FC@ericsson.com.au> Date: Tue, 14 Jan 2003 11:08:56 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: gsachin@hss.hns.com CC: megaco@ietf.org Subject: Re: [Megaco] Stream 0 References: <65256CA6.00398486.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Please look under 7.1.9 Event Descriptor 2nd paragraph about defaults. Christian gsachin@hss.hns.com wrote: > > Hi List, > > Stream ID 0 is speficied in the protocol as > "not related to a particular media stream" for event detection and signal > application. > > According to the Grammar, 0 is a valid Stream ID. > Can somebody tell in what scenarios MGC can specify streamID as 0 and > what what will it refer to (by StreamID 0) > > Regards > Sachin Gupta > > DISCLAIMER: This message is proprietary to Hughes Software Systems > Limited (HSS) and is intended solely for the use of the individual > to whom it is addressed. It may contain privileged or confidential > information and should not be circulated or used for any purpose other > than for what it is intended. If you have received this message in error, > please notify the originator immediately. If you are not the intended > recipient, you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. HSS accepts > no responsibility for loss or damage arising from the use of the information > transmitted by this email including damage from virus. > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jan 13 22:41:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03797 for ; Mon, 13 Jan 2003 22:41:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0E3tfc14420 for megaco-archive@odin.ietf.org; Mon, 13 Jan 2003 22:55:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3tfJ14417 for ; Mon, 13 Jan 2003 22:55:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03724 for ; Mon, 13 Jan 2003 22:41:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3sNJ14239; Mon, 13 Jan 2003 22:54:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3qIJ14089 for ; Mon, 13 Jan 2003 22:52:18 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03534 for ; Mon, 13 Jan 2003 22:37:51 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0E3f4KV014102; Tue, 14 Jan 2003 04:41:04 +0100 (MET) Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZQ1GN57N; Tue, 14 Jan 2003 04:41:04 +0100 Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA27069; Tue, 14 Jan 2003 04:41:03 +0100 (MET) Received: from ericsson.com.au ([146.11.233.193]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA12281; Tue, 14 Jan 2003 04:41:01 +0100 (MET) Message-ID: <3E2357BD.AB5A275C@ericsson.com.au> Date: Tue, 14 Jan 2003 11:20:13 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom-PT Taylor CC: "'Garber, Zeev'" , megaco@ietf.org Subject: Re: [Megaco] Error handling on MG References: <4D79C746863DD51197690002A52CDA000400E108@zcard0kc.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit G'Day, Please see my responses below marked [CHG]. Christian Tom-PT Taylor wrote: > > Hello. See below marked with [PTT]. > > > -----Original Message----- > > From: Garber, Zeev [mailto:zgarber@empirix.com] > > Sent: Tuesday, January 07, 2003 3:06 PM > > To: megaco@ietf.org > > Subject: [Megaco] Error handling on MG > > > > > > Hi All, > > > > Lets consider following scenario: > > > > MGC requests MG to Add physical and ephemeral($) terminations > > to newly created context($). MG realizes that physical > > termination is already added to another context. It responds > > with AddReply containing Error Descriptor . > > > > 2 questions: > > > > What is a context Id in response for the first Add command: $ > > or some new context Id? > > [PTT] I would certainly not use a specific context ID, since it is > irrelevant. I am hesitating between $ for simplicity or null. We've > already heard one vote for $. Any other opinions? [CHG] I would return what was in the request ie. $ H.248.8 (Annex L) "4.1.2.14 Error Code # : 433 Name: TerminationID is already in a Context" gives guidance also what ContextID to place in the error descriptor. > > > > > What if Physical termination was successfully added to the > > context but ephemeral wasn't (due to resource limitation for > > example). What should be the ephemeral termination id in > > response $ or some new termination Id? > > [PTT] Again, a specific termination ID would be irrelevant and misleading. > Go with $. [CHG] Agreed > > > > > Thanks a lot, > > > Ze`ev Garber > > > Software Engineer > > > Communications Infrastructure Test Group > > > p| 978.661.1211 f| 978.988.0148 > > > email | zgarber@empirix.com > > > 205 Lowell Street | Wilmington, MA | 01887 > > > E M P I R I X > > > www.empirix.com > > > > > > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jan 13 22:41:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03811 for ; Mon, 13 Jan 2003 22:41:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0E3tg314450 for megaco-archive@odin.ietf.org; Mon, 13 Jan 2003 22:55:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3tgJ14438 for ; Mon, 13 Jan 2003 22:55:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03754 for ; Mon, 13 Jan 2003 22:41:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3sGJ14211; Mon, 13 Jan 2003 22:54:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3qDJ14082 for ; Mon, 13 Jan 2003 22:52:13 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03528 for ; Mon, 13 Jan 2003 22:37:46 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0E3f0KV014092; Tue, 14 Jan 2003 04:41:00 +0100 (MET) Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZQ1GN57D; Tue, 14 Jan 2003 04:40:59 +0100 Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA27065; Tue, 14 Jan 2003 04:40:59 +0100 (MET) Received: from ericsson.com.au ([146.11.233.193]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA12277; Tue, 14 Jan 2003 04:40:56 +0100 (MET) Message-ID: <3E23563E.BE65F37D@ericsson.com.au> Date: Tue, 14 Jan 2003 11:13:50 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom-PT Taylor CC: "'mukta vasudeva'" , "'Alan Chou'" , megaco@ietf.org Subject: Re: [Megaco] Signal Descriptor Doubts References: <4D79C746863DD51197690002A52CDA000400E0F4@zcard0kc.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit G'Day Tom, I pretty much see it as you have described. I don't think there is a big overhead in keeping the signal descriptor. You certainly need to be able to keep it for the period of time whilst the signal is playing. So whilst it not optimal I don't think its an error either. Regards, Christian Tom-PT Taylor wrote: > > This is more or less the same question Alan Chou raised a week ago. It's > not something I ever thought about, but here is the situation as I see it: > -- the Signals Descriptor remains unchanged, even if the signal(s) it > describes have been terminated > -- the MG is required to maintain the knowledge of which signals have been > terminated and which have not > -- we have no way in general to indicate on audit which signals have > completed and which have not. This was probably a mistake in design. > > -----Original Message----- > From: mukta vasudeva [mailto:reachtomukta@yahoo.co.in] > Sent: Monday, January 06, 2003 9:00 AM > To: megaco@ietf.org > Subject: [Megaco] Signal Descriptor Doubts > > hi , > Hope everyone had a good Christmas and will have a wonderfull new year > ahead. > I have some doubts related to Signal Descriptor handling. > 1. > RFC Section 7.1.11 states that > "Production of a Signal on a Termination is stopped by application of > a new Signals Descriptor, or detection of an Event on the Termination ." > > Also, > "A new Signals Descriptor replaces any existing Signals Descriptor." > > Q: The MG maintains the current signal descriptor until a > new descriptor is not sent by the MGC. But, after the termination > finishes the playout of the signal or an event is detected and the > signals are stopped, the signal descriptor remains the current one > with MG until new one is received as according to the rules we cannot > remove it until new signal descriptor is received. > But my doubt is why should we maintain this descriptor since it has already > become deactivated(either by finishing playout or event stopped it) and MGC > cannot instruct MG to use it further ??. > > Thanks , > regards , > Mukta Vasudeva > > Catch all the cricket action. Download Yahoo! Score tracker > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jan 13 22:41:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03835 for ; Mon, 13 Jan 2003 22:41:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3snJ14324; Mon, 13 Jan 2003 22:54:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3qUJ14099 for ; Mon, 13 Jan 2003 22:52:30 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03541 for ; Mon, 13 Jan 2003 22:38:03 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0E3fGKV014123; Tue, 14 Jan 2003 04:41:16 +0100 (MET) Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNCVX3L; Tue, 14 Jan 2003 04:41:16 +0100 Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA27081; Tue, 14 Jan 2003 04:41:15 +0100 (MET) Received: from ericsson.com.au ([146.11.233.193]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA12293; Tue, 14 Jan 2003 04:41:13 +0100 (MET) Message-ID: <3E235BB4.74662605@ericsson.com.au> Date: Tue, 14 Jan 2003 11:37:08 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Anil Jangam CC: Fernando Vallejo Lazaro , Megaco Subject: Re: [Megaco] two transactions in the same message References: <3DD0B7DF.12E59234@alcatel.es> <004601c28a29$dd03a110$1606050a@mahindrabt.com> <01a601c2b098$19d4a8c0$1606050a@mahindrabt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Anil, A message is just an envelope so it is possible to have a reply and request in the same message. Christian _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jan 13 22:41:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03851 for ; Mon, 13 Jan 2003 22:41:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0E3tkn14466 for megaco-archive@odin.ietf.org; Mon, 13 Jan 2003 22:55:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3tkJ14462 for ; Mon, 13 Jan 2003 22:55:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03776 for ; Mon, 13 Jan 2003 22:41:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3sUJ14268; Mon, 13 Jan 2003 22:54:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3qGJ14086 for ; Mon, 13 Jan 2003 22:52:16 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03531 for ; Mon, 13 Jan 2003 22:37:49 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0E3eoKV014078; Tue, 14 Jan 2003 04:40:52 +0100 (MET) Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNMNCFH; Tue, 14 Jan 2003 04:40:50 +0100 Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA27057; Tue, 14 Jan 2003 04:40:50 +0100 (MET) Received: from ericsson.com.au ([146.11.233.193]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA12269; Tue, 14 Jan 2003 04:40:47 +0100 (MET) Message-ID: <3E235403.6D20097@ericsson.com.au> Date: Tue, 14 Jan 2003 11:04:19 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Noh Jeong Min CC: =?iso-8859-1?Q?=C0=D3=C0=E7=C8=AF?= , megaco@ietf.org Subject: Re: [Megaco] What profile should I comply with when I implement Trunk Gate Way? References: <20021226170002.2547.10054.Mailman@www1.ietf.org> <001e01c2ae0d$2e119fb0$2003a8c0@jhlim2> <000f01c2b1f8$3a61f820$e51185a5@LocalHost> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by al.edt.ericsson.se id EAA27057 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0E3qKJ14094 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Given the lack of specification in the profiles and the expired drafts and specification I would rather state what packages and procedures I support rather than any particular profile. In short I don't think there is a profile that would suit your needs. Christian Noh Jeong Min wrote: > > Hi everybody. I wish your happy new year. > > I think you should refer the Multiservice Switching Forum(MSF, http://www.msforum.org )'s implement agreements and profiles. > The 3 profiles for Media Gateway(TG,AG) published by the MSF. > > And, the technical information documents of Global MSF Interperability(GMI) are also useful to define your Trunk Gateway. > > Noh Jeong Min. > IMT System Development Group. > MERCURY Corporation. Ltd. > Tel : +82 031 310 5714, +82 031 310 5718 > Email : hmask@mercurykr.com > > > ----- Original Message ----- > From: "임재환" > To: > Sent: Saturday, December 28, 2002 10:05 AM > Subject: [Megaco] What profile should I comply with when I implement Trunk Gate Way? > > > Hello everyone! > > > > What profile should I comply with when I implement Trunk Gate Way(TGW)? > > > > My trunk Gate Way has some E1 trunk interfaces on switch circuit Network > > side and fast or giga ethernet interface on packet network side. Also, it > > can have ATM interface on packet network side alternatively. > > > > Thank you for reading my question. > > > > > > _______________________________________________ > > 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 Jan 13 22:41:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03866 for ; Mon, 13 Jan 2003 22:41:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3shJ14297; Mon, 13 Jan 2003 22:54:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3qKJ14093 for ; Mon, 13 Jan 2003 22:52:20 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03538 for ; Mon, 13 Jan 2003 22:37:53 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0E3fCAv001787; Tue, 14 Jan 2003 04:41:12 +0100 (MET) Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNMNCGN; Tue, 14 Jan 2003 04:41:12 +0100 Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA27077; Tue, 14 Jan 2003 04:41:11 +0100 (MET) Received: from ericsson.com.au ([146.11.233.193]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA12289; Tue, 14 Jan 2003 04:41:09 +0100 (MET) Message-ID: <3E235B57.1D845050@ericsson.com.au> Date: Tue, 14 Jan 2003 11:35:35 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John_Poplett@3com.com CC: megaco@ietf.org Subject: Re: [Megaco] Setting T.38 on a termination with ASN.1 encoding References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit G'Day John, For BICC based networks there is some work on going in SG11 to define new values for the Acodec for T.38 as well as specifying the appropriate transport values. This will be contained in Q.765.5, Q.1970 and Q.1950. H.248.2 (Annex f) defines binary code point for fax operation. Regards, Christian John_Poplett@3com.com wrote: > > Hi. > > For an IP trunking gateway, after an MGC has determined that a fax call is > in progress for a given context, how does it modify the packet side > termination to transition from an audio codec to T.38 with ASN.1 encoding? > > Annex F provides a text example of programming a termination to use T.38. > In this example, T.38 UDPTL is specified with the session description > protocol, .e.g.: > > v=0 > c=IN IP4 124.124.124.222 > m=image 1111 udptl t38 > a=T38FaxRateManagement:transferredTCF > a=T38UdpEC:t38UDPFEC > > Annex C provides the binary mappings for various SDP properties, including > a property "acodec" for audio codecs. It seems natural to have a similar > SDP to binary mapping for T.38 but I am not aware of such. > > For binary encoding is this termination switched from an audio codec to > T.38 by setting the IPFaxTransport property of the IP Fax Package to one of > the T.38 values? > > Thanks, > > John > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jan 13 22:42:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03889 for ; Mon, 13 Jan 2003 22:42:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0E3uH014496 for megaco-archive@odin.ietf.org; Mon, 13 Jan 2003 22:56:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3uHJ14493 for ; Mon, 13 Jan 2003 22:56:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03849 for ; Mon, 13 Jan 2003 22:41:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3snJ14324; Mon, 13 Jan 2003 22:54:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3qUJ14099 for ; Mon, 13 Jan 2003 22:52:30 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03541 for ; Mon, 13 Jan 2003 22:38:03 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0E3fGKV014123; Tue, 14 Jan 2003 04:41:16 +0100 (MET) Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNCVX3L; Tue, 14 Jan 2003 04:41:16 +0100 Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA27081; Tue, 14 Jan 2003 04:41:15 +0100 (MET) Received: from ericsson.com.au ([146.11.233.193]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA12293; Tue, 14 Jan 2003 04:41:13 +0100 (MET) Message-ID: <3E235BB4.74662605@ericsson.com.au> Date: Tue, 14 Jan 2003 11:37:08 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Anil Jangam CC: Fernando Vallejo Lazaro , Megaco Subject: Re: [Megaco] two transactions in the same message References: <3DD0B7DF.12E59234@alcatel.es> <004601c28a29$dd03a110$1606050a@mahindrabt.com> <01a601c2b098$19d4a8c0$1606050a@mahindrabt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Anil, A message is just an envelope so it is possible to have a reply and request in the same message. Christian _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jan 13 22:42:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03902 for ; Mon, 13 Jan 2003 22:42:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0E3uOY14513 for megaco-archive@odin.ietf.org; Mon, 13 Jan 2003 22:56:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3uOJ14510 for ; Mon, 13 Jan 2003 22:56:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03880 for ; Mon, 13 Jan 2003 22:41:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3shJ14297; Mon, 13 Jan 2003 22:54:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3qKJ14093 for ; Mon, 13 Jan 2003 22:52:20 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03538 for ; Mon, 13 Jan 2003 22:37:53 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0E3fCAv001787; Tue, 14 Jan 2003 04:41:12 +0100 (MET) Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNMNCGN; Tue, 14 Jan 2003 04:41:12 +0100 Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA27077; Tue, 14 Jan 2003 04:41:11 +0100 (MET) Received: from ericsson.com.au ([146.11.233.193]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA12289; Tue, 14 Jan 2003 04:41:09 +0100 (MET) Message-ID: <3E235B57.1D845050@ericsson.com.au> Date: Tue, 14 Jan 2003 11:35:35 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John_Poplett@3com.com CC: megaco@ietf.org Subject: Re: [Megaco] Setting T.38 on a termination with ASN.1 encoding References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit G'Day John, For BICC based networks there is some work on going in SG11 to define new values for the Acodec for T.38 as well as specifying the appropriate transport values. This will be contained in Q.765.5, Q.1970 and Q.1950. H.248.2 (Annex f) defines binary code point for fax operation. Regards, Christian John_Poplett@3com.com wrote: > > Hi. > > For an IP trunking gateway, after an MGC has determined that a fax call is > in progress for a given context, how does it modify the packet side > termination to transition from an audio codec to T.38 with ASN.1 encoding? > > Annex F provides a text example of programming a termination to use T.38. > In this example, T.38 UDPTL is specified with the session description > protocol, .e.g.: > > v=0 > c=IN IP4 124.124.124.222 > m=image 1111 udptl t38 > a=T38FaxRateManagement:transferredTCF > a=T38UdpEC:t38UDPFEC > > Annex C provides the binary mappings for various SDP properties, including > a property "acodec" for audio codecs. It seems natural to have a similar > SDP to binary mapping for T.38 but I am not aware of such. > > For binary encoding is this termination switched from an audio codec to > T.38 by setting the IPFaxTransport property of the IP Fax Package to one of > the T.38 values? > > Thanks, > > John > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jan 13 23:41:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03810 for ; Mon, 13 Jan 2003 22:41:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0E3tgo14435 for megaco-archive@odin.ietf.org; Mon, 13 Jan 2003 22:55:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3tgJ14432 for ; Mon, 13 Jan 2003 22:55:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03735 for ; Mon, 13 Jan 2003 22:41:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3s3J14168; Mon, 13 Jan 2003 22:54:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3q2J14073 for ; Mon, 13 Jan 2003 22:52:02 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03522 for ; Mon, 13 Jan 2003 22:37:35 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0E3ekAv001766; Tue, 14 Jan 2003 04:40:47 +0100 (MET) Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNCVXL4; Tue, 14 Jan 2003 04:40:46 +0100 Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA27053; Tue, 14 Jan 2003 04:40:45 +0100 (MET) Received: from ericsson.com.au ([146.11.233.193]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA12265; Tue, 14 Jan 2003 04:40:43 +0100 (MET) Message-ID: <3E235367.1E72F0E0@ericsson.com.au> Date: Tue, 14 Jan 2003 11:01:43 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: gokulc@future.futsoft.com CC: "'ForumMEGACO'" Subject: Re: [Megaco] Response for Fully specified parameter in request References: <001301c2ad6d$94c56480$3607020a@future.futsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Gokul, I believe the behaviour which we adoopt in Megaco is that we are conservative with what we send and liberal with what we receive. So I would say that as a MGC you should be prepared for the case where you get fully specified response and as a MG you should probably not send these fully specified responses. This is to minimise error generation. Christian gokulc wrote: > > Hi, > > As per the ABNF all the parameters in the reply are valid. Now the question > is if a Reply were received containing a parameter that was fully specified > in the corresponding request, would it be regarded as invalid reply. I do > not see any section in RFC 3015, which says so explicitly. Expecting > clarification > > Regards > gokul > > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 14 00:28:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05622 for ; Tue, 14 Jan 2003 00:28:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E5f1J20834; Tue, 14 Jan 2003 00:41:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E5a6J19968 for ; Tue, 14 Jan 2003 00:36:06 -0500 Received: from web8201.mail.in.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA05342 for ; Tue, 14 Jan 2003 00:21:35 -0500 (EST) Message-ID: <20030114052454.76831.qmail@web8201.mail.in.yahoo.com> Received: from [203.200.122.90] by web8201.mail.in.yahoo.com via HTTP; Tue, 14 Jan 2003 05:24:54 GMT Date: Tue, 14 Jan 2003 05:24:54 +0000 (GMT) From: =?iso-8859-1?q?mukta=20vasudeva?= Subject: Re: [Megaco] Problem with Dgitmap event To: amaresh_ram Cc: megaco@ietf.org In-Reply-To: <200301131012.PAA08195@WS0005.indiatimes.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1194886571-1042521894=:76151" Content-Transfer-Encoding: 8bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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-1194886571-1042521894=:76151 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hi, Thanks for your response. You are right about MG dumping the event (as per processing requirements) ,if the events decriptor for that event is not there.But maybe i didnt frame my question right: Q: If MG terminations support R2 Package then, considering the given scenario,which eventof this Package would the MGC use for the notification of the last rejected event. Because the current dial string would be sent as notification for the R2Address Event. Actually i cannot find any such event in the R2 Package which could be used for such a purpose.So does such an event exist in R2 Package through which a single collected digit could be sent back to the MGC? In any case your solution applies to the MG : if events descriptor is not there,dump the event. regards , Mukta V. amaresh_ram wrote: hi, Find my comment inline as [Amaresh]. regards, Amaresh "=?iso-8859-1?q?mukta=20vasudeva?=" wrote: Hi, I have another problem: The RFC states that: 밒f no candidates remain, the latest event is removed from the current dial string and a completion event is generated indicating full match if one of the candidates from the previous step was fully satisfied before the latest event was detected, or partial match otherwise. The event removed from the current dial string will then be reported as per the currently active event processing mechanisms.� [Amaresh] This highlighted text is rephrased in the 2nd version of Megaco and it state that the event removed from the current dial string will then be reported a separate event, buffered, or discarded according to the rules described in the previous section. Please refer to the Highlighted part: Q: Lets say the MG has received Message from MGC telling it to activate detection of R2/R2Address event of the R2 Package (or it could be the DTMF Package :dd/ce completion event.). In either case when it is found that the last event is generating a Full Match,.then the Current Dial String is sent as an Observed Parameter of the Notify generated corresponding to the R2Address event. Now , the event that is mentioned in the highlighted region is the problem. How does the MG send This Event뭩 Notification? It is mentioned that MG uses the 밹urrently active event processing mechanisms.� This implies that we cannot send this event without the activation from MGC. [Amaresh] Dump this event as no event descriptor is active. For the DTMF Package this is ok, since the MGC would activate detection of the Digits Event 뻲ildcarded with choose. 3.But in case of R2 Package Which event would the MGC use to ask for this event뭩 notification? I could not find any event in R2 package which could be used for the purpose. [Amaresh] Same as 1. Thanks, Mukta Vasudeva Catch all the cricket action. Download Yahoo! Score tracker --------------------------------- Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy the best in Movies at http://www.videos.indiatimes.com Now bid just 7 Days in Advance and get Huge Discounts on Indian Airlines Flights. So log on to http://indianairlines.indiatimes.com and Bid Now ! Catch all the cricket action. Download Yahoo! Score tracker --0-1194886571-1042521894=:76151 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

hi,

Thanks for your response.

You are right about MG dumping the  event (as per processing requirements) ,if the events decriptor for that event is not there.But maybe i didnt frame my question right:

Q: If MG terminations  support R2 Package then, considering the given scenario,which eventof this Package would the MGC use for the notification of the last rejected event. Because the current dial string would be sent as notification for the R2Address Event.

Actually i cannot find any such event in the R2 Package which could be used for such a purpose.So does such an event exist in R2 Package through which a single collected digit could be sent back to the MGC?

In any case your solution applies to the MG : if events descriptor is not there,dump the event.

regards ,

Mukta V.

 

 amaresh_ram <amaresh_ram@indiatimes.com> wrote:

hi,

Find my comment inline as [Amaresh].

regards,

Amaresh

"=?iso-8859-1?q?mukta=20vasudeva?=" wrote:

 

Hi,

I have another problem:

 

The RFC states that:

�If

      no candidates remain, the latest event is removed from the

      current dial string and a completion event is generated

      indicating full match if one of the candidates from the previous

      step was fully satisfied before the latest event was detected, or

      partial match otherwise. The event removed from the current dial

      string will then be reported as per the currently active event

      processing mechanisms.�

 [Amaresh] This highlighted text is rephrased in the 2nd version of Megaco and it state that the event removed from the current dial string will then be reported a separate event, buffered, or discarded according to the rules described in the previous section.

Please refer to the Highlighted part:

Q: Lets say the MG has received Message from MGC telling it to activate detection of  R2/R2Address event of the R2 Package (or it could be the DTMF Package :dd/ce completion event.).

In either case when it is found that the last event is generating a Full Match,.then the Current Dial String is sent as an Observed Parameter of the Notify generated corresponding to the R2Address event.

Now , the event that is mentioned in the highlighted region is the problem. How does the MG send This Event뭩 Notification?

It is mentioned that MG uses the �currently active event processing mechanisms.�

  1. This implies that we cannot send this event without the activation from MGC. [Amaresh] Dump this event as no event descriptor is active.
  2. For the DTMF Package this is ok, since the MGC would activate detection of the Digits Event 뻲ildcarded with choose.

      3.But in case of R2 Package Which event would the MGC use to ask for this event뭩 notification? I could not find any event in R2 package which could be used for the purpose. [Amaresh] Same as 1.

 

Thanks,

Mukta Vasudeva

Catch all the cricket action. Download Yahoo! Score tracker

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy the best in Movies at http://www.videos.indiatimes.com
Now bid just 7 Days in Advance and get Huge Discounts on Indian Airlines Flights. So log on to http://indianairlines.indiatimes.com and Bid Now !

Catch all the cricket action. Download Yahoo! Score tracker --0-1194886571-1042521894=:76151-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 14 00:28:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05640 for ; Tue, 14 Jan 2003 00:28:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0E5gb620935 for megaco-archive@odin.ietf.org; Tue, 14 Jan 2003 00:42:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E5gaJ20932 for ; Tue, 14 Jan 2003 00:42:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05636 for ; Tue, 14 Jan 2003 00:28:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E5f1J20834; Tue, 14 Jan 2003 00:41:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E5a6J19968 for ; Tue, 14 Jan 2003 00:36:06 -0500 Received: from web8201.mail.in.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA05342 for ; Tue, 14 Jan 2003 00:21:35 -0500 (EST) Message-ID: <20030114052454.76831.qmail@web8201.mail.in.yahoo.com> Received: from [203.200.122.90] by web8201.mail.in.yahoo.com via HTTP; Tue, 14 Jan 2003 05:24:54 GMT Date: Tue, 14 Jan 2003 05:24:54 +0000 (GMT) From: =?iso-8859-1?q?mukta=20vasudeva?= Subject: Re: [Megaco] Problem with Dgitmap event To: amaresh_ram Cc: megaco@ietf.org In-Reply-To: <200301131012.PAA08195@WS0005.indiatimes.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1194886571-1042521894=:76151" Content-Transfer-Encoding: 8bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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-1194886571-1042521894=:76151 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hi, Thanks for your response. You are right about MG dumping the event (as per processing requirements) ,if the events decriptor for that event is not there.But maybe i didnt frame my question right: Q: If MG terminations support R2 Package then, considering the given scenario,which eventof this Package would the MGC use for the notification of the last rejected event. Because the current dial string would be sent as notification for the R2Address Event. Actually i cannot find any such event in the R2 Package which could be used for such a purpose.So does such an event exist in R2 Package through which a single collected digit could be sent back to the MGC? In any case your solution applies to the MG : if events descriptor is not there,dump the event. regards , Mukta V. amaresh_ram wrote: hi, Find my comment inline as [Amaresh]. regards, Amaresh "=?iso-8859-1?q?mukta=20vasudeva?=" wrote: Hi, I have another problem: The RFC states that: 밒f no candidates remain, the latest event is removed from the current dial string and a completion event is generated indicating full match if one of the candidates from the previous step was fully satisfied before the latest event was detected, or partial match otherwise. The event removed from the current dial string will then be reported as per the currently active event processing mechanisms.� [Amaresh] This highlighted text is rephrased in the 2nd version of Megaco and it state that the event removed from the current dial string will then be reported a separate event, buffered, or discarded according to the rules described in the previous section. Please refer to the Highlighted part: Q: Lets say the MG has received Message from MGC telling it to activate detection of R2/R2Address event of the R2 Package (or it could be the DTMF Package :dd/ce completion event.). In either case when it is found that the last event is generating a Full Match,.then the Current Dial String is sent as an Observed Parameter of the Notify generated corresponding to the R2Address event. Now , the event that is mentioned in the highlighted region is the problem. How does the MG send This Event뭩 Notification? It is mentioned that MG uses the 밹urrently active event processing mechanisms.� This implies that we cannot send this event without the activation from MGC. [Amaresh] Dump this event as no event descriptor is active. For the DTMF Package this is ok, since the MGC would activate detection of the Digits Event 뻲ildcarded with choose. 3.But in case of R2 Package Which event would the MGC use to ask for this event뭩 notification? I could not find any event in R2 package which could be used for the purpose. [Amaresh] Same as 1. Thanks, Mukta Vasudeva Catch all the cricket action. Download Yahoo! Score tracker --------------------------------- Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy the best in Movies at http://www.videos.indiatimes.com Now bid just 7 Days in Advance and get Huge Discounts on Indian Airlines Flights. So log on to http://indianairlines.indiatimes.com and Bid Now ! Catch all the cricket action. Download Yahoo! Score tracker --0-1194886571-1042521894=:76151 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

hi,

Thanks for your response.

You are right about MG dumping the  event (as per processing requirements) ,if the events decriptor for that event is not there.But maybe i didnt frame my question right:

Q: If MG terminations  support R2 Package then, considering the given scenario,which eventof this Package would the MGC use for the notification of the last rejected event. Because the current dial string would be sent as notification for the R2Address Event.

Actually i cannot find any such event in the R2 Package which could be used for such a purpose.So does such an event exist in R2 Package through which a single collected digit could be sent back to the MGC?

In any case your solution applies to the MG : if events descriptor is not there,dump the event.

regards ,

Mukta V.

 

 amaresh_ram <amaresh_ram@indiatimes.com> wrote:

hi,

Find my comment inline as [Amaresh].

regards,

Amaresh

"=?iso-8859-1?q?mukta=20vasudeva?=" wrote:

 

Hi,

I have another problem:

 

The RFC states that:

�If

      no candidates remain, the latest event is removed from the

      current dial string and a completion event is generated

      indicating full match if one of the candidates from the previous

      step was fully satisfied before the latest event was detected, or

      partial match otherwise. The event removed from the current dial

      string will then be reported as per the currently active event

      processing mechanisms.�

 [Amaresh] This highlighted text is rephrased in the 2nd version of Megaco and it state that the event removed from the current dial string will then be reported a separate event, buffered, or discarded according to the rules described in the previous section.

Please refer to the Highlighted part:

Q: Lets say the MG has received Message from MGC telling it to activate detection of  R2/R2Address event of the R2 Package (or it could be the DTMF Package :dd/ce completion event.).

In either case when it is found that the last event is generating a Full Match,.then the Current Dial String is sent as an Observed Parameter of the Notify generated corresponding to the R2Address event.

Now , the event that is mentioned in the highlighted region is the problem. How does the MG send This Event뭩 Notification?

It is mentioned that MG uses the �currently active event processing mechanisms.�

  1. This implies that we cannot send this event without the activation from MGC. [Amaresh] Dump this event as no event descriptor is active.
  2. For the DTMF Package this is ok, since the MGC would activate detection of the Digits Event 뻲ildcarded with choose.

      3.But in case of R2 Package Which event would the MGC use to ask for this event뭩 notification? I could not find any event in R2 package which could be used for the purpose. [Amaresh] Same as 1.

 

Thanks,

Mukta Vasudeva

Catch all the cricket action. Download Yahoo! Score tracker

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy the best in Movies at http://www.videos.indiatimes.com
Now bid just 7 Days in Advance and get Huge Discounts on Indian Airlines Flights. So log on to http://indianairlines.indiatimes.com and Bid Now !

Catch all the cricket action. Download Yahoo! Score tracker --0-1194886571-1042521894=:76151-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 14 00:48:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05924 for ; Tue, 14 Jan 2003 00:48:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E61LJ21584; Tue, 14 Jan 2003 01:01:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E60TJ21543 for ; Tue, 14 Jan 2003 01:00:29 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05912 for ; Tue, 14 Jan 2003 00:45:58 -0500 (EST) From: shbansal@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0E5m6j23712 for ; Tue, 14 Jan 2003 11:18:06 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0E5m5M23705 for ; Tue, 14 Jan 2003 11:18:05 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h0E5oGF21672 for ; Tue, 14 Jan 2003 11:20:16 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CAE.001F4FFA ; Tue, 14 Jan 2003 11:12:00 +0530 X-Lotus-FromDomain: HSS To: "'megaco@ietf.org'" cc: vikas@hss.hns.com Message-ID: <65256CAE.001F4E86.00@sandesh.hss.hns.com> Date: Tue, 14 Jan 2003 11:21:36 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Query regarding H.248.10 (Congestion Handling Package) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi all, I have few queries in congestion handling package, The document says: "Description: The package makes it possible for the MG to control its load. The events in this package may be provisioned in the MG. The event in this package may only be applied to the Root termination." It means that the events may be provisioned in the MG without any event enabling request from MGC. My questions: 1> If the event is pre provisioned and MGC has not sent ant request for enabling this event then a) Can MG report this event to MGC without having any associated event request identifier b) If (1) yes then what will be the request identifier that should be used in notify request. c) If (1) is yes, then If the event is pre provisioned and MGC does not support such package, how MGC will convey this to MG so that MG does not report this event in future d) If (1) is no, then what is the use of pre provisioning. 2> Is MGC allowed to disable this event. If yes, then how will MGC disable this event 3> Can MGC disable the event is it is pre-provisioned Thanks and regards Shobhit DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 14 00:48:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05942 for ; Tue, 14 Jan 2003 00:48:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0E62ci21619 for megaco-archive@odin.ietf.org; Tue, 14 Jan 2003 01:02:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E62cJ21616 for ; Tue, 14 Jan 2003 01:02:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05938 for ; Tue, 14 Jan 2003 00:48:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E61LJ21584; Tue, 14 Jan 2003 01:01:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E60TJ21543 for ; Tue, 14 Jan 2003 01:00:29 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05912 for ; Tue, 14 Jan 2003 00:45:58 -0500 (EST) From: shbansal@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0E5m6j23712 for ; Tue, 14 Jan 2003 11:18:06 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0E5m5M23705 for ; Tue, 14 Jan 2003 11:18:05 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h0E5oGF21672 for ; Tue, 14 Jan 2003 11:20:16 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CAE.001F4FFA ; Tue, 14 Jan 2003 11:12:00 +0530 X-Lotus-FromDomain: HSS To: "'megaco@ietf.org'" cc: vikas@hss.hns.com Message-ID: <65256CAE.001F4E86.00@sandesh.hss.hns.com> Date: Tue, 14 Jan 2003 11:21:36 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Query regarding H.248.10 (Congestion Handling Package) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi all, I have few queries in congestion handling package, The document says: "Description: The package makes it possible for the MG to control its load. The events in this package may be provisioned in the MG. The event in this package may only be applied to the Root termination." It means that the events may be provisioned in the MG without any event enabling request from MGC. My questions: 1> If the event is pre provisioned and MGC has not sent ant request for enabling this event then a) Can MG report this event to MGC without having any associated event request identifier b) If (1) yes then what will be the request identifier that should be used in notify request. c) If (1) is yes, then If the event is pre provisioned and MGC does not support such package, how MGC will convey this to MG so that MG does not report this event in future d) If (1) is no, then what is the use of pre provisioning. 2> Is MGC allowed to disable this event. If yes, then how will MGC disable this event 3> Can MGC disable the event is it is pre-provisioned Thanks and regards Shobhit DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 14 01:43:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06925 for ; Tue, 14 Jan 2003 01:43:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E6vSJ25274; Tue, 14 Jan 2003 01:57:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E6tKJ25176 for ; Tue, 14 Jan 2003 01:55:20 -0500 Received: from exchange.td-soft.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06877 for ; Tue, 14 Jan 2003 01:40:41 -0500 (EST) Received: through eSafe SMTP Relay 1042464938; Tue Jan 14 08:55:29 2003 Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jan 2003 08:41:30 +0200 Message-ID: From: Raphael Tryster To: Christian Groves , Tom-PT Taylor Cc: "'mukta vasudeva'" , "'Alan Chou'" , megaco@ietf.org, Kevin Boyle Subject: RE: [Megaco] Signal Descriptor Doubts Date: Tue, 14 Jan 2003 08:41:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BB97.F8319510" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2BB97.F8319510 Content-Type: text/plain; charset="iso-8859-1" Kevin Boyle, answering my question a year ago, saw it differently. Raphael Tryster [The next sentence is Kevin's reply.] This has been discussed in the past, and the latter alternative (that is, the current value of the descriptor) was agreed to be the proper response, if my memory serves. Kevin -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Wednesday, February 13, 2002 8:29 AM To: megaco@ietf.org Subject: [Megaco] Auditing a signals descriptor Does the value of a signals descriptor change over time as the signals are played by the MG? The practical significance is that when an MG receives an AuditValue command asking for the signals descriptor, should it return the last value of the signals descriptor as sent by the MGC, or the set of currently playing and future signals, which may be empty if all the signals have completed? If this is still an open question, I would vote for the latter alternative, because: Perhaps this is related to the case of auditing a descriptor that had over-or under-specified parameters. I expect that in this case the MG would return just the values it has chosen, and not the entire original descriptor. Raphael Tryster -----Original Message----- From: Christian Groves [SMTP:Christian.Groves@ericsson.com.au] Sent: Tuesday, 14 January, 2003 2:14 AM To: Tom-PT Taylor Cc: 'mukta vasudeva'; 'Alan Chou'; megaco@ietf.org Subject: Re: [Megaco] Signal Descriptor Doubts G'Day Tom, I pretty much see it as you have described. I don't think there is a big overhead in keeping the signal descriptor. You certainly need to be able to keep it for the period of time whilst the signal is playing. So whilst it not optimal I don't think its an error either. Regards, Christian Tom-PT Taylor wrote: > > This is more or less the same question Alan Chou raised a week ago. It's > not something I ever thought about, but here is the situation as I see it: > -- the Signals Descriptor remains unchanged, even if the signal(s) it > describes have been terminated > -- the MG is required to maintain the knowledge of which signals have been > terminated and which have not > -- we have no way in general to indicate on audit which signals have > completed and which have not. This was probably a mistake in design. > > -----Original Message----- > From: mukta vasudeva [mailto:reachtomukta@yahoo.co.in] > Sent: Monday, January 06, 2003 9:00 AM > To: megaco@ietf.org > Subject: [Megaco] Signal Descriptor Doubts > > hi , > Hope everyone had a good Christmas and will have a wonderfull new year > ahead. > I have some doubts related to Signal Descriptor handling. > 1. > RFC Section 7.1.11 states that > "Production of a Signal on a Termination is stopped by application of > a new Signals Descriptor, or detection of an Event on the Termination ." > > Also, > "A new Signals Descriptor replaces any existing Signals Descriptor." > > Q: The MG maintains the current signal descriptor until a > new descriptor is not sent by the MGC. But, after the termination > finishes the playout of the signal or an event is detected and the > signals are stopped, the signal descriptor remains the current one > with MG until new one is received as according to the rules we cannot > remove it until new signal descriptor is received. > But my doubt is why should we maintain this descriptor since it has already > become deactivated(either by finishing playout or event stopped it) and MGC > cannot instruct MG to use it further ??. > > Thanks , > regards , > Mukta Vasudeva > > Catch all the cricket action. Download Yahoo! Score tracker > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C2BB97.F8319510 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] Signal Descriptor Doubts

Kevin Boyle, answering my question a yea= r ago, saw it differently.

Raphael Tryster

[The next sentence is Kevin's reply.]

This has been discussed in the past, and= the latter alternative (that is, the current value of the descriptor) wa= s agreed to be the proper response, if my memory serves.

Kevin
-----Original Message-----
From:   Raphael Tryster [mailto:raphael@tdsoft.com]
Sent:   Wednesday, February 1= 3, 2002 8:29 AM
To:     megaco@ietf.org
Subject:     &= nbsp;  [Megaco] Auditing a signals descriptor


Does the value of a signals descriptor c= hange over time as the signals are played by the MG?  The practical = significance is that when an MG receives an AuditValue command asking for= the signals descriptor, should it return the last value of the signals d= escriptor as sent by the MGC, or the set of currently playing and future = signals, which may be empty if all the signals have completed?

If this is still an open question, I wou= ld vote for the latter alternative, because:
Perhaps this is related to the case of = auditing a descriptor that had over-or under-specified parameters.  = I expect that in this case the MG would return just the values it has cho= sen, and not the entire original descriptor.

Raphael Tryster



    -----Original Mess= age-----
    From:   Christian Groves [= SMTP:Christian.Groves@ericsson.com.au]
    Sent:   Tuesday, 14 January, 2003 2:14 AM
    To:     Tom-PT Taylor
    Cc:     'mukta vasudeva'; 'Alan Chou'; megaco@ie= tf.org
    Subject:    &nbs= p;   Re: [Megaco] Sign= al Descriptor Doubts

    G'Day Tom,

    I pretty much see it as you have d= escribed. I don't think there is a big
    overhead in keeping the signal de= scriptor. You certainly need to be able to keep
    it for the period of time whilst = the signal is playing. So whilst it not optimal
    I don't think its an error either= =2E

    Regards, Christian

    Tom-PT Taylor wrote:
    >
    > This is more or less the sam= e question Alan Chou raised a week ago.  It's
    > not something I ever thought= about, but here is the situation as I see it:
    >   -- the Signals D= escriptor remains unchanged, even if the signal(s) it
    > describes have been terminat= ed
    >   -- the MG is req= uired to maintain the knowledge of which signals have been
    > terminated and which have no= t
    >   -- we have no wa= y in general to indicate on audit which signals have
    > completed and which have not= =2E  This was probably a mistake in design.
    >
    > -----Original Message-----
    > From: mukta vasudeva [mailto:reachtomukta@yahoo.co.in= ]
    > Sent: Monday, January 06, 20= 03 9:00 AM
    > To: megaco@ietf.org
    > Subject: [Megaco] Signal Des= criptor Doubts
    >
    > hi ,
    > Hope everyone had a good Chr= istmas and will have a wonderfull new year
    > ahead.
    > I have some doubts related t= o Signal Descriptor handling.
    > 1.
    >   RFC Section 7.1.= 11 states that
    > "Production of a Signal= on a Termination is stopped by application of
    >    a new Sign= als Descriptor, or detection of an Event on the Termination .."
    >
    > Also,
    > "A new Signals Descript= or replaces any existing Signals Descriptor."
    >
    > Q: The MG maintains the curr= ent signal descriptor until a
    > new descriptor is not sent b= y the MGC. But, after the termination
    > finishes the  playout o= f the signal or an event is detected and the
    >  signals are stopped, t= he signal descriptor remains the current one
    >  with MG until new one = is received as according to the rules we cannot
    > remove it until new signal d= escriptor is received.
    >  But my doubt is why sh= ould we maintain this descriptor since it has already
    > become deactivated(either by= finishing playout or event stopped it) and MGC
    > cannot instruct MG to use it= further ??.
    >
    > Thanks ,
    > regards ,
    > Mukta Vasudeva
    >
    >  Catch all the cricket = action. Download Yahoo! Score tracker
    > ____________________________= ___________________
    > Megaco mailing list
    > Megaco@ietf.org
    > https://www1.ietf.org/m= ailman/listinfo/megaco


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

------_=_NextPart_001_01C2BB97.F8319510-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 14 01:44:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06945 for ; Tue, 14 Jan 2003 01:44:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0E6wRt25289 for megaco-archive@odin.ietf.org; Tue, 14 Jan 2003 01:58:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E6wRJ25286 for ; Tue, 14 Jan 2003 01:58:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06939 for ; Tue, 14 Jan 2003 01:43:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E6vSJ25274; Tue, 14 Jan 2003 01:57:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E6tKJ25176 for ; Tue, 14 Jan 2003 01:55:20 -0500 Received: from exchange.td-soft.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06877 for ; Tue, 14 Jan 2003 01:40:41 -0500 (EST) Received: through eSafe SMTP Relay 1042464938; Tue Jan 14 08:55:29 2003 Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jan 2003 08:41:30 +0200 Message-ID: From: Raphael Tryster To: Christian Groves , Tom-PT Taylor Cc: "'mukta vasudeva'" , "'Alan Chou'" , megaco@ietf.org, Kevin Boyle Subject: RE: [Megaco] Signal Descriptor Doubts Date: Tue, 14 Jan 2003 08:41:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BB97.F8319510" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2BB97.F8319510 Content-Type: text/plain; charset="iso-8859-1" Kevin Boyle, answering my question a year ago, saw it differently. Raphael Tryster [The next sentence is Kevin's reply.] This has been discussed in the past, and the latter alternative (that is, the current value of the descriptor) was agreed to be the proper response, if my memory serves. Kevin -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Wednesday, February 13, 2002 8:29 AM To: megaco@ietf.org Subject: [Megaco] Auditing a signals descriptor Does the value of a signals descriptor change over time as the signals are played by the MG? The practical significance is that when an MG receives an AuditValue command asking for the signals descriptor, should it return the last value of the signals descriptor as sent by the MGC, or the set of currently playing and future signals, which may be empty if all the signals have completed? If this is still an open question, I would vote for the latter alternative, because: Perhaps this is related to the case of auditing a descriptor that had over-or under-specified parameters. I expect that in this case the MG would return just the values it has chosen, and not the entire original descriptor. Raphael Tryster -----Original Message----- From: Christian Groves [SMTP:Christian.Groves@ericsson.com.au] Sent: Tuesday, 14 January, 2003 2:14 AM To: Tom-PT Taylor Cc: 'mukta vasudeva'; 'Alan Chou'; megaco@ietf.org Subject: Re: [Megaco] Signal Descriptor Doubts G'Day Tom, I pretty much see it as you have described. I don't think there is a big overhead in keeping the signal descriptor. You certainly need to be able to keep it for the period of time whilst the signal is playing. So whilst it not optimal I don't think its an error either. Regards, Christian Tom-PT Taylor wrote: > > This is more or less the same question Alan Chou raised a week ago. It's > not something I ever thought about, but here is the situation as I see it: > -- the Signals Descriptor remains unchanged, even if the signal(s) it > describes have been terminated > -- the MG is required to maintain the knowledge of which signals have been > terminated and which have not > -- we have no way in general to indicate on audit which signals have > completed and which have not. This was probably a mistake in design. > > -----Original Message----- > From: mukta vasudeva [mailto:reachtomukta@yahoo.co.in] > Sent: Monday, January 06, 2003 9:00 AM > To: megaco@ietf.org > Subject: [Megaco] Signal Descriptor Doubts > > hi , > Hope everyone had a good Christmas and will have a wonderfull new year > ahead. > I have some doubts related to Signal Descriptor handling. > 1. > RFC Section 7.1.11 states that > "Production of a Signal on a Termination is stopped by application of > a new Signals Descriptor, or detection of an Event on the Termination ." > > Also, > "A new Signals Descriptor replaces any existing Signals Descriptor." > > Q: The MG maintains the current signal descriptor until a > new descriptor is not sent by the MGC. But, after the termination > finishes the playout of the signal or an event is detected and the > signals are stopped, the signal descriptor remains the current one > with MG until new one is received as according to the rules we cannot > remove it until new signal descriptor is received. > But my doubt is why should we maintain this descriptor since it has already > become deactivated(either by finishing playout or event stopped it) and MGC > cannot instruct MG to use it further ??. > > Thanks , > regards , > Mukta Vasudeva > > Catch all the cricket action. Download Yahoo! Score tracker > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C2BB97.F8319510 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] Signal Descriptor Doubts

Kevin Boyle, answering my question a yea= r ago, saw it differently.

Raphael Tryster

[The next sentence is Kevin's reply.]

This has been discussed in the past, and= the latter alternative (that is, the current value of the descriptor) wa= s agreed to be the proper response, if my memory serves.

Kevin
-----Original Message-----
From:   Raphael Tryster [mailto:raphael@tdsoft.com]
Sent:   Wednesday, February 1= 3, 2002 8:29 AM
To:     megaco@ietf.org
Subject:     &= nbsp;  [Megaco] Auditing a signals descriptor


Does the value of a signals descriptor c= hange over time as the signals are played by the MG?  The practical = significance is that when an MG receives an AuditValue command asking for= the signals descriptor, should it return the last value of the signals d= escriptor as sent by the MGC, or the set of currently playing and future = signals, which may be empty if all the signals have completed?

If this is still an open question, I wou= ld vote for the latter alternative, because:
Perhaps this is related to the case of = auditing a descriptor that had over-or under-specified parameters.  = I expect that in this case the MG would return just the values it has cho= sen, and not the entire original descriptor.

Raphael Tryster



    -----Original Mess= age-----
    From:   Christian Groves [= SMTP:Christian.Groves@ericsson.com.au]
    Sent:   Tuesday, 14 January, 2003 2:14 AM
    To:     Tom-PT Taylor
    Cc:     'mukta vasudeva'; 'Alan Chou'; megaco@ie= tf.org
    Subject:    &nbs= p;   Re: [Megaco] Sign= al Descriptor Doubts

    G'Day Tom,

    I pretty much see it as you have d= escribed. I don't think there is a big
    overhead in keeping the signal de= scriptor. You certainly need to be able to keep
    it for the period of time whilst = the signal is playing. So whilst it not optimal
    I don't think its an error either= =2E

    Regards, Christian

    Tom-PT Taylor wrote:
    >
    > This is more or less the sam= e question Alan Chou raised a week ago.  It's
    > not something I ever thought= about, but here is the situation as I see it:
    >   -- the Signals D= escriptor remains unchanged, even if the signal(s) it
    > describes have been terminat= ed
    >   -- the MG is req= uired to maintain the knowledge of which signals have been
    > terminated and which have no= t
    >   -- we have no wa= y in general to indicate on audit which signals have
    > completed and which have not= =2E  This was probably a mistake in design.
    >
    > -----Original Message-----
    > From: mukta vasudeva [mailto:reachtomukta@yahoo.co.in= ]
    > Sent: Monday, January 06, 20= 03 9:00 AM
    > To: megaco@ietf.org
    > Subject: [Megaco] Signal Des= criptor Doubts
    >
    > hi ,
    > Hope everyone had a good Chr= istmas and will have a wonderfull new year
    > ahead.
    > I have some doubts related t= o Signal Descriptor handling.
    > 1.
    >   RFC Section 7.1.= 11 states that
    > "Production of a Signal= on a Termination is stopped by application of
    >    a new Sign= als Descriptor, or detection of an Event on the Termination .."
    >
    > Also,
    > "A new Signals Descript= or replaces any existing Signals Descriptor."
    >
    > Q: The MG maintains the curr= ent signal descriptor until a
    > new descriptor is not sent b= y the MGC. But, after the termination
    > finishes the  playout o= f the signal or an event is detected and the
    >  signals are stopped, t= he signal descriptor remains the current one
    >  with MG until new one = is received as according to the rules we cannot
    > remove it until new signal d= escriptor is received.
    >  But my doubt is why sh= ould we maintain this descriptor since it has already
    > become deactivated(either by= finishing playout or event stopped it) and MGC
    > cannot instruct MG to use it= further ??.
    >
    > Thanks ,
    > regards ,
    > Mukta Vasudeva
    >
    >  Catch all the cricket = action. Download Yahoo! Score tracker
    > ____________________________= ___________________
    > Megaco mailing list
    > Megaco@ietf.org
    > https://www1.ietf.org/m= ailman/listinfo/megaco


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

------_=_NextPart_001_01C2BB97.F8319510-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 14 05:01:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20222 for ; Tue, 14 Jan 2003 05:01:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EADvJ16309; Tue, 14 Jan 2003 05:13:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EABoJ16232 for ; Tue, 14 Jan 2003 05:11:50 -0500 Received: from mink.ecitele.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20153 for ; Tue, 14 Jan 2003 04:57:14 -0500 (EST) From: Eli.Liluz@ecitele.com Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id LAA09016 for ; Tue, 14 Jan 2003 11:55:18 +0200 (IST) To: megaco@ietf.org X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Tue, 14 Jan 2003 12:00:34 +0200 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 01/14/2003 12:00:31 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Megaco] EventBufferControl and event handling. Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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. According to chapter 7.1.9 in case the EventBufferControl = Off the MG does not handle any event buffering for notifications. Any way, is there any need form the MG to wait for an ACK from the MGC for the previous notification before it sends a new notification even if it is in Off state ? If the answer for that question is no, is there any way to validate the event notifications order from the MG to the MGC in Off state without using a digit map ? Thank you, Eli Liluz. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 14 05:01:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20244 for ; Tue, 14 Jan 2003 05:01:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EAFlk16367 for megaco-archive@odin.ietf.org; Tue, 14 Jan 2003 05:15:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EAFlJ16363 for ; Tue, 14 Jan 2003 05:15:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20236 for ; Tue, 14 Jan 2003 05:01:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EADvJ16309; Tue, 14 Jan 2003 05:13:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EABoJ16232 for ; Tue, 14 Jan 2003 05:11:50 -0500 Received: from mink.ecitele.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20153 for ; Tue, 14 Jan 2003 04:57:14 -0500 (EST) From: Eli.Liluz@ecitele.com Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id LAA09016 for ; Tue, 14 Jan 2003 11:55:18 +0200 (IST) To: megaco@ietf.org X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Tue, 14 Jan 2003 12:00:34 +0200 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 01/14/2003 12:00:31 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Megaco] EventBufferControl and event handling. Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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. According to chapter 7.1.9 in case the EventBufferControl = Off the MG does not handle any event buffering for notifications. Any way, is there any need form the MG to wait for an ACK from the MGC for the previous notification before it sends a new notification even if it is in Off state ? If the answer for that question is no, is there any way to validate the event notifications order from the MG to the MGC in Off state without using a digit map ? Thank you, Eli Liluz. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 14 10:20:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27142 for ; Tue, 14 Jan 2003 10:20:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EFX8J04100; Tue, 14 Jan 2003 10:33:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EFSgJ03744 for ; Tue, 14 Jan 2003 10:28:42 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26679; Tue, 14 Jan 2003 10:14:01 -0500 (EST) Message-Id: <200301141514.KAA26679@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: megaco@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 14 Jan 2003 10:14:01 -0500 Subject: [Megaco] I-D ACTION:draft-ietf-megaco-3015corr-03.txt Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Media Gateway Control Working Group of the IETF. Title : Gateway Control Protocol Version 1 Author(s) : C. Groves, M. Pantaleo Filename : draft-ietf-megaco-3015corr-03.txt Pages : 212 Date : 2003-1-13 This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e. a Media Gateway and a Media Gateway Controller. The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805. This document is intended to replace RFC 3015. It is the result of continued cooperation between the IETF Megaco Working Group and ITU-T Study Group 16. It incorporates the original text of RFC 3015, modified by corrections and clarifications discussed on the Megaco E- mail list and incorporated into the Study Group 16 Implementor's Guide for Recommendation H.248. The present version of this document has undergone ITU-T Last Call as Recommendation H.248 Amendment 1. Because of ITU-T renumbering, it will be published by the ITU-T as Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-3015corr-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-megaco-3015corr-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-megaco-3015corr-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-13142141.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-megaco-3015corr-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-megaco-3015corr-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-13142141.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 14 10:20:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27186 for ; Tue, 14 Jan 2003 10:20:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EFYx304237 for megaco-archive@odin.ietf.org; Tue, 14 Jan 2003 10:34:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EFYxJ04234 for ; Tue, 14 Jan 2003 10:34:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27156 for ; Tue, 14 Jan 2003 10:20:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EFX8J04100; Tue, 14 Jan 2003 10:33:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EFSgJ03744 for ; Tue, 14 Jan 2003 10:28:42 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26679; Tue, 14 Jan 2003 10:14:01 -0500 (EST) Message-Id: <200301141514.KAA26679@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: megaco@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 14 Jan 2003 10:14:01 -0500 Subject: [Megaco] I-D ACTION:draft-ietf-megaco-3015corr-03.txt Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Media Gateway Control Working Group of the IETF. Title : Gateway Control Protocol Version 1 Author(s) : C. Groves, M. Pantaleo Filename : draft-ietf-megaco-3015corr-03.txt Pages : 212 Date : 2003-1-13 This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e. a Media Gateway and a Media Gateway Controller. The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805. This document is intended to replace RFC 3015. It is the result of continued cooperation between the IETF Megaco Working Group and ITU-T Study Group 16. It incorporates the original text of RFC 3015, modified by corrections and clarifications discussed on the Megaco E- mail list and incorporated into the Study Group 16 Implementor's Guide for Recommendation H.248. The present version of this document has undergone ITU-T Last Call as Recommendation H.248 Amendment 1. Because of ITU-T renumbering, it will be published by the ITU-T as Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-3015corr-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-megaco-3015corr-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-megaco-3015corr-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-13142141.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-megaco-3015corr-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-megaco-3015corr-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-13142141.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 14 13:32:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06001 for ; Tue, 14 Jan 2003 13:32:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EIjUJ20828; Tue, 14 Jan 2003 13:45:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EIhQJ20748 for ; Tue, 14 Jan 2003 13:43:26 -0500 Received: from zrtps0kp.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05897 for ; Tue, 14 Jan 2003 13:28:39 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0EIVwJ00333 for ; Tue, 14 Jan 2003 13:31:58 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jan 2003 13:31:58 -0500 Message-ID: From: "Kevin Boyle" To: Christian Groves , "Tom-PT Taylor" Cc: "'Carl Rutter'" , "'megaco@ietf.org'" , Kang-Sen Lu Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 Date: Tue, 14 Jan 2003 13:31:54 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , I concur with Christian on this. It seems to me that the ability to wildcard one of the positions makes the TP descriptor better able to describe the desired topology, without adding complexity. Being forced to utilize one triple for each combination -- especially in contexts with large numbers of terms -- would make the TP descriptor so heavy and complex as to be almost useless. Any suggestions for wording for this item? I'll try to put something together later today or tomorrow, but suggestions are always welcome. Kevin -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] Sent: Monday, January 13, 2003 6:52 PM To: Taylor, Tom-PT [CAR:5N00:EXCH] Cc: 'Carl Rutter'; 'megaco@ietf.org'; Kang-Sen Lu; Boyle, Kevin [NCRTP:3R90:EXCH] Subject: Re: [Megaco] Question on Section 7.1.18 Megaco V2 G'Day Tom and Carl, I had always read this to mean that you should not use * wilcard in both of the T1,T2 positions that refer to the same terminations. I think the construction (T*,T2,oneway) where only one of the T1,T2 positions is * wildcarded is useful. Maybe this is something for the IG? Regards, Christian Tom-PT Taylor wrote: > > I would agree with you. Wildcarding is only permitted in this case in > the form of partially-specified names. Not sure how useful that is. > > > -----Original Message----- > > From: Carl Rutter [mailto:crutter@telica.com] > > Sent: Tuesday, January 07, 2003 11:37 AM > > To: 'megaco@ietf.org' > > Cc: Kang-Sen Lu > > Subject: [Megaco] Question on Section 7.1.18 Megaco V2 > > > > > > We need some clarifcation on the following statement: > > > > (T1, T2, oneway) means that the Terminations that match T2 > > receive media from the Terminations matching T1, but not vice > > versa. In this case use of the ALL wildcard such that there > > are Terminations that match both T1 and T2 is not allowed. > > > > The line in question is "... such that there are Terminations that > > match both T1 and T2 is not allowed" > > > > The way we read it this clause disproves the use of Wildcard > > (*,T2,Oneway) becuase T2 will match * and T2. Hence the statement > > "Terminations that match both T1 and T2 is not allowed", excludes us > > from doing this. Is this correct? > > > > > > Thx, > > Carl > > > > Carl Rutter > > Telica, Inc. > > Building G, Suite 100 > > 734 Forest Street > > Marlboro, MA 01752 > > Email crutter@telica.com > > Voice 508-480-0909 x8178 > > Fax 508-480-0922 > > www.telica.com > > > > > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 14 13:32:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06045 for ; Tue, 14 Jan 2003 13:32:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EIkvL20902 for megaco-archive@odin.ietf.org; Tue, 14 Jan 2003 13:46:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EIkvJ20899 for ; Tue, 14 Jan 2003 13:46:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06019 for ; Tue, 14 Jan 2003 13:32:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EIjUJ20828; Tue, 14 Jan 2003 13:45:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EIhQJ20748 for ; Tue, 14 Jan 2003 13:43:26 -0500 Received: from zrtps0kp.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05897 for ; Tue, 14 Jan 2003 13:28:39 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0EIVwJ00333 for ; Tue, 14 Jan 2003 13:31:58 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jan 2003 13:31:58 -0500 Message-ID: From: "Kevin Boyle" To: Christian Groves , "Tom-PT Taylor" Cc: "'Carl Rutter'" , "'megaco@ietf.org'" , Kang-Sen Lu Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 Date: Tue, 14 Jan 2003 13:31:54 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , I concur with Christian on this. It seems to me that the ability to wildcard one of the positions makes the TP descriptor better able to describe the desired topology, without adding complexity. Being forced to utilize one triple for each combination -- especially in contexts with large numbers of terms -- would make the TP descriptor so heavy and complex as to be almost useless. Any suggestions for wording for this item? I'll try to put something together later today or tomorrow, but suggestions are always welcome. Kevin -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] Sent: Monday, January 13, 2003 6:52 PM To: Taylor, Tom-PT [CAR:5N00:EXCH] Cc: 'Carl Rutter'; 'megaco@ietf.org'; Kang-Sen Lu; Boyle, Kevin [NCRTP:3R90:EXCH] Subject: Re: [Megaco] Question on Section 7.1.18 Megaco V2 G'Day Tom and Carl, I had always read this to mean that you should not use * wilcard in both of the T1,T2 positions that refer to the same terminations. I think the construction (T*,T2,oneway) where only one of the T1,T2 positions is * wildcarded is useful. Maybe this is something for the IG? Regards, Christian Tom-PT Taylor wrote: > > I would agree with you. Wildcarding is only permitted in this case in > the form of partially-specified names. Not sure how useful that is. > > > -----Original Message----- > > From: Carl Rutter [mailto:crutter@telica.com] > > Sent: Tuesday, January 07, 2003 11:37 AM > > To: 'megaco@ietf.org' > > Cc: Kang-Sen Lu > > Subject: [Megaco] Question on Section 7.1.18 Megaco V2 > > > > > > We need some clarifcation on the following statement: > > > > (T1, T2, oneway) means that the Terminations that match T2 > > receive media from the Terminations matching T1, but not vice > > versa. In this case use of the ALL wildcard such that there > > are Terminations that match both T1 and T2 is not allowed. > > > > The line in question is "... such that there are Terminations that > > match both T1 and T2 is not allowed" > > > > The way we read it this clause disproves the use of Wildcard > > (*,T2,Oneway) becuase T2 will match * and T2. Hence the statement > > "Terminations that match both T1 and T2 is not allowed", excludes us > > from doing this. Is this correct? > > > > > > Thx, > > Carl > > > > Carl Rutter > > Telica, Inc. > > Building G, Suite 100 > > 734 Forest Street > > Marlboro, MA 01752 > > Email crutter@telica.com > > Voice 508-480-0909 x8178 > > Fax 508-480-0922 > > www.telica.com > > > > > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 14 13:55:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06870 for ; Tue, 14 Jan 2003 13:55:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJ8YJ22543; Tue, 14 Jan 2003 14:08:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJ7cJ22498 for ; Tue, 14 Jan 2003 14:07:38 -0500 Received: from zrtps0kp.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06810 for ; Tue, 14 Jan 2003 13:52:51 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0EIuBJ02018 for ; Tue, 14 Jan 2003 13:56:11 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jan 2003 13:56:11 -0500 Message-ID: From: "Kevin Boyle" To: mukta vasudeva , amaresh_ram Cc: megaco@ietf.org Subject: RE: [Megaco] Problem with Dgitmap event Date: Tue, 14 Jan 2003 13:56:05 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , One possible solution is to adapt the package to utilize the digit collection procedures outlined in H.248.16. This will allow reporting of the digit/event that caused a mismatch. Kevin -----Original Message----- From: mukta vasudeva [mailto:reachtomukta@yahoo.co.in] Sent: Tuesday, January 14, 2003 12:25 AM To: amaresh_ram Cc: megaco@ietf.org Subject: Re: [Megaco] Problem with Dgitmap event hi, Thanks for your response. You are right about MG dumping the event (as per processing requirements) ,if the events decriptor for that event is not there.But maybe i didnt frame my question right: Q: If MG terminations support R2 Package then, considering the given scenario,which eventof this Package would the MGC use for the notification of the last rejected event. Because the current dial string would be sent as notification for the R2Address Event. Actually i cannot find any such event in the R2 Package which could be used for such a purpose.So does such an event exist in R2 Package through which a single collected digit could be sent back to the MGC? In any case your solution applies to the MG : if events descriptor is not there,dump the event. regards , Mukta V. amaresh_ram wrote: hi, Find my comment inline as [Amaresh]. regards, Amaresh "=?iso-8859-1?q?mukta=20vasudeva?=" wrote: Hi, I have another problem: The RFC states that: "If no candidates remain, the latest event is removed from the current dial string and a completion event is generated indicating full match if one of the candidates from the previous step was fully satisfied before the latest event was detected, or partial match otherwise. The event removed from the current dial string will then be reported as per the currently active event processing mechanisms." [Amaresh] This highlighted text is rephrased in the 2nd version of Megaco and it state that the event removed from the current dial string will then be reported a separate event, buffered, or discarded according to the rules described in the previous section. Please refer to the Highlighted part: Q: Lets say the MG has received Message from MGC telling it to activate detection of R2/R2Address event of the R2 Package (or it could be the DTMF Package :dd/ce completion event.). In either case when it is found that the last event is generating a Full Match,.then the Current Dial String is sent as an Observed Parameter of the Notify generated corresponding to the R2Address event. Now , the event that is mentioned in the highlighted region is the problem. How does the MG send This Event's Notification? It is mentioned that MG uses the "currently active event processing mechanisms." 1. This implies that we cannot send this event without the activation from MGC. [Amaresh] Dump this event as no event descriptor is active. 2. For the DTMF Package this is ok, since the MGC would activate detection of the Digits Event -wildcarded with choose. 3.But in case of R2 Package Which event would the MGC use to ask for this event's notification? I could not find any event in R2 package which could be used for the purpose. [Amaresh] Same as 1. Thanks, Mukta Vasudeva Catch all the cricket action. Download Yahoo! Score tracker _____ Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy the best in Movies at http://www.videos.indiatimes.com Now bid just 7 Days in Advance and get Huge Discounts on Indian Airlines Flights. So log on to http://indianairlines.indiatimes.com and Bid Now ! Catch all the cricket action. Download Yahoo! Score tracker _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 14 13:55:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06896 for ; Tue, 14 Jan 2003 13:55:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EJA3r22606 for megaco-archive@odin.ietf.org; Tue, 14 Jan 2003 14:10:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJA3J22603 for ; Tue, 14 Jan 2003 14:10:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06886 for ; Tue, 14 Jan 2003 13:55:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJ8YJ22543; Tue, 14 Jan 2003 14:08:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJ7cJ22498 for ; Tue, 14 Jan 2003 14:07:38 -0500 Received: from zrtps0kp.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06810 for ; Tue, 14 Jan 2003 13:52:51 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0EIuBJ02018 for ; Tue, 14 Jan 2003 13:56:11 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jan 2003 13:56:11 -0500 Message-ID: From: "Kevin Boyle" To: mukta vasudeva , amaresh_ram Cc: megaco@ietf.org Subject: RE: [Megaco] Problem with Dgitmap event Date: Tue, 14 Jan 2003 13:56:05 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , One possible solution is to adapt the package to utilize the digit collection procedures outlined in H.248.16. This will allow reporting of the digit/event that caused a mismatch. Kevin -----Original Message----- From: mukta vasudeva [mailto:reachtomukta@yahoo.co.in] Sent: Tuesday, January 14, 2003 12:25 AM To: amaresh_ram Cc: megaco@ietf.org Subject: Re: [Megaco] Problem with Dgitmap event hi, Thanks for your response. You are right about MG dumping the event (as per processing requirements) ,if the events decriptor for that event is not there.But maybe i didnt frame my question right: Q: If MG terminations support R2 Package then, considering the given scenario,which eventof this Package would the MGC use for the notification of the last rejected event. Because the current dial string would be sent as notification for the R2Address Event. Actually i cannot find any such event in the R2 Package which could be used for such a purpose.So does such an event exist in R2 Package through which a single collected digit could be sent back to the MGC? In any case your solution applies to the MG : if events descriptor is not there,dump the event. regards , Mukta V. amaresh_ram wrote: hi, Find my comment inline as [Amaresh]. regards, Amaresh "=?iso-8859-1?q?mukta=20vasudeva?=" wrote: Hi, I have another problem: The RFC states that: "If no candidates remain, the latest event is removed from the current dial string and a completion event is generated indicating full match if one of the candidates from the previous step was fully satisfied before the latest event was detected, or partial match otherwise. The event removed from the current dial string will then be reported as per the currently active event processing mechanisms." [Amaresh] This highlighted text is rephrased in the 2nd version of Megaco and it state that the event removed from the current dial string will then be reported a separate event, buffered, or discarded according to the rules described in the previous section. Please refer to the Highlighted part: Q: Lets say the MG has received Message from MGC telling it to activate detection of R2/R2Address event of the R2 Package (or it could be the DTMF Package :dd/ce completion event.). In either case when it is found that the last event is generating a Full Match,.then the Current Dial String is sent as an Observed Parameter of the Notify generated corresponding to the R2Address event. Now , the event that is mentioned in the highlighted region is the problem. How does the MG send This Event's Notification? It is mentioned that MG uses the "currently active event processing mechanisms." 1. This implies that we cannot send this event without the activation from MGC. [Amaresh] Dump this event as no event descriptor is active. 2. For the DTMF Package this is ok, since the MGC would activate detection of the Digits Event -wildcarded with choose. 3.But in case of R2 Package Which event would the MGC use to ask for this event's notification? I could not find any event in R2 package which could be used for the purpose. [Amaresh] Same as 1. Thanks, Mukta Vasudeva Catch all the cricket action. Download Yahoo! Score tracker _____ Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy the best in Movies at http://www.videos.indiatimes.com Now bid just 7 Days in Advance and get Huge Discounts on Indian Airlines Flights. So log on to http://indianairlines.indiatimes.com and Bid Now ! Catch all the cricket action. Download Yahoo! Score tracker _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 14 14:00:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07129 for ; Tue, 14 Jan 2003 14:00:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJE9J22905; Tue, 14 Jan 2003 14:14:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJDkJ22858 for ; Tue, 14 Jan 2003 14:13:46 -0500 Received: from zrtps0kp.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07044 for ; Tue, 14 Jan 2003 13:58:59 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0EJ2IJ06263 for ; Tue, 14 Jan 2003 14:02:18 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jan 2003 14:02:18 -0500 Message-ID: From: "Kevin Boyle" To: Eli.Liluz@ecitele.com, megaco@ietf.org Subject: RE: [Megaco] EventBufferControl and event handling. Date: Tue, 14 Jan 2003 14:02:10 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , The short answer is, "It depends." The long answer is that some consideration has to be given to transport type and to whether the Notifies are coming from the same term or not. UDP does not guarantee message ordering. Given that, then it is wise for the MG to hold subsequent notifies until the outstanding one is acked. This allows the MG to ensure that proper ordering occurs -- especially in cases where ordering is important, like digit collection. Further, the MG can look at which term is generating the notify. If the two notifies are from different terms, then there is no reason to hold one while waiting for the ACK on the other. Ordering becomes important when the notifies are coming from the same term. Kevin -----Original Message----- From: Eli.Liluz@ecitele.com [mailto:Eli.Liluz@ecitele.com] Sent: Tuesday, January 14, 2003 5:01 AM To: megaco@ietf.org Subject: [Megaco] EventBufferControl and event handling. Hi all. According to chapter 7.1.9 in case the EventBufferControl = Off the MG does not handle any event buffering for notifications. Any way, is there any need form the MG to wait for an ACK from the MGC for the previous notification before it sends a new notification even if it is in Off state ? If the answer for that question is no, is there any way to validate the event notifications order from the MG to the MGC in Off state without using a digit map ? Thank you, Eli Liluz. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 14 14:01:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07179 for ; Tue, 14 Jan 2003 14:01:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EJFOU22977 for megaco-archive@odin.ietf.org; Tue, 14 Jan 2003 14:15:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJFNJ22974 for ; Tue, 14 Jan 2003 14:15:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07138 for ; Tue, 14 Jan 2003 14:00:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJE9J22905; Tue, 14 Jan 2003 14:14:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJDkJ22858 for ; Tue, 14 Jan 2003 14:13:46 -0500 Received: from zrtps0kp.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07044 for ; Tue, 14 Jan 2003 13:58:59 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0EJ2IJ06263 for ; Tue, 14 Jan 2003 14:02:18 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jan 2003 14:02:18 -0500 Message-ID: From: "Kevin Boyle" To: Eli.Liluz@ecitele.com, megaco@ietf.org Subject: RE: [Megaco] EventBufferControl and event handling. Date: Tue, 14 Jan 2003 14:02:10 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , The short answer is, "It depends." The long answer is that some consideration has to be given to transport type and to whether the Notifies are coming from the same term or not. UDP does not guarantee message ordering. Given that, then it is wise for the MG to hold subsequent notifies until the outstanding one is acked. This allows the MG to ensure that proper ordering occurs -- especially in cases where ordering is important, like digit collection. Further, the MG can look at which term is generating the notify. If the two notifies are from different terms, then there is no reason to hold one while waiting for the ACK on the other. Ordering becomes important when the notifies are coming from the same term. Kevin -----Original Message----- From: Eli.Liluz@ecitele.com [mailto:Eli.Liluz@ecitele.com] Sent: Tuesday, January 14, 2003 5:01 AM To: megaco@ietf.org Subject: [Megaco] EventBufferControl and event handling. Hi all. According to chapter 7.1.9 in case the EventBufferControl = Off the MG does not handle any event buffering for notifications. Any way, is there any need form the MG to wait for an ACK from the MGC for the previous notification before it sends a new notification even if it is in Off state ? If the answer for that question is no, is there any way to validate the event notifications order from the MG to the MGC in Off state without using a digit map ? Thank you, Eli Liluz. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 14 14:26:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08386 for ; Tue, 14 Jan 2003 14:26:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJdQJ25020; Tue, 14 Jan 2003 14:39:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJcYJ24967 for ; Tue, 14 Jan 2003 14:38:34 -0500 Received: from zrtps0kp.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08265 for ; Tue, 14 Jan 2003 14:23:44 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0EJR4J08029 for ; Tue, 14 Jan 2003 14:27:04 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jan 2003 14:27:04 -0500 Message-ID: From: "Kevin Boyle" To: Raphael Tryster , Christian Groves , "Tom-PT Taylor" Cc: "'mukta vasudeva'" , "'Alan Chou'" , megaco@ietf.org Subject: RE: [Megaco] Signal Descriptor Doubts Date: Tue, 14 Jan 2003 14:26:55 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , So, I hunted back through the archives to ensure that my memory was in tune with the reality of what was decided. The first discussion I saw in about this my archives of the list occurred from late June through mid-July 2000. The outcome of the discussion was that the MG should return what is currently "playing" and what is remaining to be "played". Now, that being said, I personally do not have strong feelings one way or the other on this. If implementation experience has shown that it is better to return the previously set descriptor, rather than the "current" descriptor, then perhaps we should change. This would also depend on how many implementations are working in this fashion already. Kevin -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Tuesday, January 14, 2003 1:41 AM To: Christian Groves; Taylor, Tom-PT [CAR:5N00:EXCH] Cc: 'mukta vasudeva'; 'Alan Chou'; megaco@ietf.org; Boyle, Kevin [NCRTP:3R90:EXCH] Subject: RE: [Megaco] Signal Descriptor Doubts Kevin Boyle, answering my question a year ago, saw it differently. Raphael Tryster [The next sentence is Kevin's reply.] This has been discussed in the past, and the latter alternative (that is, the current value of the descriptor) was agreed to be the proper response, if my memory serves. Kevin -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Wednesday, February 13, 2002 8:29 AM To: megaco@ietf.org Subject: [Megaco] Auditing a signals descriptor Does the value of a signals descriptor change over time as the signals are played by the MG? The practical significance is that when an MG receives an AuditValue command asking for the signals descriptor, should it return the last value of the signals descriptor as sent by the MGC, or the set of currently playing and future signals, which may be empty if all the signals have completed? If this is still an open question, I would vote for the latter alternative, because: Perhaps this is related to the case of auditing a descriptor that had over-or under-specified parameters. I expect that in this case the MG would return just the values it has chosen, and not the entire original descriptor. Raphael Tryster BM__MailData-----Original Message----- From: Christian Groves [SMTP:Christian.Groves@ericsson.com.au] Sent: Tuesday, 14 January, 2003 2:14 AM To: Tom-PT Taylor Cc: 'mukta vasudeva'; 'Alan Chou'; megaco@ietf.org Subject: Re: [Megaco] Signal Descriptor Doubts G'Day Tom, I pretty much see it as you have described. I don't think there is a big overhead in keeping the signal descriptor. You certainly need to be able to keep it for the period of time whilst the signal is playing. So whilst it not optimal I don't think its an error either. Regards, Christian Tom-PT Taylor wrote: > > This is more or less the same question Alan Chou raised a week ago. It's > not something I ever thought about, but here is the situation as I see it: > -- the Signals Descriptor remains unchanged, even if the signal(s) it > describes have been terminated > -- the MG is required to maintain the knowledge of which signals have been > terminated and which have not > -- we have no way in general to indicate on audit which signals have > completed and which have not. This was probably a mistake in design. > > -----Original Message----- > From: mukta vasudeva [mailto:reachtomukta@yahoo.co.in ] > Sent: Monday, January 06, 2003 9:00 AM > To: megaco@ietf.org > Subject: [Megaco] Signal Descriptor Doubts > > hi , > Hope everyone had a good Christmas and will have a wonderfull new year > ahead. > I have some doubts related to Signal Descriptor handling. > 1. > RFC Section 7.1.11 states that > "Production of a Signal on a Termination is stopped by application of > a new Signals Descriptor, or detection of an Event on the Termination .." > > Also, > "A new Signals Descriptor replaces any existing Signals Descriptor." > > Q: The MG maintains the current signal descriptor until a > new descriptor is not sent by the MGC. But, after the termination > finishes the playout of the signal or an event is detected and the > signals are stopped, the signal descriptor remains the current one > with MG until new one is received as according to the rules we cannot > remove it until new signal descriptor is received. > But my doubt is why should we maintain this descriptor since it has already > become deactivated(either by finishing playout or event stopped it) and MGC > cannot instruct MG to use it further ??. > > Thanks , > regards , > Mukta Vasudeva > > Catch all the cricket action. Download Yahoo! Score tracker > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 14 14:26:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08426 for ; Tue, 14 Jan 2003 14:26:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EJeww25128 for megaco-archive@odin.ietf.org; Tue, 14 Jan 2003 14:40:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJewJ25125 for ; Tue, 14 Jan 2003 14:40:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08399 for ; Tue, 14 Jan 2003 14:26:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJdQJ25020; Tue, 14 Jan 2003 14:39:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJcYJ24967 for ; Tue, 14 Jan 2003 14:38:34 -0500 Received: from zrtps0kp.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08265 for ; Tue, 14 Jan 2003 14:23:44 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0EJR4J08029 for ; Tue, 14 Jan 2003 14:27:04 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jan 2003 14:27:04 -0500 Message-ID: From: "Kevin Boyle" To: Raphael Tryster , Christian Groves , "Tom-PT Taylor" Cc: "'mukta vasudeva'" , "'Alan Chou'" , megaco@ietf.org Subject: RE: [Megaco] Signal Descriptor Doubts Date: Tue, 14 Jan 2003 14:26:55 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , So, I hunted back through the archives to ensure that my memory was in tune with the reality of what was decided. The first discussion I saw in about this my archives of the list occurred from late June through mid-July 2000. The outcome of the discussion was that the MG should return what is currently "playing" and what is remaining to be "played". Now, that being said, I personally do not have strong feelings one way or the other on this. If implementation experience has shown that it is better to return the previously set descriptor, rather than the "current" descriptor, then perhaps we should change. This would also depend on how many implementations are working in this fashion already. Kevin -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Tuesday, January 14, 2003 1:41 AM To: Christian Groves; Taylor, Tom-PT [CAR:5N00:EXCH] Cc: 'mukta vasudeva'; 'Alan Chou'; megaco@ietf.org; Boyle, Kevin [NCRTP:3R90:EXCH] Subject: RE: [Megaco] Signal Descriptor Doubts Kevin Boyle, answering my question a year ago, saw it differently. Raphael Tryster [The next sentence is Kevin's reply.] This has been discussed in the past, and the latter alternative (that is, the current value of the descriptor) was agreed to be the proper response, if my memory serves. Kevin -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Wednesday, February 13, 2002 8:29 AM To: megaco@ietf.org Subject: [Megaco] Auditing a signals descriptor Does the value of a signals descriptor change over time as the signals are played by the MG? The practical significance is that when an MG receives an AuditValue command asking for the signals descriptor, should it return the last value of the signals descriptor as sent by the MGC, or the set of currently playing and future signals, which may be empty if all the signals have completed? If this is still an open question, I would vote for the latter alternative, because: Perhaps this is related to the case of auditing a descriptor that had over-or under-specified parameters. I expect that in this case the MG would return just the values it has chosen, and not the entire original descriptor. Raphael Tryster BM__MailData-----Original Message----- From: Christian Groves [SMTP:Christian.Groves@ericsson.com.au] Sent: Tuesday, 14 January, 2003 2:14 AM To: Tom-PT Taylor Cc: 'mukta vasudeva'; 'Alan Chou'; megaco@ietf.org Subject: Re: [Megaco] Signal Descriptor Doubts G'Day Tom, I pretty much see it as you have described. I don't think there is a big overhead in keeping the signal descriptor. You certainly need to be able to keep it for the period of time whilst the signal is playing. So whilst it not optimal I don't think its an error either. Regards, Christian Tom-PT Taylor wrote: > > This is more or less the same question Alan Chou raised a week ago. It's > not something I ever thought about, but here is the situation as I see it: > -- the Signals Descriptor remains unchanged, even if the signal(s) it > describes have been terminated > -- the MG is required to maintain the knowledge of which signals have been > terminated and which have not > -- we have no way in general to indicate on audit which signals have > completed and which have not. This was probably a mistake in design. > > -----Original Message----- > From: mukta vasudeva [mailto:reachtomukta@yahoo.co.in ] > Sent: Monday, January 06, 2003 9:00 AM > To: megaco@ietf.org > Subject: [Megaco] Signal Descriptor Doubts > > hi , > Hope everyone had a good Christmas and will have a wonderfull new year > ahead. > I have some doubts related to Signal Descriptor handling. > 1. > RFC Section 7.1.11 states that > "Production of a Signal on a Termination is stopped by application of > a new Signals Descriptor, or detection of an Event on the Termination .." > > Also, > "A new Signals Descriptor replaces any existing Signals Descriptor." > > Q: The MG maintains the current signal descriptor until a > new descriptor is not sent by the MGC. But, after the termination > finishes the playout of the signal or an event is detected and the > signals are stopped, the signal descriptor remains the current one > with MG until new one is received as according to the rules we cannot > remove it until new signal descriptor is received. > But my doubt is why should we maintain this descriptor since it has already > become deactivated(either by finishing playout or event stopped it) and MGC > cannot instruct MG to use it further ??. > > Thanks , > regards , > Mukta Vasudeva > > Catch all the cricket action. Download Yahoo! Score tracker > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 14 21:10:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19055 for ; Tue, 14 Jan 2003 21:10:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F2OOJ21973; Tue, 14 Jan 2003 21:24:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F2LIJ21794 for ; Tue, 14 Jan 2003 21:21:18 -0500 Received: from moon.mercurykr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18943 for ; Tue, 14 Jan 2003 21:06:21 -0500 (EST) Received: from LocalHost ([165.133.17.229]) by moon.mercurykr.com (8.10.0.Beta10/8.10.0.Beta10) with SMTP id h0F2Ert18582 for ; Wed, 15 Jan 2003 11:14:53 +0900 Message-ID: <002401c2bc3b$86481b00$e51185a5@LocalHost> From: "Noh Jeong Min" To: Date: Wed, 15 Jan 2003 11:12:15 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C2BC86.F5FEC7F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Subject: [Megaco] Question on Service Change command with method as RESTART on ROOT termination. Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C2BC86.F5FEC7F0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGksIE1FR0FDTyBsaXN0Lg0KDQpJIGhhdmUgYSBkb3VidCBhYm91dCBTZXJ2aWNlIENoYW5nZSBj b21tYW5kIHdpdGggbWV0aG9kIGFzIFJlc3RhcnQgKFJlYXNvbjpDb2xkIEJvb3QpIG9uIFJvb3Qg dGVybWluYXRpb24uDQoNClExKSBEb2VzIGl0IGluZGljYXRlIHRoYXQgYWxsIHRlcm1pbmF0aW9u cyAoYWxsIHBoeXNpY2FsIHRlcm1pbmF0aW9ucyBpbiB0aGUgTlVMTCBjb250ZXh0KSBhcmUgaW4g c2VydmljZSwgYnkgZGVmYXVsdD8NCg0KT3IsIGRvZXMgTUcgbmVlZCBTZXJ2aWNlIENoYW5nZSBj b21tYW5kIHdpdGggbWV0aG9kIGFzIFJlc3RhcnQgKFJlYXNvbjogU2VydmljZSBSZXN0b3JlZCkg b24gcGh5c2ljYWwgdGVybWluYXRpb25zLCBhZnRlciBzZW5kIFNlcnZpY2UgQ2hhbmdlIGNvbW1h bmQgd2l0aCBtZXRob2QgYXMgUmVzdGFydCAoQ29sZCBCb290KSBvbiBSb290IHRlcm1pbmF0aW9u Pw0KDQoNCg== ------=_NextPart_000_0021_01C2BC86.F5FEC7F0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ4MDcuMjMwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpLCBNRUdB Q08gbGlzdC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj5JIGhhdmUgYSBkb3VidCBhYm91dCBTZXJ2aWNlIENoYW5n ZSBjb21tYW5kIHdpdGggbWV0aG9kIGFzIA0KUmVzdGFydCAoUmVhc29uOkNvbGQgQm9vdCkgb24g Um9vdCB0ZXJtaW5hdGlvbi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5RMSkgRG9lcyBpdCBpbmRpY2F0ZSB0aGF0 IGFsbCB0ZXJtaW5hdGlvbnMgKGFsbCBwaHlzaWNhbCANCnRlcm1pbmF0aW9ucyBpbiB0aGUmbmJz cDtOVUxMIGNvbnRleHQpIGFyZSBpbiBzZXJ2aWNlLCBieSBkZWZhdWx0PzwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y Pk9yLCZuYnNwO2RvZXMmbmJzcDtNRyBuZWVkJm5ic3A7U2VydmljZSBDaGFuZ2UgY29tbWFuZCB3 aXRoIA0KbWV0aG9kIGFzIFJlc3RhcnQgKFJlYXNvbjogU2VydmljZSBSZXN0b3JlZCkgb24gcGh5 c2ljYWwgdGVybWluYXRpb25zLCBhZnRlciANCnNlbmQgU2VydmljZSBDaGFuZ2UgY29tbWFuZCB3 aXRoIG1ldGhvZCBhcyBSZXN0YXJ0IChDb2xkIEJvb3QpIG9uIFJvb3QgDQp0ZXJtaW5hdGlvbj88 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0021_01C2BC86.F5FEC7F0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 14 21:11:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19077 for ; Tue, 14 Jan 2003 21:11:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0F2Pra22088 for megaco-archive@odin.ietf.org; Tue, 14 Jan 2003 21:25:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F2PrJ22085 for ; Tue, 14 Jan 2003 21:25:53 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19069 for ; Tue, 14 Jan 2003 21:10:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F2OOJ21973; Tue, 14 Jan 2003 21:24:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F2LIJ21794 for ; Tue, 14 Jan 2003 21:21:18 -0500 Received: from moon.mercurykr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18943 for ; Tue, 14 Jan 2003 21:06:21 -0500 (EST) Received: from LocalHost ([165.133.17.229]) by moon.mercurykr.com (8.10.0.Beta10/8.10.0.Beta10) with SMTP id h0F2Ert18582 for ; Wed, 15 Jan 2003 11:14:53 +0900 Message-ID: <002401c2bc3b$86481b00$e51185a5@LocalHost> From: "Noh Jeong Min" To: Date: Wed, 15 Jan 2003 11:12:15 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C2BC86.F5FEC7F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Subject: [Megaco] Question on Service Change command with method as RESTART on ROOT termination. Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C2BC86.F5FEC7F0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGksIE1FR0FDTyBsaXN0Lg0KDQpJIGhhdmUgYSBkb3VidCBhYm91dCBTZXJ2aWNlIENoYW5nZSBj b21tYW5kIHdpdGggbWV0aG9kIGFzIFJlc3RhcnQgKFJlYXNvbjpDb2xkIEJvb3QpIG9uIFJvb3Qg dGVybWluYXRpb24uDQoNClExKSBEb2VzIGl0IGluZGljYXRlIHRoYXQgYWxsIHRlcm1pbmF0aW9u cyAoYWxsIHBoeXNpY2FsIHRlcm1pbmF0aW9ucyBpbiB0aGUgTlVMTCBjb250ZXh0KSBhcmUgaW4g c2VydmljZSwgYnkgZGVmYXVsdD8NCg0KT3IsIGRvZXMgTUcgbmVlZCBTZXJ2aWNlIENoYW5nZSBj b21tYW5kIHdpdGggbWV0aG9kIGFzIFJlc3RhcnQgKFJlYXNvbjogU2VydmljZSBSZXN0b3JlZCkg b24gcGh5c2ljYWwgdGVybWluYXRpb25zLCBhZnRlciBzZW5kIFNlcnZpY2UgQ2hhbmdlIGNvbW1h bmQgd2l0aCBtZXRob2QgYXMgUmVzdGFydCAoQ29sZCBCb290KSBvbiBSb290IHRlcm1pbmF0aW9u Pw0KDQoNCg== ------=_NextPart_000_0021_01C2BC86.F5FEC7F0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ4MDcuMjMwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpLCBNRUdB Q08gbGlzdC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj5JIGhhdmUgYSBkb3VidCBhYm91dCBTZXJ2aWNlIENoYW5n ZSBjb21tYW5kIHdpdGggbWV0aG9kIGFzIA0KUmVzdGFydCAoUmVhc29uOkNvbGQgQm9vdCkgb24g Um9vdCB0ZXJtaW5hdGlvbi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5RMSkgRG9lcyBpdCBpbmRpY2F0ZSB0aGF0 IGFsbCB0ZXJtaW5hdGlvbnMgKGFsbCBwaHlzaWNhbCANCnRlcm1pbmF0aW9ucyBpbiB0aGUmbmJz cDtOVUxMIGNvbnRleHQpIGFyZSBpbiBzZXJ2aWNlLCBieSBkZWZhdWx0PzwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y Pk9yLCZuYnNwO2RvZXMmbmJzcDtNRyBuZWVkJm5ic3A7U2VydmljZSBDaGFuZ2UgY29tbWFuZCB3 aXRoIA0KbWV0aG9kIGFzIFJlc3RhcnQgKFJlYXNvbjogU2VydmljZSBSZXN0b3JlZCkgb24gcGh5 c2ljYWwgdGVybWluYXRpb25zLCBhZnRlciANCnNlbmQgU2VydmljZSBDaGFuZ2UgY29tbWFuZCB3 aXRoIG1ldGhvZCBhcyBSZXN0YXJ0IChDb2xkIEJvb3QpIG9uIFJvb3QgDQp0ZXJtaW5hdGlvbj88 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0021_01C2BC86.F5FEC7F0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jan 15 00:37:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23081 for ; Wed, 15 Jan 2003 00:37:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F5p9J01763; Wed, 15 Jan 2003 00:51:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F5kpJ01630 for ; Wed, 15 Jan 2003 00:46:51 -0500 Received: from mink.ecitele.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23034 for ; Wed, 15 Jan 2003 00:31:51 -0500 (EST) From: Dana.Herskowitz@ecitele.com Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id HAA01652 for ; Wed, 15 Jan 2003 07:29:58 +0200 (IST) To: megaco@ietf.org Cc: Eli.Liluz@ecitele.com, Benny.Lavi@ecitele.com, Ilana.Leibovitch@ecitele.com, Meir.Leshem@ecitele.com X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Wed, 15 Jan 2003 07:35:10 +0200 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 01/15/2003 07:35:10 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Megaco] Events + Events Bufer Descriptors Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hello, I have two questions regarding Events Descriptor and Events Buffer Descriptor: 1) When event is being detected and EBC=LockStep, should it be accumulated if it appears in Events Descriptor only, but not in the EB Descriptor? 2) If EBC=LockStep and the MG has just sent a Notify command, look at the following possible MGC message towards the MG: MEGACO/1 [1.1.1.1]:1111 Transaction = 500 {Context = 50 { Modify = S17/E1_1/1 { Media {TerminationState {EventBufferControl = OFF }}, Events = {dd/d1}}}} What should I do first ? : a) Clean the buffer, and then process the new Events Descriptor, or b) Act as EBC is still in LockStep, process the next "d1" event which appears in the EB (send Notify for it), and only finally clean the buffer Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 15 00:38:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23099 for ; Wed, 15 Jan 2003 00:38:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0F5qg801824 for megaco-archive@odin.ietf.org; Wed, 15 Jan 2003 00:52:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F5qgJ01821 for ; Wed, 15 Jan 2003 00:52:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23092 for ; Wed, 15 Jan 2003 00:37:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F5p9J01763; Wed, 15 Jan 2003 00:51:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F5kpJ01630 for ; Wed, 15 Jan 2003 00:46:51 -0500 Received: from mink.ecitele.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23034 for ; Wed, 15 Jan 2003 00:31:51 -0500 (EST) From: Dana.Herskowitz@ecitele.com Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id HAA01652 for ; Wed, 15 Jan 2003 07:29:58 +0200 (IST) To: megaco@ietf.org Cc: Eli.Liluz@ecitele.com, Benny.Lavi@ecitele.com, Ilana.Leibovitch@ecitele.com, Meir.Leshem@ecitele.com X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Wed, 15 Jan 2003 07:35:10 +0200 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 01/15/2003 07:35:10 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Megaco] Events + Events Bufer Descriptors Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hello, I have two questions regarding Events Descriptor and Events Buffer Descriptor: 1) When event is being detected and EBC=LockStep, should it be accumulated if it appears in Events Descriptor only, but not in the EB Descriptor? 2) If EBC=LockStep and the MG has just sent a Notify command, look at the following possible MGC message towards the MG: MEGACO/1 [1.1.1.1]:1111 Transaction = 500 {Context = 50 { Modify = S17/E1_1/1 { Media {TerminationState {EventBufferControl = OFF }}, Events = {dd/d1}}}} What should I do first ? : a) Clean the buffer, and then process the new Events Descriptor, or b) Act as EBC is still in LockStep, process the next "d1" event which appears in the EB (send Notify for it), and only finally clean the buffer Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jan 15 03:01:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19187 for ; Wed, 15 Jan 2003 03:01:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F8EZJ20690; Wed, 15 Jan 2003 03:14:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F8BXJ20601 for ; Wed, 15 Jan 2003 03:11:33 -0500 Received: from sess01.rdp.asi.alcatel.es (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19123 for ; Wed, 15 Jan 2003 02:56:30 -0500 (EST) Received: from sers002.rpi.ses.alcatel.es (localhost [127.0.0.1]) by sess01.rdp.asi.alcatel.es (8.11.2/8.11.2) with ESMTP id h0F7xnV04194; Wed, 15 Jan 2003 08:59:49 +0100 (MET) Received: from alcatel.es ([159.23.195.103]) by sers002.rpi.ses.alcatel.es (8.8.8+Sun/8.8.8) with ESMTP id IAA15137; Wed, 15 Jan 2003 08:59:53 +0100 (MET) Message-ID: <3E2514F9.F129438E@alcatel.es> Date: Wed, 15 Jan 2003 08:59:53 +0100 From: Fernando Vallejo Lazaro Organization: ALCATEL X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Noh Jeong Min CC: megaco@ietf.org Subject: Re: [Megaco] Question on Service Change command with method as RESTART on ROOT termination. References: <002401c2bc3b$86481b00$e51185a5@LocalHost> Content-Type: multipart/alternative; boundary="------------94CA257D153E489974D42956" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --------------94CA257D153E489974D42956 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, By default when the MG sends the ServiceChange Restart and receives the reply from the MGC all terminations are In Service (In 7.1.5 it says: ""in service" is the default state"). If any of them is out of service you should send a SVC Forced for that termination. Bye Fernando Noh Jeong Min wrote: > Hi, MEGACO list. I have a doubt about Service Change command with > method as Restart (Reason:Cold Boot) on Root termination. Q1) Does it > indicate that all terminations (all physical terminations in the NULL > context) are in service, by default? Or, does MG need Service Change > command with method as Restart (Reason: Service Restored) on physical > terminations, after send Service Change command with method as Restart > (Cold Boot) on Root termination? -- Fernando Vallejo Lazaro Phone: +34 91 330 8279 SW Wireline ASD-Madrid ALCATEL --------------94CA257D153E489974D42956 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

By default when the MG sends the ServiceChange Restart and receives the reply from the MGC
all terminations are In Service (In 7.1.5 it says: ""in service" is the default state").
If any of them is out of service you should send a SVC Forced for that termination.

Bye
Fernando

Noh Jeong Min wrote:

Hi, MEGACO list. I have a doubt about Service Change command with method as Restart (Reason:Cold Boot) on Root termination. Q1) Does it indicate that all terminations (all physical terminations in the NULL context) are in service, by default? Or, does MG need Service Change command with method as Restart (Reason: Service Restored) on physical terminations, after send Service Change command with method as Restart (Cold Boot) on Root termination?
-- 
Fernando Vallejo Lazaro
Phone:  +34 91 330 8279
SW  Wireline ASD-Madrid
       ALCATEL
  --------------94CA257D153E489974D42956-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 15 03:02:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19224 for ; Wed, 15 Jan 2003 03:02:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0F8GuV20788 for megaco-archive@odin.ietf.org; Wed, 15 Jan 2003 03:16:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F8GtJ20785 for ; Wed, 15 Jan 2003 03:16:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19202 for ; Wed, 15 Jan 2003 03:01:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F8EZJ20690; Wed, 15 Jan 2003 03:14:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F8BXJ20601 for ; Wed, 15 Jan 2003 03:11:33 -0500 Received: from sess01.rdp.asi.alcatel.es (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19123 for ; Wed, 15 Jan 2003 02:56:30 -0500 (EST) Received: from sers002.rpi.ses.alcatel.es (localhost [127.0.0.1]) by sess01.rdp.asi.alcatel.es (8.11.2/8.11.2) with ESMTP id h0F7xnV04194; Wed, 15 Jan 2003 08:59:49 +0100 (MET) Received: from alcatel.es ([159.23.195.103]) by sers002.rpi.ses.alcatel.es (8.8.8+Sun/8.8.8) with ESMTP id IAA15137; Wed, 15 Jan 2003 08:59:53 +0100 (MET) Message-ID: <3E2514F9.F129438E@alcatel.es> Date: Wed, 15 Jan 2003 08:59:53 +0100 From: Fernando Vallejo Lazaro Organization: ALCATEL X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Noh Jeong Min CC: megaco@ietf.org Subject: Re: [Megaco] Question on Service Change command with method as RESTART on ROOT termination. References: <002401c2bc3b$86481b00$e51185a5@LocalHost> Content-Type: multipart/alternative; boundary="------------94CA257D153E489974D42956" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --------------94CA257D153E489974D42956 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, By default when the MG sends the ServiceChange Restart and receives the reply from the MGC all terminations are In Service (In 7.1.5 it says: ""in service" is the default state"). If any of them is out of service you should send a SVC Forced for that termination. Bye Fernando Noh Jeong Min wrote: > Hi, MEGACO list. I have a doubt about Service Change command with > method as Restart (Reason:Cold Boot) on Root termination. Q1) Does it > indicate that all terminations (all physical terminations in the NULL > context) are in service, by default? Or, does MG need Service Change > command with method as Restart (Reason: Service Restored) on physical > terminations, after send Service Change command with method as Restart > (Cold Boot) on Root termination? -- Fernando Vallejo Lazaro Phone: +34 91 330 8279 SW Wireline ASD-Madrid ALCATEL --------------94CA257D153E489974D42956 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

By default when the MG sends the ServiceChange Restart and receives the reply from the MGC
all terminations are In Service (In 7.1.5 it says: ""in service" is the default state").
If any of them is out of service you should send a SVC Forced for that termination.

Bye
Fernando

Noh Jeong Min wrote:

Hi, MEGACO list. I have a doubt about Service Change command with method as Restart (Reason:Cold Boot) on Root termination. Q1) Does it indicate that all terminations (all physical terminations in the NULL context) are in service, by default? Or, does MG need Service Change command with method as Restart (Reason: Service Restored) on physical terminations, after send Service Change command with method as Restart (Cold Boot) on Root termination?
-- 
Fernando Vallejo Lazaro
Phone:  +34 91 330 8279
SW  Wireline ASD-Madrid
       ALCATEL
  --------------94CA257D153E489974D42956-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jan 15 04:42:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21071 for ; Wed, 15 Jan 2003 04:42:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F9uPJ27419; Wed, 15 Jan 2003 04:56:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F9mkJ27147 for ; Wed, 15 Jan 2003 04:48:46 -0500 Received: from mink.ecitele.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20946 for ; Wed, 15 Jan 2003 04:33:39 -0500 (EST) From: Dana.Herskowitz@ecitele.com Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id LAA06015 for ; Wed, 15 Jan 2003 11:31:45 +0200 (IST) Subject: RE: [Megaco] EventBufferControl and event handling. To: megaco@ietf.org Cc: Eli.Liluz@ecitele.com X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Wed, 15 Jan 2003 11:36:55 +0200 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 01/15/2003 11:36:58 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: , ----- Forwarded by Dana Herskowitz/ECI Telecom on 15/01/03 11:35 ----- Dana Herskowitz To: "Kevin Boyle" 15/01/03 07:58 cc: Subject: RE: [Megaco] EventBufferControl and event handling.(Document link: Dana Herskowitz) In this case, if we need to wait for reply, we have to accumulate later detected events even if EBC=OFF. Then what's the difference between OFF\LOCKSTEP? Doesn't this idea contradicts the RFC? Doesn't OFF mode disables accumulation ? Dana H. "Kevin Boyle" cc: Sent by: Subject: RE: [Megaco] EventBufferControl and event handling. megaco-admin@iet f.org 14/01/03 21:02 The short answer is, "It depends." The long answer is that some consideration has to be given to transport type and to whether the Notifies are coming from the same term or not. UDP does not guarantee message ordering. Given that, then it is wise for the MG to hold subsequent notifies until the outstanding one is acked. This allows the MG to ensure that proper ordering occurs -- especially in cases where ordering is important, like digit collection. Further, the MG can look at which term is generating the notify. If the two notifies are from different terms, then there is no reason to hold one while waiting for the ACK on the other. Ordering becomes important when the notifies are coming from the same term. Kevin -----Original Message----- From: Eli.Liluz@ecitele.com [mailto:Eli.Liluz@ecitele.com] Sent: Tuesday, January 14, 2003 5:01 AM To: megaco@ietf.org Subject: [Megaco] EventBufferControl and event handling. Hi all. According to chapter 7.1.9 in case the EventBufferControl = Off the MG does not handle any event buffering for notifications. Any way, is there any need form the MG to wait for an ACK from the MGC for the previous notification before it sends a new notification even if it is in Off state ? If the answer for that question is no, is there any way to validate the event notifications order from the MG to the MGC in Off state without using a digit map ? Thank you, Eli Liluz. _______________________________________________ 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 Jan 15 04:42:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21090 for ; Wed, 15 Jan 2003 04:42:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F9uXJ27443; Wed, 15 Jan 2003 04:56:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F9pKJ27232 for ; Wed, 15 Jan 2003 04:51:20 -0500 Received: from mink.ecitele.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20963 for ; Wed, 15 Jan 2003 04:36:17 -0500 (EST) From: Dana.Herskowitz@ecitele.com Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id LAA06322 for ; Wed, 15 Jan 2003 11:34:23 +0200 (IST) To: megaco@ietf.org X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Wed, 15 Jan 2003 11:39:34 +0200 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 01/15/2003 11:39:35 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Megaco] Events detection in LockStep mode Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hello, When receiving a new Events Descriptor and EBC=LockStep, the MG has to send Notify message. Let's say there are already 4-5 events in the buffer, which all appear in current Events Descriptor. Should the Notify message include all the events from the buffer or only the first one of them which appears in the Events Descriptor? Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 15 04:43:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21113 for ; Wed, 15 Jan 2003 04:43:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0F9vdi27498 for megaco-archive@odin.ietf.org; Wed, 15 Jan 2003 04:57:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F9vdJ27495 for ; Wed, 15 Jan 2003 04:57:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21085 for ; Wed, 15 Jan 2003 04:42:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F9uPJ27419; Wed, 15 Jan 2003 04:56:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F9mkJ27147 for ; Wed, 15 Jan 2003 04:48:46 -0500 Received: from mink.ecitele.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20946 for ; Wed, 15 Jan 2003 04:33:39 -0500 (EST) From: Dana.Herskowitz@ecitele.com Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id LAA06015 for ; Wed, 15 Jan 2003 11:31:45 +0200 (IST) Subject: RE: [Megaco] EventBufferControl and event handling. To: megaco@ietf.org Cc: Eli.Liluz@ecitele.com X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Wed, 15 Jan 2003 11:36:55 +0200 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 01/15/2003 11:36:58 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: , ----- Forwarded by Dana Herskowitz/ECI Telecom on 15/01/03 11:35 ----- Dana Herskowitz To: "Kevin Boyle" 15/01/03 07:58 cc: Subject: RE: [Megaco] EventBufferControl and event handling.(Document link: Dana Herskowitz) In this case, if we need to wait for reply, we have to accumulate later detected events even if EBC=OFF. Then what's the difference between OFF\LOCKSTEP? Doesn't this idea contradicts the RFC? Doesn't OFF mode disables accumulation ? Dana H. "Kevin Boyle" cc: Sent by: Subject: RE: [Megaco] EventBufferControl and event handling. megaco-admin@iet f.org 14/01/03 21:02 The short answer is, "It depends." The long answer is that some consideration has to be given to transport type and to whether the Notifies are coming from the same term or not. UDP does not guarantee message ordering. Given that, then it is wise for the MG to hold subsequent notifies until the outstanding one is acked. This allows the MG to ensure that proper ordering occurs -- especially in cases where ordering is important, like digit collection. Further, the MG can look at which term is generating the notify. If the two notifies are from different terms, then there is no reason to hold one while waiting for the ACK on the other. Ordering becomes important when the notifies are coming from the same term. Kevin -----Original Message----- From: Eli.Liluz@ecitele.com [mailto:Eli.Liluz@ecitele.com] Sent: Tuesday, January 14, 2003 5:01 AM To: megaco@ietf.org Subject: [Megaco] EventBufferControl and event handling. Hi all. According to chapter 7.1.9 in case the EventBufferControl = Off the MG does not handle any event buffering for notifications. Any way, is there any need form the MG to wait for an ACK from the MGC for the previous notification before it sends a new notification even if it is in Off state ? If the answer for that question is no, is there any way to validate the event notifications order from the MG to the MGC in Off state without using a digit map ? Thank you, Eli Liluz. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 15 04:43:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21126 for ; Wed, 15 Jan 2003 04:43:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0F9vfm27514 for megaco-archive@odin.ietf.org; Wed, 15 Jan 2003 04:57:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F9vfJ27511 for ; Wed, 15 Jan 2003 04:57:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21099 for ; Wed, 15 Jan 2003 04:42:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F9uXJ27443; Wed, 15 Jan 2003 04:56:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F9pKJ27232 for ; Wed, 15 Jan 2003 04:51:20 -0500 Received: from mink.ecitele.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20963 for ; Wed, 15 Jan 2003 04:36:17 -0500 (EST) From: Dana.Herskowitz@ecitele.com Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id LAA06322 for ; Wed, 15 Jan 2003 11:34:23 +0200 (IST) To: megaco@ietf.org X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Wed, 15 Jan 2003 11:39:34 +0200 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 01/15/2003 11:39:35 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Megaco] Events detection in LockStep mode Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hello, When receiving a new Events Descriptor and EBC=LockStep, the MG has to send Notify message. Let's say there are already 4-5 events in the buffer, which all appear in current Events Descriptor. Should the Notify message include all the events from the buffer or only the first one of them which appears in the Events Descriptor? Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jan 15 09:02:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27567 for ; Wed, 15 Jan 2003 09:02:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FEFiJ12521; Wed, 15 Jan 2003 09:15:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FEEbJ12465 for ; Wed, 15 Jan 2003 09:14:37 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27477 for ; Wed, 15 Jan 2003 08:59:27 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0FE2UM21554; Wed, 15 Jan 2003 09:02:30 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jan 2003 09:02:52 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E160@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Dana.Herskowitz@ecitele.com'" , megaco@ietf.org Cc: Eli.Liluz@ecitele.com, Benny.Lavi@ecitele.com, Ilana.Leibovitch@ecitele.com, Meir.Leshem@ecitele.com Subject: RE: [Megaco] Events + Events Bufer Descriptors Date: Wed, 15 Jan 2003 09:02:26 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi. See below. > -----Original Message----- > From: Dana.Herskowitz@ecitele.com > [mailto:Dana.Herskowitz@ecitele.com] > Sent: Wednesday, January 15, 2003 12:35 AM > To: megaco@ietf.org > Cc: Eli.Liluz@ecitele.com; Benny.Lavi@ecitele.com; > Ilana.Leibovitch@ecitele.com; Meir.Leshem@ecitele.com > Subject: [Megaco] Events + Events Bufer Descriptors > > > Hello, > > I have two questions regarding Events Descriptor and Events Buffer > Descriptor: > > 1) When event is being detected and EBC=LockStep, should it > be accumulated if it appears in Events Descriptor only, but > not in the EB Descriptor? [PTT] It should be accumulated only if it appears in the EB Descriptor. > > 2) If EBC=LockStep and the MG has just sent a Notify command, > look at the following possible MGC message towards the MG: > MEGACO/1 [1.1.1.1]:1111 > > Transaction = 500 {Context = 50 { > > Modify = S17/E1_1/1 { > > Media {TerminationState > {EventBufferControl = OFF > }}, > > Events = {dd/d1}}}} > > > What should I do first ? : > a) Clean the buffer, and then process the new Events Descriptor, or > b) Act as EBC is still in LockStep, process the next "d1" > event which appears in the EB (send Notify for it), and only > finally clean the buffer [PTT] Clean the buffer first. > > Regards, > Dana H. > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 15 09:02:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27588 for ; Wed, 15 Jan 2003 09:02:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FEHEa12572 for megaco-archive@odin.ietf.org; Wed, 15 Jan 2003 09:17:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FEHDJ12569 for ; Wed, 15 Jan 2003 09:17:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27572 for ; Wed, 15 Jan 2003 09:02:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FEFiJ12521; Wed, 15 Jan 2003 09:15:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FEEbJ12465 for ; Wed, 15 Jan 2003 09:14:37 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27477 for ; Wed, 15 Jan 2003 08:59:27 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0FE2UM21554; Wed, 15 Jan 2003 09:02:30 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jan 2003 09:02:52 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E160@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Dana.Herskowitz@ecitele.com'" , megaco@ietf.org Cc: Eli.Liluz@ecitele.com, Benny.Lavi@ecitele.com, Ilana.Leibovitch@ecitele.com, Meir.Leshem@ecitele.com Subject: RE: [Megaco] Events + Events Bufer Descriptors Date: Wed, 15 Jan 2003 09:02:26 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi. See below. > -----Original Message----- > From: Dana.Herskowitz@ecitele.com > [mailto:Dana.Herskowitz@ecitele.com] > Sent: Wednesday, January 15, 2003 12:35 AM > To: megaco@ietf.org > Cc: Eli.Liluz@ecitele.com; Benny.Lavi@ecitele.com; > Ilana.Leibovitch@ecitele.com; Meir.Leshem@ecitele.com > Subject: [Megaco] Events + Events Bufer Descriptors > > > Hello, > > I have two questions regarding Events Descriptor and Events Buffer > Descriptor: > > 1) When event is being detected and EBC=LockStep, should it > be accumulated if it appears in Events Descriptor only, but > not in the EB Descriptor? [PTT] It should be accumulated only if it appears in the EB Descriptor. > > 2) If EBC=LockStep and the MG has just sent a Notify command, > look at the following possible MGC message towards the MG: > MEGACO/1 [1.1.1.1]:1111 > > Transaction = 500 {Context = 50 { > > Modify = S17/E1_1/1 { > > Media {TerminationState > {EventBufferControl = OFF > }}, > > Events = {dd/d1}}}} > > > What should I do first ? : > a) Clean the buffer, and then process the new Events Descriptor, or > b) Act as EBC is still in LockStep, process the next "d1" > event which appears in the EB (send Notify for it), and only > finally clean the buffer [PTT] Clean the buffer first. > > Regards, > Dana H. > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jan 15 09:04:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27663 for ; Wed, 15 Jan 2003 09:04:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FEIAJ12626; Wed, 15 Jan 2003 09:18:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FEHCJ12564 for ; Wed, 15 Jan 2003 09:17:12 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27566 for ; Wed, 15 Jan 2003 09:02:01 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0FE5HM21780; Wed, 15 Jan 2003 09:05:18 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jan 2003 09:05:40 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E161@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Dana.Herskowitz@ecitele.com'" , megaco@ietf.org Cc: Eli.Liluz@ecitele.com Subject: RE: [Megaco] EventBufferControl and event handling. Date: Wed, 15 Jan 2003 09:05:14 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , There's a difference between accumulating events (strictly an application issue) and holding back messages (application-managed transport). Kevin was talking about the latter. > -----Original Message----- > From: Dana.Herskowitz@ecitele.com > [mailto:Dana.Herskowitz@ecitele.com] > Sent: Wednesday, January 15, 2003 4:37 AM > To: megaco@ietf.org > Cc: Eli.Liluz@ecitele.com > Subject: RE: [Megaco] EventBufferControl and event handling. > > > > ----- Forwarded by Dana Herskowitz/ECI Telecom on 15/01/03 11:35 ----- > > > > Dana Herskowitz > > > To: > "Kevin Boyle" > > 15/01/03 07:58 cc: > > > Subject: RE: > [Megaco] EventBufferControl and event handling.(Document > link: Dana > Herskowitz) > > > > > > > > > In this case, if we need to wait for reply, we have to > accumulate later detected events even if EBC=OFF. Then what's > the difference between OFF\LOCKSTEP? Doesn't this idea > contradicts the RFC? Doesn't OFF mode disables accumulation ? > > Dana H. > > > > > > > "Kevin Boyle" > > > Eli.Liluz@ecitele.com, megaco@ietf.org > > tworks.com> cc: > > > Sent by: Subject: RE: > [Megaco] EventBufferControl and event handling. > > megaco-admin@iet > > > f.org > > > > > > > > > 14/01/03 21:02 > > > > > > > > > > > > The short answer is, "It depends." > > The long answer is that some consideration has to be given to > transport type and to whether the Notifies are coming from > the same term or not. > > UDP does not guarantee message ordering. Given that, then it > is wise for the MG to hold subsequent notifies until the > outstanding one is acked. This allows the MG to ensure that > proper ordering occurs -- especially in cases where ordering > is important, like digit collection. > > Further, the MG can look at which term is generating the > notify. If the two notifies are from different terms, then > there is no reason to hold one while waiting for the ACK on > the other. Ordering becomes important when the notifies are > coming from the same term. > > Kevin > > -----Original Message----- > From: Eli.Liluz@ecitele.com [mailto:Eli.Liluz@ecitele.com] > Sent: Tuesday, January 14, 2003 5:01 AM > To: megaco@ietf.org > Subject: [Megaco] EventBufferControl and event handling. > > > Hi all. > > According to chapter 7.1.9 in case the EventBufferControl = > Off the MG does not handle any event buffering for notifications. > > Any way, is there any need form the MG to wait for an ACK > from the MGC for the previous notification before it sends a > new notification even if it is in Off state ? > > If the answer for that question is no, is there any way to > validate the event notifications order from the MG to the MGC > in Off state without using a digit map ? > > Thank you, > Eli Liluz. > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 15 09:04:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27685 for ; Wed, 15 Jan 2003 09:04:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FEJXF12666 for megaco-archive@odin.ietf.org; Wed, 15 Jan 2003 09:19:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FEJXJ12663 for ; Wed, 15 Jan 2003 09:19:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27675 for ; Wed, 15 Jan 2003 09:04:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FEIAJ12626; Wed, 15 Jan 2003 09:18:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FEHCJ12564 for ; Wed, 15 Jan 2003 09:17:12 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27566 for ; Wed, 15 Jan 2003 09:02:01 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0FE5HM21780; Wed, 15 Jan 2003 09:05:18 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jan 2003 09:05:40 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E161@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Dana.Herskowitz@ecitele.com'" , megaco@ietf.org Cc: Eli.Liluz@ecitele.com Subject: RE: [Megaco] EventBufferControl and event handling. Date: Wed, 15 Jan 2003 09:05:14 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , There's a difference between accumulating events (strictly an application issue) and holding back messages (application-managed transport). Kevin was talking about the latter. > -----Original Message----- > From: Dana.Herskowitz@ecitele.com > [mailto:Dana.Herskowitz@ecitele.com] > Sent: Wednesday, January 15, 2003 4:37 AM > To: megaco@ietf.org > Cc: Eli.Liluz@ecitele.com > Subject: RE: [Megaco] EventBufferControl and event handling. > > > > ----- Forwarded by Dana Herskowitz/ECI Telecom on 15/01/03 11:35 ----- > > > > Dana Herskowitz > > > To: > "Kevin Boyle" > > 15/01/03 07:58 cc: > > > Subject: RE: > [Megaco] EventBufferControl and event handling.(Document > link: Dana > Herskowitz) > > > > > > > > > In this case, if we need to wait for reply, we have to > accumulate later detected events even if EBC=OFF. Then what's > the difference between OFF\LOCKSTEP? Doesn't this idea > contradicts the RFC? Doesn't OFF mode disables accumulation ? > > Dana H. > > > > > > > "Kevin Boyle" > > > Eli.Liluz@ecitele.com, megaco@ietf.org > > tworks.com> cc: > > > Sent by: Subject: RE: > [Megaco] EventBufferControl and event handling. > > megaco-admin@iet > > > f.org > > > > > > > > > 14/01/03 21:02 > > > > > > > > > > > > The short answer is, "It depends." > > The long answer is that some consideration has to be given to > transport type and to whether the Notifies are coming from > the same term or not. > > UDP does not guarantee message ordering. Given that, then it > is wise for the MG to hold subsequent notifies until the > outstanding one is acked. This allows the MG to ensure that > proper ordering occurs -- especially in cases where ordering > is important, like digit collection. > > Further, the MG can look at which term is generating the > notify. If the two notifies are from different terms, then > there is no reason to hold one while waiting for the ACK on > the other. Ordering becomes important when the notifies are > coming from the same term. > > Kevin > > -----Original Message----- > From: Eli.Liluz@ecitele.com [mailto:Eli.Liluz@ecitele.com] > Sent: Tuesday, January 14, 2003 5:01 AM > To: megaco@ietf.org > Subject: [Megaco] EventBufferControl and event handling. > > > Hi all. > > According to chapter 7.1.9 in case the EventBufferControl = > Off the MG does not handle any event buffering for notifications. > > Any way, is there any need form the MG to wait for an ACK > from the MGC for the previous notification before it sends a > new notification even if it is in Off state ? > > If the answer for that question is no, is there any way to > validate the event notifications order from the MG to the MGC > in Off state without using a digit map ? > > Thank you, > Eli Liluz. > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jan 15 09:17:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28037 for ; Wed, 15 Jan 2003 09:17:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FEVGJ13146; Wed, 15 Jan 2003 09:31:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FEQBJ12929 for ; Wed, 15 Jan 2003 09:26:11 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27811 for ; Wed, 15 Jan 2003 09:11:01 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0FEEHM22601; Wed, 15 Jan 2003 09:14:17 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jan 2003 09:14:39 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E162@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Dana.Herskowitz@ecitele.com'" , megaco@ietf.org Subject: RE: [Megaco] Events detection in LockStep mode Date: Wed, 15 Jan 2003 09:14:11 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Section 7.1.9 Case 1 2(a) is quite clear on this: a single event is reported and the MG awaits a new Events Descriptor before taking further action. > -----Original Message----- > From: Dana.Herskowitz@ecitele.com > [mailto:Dana.Herskowitz@ecitele.com] > Sent: Wednesday, January 15, 2003 4:40 AM > To: megaco@ietf.org > Subject: [Megaco] Events detection in LockStep mode > > > Hello, > When receiving a new Events Descriptor and EBC=LockStep, the > MG has to send Notify message. Let's say there are already > 4-5 events in the buffer, which all appear in current Events > Descriptor. Should the Notify message include all the events > from the buffer or only the first one of them which appears > in the Events Descriptor? > > Regards, > > Dana H. > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 15 09:18:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28071 for ; Wed, 15 Jan 2003 09:18:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FEWrm13283 for megaco-archive@odin.ietf.org; Wed, 15 Jan 2003 09:32:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FEWqJ13280 for ; Wed, 15 Jan 2003 09:32:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28051 for ; Wed, 15 Jan 2003 09:17:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FEVGJ13146; Wed, 15 Jan 2003 09:31:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FEQBJ12929 for ; Wed, 15 Jan 2003 09:26:11 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27811 for ; Wed, 15 Jan 2003 09:11:01 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0FEEHM22601; Wed, 15 Jan 2003 09:14:17 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jan 2003 09:14:39 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E162@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Dana.Herskowitz@ecitele.com'" , megaco@ietf.org Subject: RE: [Megaco] Events detection in LockStep mode Date: Wed, 15 Jan 2003 09:14:11 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Section 7.1.9 Case 1 2(a) is quite clear on this: a single event is reported and the MG awaits a new Events Descriptor before taking further action. > -----Original Message----- > From: Dana.Herskowitz@ecitele.com > [mailto:Dana.Herskowitz@ecitele.com] > Sent: Wednesday, January 15, 2003 4:40 AM > To: megaco@ietf.org > Subject: [Megaco] Events detection in LockStep mode > > > Hello, > When receiving a new Events Descriptor and EBC=LockStep, the > MG has to send Notify message. Let's say there are already > 4-5 events in the buffer, which all appear in current Events > Descriptor. Should the Notify message include all the events > from the buffer or only the first one of them which appears > in the Events Descriptor? > > Regards, > > Dana H. > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jan 15 09:52:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28883 for ; Wed, 15 Jan 2003 09:52:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FF6FJ15565; Wed, 15 Jan 2003 10:06:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FF5XJ15517 for ; Wed, 15 Jan 2003 10:05:33 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28826; Wed, 15 Jan 2003 09:50:22 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0FErgM26520; Wed, 15 Jan 2003 09:53:43 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jan 2003 09:53:42 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E163@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'mmusic@ietf.org'" , "'megaco@ietf.org'" Date: Wed, 15 Jan 2003 09:53:35 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Megaco] draft-taylor-mmusic-sdp-tdm-xx Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 subject draft defined a bunch of attributes to allow text-formatted specification of bearer characteristics for TDM circuits. The Megaco NAS packages had a dependency on it. It appears that there is no real interest in this draft, so I am going to let it die. The purpose of this note is to make sure that is the right thing to do. I will rewrite the Megaco NAS packages draft to use the RFC 3108 bearerSigIE attribute where necessary. This implies that the NAS/MG has to understand the Q.931 encoding of the Bearer Capability, Low Layer Compatibility, and High Layer Compatibility Information Elements, expressed as hex strings. Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 15 09:52:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28936 for ; Wed, 15 Jan 2003 09:52:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FF7cI16296 for megaco-archive@odin.ietf.org; Wed, 15 Jan 2003 10:07:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FF7cJ16293 for ; Wed, 15 Jan 2003 10:07:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28888 for ; Wed, 15 Jan 2003 09:52:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FF6FJ15565; Wed, 15 Jan 2003 10:06:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FF5XJ15517 for ; Wed, 15 Jan 2003 10:05:33 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28826; Wed, 15 Jan 2003 09:50:22 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0FErgM26520; Wed, 15 Jan 2003 09:53:43 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jan 2003 09:53:42 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E163@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'mmusic@ietf.org'" , "'megaco@ietf.org'" Date: Wed, 15 Jan 2003 09:53:35 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Megaco] draft-taylor-mmusic-sdp-tdm-xx Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 subject draft defined a bunch of attributes to allow text-formatted specification of bearer characteristics for TDM circuits. The Megaco NAS packages had a dependency on it. It appears that there is no real interest in this draft, so I am going to let it die. The purpose of this note is to make sure that is the right thing to do. I will rewrite the Megaco NAS packages draft to use the RFC 3108 bearerSigIE attribute where necessary. This implies that the NAS/MG has to understand the Q.931 encoding of the Bearer Capability, Low Layer Compatibility, and High Layer Compatibility Information Elements, expressed as hex strings. Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jan 16 00:09:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21077 for ; Thu, 16 Jan 2003 00:09:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G5OJJ10311; Thu, 16 Jan 2003 00:24:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G5MYJ10245 for ; Thu, 16 Jan 2003 00:22:34 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21030 for ; Thu, 16 Jan 2003 00:07:06 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0G5AKAv003870; Thu, 16 Jan 2003 06:10:20 +0100 (MET) Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNDHNHS; Thu, 16 Jan 2003 06:10:20 +0100 Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id GAA11124; Thu, 16 Jan 2003 06:10:19 +0100 (MET) Received: from ericsson.com.au ([146.11.233.193]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id GAA15439; Thu, 16 Jan 2003 06:10:16 +0100 (MET) Message-ID: <3E26363A.3D0603E7@ericsson.com.au> Date: Thu, 16 Jan 2003 15:34:02 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Boyle CC: Raphael Tryster , Tom-PT Taylor , "'mukta vasudeva'" , "'Alan Chou'" , megaco@ietf.org Subject: Re: [Megaco] Signal Descriptor Doubts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit G'Day Kevin and Raphael, In v2 the specification already has text on what should happen:- 7.2.5 AuditValue ... o To audit a signal the relevant signal list ID and/or signal ID are provided. Only if the signal is active the values of all the signal parameters are returned including: the keepactive indication, signal type, duration, signal completion indication and package defined properties. Regards, Christian _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jan 16 00:10:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21094 for ; Thu, 16 Jan 2003 00:10:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G5OQJ10332; Thu, 16 Jan 2003 00:24:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G5MgJ10253 for ; Thu, 16 Jan 2003 00:22:42 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21034 for ; Thu, 16 Jan 2003 00:07:14 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0G5APAv003881; Thu, 16 Jan 2003 06:10:25 +0100 (MET) Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNM0HXJ; Thu, 16 Jan 2003 06:10:25 +0100 Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id GAA11128; Thu, 16 Jan 2003 06:10:24 +0100 (MET) Received: from ericsson.com.au ([146.11.233.193]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id GAA15443; Thu, 16 Jan 2003 06:10:21 +0100 (MET) Message-ID: <3E263724.F1A3A946@ericsson.com.au> Date: Thu, 16 Jan 2003 15:37:56 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: shbansal@hss.hns.com CC: "'megaco@ietf.org'" , vikas@hss.hns.com Subject: Re: [Megaco] Query regarding H.248.10 (Congestion Handling Package) References: <65256CAE.001F4E86.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Shobhit, Please see my replies below. Regards, Christian shbansal@hss.hns.com wrote: > > Hi all, > > I have few queries in congestion handling package, > > The document says: > > "Description: > > The package makes it possible for the MG to control its load. > > The events in this package may be provisioned in the MG. > > The event in this package may only be applied to the Root termination." > > It means that the events may be provisioned in the MG without any event enabling > request from MGC. > > My questions: > > 1> If the event is pre provisioned and MGC has not sent ant request for enabling > this event then > > a) Can MG report this event to MGC without having any associated event > request identifier [CHG] No > > b) If (1) yes then what will be the request identifier that should be used > in notify request. > > c) If (1) is yes, then If the event is pre provisioned and MGC does not > support such package, > > how MGC will convey this to MG so that MG does not report this event > in future > > d) If (1) is no, then what is the use of pre provisioning. [CHG] The request ID must be reported as part on an event. Therefore you have one of two options use EventID=0 or as part of the pre-provisioning pre-provision the requestID that will be used. > > 2> Is MGC allowed to disable this event. If yes, then how will MGC disable this > event [CHG] Yes. Through normal event disable/replacement routines. > > 3> Can MGC disable the event is it is pre-provisioned [CHG] Yes. I can't why you would pre-provision the event in the MGC and MG then disable it?? > > Thanks and regards > > Shobhit > > DISCLAIMER: This message is proprietary to Hughes Software Systems > Limited (HSS) and is intended solely for the use of the individual > to whom it is addressed. It may contain privileged or confidential > information and should not be circulated or used for any purpose other > than for what it is intended. If you have received this message in error, > please notify the originator immediately. If you are not the intended > recipient, you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. HSS accepts > no responsibility for loss or damage arising from the use of the information > transmitted by this email including damage from virus. > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jan 16 00:10:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21112 for ; Thu, 16 Jan 2003 00:10:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0G5POR10390 for megaco-archive@odin.ietf.org; Thu, 16 Jan 2003 00:25:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G5POJ10387 for ; Thu, 16 Jan 2003 00:25:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21083 for ; Thu, 16 Jan 2003 00:09:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G5OJJ10311; Thu, 16 Jan 2003 00:24:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G5MYJ10245 for ; Thu, 16 Jan 2003 00:22:34 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21030 for ; Thu, 16 Jan 2003 00:07:06 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0G5AKAv003870; Thu, 16 Jan 2003 06:10:20 +0100 (MET) Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNDHNHS; Thu, 16 Jan 2003 06:10:20 +0100 Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id GAA11124; Thu, 16 Jan 2003 06:10:19 +0100 (MET) Received: from ericsson.com.au ([146.11.233.193]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id GAA15439; Thu, 16 Jan 2003 06:10:16 +0100 (MET) Message-ID: <3E26363A.3D0603E7@ericsson.com.au> Date: Thu, 16 Jan 2003 15:34:02 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Boyle CC: Raphael Tryster , Tom-PT Taylor , "'mukta vasudeva'" , "'Alan Chou'" , megaco@ietf.org Subject: Re: [Megaco] Signal Descriptor Doubts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit G'Day Kevin and Raphael, In v2 the specification already has text on what should happen:- 7.2.5 AuditValue ... o To audit a signal the relevant signal list ID and/or signal ID are provided. Only if the signal is active the values of all the signal parameters are returned including: the keepactive indication, signal type, duration, signal completion indication and package defined properties. Regards, Christian _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jan 16 00:10:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21125 for ; Thu, 16 Jan 2003 00:10:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0G5PTB10405 for megaco-archive@odin.ietf.org; Thu, 16 Jan 2003 00:25:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G5PTJ10402 for ; Thu, 16 Jan 2003 00:25:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21103 for ; Thu, 16 Jan 2003 00:10:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G5OQJ10332; Thu, 16 Jan 2003 00:24:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G5MgJ10253 for ; Thu, 16 Jan 2003 00:22:42 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21034 for ; Thu, 16 Jan 2003 00:07:14 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0G5APAv003881; Thu, 16 Jan 2003 06:10:25 +0100 (MET) Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNM0HXJ; Thu, 16 Jan 2003 06:10:25 +0100 Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id GAA11128; Thu, 16 Jan 2003 06:10:24 +0100 (MET) Received: from ericsson.com.au ([146.11.233.193]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id GAA15443; Thu, 16 Jan 2003 06:10:21 +0100 (MET) Message-ID: <3E263724.F1A3A946@ericsson.com.au> Date: Thu, 16 Jan 2003 15:37:56 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: shbansal@hss.hns.com CC: "'megaco@ietf.org'" , vikas@hss.hns.com Subject: Re: [Megaco] Query regarding H.248.10 (Congestion Handling Package) References: <65256CAE.001F4E86.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Shobhit, Please see my replies below. Regards, Christian shbansal@hss.hns.com wrote: > > Hi all, > > I have few queries in congestion handling package, > > The document says: > > "Description: > > The package makes it possible for the MG to control its load. > > The events in this package may be provisioned in the MG. > > The event in this package may only be applied to the Root termination." > > It means that the events may be provisioned in the MG without any event enabling > request from MGC. > > My questions: > > 1> If the event is pre provisioned and MGC has not sent ant request for enabling > this event then > > a) Can MG report this event to MGC without having any associated event > request identifier [CHG] No > > b) If (1) yes then what will be the request identifier that should be used > in notify request. > > c) If (1) is yes, then If the event is pre provisioned and MGC does not > support such package, > > how MGC will convey this to MG so that MG does not report this event > in future > > d) If (1) is no, then what is the use of pre provisioning. [CHG] The request ID must be reported as part on an event. Therefore you have one of two options use EventID=0 or as part of the pre-provisioning pre-provision the requestID that will be used. > > 2> Is MGC allowed to disable this event. If yes, then how will MGC disable this > event [CHG] Yes. Through normal event disable/replacement routines. > > 3> Can MGC disable the event is it is pre-provisioned [CHG] Yes. I can't why you would pre-provision the event in the MGC and MG then disable it?? > > Thanks and regards > > Shobhit > > DISCLAIMER: This message is proprietary to Hughes Software Systems > Limited (HSS) and is intended solely for the use of the individual > to whom it is addressed. It may contain privileged or confidential > information and should not be circulated or used for any purpose other > than for what it is intended. If you have received this message in error, > please notify the originator immediately. If you are not the intended > recipient, you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. HSS accepts > no responsibility for loss or damage arising from the use of the information > transmitted by this email including damage from virus. > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jan 16 02:06:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28335 for ; Thu, 16 Jan 2003 02:06:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G7F8J26219; Thu, 16 Jan 2003 02:15:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G72KJ15812 for ; Thu, 16 Jan 2003 02:02:20 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23087 for ; Thu, 16 Jan 2003 01:46:42 -0500 (EST) Received: from z19322a (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H8S00K8GO87MD@mta0.huawei.com> for megaco@ietf.org; Thu, 16 Jan 2003 14:48:09 +0800 (CST) Date: Thu, 16 Jan 2003 14:46:13 +0800 From: Alan Chou Subject: RE: [Megaco] Signal Descriptor Doubts In-reply-to: <3E26363A.3D0603E7@ericsson.com.au> To: "'Christian Groves'" , "'Kevin Boyle'" Cc: "'Raphael Tryster'" , "'Tom-PT Taylor'" , "'mukta vasudeva'" , megaco@ietf.org Message-id: <000001c2bd2a$f6acefc0$dc486e0a@HUAWEI.COM> Organization: Huawei Technologies Co.,Ltd. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=gb2312 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0G72KJ15813 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit 　　Hi all， 　　 Shall MG maintain the active state for the event, according the section 7.1.9 Events Descriptor: 　　When the MG receives a command with a new EventsDescriptor, one or 　　 more events may have been buffered in the EventBuffer in the MG. The 　　 value of EventBufferControl then determines how the MG treats such 　　 buffered events. 　　 　　 Case 1 　　 　　 If EventBufferControl equals LockStep and the MG receives a new 　　 EventsDescriptor it will check the FIFO EventBuffer and take the 　　 following actions: 　　 　　 1. If the EventBuffer is empty, the MG waits for detection of events 　　 based on the new EventsDescriptor. 　　 　　 2. If the EventBuffer is non-empty, the MG processes the FIFO queue 　　 starting with the first event: 　　 　　 a) If the event in the queue is in the events listed in the new 　　 EventsDescriptor, the MG acts on the event and removes the 　　 event from the EventBuffer. The time stamp of the Notify shall 　　 be the time the event was actually detected. The MG then waits for 　　 a new EventsDescriptor. ..... 　　according the above, shall we think that the new event description should active only one time detection ? If MG detect the event which was defined in event description, shall MG set the event to inactive, treat the subsequent detection for this event as invalid detection. 　　It will affect the implementation for event detect, since MG will use the separate resource for some event detection, if does'nt maintain the active state, MG will keep the resource along with the call in the whole time, that's not a good way. 　　Alan Chou 　　 ------------------------------------------------------------------------ 　　Huawei Technologies Co, Ltd. 　　3rd floor Luneng Building, No. 1 Shangdi 6th Street, 　　Haidian district, Beijing, China 100085 　　Fax : +86 (0)10 82882937 　　Phone : +86 (0)10 82882599 　　E-mail : zhouzifeng@huawei.com 　　Web : http://www.huawei.com 　　 ------------------------------------------------------------------------ 　　 　　-----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of Christian Groves Sent: Thursday, January 16, 2003 12:34 PM To: Kevin Boyle Cc: Raphael Tryster; Tom-PT Taylor; 'mukta vasudeva'; 'Alan Chou'; megaco@ietf.org Subject: Re: [Megaco] Signal Descriptor Doubts 　　 　　G'Day Kevin and Raphael, 　　 　　In v2 the specification already has text on what should happen:- 　　7.2.5 AuditValue 　　... 　　o To audit a signal the relevant signal list ID and/or signal ID are provided. 　　Only if the signal is active the values of all the signal parameters are 　　returned including: the keepactive indication, signal type, duration, signal 　　completion indication and package defined properties. 　　 　　Regards, Christian 　　 　　 　　_______________________________________________ 　　Megaco mailing list 　　Megaco@ietf.org 　　https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jan 16 02:06:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28781 for ; Thu, 16 Jan 2003 02:06:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0G7LWp27135 for megaco-archive@odin.ietf.org; Thu, 16 Jan 2003 02:21:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G7LVJ27132 for ; Thu, 16 Jan 2003 02:21:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28344 for ; Thu, 16 Jan 2003 02:06:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G7F8J26219; Thu, 16 Jan 2003 02:15:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G72KJ15812 for ; Thu, 16 Jan 2003 02:02:20 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23087 for ; Thu, 16 Jan 2003 01:46:42 -0500 (EST) Received: from z19322a (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H8S00K8GO87MD@mta0.huawei.com> for megaco@ietf.org; Thu, 16 Jan 2003 14:48:09 +0800 (CST) Date: Thu, 16 Jan 2003 14:46:13 +0800 From: Alan Chou Subject: RE: [Megaco] Signal Descriptor Doubts In-reply-to: <3E26363A.3D0603E7@ericsson.com.au> To: "'Christian Groves'" , "'Kevin Boyle'" Cc: "'Raphael Tryster'" , "'Tom-PT Taylor'" , "'mukta vasudeva'" , megaco@ietf.org Message-id: <000001c2bd2a$f6acefc0$dc486e0a@HUAWEI.COM> Organization: Huawei Technologies Co.,Ltd. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=gb2312 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0G72KJ15813 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit 　　Hi all， 　　 Shall MG maintain the active state for the event, according the section 7.1.9 Events Descriptor: 　　When the MG receives a command with a new EventsDescriptor, one or 　　 more events may have been buffered in the EventBuffer in the MG. The 　　 value of EventBufferControl then determines how the MG treats such 　　 buffered events. 　　 　　 Case 1 　　 　　 If EventBufferControl equals LockStep and the MG receives a new 　　 EventsDescriptor it will check the FIFO EventBuffer and take the 　　 following actions: 　　 　　 1. If the EventBuffer is empty, the MG waits for detection of events 　　 based on the new EventsDescriptor. 　　 　　 2. If the EventBuffer is non-empty, the MG processes the FIFO queue 　　 starting with the first event: 　　 　　 a) If the event in the queue is in the events listed in the new 　　 EventsDescriptor, the MG acts on the event and removes the 　　 event from the EventBuffer. The time stamp of the Notify shall 　　 be the time the event was actually detected. The MG then waits for 　　 a new EventsDescriptor. ..... 　　according the above, shall we think that the new event description should active only one time detection ? If MG detect the event which was defined in event description, shall MG set the event to inactive, treat the subsequent detection for this event as invalid detection. 　　It will affect the implementation for event detect, since MG will use the separate resource for some event detection, if does'nt maintain the active state, MG will keep the resource along with the call in the whole time, that's not a good way. 　　Alan Chou 　　 ------------------------------------------------------------------------ 　　Huawei Technologies Co, Ltd. 　　3rd floor Luneng Building, No. 1 Shangdi 6th Street, 　　Haidian district, Beijing, China 100085 　　Fax : +86 (0)10 82882937 　　Phone : +86 (0)10 82882599 　　E-mail : zhouzifeng@huawei.com 　　Web : http://www.huawei.com 　　 ------------------------------------------------------------------------ 　　 　　-----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of Christian Groves Sent: Thursday, January 16, 2003 12:34 PM To: Kevin Boyle Cc: Raphael Tryster; Tom-PT Taylor; 'mukta vasudeva'; 'Alan Chou'; megaco@ietf.org Subject: Re: [Megaco] Signal Descriptor Doubts 　　 　　G'Day Kevin and Raphael, 　　 　　In v2 the specification already has text on what should happen:- 　　7.2.5 AuditValue 　　... 　　o To audit a signal the relevant signal list ID and/or signal ID are provided. 　　Only if the signal is active the values of all the signal parameters are 　　returned including: the keepactive indication, signal type, duration, signal 　　completion indication and package defined properties. 　　 　　Regards, Christian 　　 　　 　　_______________________________________________ 　　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 Jan 16 04:44:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05605 for ; Thu, 16 Jan 2003 04:44:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G9tAJ06146; Thu, 16 Jan 2003 04:55:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G9nIJ05884 for ; Thu, 16 Jan 2003 04:49:18 -0500 Received: from mink.ecitele.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05536 for ; Thu, 16 Jan 2003 04:33:43 -0500 (EST) From: Dana.Herskowitz@ecitele.com Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id LAA13787; Thu, 16 Jan 2003 11:31:44 +0200 (IST) Subject: RE: [Megaco] Events detection in LockStep mode To: "Tom-PT Taylor" , megaco@ietf.org Cc: Eli.Liluz@ecitele.com X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Thu, 16 Jan 2003 11:36:55 +0200 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 01/16/2003 11:36:58 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: , Thanks for replying. The RFC also says: The MG may report several events in a single Transaction as long as this does not unnecessarily delay the reporting of individual events. Does it mean reporting same events which happened as a result of same trigger? Dana H. "Tom-PT Taylor" , megaco@ietf.org tworks.com> cc: Subject: RE: [Megaco] Events detection in LockStep mode 15/01/03 16:14 Section 7.1.9 Case 1 2(a) is quite clear on this: a single event is reported and the MG awaits a new Events Descriptor before taking further action. > -----Original Message----- > From: Dana.Herskowitz@ecitele.com > [mailto:Dana.Herskowitz@ecitele.com] > Sent: Wednesday, January 15, 2003 4:40 AM > To: megaco@ietf.org > Subject: [Megaco] Events detection in LockStep mode > > > Hello, > When receiving a new Events Descriptor and EBC=LockStep, the > MG has to send Notify message. Let's say there are already > 4-5 events in the buffer, which all appear in current Events > Descriptor. Should the Notify message include all the events > from the buffer or only the first one of them which appears > in the Events Descriptor? > > Regards, > > Dana H. > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jan 16 04:44:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05626 for ; Thu, 16 Jan 2003 04:44:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0G9xlO06318 for megaco-archive@odin.ietf.org; Thu, 16 Jan 2003 04:59:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G9xlJ06315 for ; Thu, 16 Jan 2003 04:59:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05616 for ; Thu, 16 Jan 2003 04:44:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G9tAJ06146; Thu, 16 Jan 2003 04:55:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G9nIJ05884 for ; Thu, 16 Jan 2003 04:49:18 -0500 Received: from mink.ecitele.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05536 for ; Thu, 16 Jan 2003 04:33:43 -0500 (EST) From: Dana.Herskowitz@ecitele.com Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id LAA13787; Thu, 16 Jan 2003 11:31:44 +0200 (IST) Subject: RE: [Megaco] Events detection in LockStep mode To: "Tom-PT Taylor" , megaco@ietf.org Cc: Eli.Liluz@ecitele.com X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Thu, 16 Jan 2003 11:36:55 +0200 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 01/16/2003 11:36:58 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: , Thanks for replying. The RFC also says: The MG may report several events in a single Transaction as long as this does not unnecessarily delay the reporting of individual events. Does it mean reporting same events which happened as a result of same trigger? Dana H. "Tom-PT Taylor" , megaco@ietf.org tworks.com> cc: Subject: RE: [Megaco] Events detection in LockStep mode 15/01/03 16:14 Section 7.1.9 Case 1 2(a) is quite clear on this: a single event is reported and the MG awaits a new Events Descriptor before taking further action. > -----Original Message----- > From: Dana.Herskowitz@ecitele.com > [mailto:Dana.Herskowitz@ecitele.com] > Sent: Wednesday, January 15, 2003 4:40 AM > To: megaco@ietf.org > Subject: [Megaco] Events detection in LockStep mode > > > Hello, > When receiving a new Events Descriptor and EBC=LockStep, the > MG has to send Notify message. Let's say there are already > 4-5 events in the buffer, which all appear in current Events > Descriptor. Should the Notify message include all the events > from the buffer or only the first one of them which appears > in the Events Descriptor? > > Regards, > > Dana H. > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jan 16 05:34:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06363 for ; Thu, 16 Jan 2003 05:34:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GAjJJ09709; Thu, 16 Jan 2003 05:45:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GAeNJ09475 for ; Thu, 16 Jan 2003 05:40:23 -0500 Received: from exchange.td-soft.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06240 for ; Thu, 16 Jan 2003 05:24:43 -0500 (EST) Received: through eSafe SMTP Relay 1042697016; Thu Jan 16 12:39:34 2003 Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jan 2003 12:25:41 +0200 Message-ID: From: Raphael Tryster To: Christian Groves , Kevin Boyle Cc: Raphael Tryster , Tom-PT Taylor , "'mukta vasudeva'" , "'Alan Chou'" , megaco@ietf.org Subject: RE: [Megaco] Signal Descriptor Doubts Date: Thu, 16 Jan 2003 12:25:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BD49.9D78B0F0" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2BD49.9D78B0F0 Content-Type: text/plain; charset="iso-8859-1" G'Day Christian, You seem to be agreeing that a signal that has finished playing should not be returned in reply to an audit. Are you going further and saying that a signal that has not yet started playing should also not be returned? Or do you agree that the term "active" can be stretched, as Kevin says, to mean "what is currently playing and what is remaining to be "played"? In other words, not dead yet? I think this is useful. Raphael Tryster -----Original Message----- From: Christian Groves [SMTP:Christian.Groves@ericsson.com.au] Sent: Thursday, 16 January, 2003 6:34 AM To: Kevin Boyle Cc: Raphael Tryster; Tom-PT Taylor; 'mukta vasudeva'; 'Alan Chou'; megaco@ietf.org Subject: Re: [Megaco] Signal Descriptor Doubts G'Day Kevin and Raphael, In v2 the specification already has text on what should happen:- 7.2.5 AuditValue ... o To audit a signal the relevant signal list ID and/or signal ID are provided. Only if the signal is active the values of all the signal parameters are returned including: the keepactive indication, signal type, duration, signal completion indication and package defined properties. Regards, Christian ------_=_NextPart_001_01C2BD49.9D78B0F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] Signal Descriptor Doubts

G'Day Christian,

You seem to be agreeing that a signal th= at has finished playing should not be returned in reply to an audit. = ; Are you going further and saying that a signal that has not yet started= playing should also not be returned?  Or do you agree that the term= "active" can be stretched, as Kevin says, to mean "what is currently playing and what is remaining to be "pl= ayed"?  In other words, not dea= d yet?  I think this is useful.

Raphael Tryster

    -----Original Mess= age-----
    From:   Christian Groves [= SMTP:Christian.Groves@ericsson.com.au]
    Sent:   Thursday, 16 January, 2003 6:34 AM
    To:     Kevin Boyle
    Cc:     Raphael Tryster; Tom-PT Taylor; 'mukta v= asudeva'; 'Alan Chou'; megaco@ietf.org
    Subject:    &nbs= p;   Re: [Megaco] Sign= al Descriptor Doubts

    G'Day Kevin and Raphael,

    In v2 the specification already ha= s text on what should happen:-
    7.2.5   AuditValue
    ...
    o     &n= bsp; To audit a signal the relevant signal list ID and/or signal ID are p= rovided.
    Only if the signal is active the = values of all the signal parameters are
    returned including: the keepactiv= e indication, signal type, duration, signal
    completion indication and package= defined properties.

    Regards, Christian

------_=_NextPart_001_01C2BD49.9D78B0F0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jan 16 05:34:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06398 for ; Thu, 16 Jan 2003 05:34:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GAnm909894 for megaco-archive@odin.ietf.org; Thu, 16 Jan 2003 05:49:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GAnmJ09891 for ; Thu, 16 Jan 2003 05:49:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06375 for ; Thu, 16 Jan 2003 05:34:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GAjJJ09709; Thu, 16 Jan 2003 05:45:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GAeNJ09475 for ; Thu, 16 Jan 2003 05:40:23 -0500 Received: from exchange.td-soft.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06240 for ; Thu, 16 Jan 2003 05:24:43 -0500 (EST) Received: through eSafe SMTP Relay 1042697016; Thu Jan 16 12:39:34 2003 Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jan 2003 12:25:41 +0200 Message-ID: From: Raphael Tryster To: Christian Groves , Kevin Boyle Cc: Raphael Tryster , Tom-PT Taylor , "'mukta vasudeva'" , "'Alan Chou'" , megaco@ietf.org Subject: RE: [Megaco] Signal Descriptor Doubts Date: Thu, 16 Jan 2003 12:25:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BD49.9D78B0F0" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2BD49.9D78B0F0 Content-Type: text/plain; charset="iso-8859-1" G'Day Christian, You seem to be agreeing that a signal that has finished playing should not be returned in reply to an audit. Are you going further and saying that a signal that has not yet started playing should also not be returned? Or do you agree that the term "active" can be stretched, as Kevin says, to mean "what is currently playing and what is remaining to be "played"? In other words, not dead yet? I think this is useful. Raphael Tryster -----Original Message----- From: Christian Groves [SMTP:Christian.Groves@ericsson.com.au] Sent: Thursday, 16 January, 2003 6:34 AM To: Kevin Boyle Cc: Raphael Tryster; Tom-PT Taylor; 'mukta vasudeva'; 'Alan Chou'; megaco@ietf.org Subject: Re: [Megaco] Signal Descriptor Doubts G'Day Kevin and Raphael, In v2 the specification already has text on what should happen:- 7.2.5 AuditValue ... o To audit a signal the relevant signal list ID and/or signal ID are provided. Only if the signal is active the values of all the signal parameters are returned including: the keepactive indication, signal type, duration, signal completion indication and package defined properties. Regards, Christian ------_=_NextPart_001_01C2BD49.9D78B0F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] Signal Descriptor Doubts

G'Day Christian,

You seem to be agreeing that a signal th= at has finished playing should not be returned in reply to an audit. = ; Are you going further and saying that a signal that has not yet started= playing should also not be returned?  Or do you agree that the term= "active" can be stretched, as Kevin says, to mean "what is currently playing and what is remaining to be "pl= ayed"?  In other words, not dea= d yet?  I think this is useful.

Raphael Tryster

    -----Original Mess= age-----
    From:   Christian Groves [= SMTP:Christian.Groves@ericsson.com.au]
    Sent:   Thursday, 16 January, 2003 6:34 AM
    To:     Kevin Boyle
    Cc:     Raphael Tryster; Tom-PT Taylor; 'mukta v= asudeva'; 'Alan Chou'; megaco@ietf.org
    Subject:    &nbs= p;   Re: [Megaco] Sign= al Descriptor Doubts

    G'Day Kevin and Raphael,

    In v2 the specification already ha= s text on what should happen:-
    7.2.5   AuditValue
    ...
    o     &n= bsp; To audit a signal the relevant signal list ID and/or signal ID are p= rovided.
    Only if the signal is active the = values of all the signal parameters are
    returned including: the keepactiv= e indication, signal type, duration, signal
    completion indication and package= defined properties.

    Regards, Christian

------_=_NextPart_001_01C2BD49.9D78B0F0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jan 16 05:49:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06785 for ; Thu, 16 Jan 2003 05:49:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GB0QJ10389; Thu, 16 Jan 2003 06:00:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GAs1J10134 for ; Thu, 16 Jan 2003 05:54:01 -0500 Received: from exchange.td-soft.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06499 for ; Thu, 16 Jan 2003 05:38:28 -0500 (EST) Received: through eSafe SMTP Relay 1042697016; Thu Jan 16 12:53:23 2003 Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jan 2003 12:39:27 +0200 Message-ID: From: Raphael Tryster To: "'megaco@ietf.org'" Date: Thu, 16 Jan 2003 12:39:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BD4B.865AA700" Subject: [Megaco] Spelling the long form of AC Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2BD4B.865AA700 Content-Type: text/plain Is there an error in RFC 3015 and all its updates, or is there just one command whose name (AuditCapabilities) is different from its long spelling (AuditCapability)? Raphael Tryster ------_=_NextPart_001_01C2BD4B.865AA700 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Spelling the long form of AC

Is there an error in RFC 3015 and all it= s updates, or is there just one command whose name (AuditCapabilities) is= different from its long spelling (AuditCapability)?

Raphael Tryster

------_=_NextPart_001_01C2BD4B.865AA700-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jan 16 05:49:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06813 for ; Thu, 16 Jan 2003 05:49:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GB4vE10770 for megaco-archive@odin.ietf.org; Thu, 16 Jan 2003 06:04:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GB4vJ10767 for ; Thu, 16 Jan 2003 06:04:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06795 for ; Thu, 16 Jan 2003 05:49:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GB0QJ10389; Thu, 16 Jan 2003 06:00:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GAs1J10134 for ; Thu, 16 Jan 2003 05:54:01 -0500 Received: from exchange.td-soft.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06499 for ; Thu, 16 Jan 2003 05:38:28 -0500 (EST) Received: through eSafe SMTP Relay 1042697016; Thu Jan 16 12:53:23 2003 Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jan 2003 12:39:27 +0200 Message-ID: From: Raphael Tryster To: "'megaco@ietf.org'" Date: Thu, 16 Jan 2003 12:39:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BD4B.865AA700" Subject: [Megaco] Spelling the long form of AC Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2BD4B.865AA700 Content-Type: text/plain Is there an error in RFC 3015 and all its updates, or is there just one command whose name (AuditCapabilities) is different from its long spelling (AuditCapability)? Raphael Tryster ------_=_NextPart_001_01C2BD4B.865AA700 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Spelling the long form of AC

Is there an error in RFC 3015 and all it= s updates, or is there just one command whose name (AuditCapabilities) is= different from its long spelling (AuditCapability)?

Raphael Tryster

------_=_NextPart_001_01C2BD4B.865AA700-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jan 16 08:55:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10877 for ; Thu, 16 Jan 2003 08:55:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GE6EJ23362; Thu, 16 Jan 2003 09:06:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GE3uJ23292 for ; Thu, 16 Jan 2003 09:03:56 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10795 for ; Thu, 16 Jan 2003 08:48:17 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0GDpWh17095; Thu, 16 Jan 2003 08:51:32 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jan 2003 08:51:33 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E170@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Alan Chou'" Cc: megaco@ietf.org Subject: RE: [Megaco] Signal Descriptor Doubts Date: Thu, 16 Jan 2003 08:51:30 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Assuming Lockstep operation: Event DETECTION is done on the basis of the EventBufferDescriptor. That puts detected events into a queue, along with the time each was detected. When a new Events Descriptor is activated, successive events in the queue are processed until one generates a notification (i.e. is RECOGNIZED). The processed events are removed from the queue, so I'm not sure what you mean about them being kept around for the whole call. > -----Original Message----- > From: Alan Chou [mailto:zhouzifeng@huawei.com] > Sent: Thursday, January 16, 2003 1:46 AM > To: 'Christian Groves'; Boyle, Kevin [NCRTP:3Z40:EXCH] > Cc: 'Raphael Tryster'; Taylor, Tom-PT [CAR:5N00:EXCH]; 'mukta > vasudeva'; megaco@ietf.org > Subject: RE: [Megaco] Signal Descriptor Doubts > > > $B!!!!(JHi all$B!$(J > $B!!!!(J Shall MG maintain the active state for the event, > according the section 7.1.9 Events Descriptor: > $B!!!!(JWhen the MG receives a command with a new EventsDescriptor, one or > $B!!!!(J more events may have been buffered in the EventBuffer in > the MG. The > $B!!!!(J value of EventBufferControl then determines how the MG > treats such > $B!!!!(J buffered events. > $B!!!!(J > $B!!!!(J Case 1 > $B!!!!(J > $B!!!!(J If EventBufferControl equals LockStep and the MG receives a new > $B!!!!(J EventsDescriptor it will check the FIFO EventBuffer and take the > $B!!!!(J following actions: > $B!!!!(J > $B!!!!(J 1. If the EventBuffer is empty, the MG waits for > detection of events > $B!!!!(J based on the new EventsDescriptor. > $B!!!!(J > $B!!!!(J 2. If the EventBuffer is non-empty, the MG processes the > FIFO queue > $B!!!!(J starting with the first event: > $B!!!!(J > $B!!!!(J a) If the event in the queue is in the events listed > in the new > $B!!!!(J EventsDescriptor, the MG acts on the event and removes the > $B!!!!(J event from the EventBuffer. The time stamp of the > Notify shall > $B!!!!(J be the time the event was actually detected. The > MG then waits for > $B!!!!(J a new EventsDescriptor. ..... > $B!!!!(Jaccording the above, shall we think that the new event > description should active only one time detection ? If MG > detect the event which was defined in event description, > shall MG set the event to inactive, treat the subsequent > detection for this event as invalid detection. > $B!!!!(JIt will affect the implementation for event detect, since > MG will use the separate resource for some event detection, > if does'nt maintain the active state, MG will keep the > resource along with the call in the whole time, that's not a good way. > $B!!!!(JAlan Chou > $B!!!!(J > -------------------------------------------------------------- > ---------- > $B!!!!(JHuawei Technologies Co, Ltd. > $B!!!!(J3rd floor Luneng Building, No. 1 Shangdi 6th Street, > $B!!!!(JHaidian district, Beijing, China 100085 > $B!!!!(JFax : +86 (0)10 82882937 > $B!!!!(JPhone : +86 (0)10 82882599 > $B!!!!(JE-mail : zhouzifeng@huawei.com > $B!!!!(JWeb : http://www.huawei.com > $B!!!!(J > -------------------------------------------------------------- > ---------- > $B!!!!(J > $B!!!!(J-----Original Message----- > From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On > Behalf Of Christian Groves > Sent: Thursday, January 16, 2003 12:34 PM > To: Kevin Boyle > Cc: Raphael Tryster; Tom-PT Taylor; 'mukta vasudeva'; 'Alan > Chou'; megaco@ietf.org > Subject: Re: [Megaco] Signal Descriptor Doubts > $B!!!!(J > $B!!!!(JG'Day Kevin and Raphael, > $B!!!!(J > $B!!!!(JIn v2 the specification already has text on what should happen:- > $B!!!!(J7.2.5 AuditValue > $B!!!!(J... > $B!!!!(Jo To audit a signal the relevant signal list ID and/or signal ID > are provided. > $B!!!!(JOnly if the signal is active the values of all the signal > parameters are > $B!!!!(Jreturned including: the keepactive indication, signal type, > duration, signal > $B!!!!(Jcompletion indication and package defined properties. > $B!!!!(J > $B!!!!(JRegards, Christian > $B!!!!(J > $B!!!!(J > $B!!!!(J_______________________________________________ > $B!!!!(JMegaco mailing list > $B!!!!(JMegaco@ietf.org > $B!!!!(Jhttps://www1.ietf.org/mailman/listinfo/megaco > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jan 16 08:55:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10903 for ; Thu, 16 Jan 2003 08:55:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GEB3t24322 for megaco-archive@odin.ietf.org; Thu, 16 Jan 2003 09:11:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEB3J24319 for ; Thu, 16 Jan 2003 09:11:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10891 for ; Thu, 16 Jan 2003 08:55:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GE6EJ23362; Thu, 16 Jan 2003 09:06:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GE3uJ23292 for ; Thu, 16 Jan 2003 09:03:56 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10795 for ; Thu, 16 Jan 2003 08:48:17 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0GDpWh17095; Thu, 16 Jan 2003 08:51:32 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jan 2003 08:51:33 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E170@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Alan Chou'" Cc: megaco@ietf.org Subject: RE: [Megaco] Signal Descriptor Doubts Date: Thu, 16 Jan 2003 08:51:30 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Assuming Lockstep operation: Event DETECTION is done on the basis of the EventBufferDescriptor. That puts detected events into a queue, along with the time each was detected. When a new Events Descriptor is activated, successive events in the queue are processed until one generates a notification (i.e. is RECOGNIZED). The processed events are removed from the queue, so I'm not sure what you mean about them being kept around for the whole call. > -----Original Message----- > From: Alan Chou [mailto:zhouzifeng@huawei.com] > Sent: Thursday, January 16, 2003 1:46 AM > To: 'Christian Groves'; Boyle, Kevin [NCRTP:3Z40:EXCH] > Cc: 'Raphael Tryster'; Taylor, Tom-PT [CAR:5N00:EXCH]; 'mukta > vasudeva'; megaco@ietf.org > Subject: RE: [Megaco] Signal Descriptor Doubts > > > $B!!!!(JHi all$B!$(J > $B!!!!(J Shall MG maintain the active state for the event, > according the section 7.1.9 Events Descriptor: > $B!!!!(JWhen the MG receives a command with a new EventsDescriptor, one or > $B!!!!(J more events may have been buffered in the EventBuffer in > the MG. The > $B!!!!(J value of EventBufferControl then determines how the MG > treats such > $B!!!!(J buffered events. > $B!!!!(J > $B!!!!(J Case 1 > $B!!!!(J > $B!!!!(J If EventBufferControl equals LockStep and the MG receives a new > $B!!!!(J EventsDescriptor it will check the FIFO EventBuffer and take the > $B!!!!(J following actions: > $B!!!!(J > $B!!!!(J 1. If the EventBuffer is empty, the MG waits for > detection of events > $B!!!!(J based on the new EventsDescriptor. > $B!!!!(J > $B!!!!(J 2. If the EventBuffer is non-empty, the MG processes the > FIFO queue > $B!!!!(J starting with the first event: > $B!!!!(J > $B!!!!(J a) If the event in the queue is in the events listed > in the new > $B!!!!(J EventsDescriptor, the MG acts on the event and removes the > $B!!!!(J event from the EventBuffer. The time stamp of the > Notify shall > $B!!!!(J be the time the event was actually detected. The > MG then waits for > $B!!!!(J a new EventsDescriptor. ..... > $B!!!!(Jaccording the above, shall we think that the new event > description should active only one time detection ? If MG > detect the event which was defined in event description, > shall MG set the event to inactive, treat the subsequent > detection for this event as invalid detection. > $B!!!!(JIt will affect the implementation for event detect, since > MG will use the separate resource for some event detection, > if does'nt maintain the active state, MG will keep the > resource along with the call in the whole time, that's not a good way. > $B!!!!(JAlan Chou > $B!!!!(J > -------------------------------------------------------------- > ---------- > $B!!!!(JHuawei Technologies Co, Ltd. > $B!!!!(J3rd floor Luneng Building, No. 1 Shangdi 6th Street, > $B!!!!(JHaidian district, Beijing, China 100085 > $B!!!!(JFax : +86 (0)10 82882937 > $B!!!!(JPhone : +86 (0)10 82882599 > $B!!!!(JE-mail : zhouzifeng@huawei.com > $B!!!!(JWeb : http://www.huawei.com > $B!!!!(J > -------------------------------------------------------------- > ---------- > $B!!!!(J > $B!!!!(J-----Original Message----- > From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On > Behalf Of Christian Groves > Sent: Thursday, January 16, 2003 12:34 PM > To: Kevin Boyle > Cc: Raphael Tryster; Tom-PT Taylor; 'mukta vasudeva'; 'Alan > Chou'; megaco@ietf.org > Subject: Re: [Megaco] Signal Descriptor Doubts > $B!!!!(J > $B!!!!(JG'Day Kevin and Raphael, > $B!!!!(J > $B!!!!(JIn v2 the specification already has text on what should happen:- > $B!!!!(J7.2.5 AuditValue > $B!!!!(J... > $B!!!!(Jo To audit a signal the relevant signal list ID and/or signal ID > are provided. > $B!!!!(JOnly if the signal is active the values of all the signal > parameters are > $B!!!!(Jreturned including: the keepactive indication, signal type, > duration, signal > $B!!!!(Jcompletion indication and package defined properties. > $B!!!!(J > $B!!!!(JRegards, Christian > $B!!!!(J > $B!!!!(J > $B!!!!(J_______________________________________________ > $B!!!!(JMegaco mailing list > $B!!!!(JMegaco@ietf.org > $B!!!!(Jhttps://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 Jan 16 08:56:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10936 for ; Thu, 16 Jan 2003 08:56:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GE7SJ24087; Thu, 16 Jan 2003 09:07:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GE6iJ23408 for ; Thu, 16 Jan 2003 09:06:44 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10825 for ; Thu, 16 Jan 2003 08:51:05 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0GDsGq21691; Thu, 16 Jan 2003 08:54:19 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jan 2003 08:54:17 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E171@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Dana.Herskowitz@ecitele.com'" , megaco@ietf.org Cc: Eli.Liluz@ecitele.com Subject: RE: [Megaco] Events detection in LockStep mode Date: Thu, 16 Jan 2003 08:54:16 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , There are two ways in which multiple events could be reported: 1) You are NOT operating in Lockstep mode, or 2) The first NOTIFY is accompanied by activation of an embedded Events Descriptor which generates a second NOTIFY. > -----Original Message----- > From: Dana.Herskowitz@ecitele.com > [mailto:Dana.Herskowitz@ecitele.com] > Sent: Thursday, January 16, 2003 4:37 AM > To: Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org > Cc: Eli.Liluz@ecitele.com > Subject: RE: [Megaco] Events detection in LockStep mode > > > > Thanks for replying. The RFC also says: > > The MG may report several events in a single Transaction as long as > this does not unnecessarily delay the reporting of > individual events. > > Does it mean reporting same events which happened as a result > of same trigger? > > Dana H. > > > > > > > "Tom-PT Taylor" > > > "'Dana.Herskowitz@ecitele.com'" > , megaco@ietf.org > tworks.com> cc: > > > Subject: RE: > [Megaco] Events detection in LockStep mode > > 15/01/03 16:14 > > > > > > > > > > > > Section 7.1.9 Case 1 2(a) is quite clear on this: a single > event is reported and the MG awaits a new Events Descriptor > before taking further action. > > > -----Original Message----- > > From: Dana.Herskowitz@ecitele.com > [mailto:Dana.Herskowitz@ecitele.com] > > Sent: Wednesday, > January 15, 2003 4:40 AM > > To: megaco@ietf.org > > Subject: [Megaco] Events detection in LockStep mode > > > > > > Hello, > > When receiving a new Events Descriptor and EBC=LockStep, the > > MG has to send Notify message. Let's say there are already > > 4-5 events in the buffer, which all appear in current Events > > Descriptor. Should the Notify message include all the events > > from the buffer or only the first one of them which appears > > in the Events Descriptor? > > > > Regards, > > > > Dana H. > > > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > > > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jan 16 08:57:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10956 for ; Thu, 16 Jan 2003 08:57:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GECKL24401 for megaco-archive@odin.ietf.org; Thu, 16 Jan 2003 09:12:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GECKJ24398 for ; Thu, 16 Jan 2003 09:12:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10950 for ; Thu, 16 Jan 2003 08:56:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GE7SJ24087; Thu, 16 Jan 2003 09:07:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GE6iJ23408 for ; Thu, 16 Jan 2003 09:06:44 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10825 for ; Thu, 16 Jan 2003 08:51:05 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0GDsGq21691; Thu, 16 Jan 2003 08:54:19 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jan 2003 08:54:17 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E171@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Dana.Herskowitz@ecitele.com'" , megaco@ietf.org Cc: Eli.Liluz@ecitele.com Subject: RE: [Megaco] Events detection in LockStep mode Date: Thu, 16 Jan 2003 08:54:16 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , There are two ways in which multiple events could be reported: 1) You are NOT operating in Lockstep mode, or 2) The first NOTIFY is accompanied by activation of an embedded Events Descriptor which generates a second NOTIFY. > -----Original Message----- > From: Dana.Herskowitz@ecitele.com > [mailto:Dana.Herskowitz@ecitele.com] > Sent: Thursday, January 16, 2003 4:37 AM > To: Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org > Cc: Eli.Liluz@ecitele.com > Subject: RE: [Megaco] Events detection in LockStep mode > > > > Thanks for replying. The RFC also says: > > The MG may report several events in a single Transaction as long as > this does not unnecessarily delay the reporting of > individual events. > > Does it mean reporting same events which happened as a result > of same trigger? > > Dana H. > > > > > > > "Tom-PT Taylor" > > > "'Dana.Herskowitz@ecitele.com'" > , megaco@ietf.org > tworks.com> cc: > > > Subject: RE: > [Megaco] Events detection in LockStep mode > > 15/01/03 16:14 > > > > > > > > > > > > Section 7.1.9 Case 1 2(a) is quite clear on this: a single > event is reported and the MG awaits a new Events Descriptor > before taking further action. > > > -----Original Message----- > > From: Dana.Herskowitz@ecitele.com > [mailto:Dana.Herskowitz@ecitele.com] > > Sent: Wednesday, > January 15, 2003 4:40 AM > > To: megaco@ietf.org > > Subject: [Megaco] Events detection in LockStep mode > > > > > > Hello, > > When receiving a new Events Descriptor and EBC=LockStep, the > > MG has to send Notify message. Let's say there are already > > 4-5 events in the buffer, which all appear in current Events > > Descriptor. Should the Notify message include all the events > > from the buffer or only the first one of them which appears > > in the Events Descriptor? > > > > Regards, > > > > Dana H. > > > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > > > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jan 16 09:01:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11080 for ; Thu, 16 Jan 2003 09:01:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GECCJ24388; Thu, 16 Jan 2003 09:12:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEBMJ24341 for ; Thu, 16 Jan 2003 09:11:22 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10897 for ; Thu, 16 Jan 2003 08:55:43 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0GDwgq22189; Thu, 16 Jan 2003 08:58:42 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jan 2003 08:58:43 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E172@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Raphael Tryster'" , Christian Groves , "Kevin Boyle" Cc: "'mukta vasudeva'" , "'Alan Chou'" , megaco@ietf.org Subject: RE: [Megaco] Signal Descriptor Doubts Date: Thu, 16 Jan 2003 08:58:40 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , I should have looked before making my original reply. Anyway, I would agree with the interpretation that the aufdit reports all events currently being played or not yet played. I think that's what we intended, and, more to the point, that seems to be the most useful. -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Thursday, January 16, 2003 5:26 AM To: Christian Groves; Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: Raphael Tryster; Taylor, Tom-PT [CAR:5N00:EXCH]; 'mukta vasudeva'; 'Alan Chou'; megaco@ietf.org Subject: RE: [Megaco] Signal Descriptor Doubts G'Day Christian, You seem to be agreeing that a signal that has finished playing should not be returned in reply to an audit. Are you going further and saying that a signal that has not yet started playing should also not be returned? Or do you agree that the term "active" can be stretched, as Kevin says, to mean "what is currently playing and what is remaining to be "played"? In other words, not dead yet? I think this is useful. Raphael Tryster -----Original Message----- From: Christian Groves [SMTP:Christian.Groves@ericsson.com.au] Sent: Thursday, 16 January, 2003 6:34 AM To: Kevin Boyle Cc: Raphael Tryster; Tom-PT Taylor; 'mukta vasudeva'; 'Alan Chou'; megaco@ietf.org Subject: Re: [Megaco] Signal Descriptor Doubts G'Day Kevin and Raphael, In v2 the specification already has text on what should happen:- 7.2.5 AuditValue ... o To audit a signal the relevant signal list ID and/or signal ID are provided. Only if the signal is active the values of all the signal parameters are returned including: the keepactive indication, signal type, duration, signal completion indication and package defined properties. Regards, Christian _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jan 16 09:01:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11139 for ; Thu, 16 Jan 2003 09:01:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GEH1M24654 for megaco-archive@odin.ietf.org; Thu, 16 Jan 2003 09:17:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEH1J24643 for ; Thu, 16 Jan 2003 09:17:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11094 for ; Thu, 16 Jan 2003 09:01:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GECCJ24388; Thu, 16 Jan 2003 09:12:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEBMJ24341 for ; Thu, 16 Jan 2003 09:11:22 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10897 for ; Thu, 16 Jan 2003 08:55:43 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0GDwgq22189; Thu, 16 Jan 2003 08:58:42 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jan 2003 08:58:43 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E172@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Raphael Tryster'" , Christian Groves , "Kevin Boyle" Cc: "'mukta vasudeva'" , "'Alan Chou'" , megaco@ietf.org Subject: RE: [Megaco] Signal Descriptor Doubts Date: Thu, 16 Jan 2003 08:58:40 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , I should have looked before making my original reply. Anyway, I would agree with the interpretation that the aufdit reports all events currently being played or not yet played. I think that's what we intended, and, more to the point, that seems to be the most useful. -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Thursday, January 16, 2003 5:26 AM To: Christian Groves; Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: Raphael Tryster; Taylor, Tom-PT [CAR:5N00:EXCH]; 'mukta vasudeva'; 'Alan Chou'; megaco@ietf.org Subject: RE: [Megaco] Signal Descriptor Doubts G'Day Christian, You seem to be agreeing that a signal that has finished playing should not be returned in reply to an audit. Are you going further and saying that a signal that has not yet started playing should also not be returned? Or do you agree that the term "active" can be stretched, as Kevin says, to mean "what is currently playing and what is remaining to be "played"? In other words, not dead yet? I think this is useful. Raphael Tryster -----Original Message----- From: Christian Groves [SMTP:Christian.Groves@ericsson.com.au] Sent: Thursday, 16 January, 2003 6:34 AM To: Kevin Boyle Cc: Raphael Tryster; Tom-PT Taylor; 'mukta vasudeva'; 'Alan Chou'; megaco@ietf.org Subject: Re: [Megaco] Signal Descriptor Doubts G'Day Kevin and Raphael, In v2 the specification already has text on what should happen:- 7.2.5 AuditValue ... o To audit a signal the relevant signal list ID and/or signal ID are provided. Only if the signal is active the values of all the signal parameters are returned including: the keepactive indication, signal type, duration, signal completion indication and package defined properties. Regards, Christian _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jan 16 13:18:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18872 for ; Thu, 16 Jan 2003 13:18:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIX7J11695; Thu, 16 Jan 2003 13:33:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIUaJ11536 for ; Thu, 16 Jan 2003 13:30:36 -0500 Received: from zrtps0kn.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18761 for ; Thu, 16 Jan 2003 13:14:52 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0GIID619131 for ; Thu, 16 Jan 2003 13:18:13 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jan 2003 13:18:13 -0500 Message-ID: From: "Kevin Boyle" To: Dana.Herskowitz@ecitele.com, "Tom-PT Taylor" , megaco@ietf.org Cc: Eli.Liluz@ecitele.com Subject: RE: [Megaco] Events detection in LockStep mode Date: Thu, 16 Jan 2003 13:18:13 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Sure. Essentially what the spec is saying is that while you can notify multiple events at once, you cannot hold events waiting for others to occur solely to bundle them. Since a significant number of applications for H.248 are real-time critical, holding events will introduce race conditions, lag, and other undesirable timing problems. Kevin -----Original Message----- From: Dana.Herskowitz@ecitele.com [mailto:Dana.Herskowitz@ecitele.com] Sent: Thursday, January 16, 2003 4:37 AM To: Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org Cc: Eli.Liluz@ecitele.com Subject: RE: [Megaco] Events detection in LockStep mode Thanks for replying. The RFC also says: The MG may report several events in a single Transaction as long as this does not unnecessarily delay the reporting of individual events. Does it mean reporting same events which happened as a result of same trigger? Dana H. "Tom-PT Taylor" , megaco@ietf.org tworks.com> cc: Subject: RE: [Megaco] Events detection in LockStep mode 15/01/03 16:14 Section 7.1.9 Case 1 2(a) is quite clear on this: a single event is reported and the MG awaits a new Events Descriptor before taking further action. > -----Original Message----- > From: Dana.Herskowitz@ecitele.com [mailto:Dana.Herskowitz@ecitele.com] > Sent: Wednesday, January 15, 2003 4:40 AM > To: megaco@ietf.org > Subject: [Megaco] Events detection in LockStep mode > > > Hello, > When receiving a new Events Descriptor and EBC=LockStep, the > MG has to send Notify message. Let's say there are already > 4-5 events in the buffer, which all appear in current Events > Descriptor. Should the Notify message include all the events > from the buffer or only the first one of them which appears > in the Events Descriptor? > > Regards, > > Dana H. > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jan 16 13:19:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18907 for ; Thu, 16 Jan 2003 13:19:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GIYio11767 for megaco-archive@odin.ietf.org; Thu, 16 Jan 2003 13:34:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIYiJ11764 for ; Thu, 16 Jan 2003 13:34:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18893 for ; Thu, 16 Jan 2003 13:19:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIX7J11695; Thu, 16 Jan 2003 13:33:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIUaJ11536 for ; Thu, 16 Jan 2003 13:30:36 -0500 Received: from zrtps0kn.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18761 for ; Thu, 16 Jan 2003 13:14:52 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0GIID619131 for ; Thu, 16 Jan 2003 13:18:13 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jan 2003 13:18:13 -0500 Message-ID: From: "Kevin Boyle" To: Dana.Herskowitz@ecitele.com, "Tom-PT Taylor" , megaco@ietf.org Cc: Eli.Liluz@ecitele.com Subject: RE: [Megaco] Events detection in LockStep mode Date: Thu, 16 Jan 2003 13:18:13 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Sure. Essentially what the spec is saying is that while you can notify multiple events at once, you cannot hold events waiting for others to occur solely to bundle them. Since a significant number of applications for H.248 are real-time critical, holding events will introduce race conditions, lag, and other undesirable timing problems. Kevin -----Original Message----- From: Dana.Herskowitz@ecitele.com [mailto:Dana.Herskowitz@ecitele.com] Sent: Thursday, January 16, 2003 4:37 AM To: Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org Cc: Eli.Liluz@ecitele.com Subject: RE: [Megaco] Events detection in LockStep mode Thanks for replying. The RFC also says: The MG may report several events in a single Transaction as long as this does not unnecessarily delay the reporting of individual events. Does it mean reporting same events which happened as a result of same trigger? Dana H. "Tom-PT Taylor" , megaco@ietf.org tworks.com> cc: Subject: RE: [Megaco] Events detection in LockStep mode 15/01/03 16:14 Section 7.1.9 Case 1 2(a) is quite clear on this: a single event is reported and the MG awaits a new Events Descriptor before taking further action. > -----Original Message----- > From: Dana.Herskowitz@ecitele.com [mailto:Dana.Herskowitz@ecitele.com] > Sent: Wednesday, January 15, 2003 4:40 AM > To: megaco@ietf.org > Subject: [Megaco] Events detection in LockStep mode > > > Hello, > When receiving a new Events Descriptor and EBC=LockStep, the > MG has to send Notify message. Let's say there are already > 4-5 events in the buffer, which all appear in current Events > Descriptor. Should the Notify message include all the events > from the buffer or only the first one of them which appears > in the Events Descriptor? > > Regards, > > Dana H. > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jan 16 20:40:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28841 for ; Thu, 16 Jan 2003 20:40:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H1trJ08591; Thu, 16 Jan 2003 20:55:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H1rGJ08509 for ; Thu, 16 Jan 2003 20:53:16 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28794 for ; Thu, 16 Jan 2003 20:37:24 -0500 (EST) Received: from cisco.com (dhcp-128-107-141-60.cisco.com [128.107.141.60]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0H1ejuV012457 for ; Thu, 16 Jan 2003 17:40:45 -0800 (PST) Message-ID: <3E275F1E.FC2998C4@cisco.com> Date: Thu, 16 Jan 2003 20:40:46 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: megaco@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] MGCP 1.0bis published as RFC 3435 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 FYI The updated MGCP 1.0 specification, also known as MGCP 1.0bis or 2705bis, has now been published as RFC 3435. As usual, please send questions or comments on MGCP to "mgcp@pulver.com" or "mgcp@vovida.org". Regards Flemming _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jan 16 20:41:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28873 for ; Thu, 16 Jan 2003 20:41:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0H1uiC08676 for megaco-archive@odin.ietf.org; Thu, 16 Jan 2003 20:56:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H1uhJ08673 for ; Thu, 16 Jan 2003 20:56:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28856 for ; Thu, 16 Jan 2003 20:40:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H1trJ08591; Thu, 16 Jan 2003 20:55:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H1rGJ08509 for ; Thu, 16 Jan 2003 20:53:16 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28794 for ; Thu, 16 Jan 2003 20:37:24 -0500 (EST) Received: from cisco.com (dhcp-128-107-141-60.cisco.com [128.107.141.60]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0H1ejuV012457 for ; Thu, 16 Jan 2003 17:40:45 -0800 (PST) Message-ID: <3E275F1E.FC2998C4@cisco.com> Date: Thu, 16 Jan 2003 20:40:46 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: megaco@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] MGCP 1.0bis published as RFC 3435 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit FYI The updated MGCP 1.0 specification, also known as MGCP 1.0bis or 2705bis, has now been published as RFC 3435. As usual, please send questions or comments on MGCP to "mgcp@pulver.com" or "mgcp@vovida.org". Regards Flemming _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Jan 17 00:14:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02748 for ; Fri, 17 Jan 2003 00:14:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H5SeJ20562; Fri, 17 Jan 2003 00:28:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H5QKJ20496 for ; Fri, 17 Jan 2003 00:26:20 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02708 for ; Fri, 17 Jan 2003 00:10:23 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0H5DcKV006215; Fri, 17 Jan 2003 06:13:38 +0100 (MET) Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNBRSP4; Fri, 17 Jan 2003 06:13:38 +0100 Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id GAA17566; Fri, 17 Jan 2003 06:13:37 +0100 (MET) Received: from ericsson.com.au ([146.11.233.193]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id GAA16935; Fri, 17 Jan 2003 06:13:33 +0100 (MET) Message-ID: <3E274C19.FACB6E83@ericsson.com.au> Date: Fri, 17 Jan 2003 11:19:37 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Raphael Tryster CC: Kevin Boyle , Tom-PT Taylor , "'mukta vasudeva'" , "'Alan Chou'" , megaco@ietf.org Subject: Re: [Megaco] Signal Descriptor Doubts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit G'Day Raphael, I don't think we need to stretch any term. As far as Megaco is concerned the MG returns a reply when it is sure the signals will play. Therefore as soon as the reply is sent the signals are active. So to me signals/signal lists are either active or finished. Active get reported, Finished ones do not. Cheers, Christian Raphael Tryster wrote: > > G'Day Christian, > > You seem to be agreeing that a signal that has finished playing should not be > returned in reply to an audit. Are you going further and saying that a signal > that has not yet started playing should also not be returned? Or do you agree > that the term "active" can be stretched, as Kevin says, to mean "what is > currently playing and what is remaining to be "played"? In other words, not > dead yet? I think this is useful. > > Raphael Tryster > > -----Original Message----- > From: Christian Groves [SMTP:Christian.Groves@ericsson.com.au] > Sent: Thursday, 16 January, 2003 6:34 AM > To: Kevin Boyle > Cc: Raphael Tryster; Tom-PT Taylor; 'mukta vasudeva'; 'Alan Chou'; > megaco@ietf.org > Subject: Re: [Megaco] Signal Descriptor Doubts > > G'Day Kevin and Raphael, > > In v2 the specification already has text on what should happen:- > 7.2.5 AuditValue > ... > o To audit a signal the relevant signal list ID and/or signal ID > are provided. > Only if the signal is active the values of all the signal parameters are > returned including: the keepactive indication, signal type, duration, > signal > completion indication and package defined properties. > > Regards, Christian _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Jan 17 00:15:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02770 for ; Fri, 17 Jan 2003 00:15:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0H5US420637 for megaco-archive@odin.ietf.org; Fri, 17 Jan 2003 00:30:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H5URJ20634 for ; Fri, 17 Jan 2003 00:30:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02762 for ; Fri, 17 Jan 2003 00:14:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H5SeJ20562; Fri, 17 Jan 2003 00:28:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H5QKJ20496 for ; Fri, 17 Jan 2003 00:26:20 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02708 for ; Fri, 17 Jan 2003 00:10:23 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0H5DcKV006215; Fri, 17 Jan 2003 06:13:38 +0100 (MET) Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNBRSP4; Fri, 17 Jan 2003 06:13:38 +0100 Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id GAA17566; Fri, 17 Jan 2003 06:13:37 +0100 (MET) Received: from ericsson.com.au ([146.11.233.193]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id GAA16935; Fri, 17 Jan 2003 06:13:33 +0100 (MET) Message-ID: <3E274C19.FACB6E83@ericsson.com.au> Date: Fri, 17 Jan 2003 11:19:37 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Raphael Tryster CC: Kevin Boyle , Tom-PT Taylor , "'mukta vasudeva'" , "'Alan Chou'" , megaco@ietf.org Subject: Re: [Megaco] Signal Descriptor Doubts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit G'Day Raphael, I don't think we need to stretch any term. As far as Megaco is concerned the MG returns a reply when it is sure the signals will play. Therefore as soon as the reply is sent the signals are active. So to me signals/signal lists are either active or finished. Active get reported, Finished ones do not. Cheers, Christian Raphael Tryster wrote: > > G'Day Christian, > > You seem to be agreeing that a signal that has finished playing should not be > returned in reply to an audit. Are you going further and saying that a signal > that has not yet started playing should also not be returned? Or do you agree > that the term "active" can be stretched, as Kevin says, to mean "what is > currently playing and what is remaining to be "played"? In other words, not > dead yet? I think this is useful. > > Raphael Tryster > > -----Original Message----- > From: Christian Groves [SMTP:Christian.Groves@ericsson.com.au] > Sent: Thursday, 16 January, 2003 6:34 AM > To: Kevin Boyle > Cc: Raphael Tryster; Tom-PT Taylor; 'mukta vasudeva'; 'Alan Chou'; > megaco@ietf.org > Subject: Re: [Megaco] Signal Descriptor Doubts > > G'Day Kevin and Raphael, > > In v2 the specification already has text on what should happen:- > 7.2.5 AuditValue > ... > o To audit a signal the relevant signal list ID and/or signal ID > are provided. > Only if the signal is active the values of all the signal parameters are > returned including: the keepactive indication, signal type, duration, > signal > completion indication and package defined properties. > > Regards, Christian _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jan 20 08:23:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19331 for ; Mon, 20 Jan 2003 08:23:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KDcXJ19686; Mon, 20 Jan 2003 08:38:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KDYFJ18637 for ; Mon, 20 Jan 2003 08:34:15 -0500 Received: from shardagate.mahindrabt.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18941 for ; Mon, 20 Jan 2003 08:16:36 -0500 (EST) Received: from thisdomain (mailscan.sharda.mahindrabt.com [10.5.0.97]) by shardagate.mahindrabt.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA20518 for ; Mon, 20 Jan 2003 18:49:56 +0530 Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Mon, 20 Jan 2003 18:38:55 +0530 Date: Mon, 20 Jan 2003 18:38:55 +0530 X-Originating-IP: 10.5.0.15 X-Auth-User: anilj@mahindrabt.com Received: from dscp00986 ([10.5.6.22]) by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id SAA21313 for ; Mon, 20 Jan 2003 18:49:49 +0530 Message-ID: <00bd01c2c087$0980a920$1606050a@mahindrabt.com> From: "Anil Jangam" To: References: <3E274C19.FACB6E83@ericsson.com.au> Date: Mon, 20 Jan 2003 18:52:53 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BA_01C2C0B5.231C3560" X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: [Megaco] auditReturnParameter in AmmsReply Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_00BA_01C2C0B5.231C3560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi, as per the AuditReturnParameter (inside ammsReply) definition, it is = mentioned that it may contain the AuditItem. Also it may contain = EventsDescriptor as well. auditReturnParameter =3D (mediaDescriptor / modemDescriptor / muxDescriptor / eventsDescriptor / signalsDescriptor / digitMapDescriptor / observedEventsDescriptor / = eventBufferDescriptor / statisticsDescriptor / packagesDescriptor / errorDescriptor / auditItem)=20 ;at-most-once, and DigitMapToken and PackagesToken are not allowed ;in = AuditCapabilities command auditItem =3D ( MuxToken / ModemToken / MediaToken / SignalsToken / EventBufferToken / DigitMapToken / StatsToken / EventsToken / ObservedEventsToken / PackagesToken ) In above case, if the EventDescriptor is received empty, then how the = corresponding Token should be treated?? Should it be treated as empty = EventDescriptor OR be as AuditItem?? What is the difference between = these two?? P.S.: The EventDescriptor is defined, where except token everything is = optional: eventsDescriptor =3D EventsToken [ EQUAL RequestID LBRKT requestedEvent *( COMMA requestedEvent ) = RBRKT ] ********************************************************* Disclaimer This message (including any attachments) contains=20 confidential information intended for a specific=20 individual and purpose, and is protected by law.=20 If you are not the intended recipient, you should=20 delete this message and are hereby notified that=20 any disclosure, copying, or distribution of this message, or the taking of any action based on it,=20 is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ------=_NextPart_000_00BA_01C2C0B5.231C3560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi,
 
as per the AuditReturnParameter = (inside=20 ammsReply) definition, it is mentioned that it may contain the = AuditItem.=20 Also it may contain EventsDescriptor as well.
 
auditReturnParameter =3D = (mediaDescriptor /=20 modemDescriptor=20 /
           &n= bsp;           &nb= sp;     =20 muxDescriptor / eventsDescriptor=20 /
           &n= bsp;           &nb= sp;     =20 signalsDescriptor / digitMapDescriptor=20 /
           &n= bsp;           &nb= sp;     =20 observedEventsDescriptor / eventBufferDescriptor=20 /
           &n= bsp;           &nb= sp;     =20 statisticsDescriptor / packagesDescriptor=20 /
           &n= bsp;           &nb= sp;      errorDescriptor=20 / auditItem)
 
 ;at-most-once, and DigitMapToken = and=20 PackagesToken are not allowed ;in AuditCapabilities=20 command
auditItem         = ;  =20 =3D ( MuxToken / ModemToken / MediaToken=20 /
           &n= bsp;           &nb= sp;     =20 SignalsToken / EventBufferToken=20 /
           &n= bsp;           &nb= sp;     =20 DigitMapToken / StatsToken / EventsToken=20 /
           &n= bsp;           &nb= sp;     =20 ObservedEventsToken / PackagesToken )
 
In above case, if the = EventDescriptor is=20 received empty, then how the corresponding Token should be treated?? = Should it=20 be treated as empty EventDescriptor OR be as AuditItem?? What is the = difference=20 between these two??
 
P.S.: The EventDescriptor is defined, = where except=20 token everything is optional:
eventsDescriptor     =3D=20 EventsToken [ EQUAL RequestID=20 LBRKT
          &nbs= p;            = ;   =20 requestedEvent *( COMMA requestedEvent ) RBRKT = ]

*********************************************************
Disclaimer

This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com

------=_NextPart_000_00BA_01C2C0B5.231C3560-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jan 20 08:24:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19409 for ; Mon, 20 Jan 2003 08:24:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KDfUJ19863 for megaco-archive@odin.ietf.org; Mon, 20 Jan 2003 08:41:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KDfUJ19860 for ; Mon, 20 Jan 2003 08:41:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19359 for ; Mon, 20 Jan 2003 08:23:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KDcXJ19686; Mon, 20 Jan 2003 08:38:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KDYFJ18637 for ; Mon, 20 Jan 2003 08:34:15 -0500 Received: from shardagate.mahindrabt.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18941 for ; Mon, 20 Jan 2003 08:16:36 -0500 (EST) Received: from thisdomain (mailscan.sharda.mahindrabt.com [10.5.0.97]) by shardagate.mahindrabt.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA20518 for ; Mon, 20 Jan 2003 18:49:56 +0530 Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Mon, 20 Jan 2003 18:38:55 +0530 Date: Mon, 20 Jan 2003 18:38:55 +0530 X-Originating-IP: 10.5.0.15 X-Auth-User: anilj@mahindrabt.com Received: from dscp00986 ([10.5.6.22]) by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id SAA21313 for ; Mon, 20 Jan 2003 18:49:49 +0530 Message-ID: <00bd01c2c087$0980a920$1606050a@mahindrabt.com> From: "Anil Jangam" To: References: <3E274C19.FACB6E83@ericsson.com.au> Date: Mon, 20 Jan 2003 18:52:53 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BA_01C2C0B5.231C3560" X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: [Megaco] auditReturnParameter in AmmsReply Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_00BA_01C2C0B5.231C3560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi, as per the AuditReturnParameter (inside ammsReply) definition, it is = mentioned that it may contain the AuditItem. Also it may contain = EventsDescriptor as well. auditReturnParameter =3D (mediaDescriptor / modemDescriptor / muxDescriptor / eventsDescriptor / signalsDescriptor / digitMapDescriptor / observedEventsDescriptor / = eventBufferDescriptor / statisticsDescriptor / packagesDescriptor / errorDescriptor / auditItem)=20 ;at-most-once, and DigitMapToken and PackagesToken are not allowed ;in = AuditCapabilities command auditItem =3D ( MuxToken / ModemToken / MediaToken / SignalsToken / EventBufferToken / DigitMapToken / StatsToken / EventsToken / ObservedEventsToken / PackagesToken ) In above case, if the EventDescriptor is received empty, then how the = corresponding Token should be treated?? Should it be treated as empty = EventDescriptor OR be as AuditItem?? What is the difference between = these two?? P.S.: The EventDescriptor is defined, where except token everything is = optional: eventsDescriptor =3D EventsToken [ EQUAL RequestID LBRKT requestedEvent *( COMMA requestedEvent ) = RBRKT ] ********************************************************* Disclaimer This message (including any attachments) contains=20 confidential information intended for a specific=20 individual and purpose, and is protected by law.=20 If you are not the intended recipient, you should=20 delete this message and are hereby notified that=20 any disclosure, copying, or distribution of this message, or the taking of any action based on it,=20 is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ------=_NextPart_000_00BA_01C2C0B5.231C3560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi,
 
as per the AuditReturnParameter = (inside=20 ammsReply) definition, it is mentioned that it may contain the = AuditItem.=20 Also it may contain EventsDescriptor as well.
 
auditReturnParameter =3D = (mediaDescriptor /=20 modemDescriptor=20 /
           &n= bsp;           &nb= sp;     =20 muxDescriptor / eventsDescriptor=20 /
           &n= bsp;           &nb= sp;     =20 signalsDescriptor / digitMapDescriptor=20 /
           &n= bsp;           &nb= sp;     =20 observedEventsDescriptor / eventBufferDescriptor=20 /
           &n= bsp;           &nb= sp;     =20 statisticsDescriptor / packagesDescriptor=20 /
           &n= bsp;           &nb= sp;      errorDescriptor=20 / auditItem)
 
 ;at-most-once, and DigitMapToken = and=20 PackagesToken are not allowed ;in AuditCapabilities=20 command
auditItem         = ;  =20 =3D ( MuxToken / ModemToken / MediaToken=20 /
           &n= bsp;           &nb= sp;     =20 SignalsToken / EventBufferToken=20 /
           &n= bsp;           &nb= sp;     =20 DigitMapToken / StatsToken / EventsToken=20 /
           &n= bsp;           &nb= sp;     =20 ObservedEventsToken / PackagesToken )
 
In above case, if the = EventDescriptor is=20 received empty, then how the corresponding Token should be treated?? = Should it=20 be treated as empty EventDescriptor OR be as AuditItem?? What is the = difference=20 between these two??
 
P.S.: The EventDescriptor is defined, = where except=20 token everything is optional:
eventsDescriptor     =3D=20 EventsToken [ EQUAL RequestID=20 LBRKT
          &nbs= p;            = ;   =20 requestedEvent *( COMMA requestedEvent ) RBRKT = ]

*********************************************************
Disclaimer

This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com

------=_NextPart_000_00BA_01C2C0B5.231C3560-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jan 20 16:15:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01277 for ; Mon, 20 Jan 2003 16:15:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KLVVJ15691; Mon, 20 Jan 2003 16:31:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KLTGJ15579 for ; Mon, 20 Jan 2003 16:29:16 -0500 Received: from topaz.3com.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01119 for ; Mon, 20 Jan 2003 16:11:33 -0500 (EST) From: John_Poplett@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0KLEYL14485 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Mon, 20 Jan 2003 13:14:35 -0800 (PST) Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79]) by opal.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0KLEuS21603 for ; Mon, 20 Jan 2003 13:14:56 -0800 (PST) To: megaco@ietf.org Date: Mon, 20 Jan 2003 15:16:25 -0600 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Megaco] Binary equivalent for SDP ptime attribute Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, all. What is the binary equivalent / mapping for the SDP ptime attribute? Thanks, John _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jan 20 16:15:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01318 for ; Mon, 20 Jan 2003 16:15:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KLWvR15874 for megaco-archive@odin.ietf.org; Mon, 20 Jan 2003 16:32:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KLWvJ15871 for ; Mon, 20 Jan 2003 16:32:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01287 for ; Mon, 20 Jan 2003 16:15:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KLVVJ15691; Mon, 20 Jan 2003 16:31:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KLTGJ15579 for ; Mon, 20 Jan 2003 16:29:16 -0500 Received: from topaz.3com.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01119 for ; Mon, 20 Jan 2003 16:11:33 -0500 (EST) From: John_Poplett@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0KLEYL14485 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Mon, 20 Jan 2003 13:14:35 -0800 (PST) Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79]) by opal.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0KLEuS21603 for ; Mon, 20 Jan 2003 13:14:56 -0800 (PST) To: megaco@ietf.org Date: Mon, 20 Jan 2003 15:16:25 -0600 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Megaco] Binary equivalent for SDP ptime attribute Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, all. What is the binary equivalent / mapping for the SDP ptime attribute? Thanks, John _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 21 01:12:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12377 for ; Tue, 21 Jan 2003 01:12:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L6OGJ12540; Tue, 21 Jan 2003 01:24:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L6LsJ12412 for ; Tue, 21 Jan 2003 01:21:54 -0500 Received: from ish7.ericsson.com.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12232 for ; Tue, 21 Jan 2003 01:03:56 -0500 (EST) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id h0L655G04288; Tue, 21 Jan 2003 17:05:05 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h0L67E919313; Tue, 21 Jan 2003 17:07:16 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.193]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id C8QWQLF8; Tue, 21 Jan 2003 17:07:14 +1100 Message-ID: <3E2CE29C.8364907E@ericsson.com.au> Date: Tue, 21 Jan 2003 17:03:08 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John_Poplett@3com.com, megaco@ietf.org Subject: Re: [Megaco] Binary equivalent for SDP ptime attribute References: <3E2C97FE.7A11F55E@ericsson.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > G'Day John, > > There isn't a direct binary equivalent for this. However is can be carried by: > SDP_A B00C String Zero or more session attributes Ref.: RFC 2327 > > Alternatively if people would like a specific attribute we could create a new > codepoint for the IG: > Ptime 1010 Integer > This gives the length of time in milliseconds represented by the > media in a packet. > Ref.: RFC 2327 > > Regards, Christian > > John_Poplett@3com.com wrote: > > > > Hi, all. > > > > What is the binary equivalent / mapping for the SDP ptime attribute? > > > > Thanks, > > > > John > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 21 01:12:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12394 for ; Tue, 21 Jan 2003 01:12:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0L6UO912711 for megaco-archive@odin.ietf.org; Tue, 21 Jan 2003 01:30:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L6UNJ12708 for ; Tue, 21 Jan 2003 01:30:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12391 for ; Tue, 21 Jan 2003 01:12:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L6OGJ12540; Tue, 21 Jan 2003 01:24:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L6LsJ12412 for ; Tue, 21 Jan 2003 01:21:54 -0500 Received: from ish7.ericsson.com.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12232 for ; Tue, 21 Jan 2003 01:03:56 -0500 (EST) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id h0L655G04288; Tue, 21 Jan 2003 17:05:05 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h0L67E919313; Tue, 21 Jan 2003 17:07:16 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.193]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id C8QWQLF8; Tue, 21 Jan 2003 17:07:14 +1100 Message-ID: <3E2CE29C.8364907E@ericsson.com.au> Date: Tue, 21 Jan 2003 17:03:08 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John_Poplett@3com.com, megaco@ietf.org Subject: Re: [Megaco] Binary equivalent for SDP ptime attribute References: <3E2C97FE.7A11F55E@ericsson.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > G'Day John, > > There isn't a direct binary equivalent for this. However is can be carried by: > SDP_A B00C String Zero or more session attributes Ref.: RFC 2327 > > Alternatively if people would like a specific attribute we could create a new > codepoint for the IG: > Ptime 1010 Integer > This gives the length of time in milliseconds represented by the > media in a packet. > Ref.: RFC 2327 > > Regards, Christian > > John_Poplett@3com.com wrote: > > > > Hi, all. > > > > What is the binary equivalent / mapping for the SDP ptime attribute? > > > > Thanks, > > > > John > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 21 02:00:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14094 for ; Tue, 21 Jan 2003 02:00:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L7HgJ25467; Tue, 21 Jan 2003 02:17:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L7GRJ25429 for ; Tue, 21 Jan 2003 02:16:27 -0500 Received: from web41314.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA12777 for ; Tue, 21 Jan 2003 01:58:31 -0500 (EST) Message-ID: <20030121070156.21788.qmail@web41314.mail.yahoo.com> Received: from [203.200.20.226] by web41314.mail.yahoo.com via HTTP; Mon, 20 Jan 2003 23:01:56 PST Date: Mon, 20 Jan 2003 23:01:56 -0800 (PST) From: uma ramanan To: megaco@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Megaco] Notifying errors in Transaction Reply/Pending Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi all, I would like to know as to how are errors in Transaction Reply/Transaction Pending (eg Syntax Error s : SyntaxErrorTransactionReply) informed to the sender. In case of Transaction Requests, the errors are notified in Transaction Reply, but i am not clear about the procedure to be followed in case of Transaction Reply/Pending. Should Notify Command be used for this purpose ? Thanks & Regards, Uma __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 21 02:01:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14820 for ; Tue, 21 Jan 2003 02:01:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0L7Ivg25512 for megaco-archive@odin.ietf.org; Tue, 21 Jan 2003 02:18:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L7IuJ25509 for ; Tue, 21 Jan 2003 02:18:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14113 for ; Tue, 21 Jan 2003 02:01:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L7HgJ25467; Tue, 21 Jan 2003 02:17:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L7GRJ25429 for ; Tue, 21 Jan 2003 02:16:27 -0500 Received: from web41314.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA12777 for ; Tue, 21 Jan 2003 01:58:31 -0500 (EST) Message-ID: <20030121070156.21788.qmail@web41314.mail.yahoo.com> Received: from [203.200.20.226] by web41314.mail.yahoo.com via HTTP; Mon, 20 Jan 2003 23:01:56 PST Date: Mon, 20 Jan 2003 23:01:56 -0800 (PST) From: uma ramanan To: megaco@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Megaco] Notifying errors in Transaction Reply/Pending Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi all, I would like to know as to how are errors in Transaction Reply/Transaction Pending (eg Syntax Error s : SyntaxErrorTransactionReply) informed to the sender. In case of Transaction Requests, the errors are notified in Transaction Reply, but i am not clear about the procedure to be followed in case of Transaction Reply/Pending. Should Notify Command be used for this purpose ? Thanks & Regards, Uma __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 21 03:26:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23535 for ; Tue, 21 Jan 2003 03:26:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L8hGJ31048; Tue, 21 Jan 2003 03:43:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L8fjJ30978 for ; Tue, 21 Jan 2003 03:41:45 -0500 Received: from web40810.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA23513 for ; Tue, 21 Jan 2003 03:23:46 -0500 (EST) Message-ID: <20030121082713.22837.qmail@web40810.mail.yahoo.com> Received: from [202.134.200.4] by web40810.mail.yahoo.com via HTTP; Tue, 21 Jan 2003 00:27:13 PST Date: Tue, 21 Jan 2003 00:27:13 -0800 (PST) From: baljeet gill To: megaco@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1672312601-1043137633=:21556" 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: , --0-1672312601-1043137633=:21556 Content-Type: text/plain; charset=us-ascii Hi, Trying to correlate IN-CS2 with megaco, it just comes to my mind that can we have a MERGE command wherein we could merge two contexts into one. (useful for services like Three Way Calling(TWC) and Call Transfer(CT)). Cheers, B.S.Gill --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now --0-1672312601-1043137633=:21556 Content-Type: text/html; charset=us-ascii

Hi,

Trying to correlate IN-CS2 with megaco, it just comes to my mind that can we have a MERGE command wherein we could merge two contexts into one. (useful for services like Three Way Calling(TWC) and Call Transfer(CT)).

Cheers,

B.S.Gill


Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now --0-1672312601-1043137633=:21556-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 21 03:27:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23553 for ; Tue, 21 Jan 2003 03:27:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0L8iUC31100 for megaco-archive@odin.ietf.org; Tue, 21 Jan 2003 03:44:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L8iTJ31097 for ; Tue, 21 Jan 2003 03:44:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23549 for ; Tue, 21 Jan 2003 03:26:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L8hGJ31048; Tue, 21 Jan 2003 03:43:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L8fjJ30978 for ; Tue, 21 Jan 2003 03:41:45 -0500 Received: from web40810.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA23513 for ; Tue, 21 Jan 2003 03:23:46 -0500 (EST) Message-ID: <20030121082713.22837.qmail@web40810.mail.yahoo.com> Received: from [202.134.200.4] by web40810.mail.yahoo.com via HTTP; Tue, 21 Jan 2003 00:27:13 PST Date: Tue, 21 Jan 2003 00:27:13 -0800 (PST) From: baljeet gill To: megaco@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1672312601-1043137633=:21556" 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: , --0-1672312601-1043137633=:21556 Content-Type: text/plain; charset=us-ascii Hi, Trying to correlate IN-CS2 with megaco, it just comes to my mind that can we have a MERGE command wherein we could merge two contexts into one. (useful for services like Three Way Calling(TWC) and Call Transfer(CT)). Cheers, B.S.Gill --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now --0-1672312601-1043137633=:21556 Content-Type: text/html; charset=us-ascii

Hi,

Trying to correlate IN-CS2 with megaco, it just comes to my mind that can we have a MERGE command wherein we could merge two contexts into one. (useful for services like Three Way Calling(TWC) and Call Transfer(CT)).

Cheers,

B.S.Gill


Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now --0-1672312601-1043137633=:21556-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 21 10:10:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01916 for ; Tue, 21 Jan 2003 10:10:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LFRQJ23884; Tue, 21 Jan 2003 10:27:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LFGqJ23458 for ; Tue, 21 Jan 2003 10:16:52 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01673 for ; Tue, 21 Jan 2003 09:58:46 -0500 (EST) From: manfred.volz@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0LF1C013109 for ; Tue, 21 Jan 2003 17:01:12 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 21 Jan 2003 17:02:10 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 21 Jan 2003 17:02:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Megaco] ALL in Topology descriptor and CHOOSE in command Date: Tue, 21 Jan 2003 17:02:09 +0200 Message-ID: <91FE6174A23D934D8EFB0EF75284E5BB81328E@esebe018.ntc.nokia.com> Thread-Topic: [Megaco] ALL in Topology descriptor and CHOOSE in command Thread-Index: AcLBXhD5peKaC1L8T8O0vlr7JOl6gw== To: X-OriginalArrivalTime: 21 Jan 2003 15:02:10.0890 (UTC) FILETIME=[12F492A0:01C2C15E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0LFGqJ23459 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, Let's assume we have 2 terminations T1 and T2 which are oneway connected. Now we add a new termination T3 with the following topology settings. Topology (T1,ALL,isolate) ADD $ Which of the following results is correct? a.) T1 is isolated from T2 and T1 is isolated from T3 and T2 is bothway connected to T3 b.) T1 is isolated from T2 and T1 is bothway connected to T3 and T2 is bothway connected to T3 Thanks for your help. best regards Manfred _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 21 10:11:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01953 for ; Tue, 21 Jan 2003 10:11:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LFT2T24040 for megaco-archive@odin.ietf.org; Tue, 21 Jan 2003 10:29:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LFT2J24037 for ; Tue, 21 Jan 2003 10:29:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01932 for ; Tue, 21 Jan 2003 10:10:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LFRQJ23884; Tue, 21 Jan 2003 10:27:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LFGqJ23458 for ; Tue, 21 Jan 2003 10:16:52 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01673 for ; Tue, 21 Jan 2003 09:58:46 -0500 (EST) From: manfred.volz@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0LF1C013109 for ; Tue, 21 Jan 2003 17:01:12 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 21 Jan 2003 17:02:10 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 21 Jan 2003 17:02:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Megaco] ALL in Topology descriptor and CHOOSE in command Date: Tue, 21 Jan 2003 17:02:09 +0200 Message-ID: <91FE6174A23D934D8EFB0EF75284E5BB81328E@esebe018.ntc.nokia.com> Thread-Topic: [Megaco] ALL in Topology descriptor and CHOOSE in command Thread-Index: AcLBXhD5peKaC1L8T8O0vlr7JOl6gw== To: X-OriginalArrivalTime: 21 Jan 2003 15:02:10.0890 (UTC) FILETIME=[12F492A0:01C2C15E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0LFGqJ23459 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi all, Let's assume we have 2 terminations T1 and T2 which are oneway connected. Now we add a new termination T3 with the following topology settings. Topology (T1,ALL,isolate) ADD $ Which of the following results is correct? a.) T1 is isolated from T2 and T1 is isolated from T3 and T2 is bothway connected to T3 b.) T1 is isolated from T2 and T1 is bothway connected to T3 and T2 is bothway connected to T3 Thanks for your help. best regards Manfred _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 21 16:18:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12276 for ; Tue, 21 Jan 2003 16:18:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LLZQJ17621; Tue, 21 Jan 2003 16:35:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LLWBJ17524 for ; Tue, 21 Jan 2003 16:32:11 -0500 Received: from zrtps0kp.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12221 for ; Tue, 21 Jan 2003 16:13:58 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0LLHMW27462 for ; Tue, 21 Jan 2003 16:17:23 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Jan 2003 16:17:22 -0500 Message-ID: From: "Kevin Boyle" To: baljeet gill , megaco@ietf.org Subject: RE: [Megaco] (no subject) Date: Tue, 21 Jan 2003 16:17:21 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , What's wrong with MOVE? Kevin -----Original Message----- From: baljeet gill [mailto:gill_b_s@yahoo.com] Sent: Tuesday, January 21, 2003 3:27 AM To: megaco@ietf.org Subject: [Megaco] (no subject) Hi, Trying to correlate IN-CS2 with megaco, it just comes to my mind that can we have a MERGE command wherein we could merge two contexts into one. (useful for services like Three Way Calling(TWC) and Call Transfer(CT)). Cheers, B.S.Gill _____ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 21 16:19:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12293 for ; Tue, 21 Jan 2003 16:19:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LLamH17692 for megaco-archive@odin.ietf.org; Tue, 21 Jan 2003 16:36:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LLamJ17689 for ; Tue, 21 Jan 2003 16:36:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12290 for ; Tue, 21 Jan 2003 16:18:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LLZQJ17621; Tue, 21 Jan 2003 16:35:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LLWBJ17524 for ; Tue, 21 Jan 2003 16:32:11 -0500 Received: from zrtps0kp.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12221 for ; Tue, 21 Jan 2003 16:13:58 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0LLHMW27462 for ; Tue, 21 Jan 2003 16:17:23 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Jan 2003 16:17:22 -0500 Message-ID: From: "Kevin Boyle" To: baljeet gill , megaco@ietf.org Subject: RE: [Megaco] (no subject) Date: Tue, 21 Jan 2003 16:17:21 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , What's wrong with MOVE? Kevin -----Original Message----- From: baljeet gill [mailto:gill_b_s@yahoo.com] Sent: Tuesday, January 21, 2003 3:27 AM To: megaco@ietf.org Subject: [Megaco] (no subject) Hi, Trying to correlate IN-CS2 with megaco, it just comes to my mind that can we have a MERGE command wherein we could merge two contexts into one. (useful for services like Three Way Calling(TWC) and Call Transfer(CT)). Cheers, B.S.Gill _____ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 21 16:33:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12669 for ; Tue, 21 Jan 2003 16:33:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LLoVJ18927; Tue, 21 Jan 2003 16:50:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LLnOJ18885 for ; Tue, 21 Jan 2003 16:49:24 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12605 for ; Tue, 21 Jan 2003 16:31:11 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA22740; Tue, 21 Jan 2003 16:34:33 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA29221; Tue, 21 Jan 2003 16:34:33 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Jan 2003 16:34:34 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D39@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Raphael Tryster'" , "'megaco@ietf.org'" Subject: RE: [Megaco] Spelling the long form of AC Date: Tue, 21 Jan 2003 16:34:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C194.B781B7CC" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2C194.B781B7CC Content-Type: text/plain; charset="iso-8859-1" Guilty as charged. AuditCapability should be used consistently I think. Brian -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Thursday, January 16, 2003 5:39 AM To: 'megaco@ietf.org' Subject: [Megaco] Spelling the long form of AC Is there an error in RFC 3015 and all its updates, or is there just one command whose name (AuditCapabilities) is different from its long spelling (AuditCapability)? Raphael Tryster ------_=_NextPart_001_01C2C194.B781B7CC Content-Type: text/html; charset="iso-8859-1" Spelling the long form of AC
Guilty as charged.  AuditCapability should be used consistently I think.
 
Brian
-----Original Message-----
From: Raphael Tryster [mailto:raphael@tdsoft.com]
Sent: Thursday, January 16, 2003 5:39 AM
To: 'megaco@ietf.org'
Subject: [Megaco] Spelling the long form of AC

Is there an error in RFC 3015 and all its updates, or is there just one command whose name (AuditCapabilities) is different from its long spelling (AuditCapability)?

Raphael Tryster

------_=_NextPart_001_01C2C194.B781B7CC-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 21 16:34:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12693 for ; Tue, 21 Jan 2003 16:34:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LLq2418992 for megaco-archive@odin.ietf.org; Tue, 21 Jan 2003 16:52:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LLq2J18989 for ; Tue, 21 Jan 2003 16:52:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12683 for ; Tue, 21 Jan 2003 16:33:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LLoVJ18927; Tue, 21 Jan 2003 16:50:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LLnOJ18885 for ; Tue, 21 Jan 2003 16:49:24 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12605 for ; Tue, 21 Jan 2003 16:31:11 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA22740; Tue, 21 Jan 2003 16:34:33 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA29221; Tue, 21 Jan 2003 16:34:33 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Jan 2003 16:34:34 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D39@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Raphael Tryster'" , "'megaco@ietf.org'" Subject: RE: [Megaco] Spelling the long form of AC Date: Tue, 21 Jan 2003 16:34:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C194.B781B7CC" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2C194.B781B7CC Content-Type: text/plain; charset="iso-8859-1" Guilty as charged. AuditCapability should be used consistently I think. Brian -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Thursday, January 16, 2003 5:39 AM To: 'megaco@ietf.org' Subject: [Megaco] Spelling the long form of AC Is there an error in RFC 3015 and all its updates, or is there just one command whose name (AuditCapabilities) is different from its long spelling (AuditCapability)? Raphael Tryster ------_=_NextPart_001_01C2C194.B781B7CC Content-Type: text/html; charset="iso-8859-1" Spelling the long form of AC
Guilty as charged.  AuditCapability should be used consistently I think.
 
Brian
-----Original Message-----
From: Raphael Tryster [mailto:raphael@tdsoft.com]
Sent: Thursday, January 16, 2003 5:39 AM
To: 'megaco@ietf.org'
Subject: [Megaco] Spelling the long form of AC

Is there an error in RFC 3015 and all its updates, or is there just one command whose name (AuditCapabilities) is different from its long spelling (AuditCapability)?

Raphael Tryster

------_=_NextPart_001_01C2C194.B781B7CC-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 21 16:46:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13033 for ; Tue, 21 Jan 2003 16:46:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LM3HJ19913; Tue, 21 Jan 2003 17:03:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LM2ZJ19883 for ; Tue, 21 Jan 2003 17:02:35 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13016 for ; Tue, 21 Jan 2003 16:44:21 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0LLliF16679; Tue, 21 Jan 2003 16:47:44 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Jan 2003 16:47:45 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E1B8@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'uma ramanan'" , megaco@ietf.org Subject: RE: [Megaco] Notifying errors in Transaction Reply/Pending Date: Tue, 21 Jan 2003 16:47:41 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , There is no way to report errors in Transaction Reply/Pending. This is deliberate, both to reduce the effectiveness of one form of denial of service attack and to prevent the possibility of an infinite loop of error reporting. > -----Original Message----- > From: uma ramanan [mailto:umaramanan@yahoo.com] > Sent: Tuesday, January 21, 2003 2:02 AM > To: megaco@ietf.org > Subject: [Megaco] Notifying errors in Transaction Reply/Pending > > > Hi all, > > I would like to know as to how are errors in > Transaction Reply/Transaction Pending (eg Syntax Error > s : SyntaxErrorTransactionReply) informed to the > sender. In case of Transaction Requests, the errors > are notified in Transaction Reply, but i am not clear > about the procedure to be followed in case of > Transaction Reply/Pending. Should Notify Command be > used for this purpose ? > > Thanks & Regards, > Uma > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 21 16:46:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13051 for ; Tue, 21 Jan 2003 16:46:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LM4UV19962 for megaco-archive@odin.ietf.org; Tue, 21 Jan 2003 17:04:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LM4UJ19959 for ; Tue, 21 Jan 2003 17:04:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13047 for ; Tue, 21 Jan 2003 16:46:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LM3HJ19913; Tue, 21 Jan 2003 17:03:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LM2ZJ19883 for ; Tue, 21 Jan 2003 17:02:35 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13016 for ; Tue, 21 Jan 2003 16:44:21 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0LLliF16679; Tue, 21 Jan 2003 16:47:44 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Jan 2003 16:47:45 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E1B8@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'uma ramanan'" , megaco@ietf.org Subject: RE: [Megaco] Notifying errors in Transaction Reply/Pending Date: Tue, 21 Jan 2003 16:47:41 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , There is no way to report errors in Transaction Reply/Pending. This is deliberate, both to reduce the effectiveness of one form of denial of service attack and to prevent the possibility of an infinite loop of error reporting. > -----Original Message----- > From: uma ramanan [mailto:umaramanan@yahoo.com] > Sent: Tuesday, January 21, 2003 2:02 AM > To: megaco@ietf.org > Subject: [Megaco] Notifying errors in Transaction Reply/Pending > > > Hi all, > > I would like to know as to how are errors in > Transaction Reply/Transaction Pending (eg Syntax Error > s : SyntaxErrorTransactionReply) informed to the > sender. In case of Transaction Requests, the errors > are notified in Transaction Reply, but i am not clear > about the procedure to be followed in case of > Transaction Reply/Pending. Should Notify Command be > used for this purpose ? > > Thanks & Regards, > Uma > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jan 22 00:27:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22104 for ; Wed, 22 Jan 2003 00:27:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M5iaJ14584; Wed, 22 Jan 2003 00:44:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M5gWJ14509 for ; Wed, 22 Jan 2003 00:42:33 -0500 Received: from ish7.ericsson.com.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21981 for ; Wed, 22 Jan 2003 00:24:07 -0500 (EST) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id h0M5PJG26069; Wed, 22 Jan 2003 16:25:19 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h0M5RUE17008; Wed, 22 Jan 2003 16:27:30 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.193]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DNA2094V; Wed, 22 Jan 2003 16:27:29 +1100 Message-ID: <3E2DDF5B.715FFF1A@ericsson.com.au> Date: Wed, 22 Jan 2003 11:01:31 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: baljeet gill CC: megaco@ietf.org Subject: Re: [Megaco] (no subject) References: <20030121082713.22837.qmail@web40810.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit G'Day B.S. We have the equivalent command MOVE. You can move the contents of one context to another which essentially performs the merge function. Cheers, Christian baljeet gill wrote: > > Hi, > > Trying to correlate IN-CS2 with megaco, it just comes to my mind that can we > have a MERGE command wherein we could merge two contexts into one. (useful for > services like Three Way Calling(TWC) and Call Transfer(CT)). > > Cheers, > > B.S.Gill > > ------------------------------------------------------------------------------ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jan 22 00:28:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22122 for ; Wed, 22 Jan 2003 00:28:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M5iqJ14607; Wed, 22 Jan 2003 00:44:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M5gaJ14513 for ; Wed, 22 Jan 2003 00:42:36 -0500 Received: from ish7.ericsson.com.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21998 for ; Wed, 22 Jan 2003 00:24:12 -0500 (EST) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id h0M5PLG26077; Wed, 22 Jan 2003 16:25:21 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h0M5RVE17014; Wed, 22 Jan 2003 16:27:32 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.193]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DNA2094Y; Wed, 22 Jan 2003 16:27:30 +1100 Message-ID: <3E2DE08C.ADBA5B86@ericsson.com.au> Date: Wed, 22 Jan 2003 11:06:36 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: manfred.volz@NOKIA.COM CC: megaco@ietf.org Subject: Re: [Megaco] ALL in Topology descriptor and CHOOSE in command References: <91FE6174A23D934D8EFB0EF75284E5BB81328E@esebe018.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Manfred, In accordance to 7.1.18 "The Topology descriptor occurs before the commands in an action." it would be b). Christian manfred.volz@NOKIA.COM wrote: > > Hi all, > > Let's assume we have 2 terminations T1 and T2 which are oneway connected. > Now we add a new termination T3 with the following topology settings. > > Topology (T1,ALL,isolate) > ADD $ > > Which of the following results is correct? > > a.) T1 is isolated from T2 and > T1 is isolated from T3 and > T2 is bothway connected to T3 > b.) T1 is isolated from T2 and > T1 is bothway connected to T3 and > T2 is bothway connected to T3 > > Thanks for your help. > > best regards Manfred > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 22 00:28:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22124 for ; Wed, 22 Jan 2003 00:28:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0M5juS14634 for megaco-archive@odin.ietf.org; Wed, 22 Jan 2003 00:45:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M5jtJ14631 for ; Wed, 22 Jan 2003 00:45:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22118 for ; Wed, 22 Jan 2003 00:27:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M5iaJ14584; Wed, 22 Jan 2003 00:44:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M5gWJ14509 for ; Wed, 22 Jan 2003 00:42:33 -0500 Received: from ish7.ericsson.com.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21981 for ; Wed, 22 Jan 2003 00:24:07 -0500 (EST) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id h0M5PJG26069; Wed, 22 Jan 2003 16:25:19 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h0M5RUE17008; Wed, 22 Jan 2003 16:27:30 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.193]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DNA2094V; Wed, 22 Jan 2003 16:27:29 +1100 Message-ID: <3E2DDF5B.715FFF1A@ericsson.com.au> Date: Wed, 22 Jan 2003 11:01:31 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: baljeet gill CC: megaco@ietf.org Subject: Re: [Megaco] (no subject) References: <20030121082713.22837.qmail@web40810.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit G'Day B.S. We have the equivalent command MOVE. You can move the contents of one context to another which essentially performs the merge function. Cheers, Christian baljeet gill wrote: > > Hi, > > Trying to correlate IN-CS2 with megaco, it just comes to my mind that can we > have a MERGE command wherein we could merge two contexts into one. (useful for > services like Three Way Calling(TWC) and Call Transfer(CT)). > > Cheers, > > B.S.Gill > > ------------------------------------------------------------------------------ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 22 00:28:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22152 for ; Wed, 22 Jan 2003 00:28:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0M5kSQ14657 for megaco-archive@odin.ietf.org; Wed, 22 Jan 2003 00:46:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M5kRJ14654 for ; Wed, 22 Jan 2003 00:46:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22146 for ; Wed, 22 Jan 2003 00:28:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M5iqJ14607; Wed, 22 Jan 2003 00:44:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M5gaJ14513 for ; Wed, 22 Jan 2003 00:42:36 -0500 Received: from ish7.ericsson.com.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21998 for ; Wed, 22 Jan 2003 00:24:12 -0500 (EST) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id h0M5PLG26077; Wed, 22 Jan 2003 16:25:21 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h0M5RVE17014; Wed, 22 Jan 2003 16:27:32 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.193]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DNA2094Y; Wed, 22 Jan 2003 16:27:30 +1100 Message-ID: <3E2DE08C.ADBA5B86@ericsson.com.au> Date: Wed, 22 Jan 2003 11:06:36 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: manfred.volz@NOKIA.COM CC: megaco@ietf.org Subject: Re: [Megaco] ALL in Topology descriptor and CHOOSE in command References: <91FE6174A23D934D8EFB0EF75284E5BB81328E@esebe018.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Manfred, In accordance to 7.1.18 "The Topology descriptor occurs before the commands in an action." it would be b). Christian manfred.volz@NOKIA.COM wrote: > > Hi all, > > Let's assume we have 2 terminations T1 and T2 which are oneway connected. > Now we add a new termination T3 with the following topology settings. > > Topology (T1,ALL,isolate) > ADD $ > > Which of the following results is correct? > > a.) T1 is isolated from T2 and > T1 is isolated from T3 and > T2 is bothway connected to T3 > b.) T1 is isolated from T2 and > T1 is bothway connected to T3 and > T2 is bothway connected to T3 > > Thanks for your help. > > best regards Manfred > > _______________________________________________ > 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 Jan 22 17:25:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09803 for ; Wed, 22 Jan 2003 17:25:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MMhOJ26202; Wed, 22 Jan 2003 17:43:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MMeZJ26109 for ; Wed, 22 Jan 2003 17:40:35 -0500 Received: from sparky.afc.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09724 for ; Wed, 22 Jan 2003 17:21:51 -0500 (EST) Received: (qmail 32291 invoked from network); 22 Jan 2003 22:21:27 -0000 Received: from unknown (HELO zzzconn03.fibre.com) (10.1.4.53) by 0 with SMTP; 22 Jan 2003 22:21:27 -0000 Received: FROM xconn01.fibre.com BY zzzconn03.fibre.com ; Wed Jan 22 14:25:32 2003 -0800 Received: by xconn01.fibre.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Jan 2003 14:24:29 -0800 Message-ID: From: John Stock To: "'megaco@ietf.org'" Date: Wed, 22 Jan 2003 14:25:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Megaco] Glare condition when using embedded descriptors Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi all, I was wondering about handling of this situation: - Embedded descriptors are used, such that when a user goes offhook, the MG will provide dialtone and begin digit collection without waiting for additional signals from the MGC - A glare condition happens, such that a ring-in on the phone from the MGC side occurs at the same time as the offhook, such that the MG sends the offhook notification before receiving the Add command on the ring-in. - Thus the MG will begin dial tone before getting the Add, and will cease it when connecting the physical termination to the incoming call. - The MGC will receive the offhook notification after sending the Add command for the ring-in, thus sees it simply as a user answering a terminating call. My questions are these: - Is it proper to handle it this way, such that the subscriber is connected to the incoming call, instead of the alternative which is to block the incoming call and to provide dial tone and collect digits from the subscriber for a separate outgoing call? I believe this is the way it works with other protocols, such as Q.931 in GR303. - The odd thing is the brief spurt of dial tone, which may be exacerbated by any MGC<->MG messaging delay. Does anyone know anything that's proposed for handling this? Though it's probably not a big deal since one would expect this to happen very very seldomly. An obvious solution is to not use the embedded descriptors, however this then of course removes the benefits of doing such. Another solution may be to have the MG wait for the Reply to the offhook before providing dial tone, but this is kind of complex because the Reply handling may be in a completely different entity and level than event/signal handling. Thanks. John Stock Systems Engineering Advanced Fibre Communications john.stock@afc.com 707-792-6249 This message (including any attachments) is intended only for the use of the named addressee(s), and may contain information that is legally privileged, confidential or exempt from disclosure under applicable law. If you are not a named addressee, you are hereby notified that any use, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the original sender immediately by telephone or by return E-mail and delete this message, along with any attachments, from your computer. Thank you. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 22 17:26:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09831 for ; Wed, 22 Jan 2003 17:26:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MMiiF26253 for megaco-archive@odin.ietf.org; Wed, 22 Jan 2003 17:44:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MMiiJ26250 for ; Wed, 22 Jan 2003 17:44:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09817 for ; Wed, 22 Jan 2003 17:26:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MMhOJ26202; Wed, 22 Jan 2003 17:43:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MMeZJ26109 for ; Wed, 22 Jan 2003 17:40:35 -0500 Received: from sparky.afc.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09724 for ; Wed, 22 Jan 2003 17:21:51 -0500 (EST) Received: (qmail 32291 invoked from network); 22 Jan 2003 22:21:27 -0000 Received: from unknown (HELO zzzconn03.fibre.com) (10.1.4.53) by 0 with SMTP; 22 Jan 2003 22:21:27 -0000 Received: FROM xconn01.fibre.com BY zzzconn03.fibre.com ; Wed Jan 22 14:25:32 2003 -0800 Received: by xconn01.fibre.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Jan 2003 14:24:29 -0800 Message-ID: From: John Stock To: "'megaco@ietf.org'" Date: Wed, 22 Jan 2003 14:25:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Megaco] Glare condition when using embedded descriptors Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi all, I was wondering about handling of this situation: - Embedded descriptors are used, such that when a user goes offhook, the MG will provide dialtone and begin digit collection without waiting for additional signals from the MGC - A glare condition happens, such that a ring-in on the phone from the MGC side occurs at the same time as the offhook, such that the MG sends the offhook notification before receiving the Add command on the ring-in. - Thus the MG will begin dial tone before getting the Add, and will cease it when connecting the physical termination to the incoming call. - The MGC will receive the offhook notification after sending the Add command for the ring-in, thus sees it simply as a user answering a terminating call. My questions are these: - Is it proper to handle it this way, such that the subscriber is connected to the incoming call, instead of the alternative which is to block the incoming call and to provide dial tone and collect digits from the subscriber for a separate outgoing call? I believe this is the way it works with other protocols, such as Q.931 in GR303. - The odd thing is the brief spurt of dial tone, which may be exacerbated by any MGC<->MG messaging delay. Does anyone know anything that's proposed for handling this? Though it's probably not a big deal since one would expect this to happen very very seldomly. An obvious solution is to not use the embedded descriptors, however this then of course removes the benefits of doing such. Another solution may be to have the MG wait for the Reply to the offhook before providing dial tone, but this is kind of complex because the Reply handling may be in a completely different entity and level than event/signal handling. Thanks. John Stock Systems Engineering Advanced Fibre Communications john.stock@afc.com 707-792-6249 This message (including any attachments) is intended only for the use of the named addressee(s), and may contain information that is legally privileged, confidential or exempt from disclosure under applicable law. If you are not a named addressee, you are hereby notified that any use, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the original sender immediately by telephone or by return E-mail and delete this message, along with any attachments, from your computer. Thank you. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jan 22 17:31:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09965 for ; Wed, 22 Jan 2003 17:31:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MMmBJ26413; Wed, 22 Jan 2003 17:48:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MMlBJ26386 for ; Wed, 22 Jan 2003 17:47:11 -0500 Received: from sparky.afc.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09900 for ; Wed, 22 Jan 2003 17:28:27 -0500 (EST) Received: (qmail 2168 invoked from network); 22 Jan 2003 22:28:04 -0000 Received: from unknown (HELO zzzconn03.fibre.com) (10.1.4.53) by 0 with SMTP; 22 Jan 2003 22:28:04 -0000 Received: FROM xconn01.fibre.com BY zzzconn03.fibre.com ; Wed Jan 22 14:32:08 2003 -0800 Received: by xconn01.fibre.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Jan 2003 14:31:05 -0800 Message-ID: From: John Stock To: John Stock , "'megaco@ietf.org'" Date: Wed, 22 Jan 2003 14:31:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Megaco] RE: Glare condition when using embedded descriptors Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Actually I just remember that an offhook event is not sent to the MG in the case of embedded descriptors. However this actually exacerbates the problem - there is actually a very large widow where this glare condition can occur. I'm certain this must have been discussed at some point, though couldn't find anything in looking through past emails. If such a discussion has taken place, can someone point me to the email thread? Thanks. > -----Original Message----- > From: John Stock > Sent: Wednesday, January 22, 2003 2:25 PM > To: 'megaco@ietf.org' > Subject: Glare condition when using embedded descriptors > > Hi all, > > I was wondering about handling of this situation: > > - Embedded descriptors are used, such that when a user goes offhook, the > MG will provide dialtone and begin digit collection without waiting for > additional signals from the MGC > - A glare condition happens, such that a ring-in on the phone from the MGC > side occurs at the same time as the offhook, such that the MG sends the > offhook notification before receiving the Add command on the ring-in. > - Thus the MG will begin dial tone before getting the Add, and will cease > it when connecting the physical termination to the incoming call. > - The MGC will receive the offhook notification after sending the Add > command for the ring-in, thus sees it simply as a user answering a > terminating call. > > My questions are these: > > - Is it proper to handle it this way, such that the subscriber is > connected to the incoming call, instead of the alternative which is to > block the incoming call and to provide dial tone and collect digits from > the subscriber for a separate outgoing call? I believe this is the way it > works with other protocols, such as Q.931 in GR303. > - The odd thing is the brief spurt of dial tone, which may be exacerbated > by any MGC<->MG messaging delay. Does anyone know anything that's > proposed for handling this? Though it's probably not a big deal since one > would expect this to happen very very seldomly. An obvious solution is to > not use the embedded descriptors, however this then of course removes the > benefits of doing such. Another solution may be to have the MG wait for > the Reply to the offhook before providing dial tone, but this is kind of > complex because the Reply handling may be in a completely different entity > and level than event/signal handling. > > Thanks. > > John Stock > Systems Engineering > Advanced Fibre Communications > john.stock@afc.com > 707-792-6249 > > This message (including any attachments) is intended only for the use of > the named addressee(s), and may contain information that is legally > privileged, confidential or exempt from disclosure under applicable law. > If you are not a named addressee, you are hereby notified that any use, > dissemination, distribution or copying of this message is strictly > prohibited. If you have received this message in error, please notify the > original sender immediately by telephone or by return E-mail and delete > this message, along with any attachments, from your computer. Thank you. > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 22 17:32:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10002 for ; Wed, 22 Jan 2003 17:32:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MMoGZ26507 for megaco-archive@odin.ietf.org; Wed, 22 Jan 2003 17:50:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MMoGJ26504 for ; Wed, 22 Jan 2003 17:50:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09979 for ; Wed, 22 Jan 2003 17:31:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MMmBJ26413; Wed, 22 Jan 2003 17:48:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MMlBJ26386 for ; Wed, 22 Jan 2003 17:47:11 -0500 Received: from sparky.afc.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09900 for ; Wed, 22 Jan 2003 17:28:27 -0500 (EST) Received: (qmail 2168 invoked from network); 22 Jan 2003 22:28:04 -0000 Received: from unknown (HELO zzzconn03.fibre.com) (10.1.4.53) by 0 with SMTP; 22 Jan 2003 22:28:04 -0000 Received: FROM xconn01.fibre.com BY zzzconn03.fibre.com ; Wed Jan 22 14:32:08 2003 -0800 Received: by xconn01.fibre.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Jan 2003 14:31:05 -0800 Message-ID: From: John Stock To: John Stock , "'megaco@ietf.org'" Date: Wed, 22 Jan 2003 14:31:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Megaco] RE: Glare condition when using embedded descriptors Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Actually I just remember that an offhook event is not sent to the MG in the case of embedded descriptors. However this actually exacerbates the problem - there is actually a very large widow where this glare condition can occur. I'm certain this must have been discussed at some point, though couldn't find anything in looking through past emails. If such a discussion has taken place, can someone point me to the email thread? Thanks. > -----Original Message----- > From: John Stock > Sent: Wednesday, January 22, 2003 2:25 PM > To: 'megaco@ietf.org' > Subject: Glare condition when using embedded descriptors > > Hi all, > > I was wondering about handling of this situation: > > - Embedded descriptors are used, such that when a user goes offhook, the > MG will provide dialtone and begin digit collection without waiting for > additional signals from the MGC > - A glare condition happens, such that a ring-in on the phone from the MGC > side occurs at the same time as the offhook, such that the MG sends the > offhook notification before receiving the Add command on the ring-in. > - Thus the MG will begin dial tone before getting the Add, and will cease > it when connecting the physical termination to the incoming call. > - The MGC will receive the offhook notification after sending the Add > command for the ring-in, thus sees it simply as a user answering a > terminating call. > > My questions are these: > > - Is it proper to handle it this way, such that the subscriber is > connected to the incoming call, instead of the alternative which is to > block the incoming call and to provide dial tone and collect digits from > the subscriber for a separate outgoing call? I believe this is the way it > works with other protocols, such as Q.931 in GR303. > - The odd thing is the brief spurt of dial tone, which may be exacerbated > by any MGC<->MG messaging delay. Does anyone know anything that's > proposed for handling this? Though it's probably not a big deal since one > would expect this to happen very very seldomly. An obvious solution is to > not use the embedded descriptors, however this then of course removes the > benefits of doing such. Another solution may be to have the MG wait for > the Reply to the offhook before providing dial tone, but this is kind of > complex because the Reply handling may be in a completely different entity > and level than event/signal handling. > > Thanks. > > John Stock > Systems Engineering > Advanced Fibre Communications > john.stock@afc.com > 707-792-6249 > > This message (including any attachments) is intended only for the use of > the named addressee(s), and may contain information that is legally > privileged, confidential or exempt from disclosure under applicable law. > If you are not a named addressee, you are hereby notified that any use, > dissemination, distribution or copying of this message is strictly > prohibited. If you have received this message in error, please notify the > original sender immediately by telephone or by return E-mail and delete > this message, along with any attachments, from your computer. Thank you. > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Jan 24 04:06:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13662 for ; Fri, 24 Jan 2003 04:06:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O9NhJ14601; Fri, 24 Jan 2003 04:23:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O9KZJ14513 for ; Fri, 24 Jan 2003 04:20:35 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13516 for ; Fri, 24 Jan 2003 04:01:07 -0500 (EST) From: shbansal@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0O93Gj29772 for ; Fri, 24 Jan 2003 14:33:16 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0O93FM29767; Fri, 24 Jan 2003 14:33:15 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h0O95TZ29066; Fri, 24 Jan 2003 14:35:31 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CB8.00312D25 ; Fri, 24 Jan 2003 14:27:08 +0530 X-Lotus-FromDomain: HSS To: Christian Groves cc: manfred.volz@nokia.com, megaco@ietf.org Message-ID: <65256CB8.00312C83.00@sandesh.hss.hns.com> Date: Fri, 24 Jan 2003 14:36:53 +0530 Subject: Re: [Megaco] ALL in Topology descriptor and CHOOSE in command Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Chris, In earlier mails it was stated that Section 7.1.18 means that you must consider the topology descriptor before addressing the commands. You should then use the information that is in the topology descriptor when you process the commands in the message. Now with this implementation the final result should be T1 is isolated from T2 and T1 is isolated from T3 and T2 is bothway connected to T3 Correct me if I have some wrong interpretation Thanks and regards Shobhit Christian Groves on 01/22/2003 05:36:36 AM To: manfred.volz@nokia.com cc: megaco@ietf.org (bcc: Shobhit Bansal/HSS) Subject: Re: [Megaco] ALL in Topology descriptor and CHOOSE in command Hello Manfred, In accordance to 7.1.18 "The Topology descriptor occurs before the commands in an action." it would be b). Christian manfred.volz@NOKIA.COM wrote: > > Hi all, > > Let's assume we have 2 terminations T1 and T2 which are oneway connected. > Now we add a new termination T3 with the following topology settings. > > Topology (T1,ALL,isolate) > ADD $ > > Which of the following results is correct? > > a.) T1 is isolated from T2 and > T1 is isolated from T3 and > T2 is bothway connected to T3 > b.) T1 is isolated from T2 and > T1 is bothway connected to T3 and > T2 is bothway connected to T3 > > Thanks for your help. > > best regards Manfred > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Jan 24 04:06:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13697 for ; Fri, 24 Jan 2003 04:06:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0O9Pf714734 for megaco-archive@odin.ietf.org; Fri, 24 Jan 2003 04:25:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O9PfJ14731 for ; Fri, 24 Jan 2003 04:25:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13677 for ; Fri, 24 Jan 2003 04:06:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O9NhJ14601; Fri, 24 Jan 2003 04:23:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O9KZJ14513 for ; Fri, 24 Jan 2003 04:20:35 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13516 for ; Fri, 24 Jan 2003 04:01:07 -0500 (EST) From: shbansal@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0O93Gj29772 for ; Fri, 24 Jan 2003 14:33:16 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0O93FM29767; Fri, 24 Jan 2003 14:33:15 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h0O95TZ29066; Fri, 24 Jan 2003 14:35:31 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CB8.00312D25 ; Fri, 24 Jan 2003 14:27:08 +0530 X-Lotus-FromDomain: HSS To: Christian Groves cc: manfred.volz@nokia.com, megaco@ietf.org Message-ID: <65256CB8.00312C83.00@sandesh.hss.hns.com> Date: Fri, 24 Jan 2003 14:36:53 +0530 Subject: Re: [Megaco] ALL in Topology descriptor and CHOOSE in command Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Chris, In earlier mails it was stated that Section 7.1.18 means that you must consider the topology descriptor before addressing the commands. You should then use the information that is in the topology descriptor when you process the commands in the message. Now with this implementation the final result should be T1 is isolated from T2 and T1 is isolated from T3 and T2 is bothway connected to T3 Correct me if I have some wrong interpretation Thanks and regards Shobhit Christian Groves on 01/22/2003 05:36:36 AM To: manfred.volz@nokia.com cc: megaco@ietf.org (bcc: Shobhit Bansal/HSS) Subject: Re: [Megaco] ALL in Topology descriptor and CHOOSE in command Hello Manfred, In accordance to 7.1.18 "The Topology descriptor occurs before the commands in an action." it would be b). Christian manfred.volz@NOKIA.COM wrote: > > Hi all, > > Let's assume we have 2 terminations T1 and T2 which are oneway connected. > Now we add a new termination T3 with the following topology settings. > > Topology (T1,ALL,isolate) > ADD $ > > Which of the following results is correct? > > a.) T1 is isolated from T2 and > T1 is isolated from T3 and > T2 is bothway connected to T3 > b.) T1 is isolated from T2 and > T1 is bothway connected to T3 and > T2 is bothway connected to T3 > > Thanks for your help. > > best regards Manfred > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Jan 24 09:16:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20005 for ; Fri, 24 Jan 2003 09:16:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OEYCJ01573; Fri, 24 Jan 2003 09:34:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OEWdJ01491 for ; Fri, 24 Jan 2003 09:32:39 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19883 for ; Fri, 24 Jan 2003 09:13:07 -0500 (EST) Received: from cisco.com (rtp-vpn2-163.cisco.com [10.82.240.163]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h0OEGVB6025622 for ; Fri, 24 Jan 2003 06:16:31 -0800 (PST) Message-ID: <3E314AC1.79AC798C@cisco.com> Date: Fri, 24 Jan 2003 09:16:33 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Megaco Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] Can an MG ever subtract an ephemeral termination ? Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Barring reboots, memory loss and similar things, can an ephemeral termination ever be subtracted from a Context ? For example, let's say I have an RTP termination, and the underlying IP interface disappears. I assume I'd have to generate a ServiceChange for this ephemeral, but would it be valid for the MG to also Subtract (i.e. destroy) the ephemeral ? Thanks Flemming _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Jan 24 09:17:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20042 for ; Fri, 24 Jan 2003 09:17:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OEaVB01692 for megaco-archive@odin.ietf.org; Fri, 24 Jan 2003 09:36:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OEaUJ01689 for ; Fri, 24 Jan 2003 09:36:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20019 for ; Fri, 24 Jan 2003 09:16:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OEYCJ01573; Fri, 24 Jan 2003 09:34:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OEWdJ01491 for ; Fri, 24 Jan 2003 09:32:39 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19883 for ; Fri, 24 Jan 2003 09:13:07 -0500 (EST) Received: from cisco.com (rtp-vpn2-163.cisco.com [10.82.240.163]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h0OEGVB6025622 for ; Fri, 24 Jan 2003 06:16:31 -0800 (PST) Message-ID: <3E314AC1.79AC798C@cisco.com> Date: Fri, 24 Jan 2003 09:16:33 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Megaco Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] Can an MG ever subtract an ephemeral termination ? Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Barring reboots, memory loss and similar things, can an ephemeral termination ever be subtracted from a Context ? For example, let's say I have an RTP termination, and the underlying IP interface disappears. I assume I'd have to generate a ServiceChange for this ephemeral, but would it be valid for the MG to also Subtract (i.e. destroy) the ephemeral ? Thanks Flemming _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Jan 24 09:38:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20870 for ; Fri, 24 Jan 2003 09:38:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OErIJ03181; Fri, 24 Jan 2003 09:53:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OEqMJ03122 for ; Fri, 24 Jan 2003 09:52:22 -0500 Received: from zrtps06s.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20719 for ; Fri, 24 Jan 2003 09:32:49 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0OEaGw06970 for ; Fri, 24 Jan 2003 09:36:16 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Jan 2003 09:36:16 -0500 Message-ID: From: "Kevin Boyle" To: Flemming Andreasen , Megaco Subject: RE: [Megaco] Can an MG ever subtract an ephemeral termination ? Date: Fri, 24 Jan 2003 09:36:14 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , MG's may NOT autonomously subtract ANY termination. There are other methods whereby loss of bearer (for whatever reason) can be reported to the MGC. The network package includes an event that can be used to report network failures. It is up to the MGC to decide whether or not to subtract the term. This allows the MGC to perform other actions on the termination that would not be possible if the MG subtracted it on its own (like auditing, for example). Kevin -----Original Message----- From: Flemming Andreasen [mailto:fandreas@cisco.com] Sent: Friday, January 24, 2003 9:17 AM To: Megaco Subject: [Megaco] Can an MG ever subtract an ephemeral termination ? Barring reboots, memory loss and similar things, can an ephemeral termination ever be subtracted from a Context ? For example, let's say I have an RTP termination, and the underlying IP interface disappears. I assume I'd have to generate a ServiceChange for this ephemeral, but would it be valid for the MG to also Subtract (i.e. destroy) the ephemeral ? Thanks Flemming _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Jan 24 09:38:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20891 for ; Fri, 24 Jan 2003 09:38:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OEvfr03389 for megaco-archive@odin.ietf.org; Fri, 24 Jan 2003 09:57:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OEvfJ03386 for ; Fri, 24 Jan 2003 09:57:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20885 for ; Fri, 24 Jan 2003 09:38:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OErIJ03181; Fri, 24 Jan 2003 09:53:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OEqMJ03122 for ; Fri, 24 Jan 2003 09:52:22 -0500 Received: from zrtps06s.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20719 for ; Fri, 24 Jan 2003 09:32:49 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0OEaGw06970 for ; Fri, 24 Jan 2003 09:36:16 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Jan 2003 09:36:16 -0500 Message-ID: From: "Kevin Boyle" To: Flemming Andreasen , Megaco Subject: RE: [Megaco] Can an MG ever subtract an ephemeral termination ? Date: Fri, 24 Jan 2003 09:36:14 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , MG's may NOT autonomously subtract ANY termination. There are other methods whereby loss of bearer (for whatever reason) can be reported to the MGC. The network package includes an event that can be used to report network failures. It is up to the MGC to decide whether or not to subtract the term. This allows the MGC to perform other actions on the termination that would not be possible if the MG subtracted it on its own (like auditing, for example). Kevin -----Original Message----- From: Flemming Andreasen [mailto:fandreas@cisco.com] Sent: Friday, January 24, 2003 9:17 AM To: Megaco Subject: [Megaco] Can an MG ever subtract an ephemeral termination ? Barring reboots, memory loss and similar things, can an ephemeral termination ever be subtracted from a Context ? For example, let's say I have an RTP termination, and the underlying IP interface disappears. I assume I'd have to generate a ServiceChange for this ephemeral, but would it be valid for the MG to also Subtract (i.e. destroy) the ephemeral ? Thanks Flemming _______________________________________________ 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 Jan 24 09:44:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21079 for ; Fri, 24 Jan 2003 09:43:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OF1RJ03614; Fri, 24 Jan 2003 10:01:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OF0hJ03559 for ; Fri, 24 Jan 2003 10:00:43 -0500 Received: from wiprom2mx1.wipro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20985 for ; Fri, 24 Jan 2003 09:41:08 -0500 (EST) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h0OEiXv05066 for ; Fri, 24 Jan 2003 20:14:33 +0530 (IST) Received: from blr-ec-msg02.wipro.com ([10.200.51.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 24 Jan 2003 20:14:28 +0530 Received: from wipro.com ([192.168.178.243]) by blr-ec-msg02.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 24 Jan 2003 20:14:28 +0530 Message-ID: <3E315248.850F6E5A@wipro.com> Date: Fri, 24 Jan 2003 20:18:40 +0530 From: Shashi Kumar Organization: Wipro Technologies X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen CC: Megaco Subject: Re: [Megaco] Can an MG ever subtract an ephemeral termination ? References: <3E314AC1.79AC798C@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2003 14:44:28.0380 (UTC) FILETIME=[18E3A9C0:01C2C3B7] 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 yes, MGC would/can always direct/issue a subtract command towards MG to remove a ephemeral termination from a valid context. Thanks, Shashi Flemming Andreasen wrote: > > Barring reboots, memory loss and similar things, can an ephemeral > termination ever be subtracted from a Context ? For example, let's say I > have an RTP termination, and the underlying IP interface disappears. I > assume I'd have to generate a ServiceChange for this ephemeral, but > would it be valid for the MG to also Subtract (i.e. destroy) the > ephemeral ? > > Thanks > > Flemming > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Jan 24 09:44:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21114 for ; Fri, 24 Jan 2003 09:44:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OF3ZN03720 for megaco-archive@odin.ietf.org; Fri, 24 Jan 2003 10:03:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OF3YJ03717 for ; Fri, 24 Jan 2003 10:03:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21093 for ; Fri, 24 Jan 2003 09:44:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OF1RJ03614; Fri, 24 Jan 2003 10:01:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OF0hJ03559 for ; Fri, 24 Jan 2003 10:00:43 -0500 Received: from wiprom2mx1.wipro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20985 for ; Fri, 24 Jan 2003 09:41:08 -0500 (EST) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h0OEiXv05066 for ; Fri, 24 Jan 2003 20:14:33 +0530 (IST) Received: from blr-ec-msg02.wipro.com ([10.200.51.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 24 Jan 2003 20:14:28 +0530 Received: from wipro.com ([192.168.178.243]) by blr-ec-msg02.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 24 Jan 2003 20:14:28 +0530 Message-ID: <3E315248.850F6E5A@wipro.com> Date: Fri, 24 Jan 2003 20:18:40 +0530 From: Shashi Kumar Organization: Wipro Technologies X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen CC: Megaco Subject: Re: [Megaco] Can an MG ever subtract an ephemeral termination ? References: <3E314AC1.79AC798C@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2003 14:44:28.0380 (UTC) FILETIME=[18E3A9C0:01C2C3B7] Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit yes, MGC would/can always direct/issue a subtract command towards MG to remove a ephemeral termination from a valid context. Thanks, Shashi Flemming Andreasen wrote: > > Barring reboots, memory loss and similar things, can an ephemeral > termination ever be subtracted from a Context ? For example, let's say I > have an RTP termination, and the underlying IP interface disappears. I > assume I'd have to generate a ServiceChange for this ephemeral, but > would it be valid for the MG to also Subtract (i.e. destroy) the > ephemeral ? > > Thanks > > Flemming > > _______________________________________________ > 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 Jan 24 10:08:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21980 for ; Fri, 24 Jan 2003 10:08:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OFN8J05377; Fri, 24 Jan 2003 10:23:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OFKBJ05184 for ; Fri, 24 Jan 2003 10:20:11 -0500 Received: from wiprom2mx1.wipro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21666 for ; Fri, 24 Jan 2003 10:00:35 -0500 (EST) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h0OF40v07579 for ; Fri, 24 Jan 2003 20:34:00 +0530 (IST) Received: from blr-ec-msg02.wipro.com ([10.200.51.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 24 Jan 2003 20:33:55 +0530 Received: from wipro.com ([192.168.178.243]) by blr-ec-msg02.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 24 Jan 2003 20:33:55 +0530 Message-ID: <3E3156D7.C84ED8AD@wipro.com> Date: Fri, 24 Jan 2003 20:38:07 +0530 From: Shashi Kumar Organization: Wipro Technologies X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen CC: Megaco Subject: Re: [Megaco] Can an MG ever subtract an ephemeral termination ? References: <3E314AC1.79AC798C@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2003 15:03:55.0348 (UTC) FILETIME=[D074D940:01C2C3B9] 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 whatever may be the scenario, protocol has no provision to allow MG take it's own decision on subtracting a termination from a context. Shashi Flemming Andreasen wrote: > > Barring reboots, memory loss and similar things, can an ephemeral > termination ever be subtracted from a Context ? For example, let's say I > have an RTP termination, and the underlying IP interface disappears. I > assume I'd have to generate a ServiceChange for this ephemeral, but > would it be valid for the MG to also Subtract (i.e. destroy) the > ephemeral ? > > Thanks > > Flemming > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Jan 24 10:08:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22018 for ; Fri, 24 Jan 2003 10:08:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OFRjP05620 for megaco-archive@odin.ietf.org; Fri, 24 Jan 2003 10:27:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OFRjJ05617 for ; Fri, 24 Jan 2003 10:27:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21990 for ; Fri, 24 Jan 2003 10:08:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OFN8J05377; Fri, 24 Jan 2003 10:23:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OFKBJ05184 for ; Fri, 24 Jan 2003 10:20:11 -0500 Received: from wiprom2mx1.wipro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21666 for ; Fri, 24 Jan 2003 10:00:35 -0500 (EST) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h0OF40v07579 for ; Fri, 24 Jan 2003 20:34:00 +0530 (IST) Received: from blr-ec-msg02.wipro.com ([10.200.51.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 24 Jan 2003 20:33:55 +0530 Received: from wipro.com ([192.168.178.243]) by blr-ec-msg02.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 24 Jan 2003 20:33:55 +0530 Message-ID: <3E3156D7.C84ED8AD@wipro.com> Date: Fri, 24 Jan 2003 20:38:07 +0530 From: Shashi Kumar Organization: Wipro Technologies X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen CC: Megaco Subject: Re: [Megaco] Can an MG ever subtract an ephemeral termination ? References: <3E314AC1.79AC798C@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2003 15:03:55.0348 (UTC) FILETIME=[D074D940:01C2C3B9] Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit whatever may be the scenario, protocol has no provision to allow MG take it's own decision on subtracting a termination from a context. Shashi Flemming Andreasen wrote: > > Barring reboots, memory loss and similar things, can an ephemeral > termination ever be subtracted from a Context ? For example, let's say I > have an RTP termination, and the underlying IP interface disappears. I > assume I'd have to generate a ServiceChange for this ephemeral, but > would it be valid for the MG to also Subtract (i.e. destroy) the > ephemeral ? > > Thanks > > Flemming > > _______________________________________________ > 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 Sat Jan 25 06:44:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23109 for ; Sat, 25 Jan 2003 06:44:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PBxXJ17611; Sat, 25 Jan 2003 06:59:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PBYjJ16553 for ; Sat, 25 Jan 2003 06:34:45 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22827 for ; Sat, 25 Jan 2003 06:14:44 -0500 (EST) From: ckaushik@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0PBGsj08050 for ; Sat, 25 Jan 2003 16:46:54 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0PBGrM08043; Sat, 25 Jan 2003 16:46:53 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h0PBJ7908370; Sat, 25 Jan 2003 16:49:09 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CB9.003D67D9 ; Sat, 25 Jan 2003 16:40:42 +0530 X-Lotus-FromDomain: HSS To: Christian Groves , megaco@ietf.org Message-ID: <65256CB9.003D66D8.00@sandesh.hss.hns.com> Date: Sat, 25 Jan 2003 16:50:27 +0530 Subject: Re: [Megaco] ALL in Topology descriptor and CHOOSE in command Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Christian/List, Extending this discussion further pls consider the following scenarios: **C1, C2 and C3 are three commands in the same action as the Topology Descriptor** 1. Topology={T1,T2,isolate,T1,T3,oneway,T1,T4,bothway},C1,C2,C3 As per the discussions held on mailing list earlier: (a) Topology descriptor will be executed in the beginning and before any of the commands C1,C2 or C3 are executed. (b) If any error occurs in the execution of the Topology descriptor, a Context Level Error is sent in the response and non of the commands in the action i.e. C1, C2 or C3 get executed. 2. Topology={T1,T2,isolate,$,T1,oneway,T1,T3,oneway},C1,C2,Add=${Media..., Event..., Signal...} (a) Topologies T1,T2,isolate and T1,T3,oneway will be applied before execution of commands C1, C2 and Add=$. Topology $,T1,oneway gets executed once the execution of Add=$ is complete. (b) If execution of Topology $,T1,oneway fails a Command Level response is sent at the same level where the command Add=$ is present. I have the following queries regarding the above scenarios: - 1. Does the execution of all the Topology triples determine the final result of the execution of Topology Descriptor OR Are the Topology Triples considered to be independent of each other and the result of execution of one does not affect the other? 2. In the second bullet above, if execution of Topology $,T1,oneway fails, what happens to the commands C1, C2 and Topologies T1,T2,isolate and T1,T3,oneway. These commands and Topologies have already been executed before the failure of Topology $,T1,oneway. Does the MG send a Success response for commands C1, C2 and Topologies T1,T2,isolate and T1,T3,oneway and an error response for Topology $,T1,oneway OR Is the MG expected to do a rollback for commands C1, C2 and topologies already executed and send an error response for the same. Pls clarify. Regards, Chintan... www.hssworld.com shbansal@hss.hns.com on 01/24/2003 02:36:53 PM To: Christian Groves cc: manfred.volz@nokia.com, megaco@ietf.org (bcc: Chintan Kaushik/HSS) Subject: Re: [Megaco] ALL in Topology descriptor and CHOOSE in command Hi Chris, In earlier mails it was stated that Section 7.1.18 means that you must consider the topology descriptor before addressing the commands. You should then use the information that is in the topology descriptor when you process the commands in the message. Now with this implementation the final result should be T1 is isolated from T2 and T1 is isolated from T3 and T2 is bothway connected to T3 Correct me if I have some wrong interpretation Thanks and regards Shobhit Christian Groves on 01/22/2003 05:36:36 AM To: manfred.volz@nokia.com cc: megaco@ietf.org (bcc: Shobhit Bansal/HSS) Subject: Re: [Megaco] ALL in Topology descriptor and CHOOSE in command Hello Manfred, In accordance to 7.1.18 "The Topology descriptor occurs before the commands in an action." it would be b). Christian manfred.volz@NOKIA.COM wrote: > > Hi all, > > Let's assume we have 2 terminations T1 and T2 which are oneway connected. > Now we add a new termination T3 with the following topology settings. > > Topology (T1,ALL,isolate) > ADD $ > > Which of the following results is correct? > > a.) T1 is isolated from T2 and > T1 is isolated from T3 and > T2 is bothway connected to T3 > b.) T1 is isolated from T2 and > T1 is bothway connected to T3 and > T2 is bothway connected to T3 > > Thanks for your help. > > best regards Manfred > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Sat Jan 25 06:44:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23128 for ; Sat, 25 Jan 2003 06:44:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0PC47g17743 for megaco-archive@odin.ietf.org; Sat, 25 Jan 2003 07:04:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PC47J17740 for ; Sat, 25 Jan 2003 07:04:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23120 for ; Sat, 25 Jan 2003 06:44:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PBxXJ17611; Sat, 25 Jan 2003 06:59:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PBYjJ16553 for ; Sat, 25 Jan 2003 06:34:45 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22827 for ; Sat, 25 Jan 2003 06:14:44 -0500 (EST) From: ckaushik@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0PBGsj08050 for ; Sat, 25 Jan 2003 16:46:54 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0PBGrM08043; Sat, 25 Jan 2003 16:46:53 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h0PBJ7908370; Sat, 25 Jan 2003 16:49:09 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CB9.003D67D9 ; Sat, 25 Jan 2003 16:40:42 +0530 X-Lotus-FromDomain: HSS To: Christian Groves , megaco@ietf.org Message-ID: <65256CB9.003D66D8.00@sandesh.hss.hns.com> Date: Sat, 25 Jan 2003 16:50:27 +0530 Subject: Re: [Megaco] ALL in Topology descriptor and CHOOSE in command Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Christian/List, Extending this discussion further pls consider the following scenarios: **C1, C2 and C3 are three commands in the same action as the Topology Descriptor** 1. Topology={T1,T2,isolate,T1,T3,oneway,T1,T4,bothway},C1,C2,C3 As per the discussions held on mailing list earlier: (a) Topology descriptor will be executed in the beginning and before any of the commands C1,C2 or C3 are executed. (b) If any error occurs in the execution of the Topology descriptor, a Context Level Error is sent in the response and non of the commands in the action i.e. C1, C2 or C3 get executed. 2. Topology={T1,T2,isolate,$,T1,oneway,T1,T3,oneway},C1,C2,Add=${Media..., Event..., Signal...} (a) Topologies T1,T2,isolate and T1,T3,oneway will be applied before execution of commands C1, C2 and Add=$. Topology $,T1,oneway gets executed once the execution of Add=$ is complete. (b) If execution of Topology $,T1,oneway fails a Command Level response is sent at the same level where the command Add=$ is present. I have the following queries regarding the above scenarios: - 1. Does the execution of all the Topology triples determine the final result of the execution of Topology Descriptor OR Are the Topology Triples considered to be independent of each other and the result of execution of one does not affect the other? 2. In the second bullet above, if execution of Topology $,T1,oneway fails, what happens to the commands C1, C2 and Topologies T1,T2,isolate and T1,T3,oneway. These commands and Topologies have already been executed before the failure of Topology $,T1,oneway. Does the MG send a Success response for commands C1, C2 and Topologies T1,T2,isolate and T1,T3,oneway and an error response for Topology $,T1,oneway OR Is the MG expected to do a rollback for commands C1, C2 and topologies already executed and send an error response for the same. Pls clarify. Regards, Chintan... www.hssworld.com shbansal@hss.hns.com on 01/24/2003 02:36:53 PM To: Christian Groves cc: manfred.volz@nokia.com, megaco@ietf.org (bcc: Chintan Kaushik/HSS) Subject: Re: [Megaco] ALL in Topology descriptor and CHOOSE in command Hi Chris, In earlier mails it was stated that Section 7.1.18 means that you must consider the topology descriptor before addressing the commands. You should then use the information that is in the topology descriptor when you process the commands in the message. Now with this implementation the final result should be T1 is isolated from T2 and T1 is isolated from T3 and T2 is bothway connected to T3 Correct me if I have some wrong interpretation Thanks and regards Shobhit Christian Groves on 01/22/2003 05:36:36 AM To: manfred.volz@nokia.com cc: megaco@ietf.org (bcc: Shobhit Bansal/HSS) Subject: Re: [Megaco] ALL in Topology descriptor and CHOOSE in command Hello Manfred, In accordance to 7.1.18 "The Topology descriptor occurs before the commands in an action." it would be b). Christian manfred.volz@NOKIA.COM wrote: > > Hi all, > > Let's assume we have 2 terminations T1 and T2 which are oneway connected. > Now we add a new termination T3 with the following topology settings. > > Topology (T1,ALL,isolate) > ADD $ > > Which of the following results is correct? > > a.) T1 is isolated from T2 and > T1 is isolated from T3 and > T2 is bothway connected to T3 > b.) T1 is isolated from T2 and > T1 is bothway connected to T3 and > T2 is bothway connected to T3 > > Thanks for your help. > > best regards Manfred > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Jan 27 15:16:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25269 for ; Mon, 27 Jan 2003 15:16:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RKUlJ14655; Mon, 27 Jan 2003 15:30:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RKPOJ14492 for ; Mon, 27 Jan 2003 15:25:24 -0500 Received: from zrtps06s.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24966 for ; Mon, 27 Jan 2003 15:04:17 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0RK7jg08631 for ; Mon, 27 Jan 2003 15:07:45 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Jan 2003 15:07:40 -0500 Message-ID: From: "Kevin Boyle" To: John Stock , "'megaco@ietf.org'" Subject: RE: [Megaco] RE: Glare condition when using embedded descriptors Date: Mon, 27 Jan 2003 15:07:38 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Actually, the offhook IS sent. Just because it has embedded descriptors does not relieve the MG of its responsibility to report detected events. Kevin -----Original Message----- From: John Stock [mailto:John.Stock@afc.com] Sent: Wednesday, January 22, 2003 5:32 PM To: John Stock; 'megaco@ietf.org' Subject: [Megaco] RE: Glare condition when using embedded descriptors Actually I just remember that an offhook event is not sent to the MG in the case of embedded descriptors. However this actually exacerbates the problem - there is actually a very large widow where this glare condition can occur. I'm certain this must have been discussed at some point, though couldn't find anything in looking through past emails. If such a discussion has taken place, can someone point me to the email thread? Thanks. > -----Original Message----- > From: John Stock > Sent: Wednesday, January 22, 2003 2:25 PM > To: 'megaco@ietf.org' > Subject: Glare condition when using embedded descriptors > > Hi all, > > I was wondering about handling of this situation: > > - Embedded descriptors are used, such that when a user goes offhook, > the MG will provide dialtone and begin digit collection without > waiting for additional signals from the MGC > - A glare condition happens, such that a ring-in on the phone from the > MGC side occurs at the same time as the offhook, such that the MG > sends the offhook notification before receiving the Add command on the > ring-in. > - Thus the MG will begin dial tone before getting the Add, and will cease > it when connecting the physical termination to the incoming call. > - The MGC will receive the offhook notification after sending the Add > command for the ring-in, thus sees it simply as a user answering a > terminating call. > > My questions are these: > > - Is it proper to handle it this way, such that the subscriber is > connected to the incoming call, instead of the alternative which is to > block the incoming call and to provide dial tone and collect digits > from the subscriber for a separate outgoing call? I believe this is > the way it works with other protocols, such as Q.931 in GR303. > - The odd thing is the brief spurt of dial tone, which may be > exacerbated by any MGC<->MG messaging delay. Does anyone know > anything that's proposed for handling this? Though it's probably not > a big deal since one would expect this to happen very very seldomly. > An obvious solution is to not use the embedded descriptors, however > this then of course removes the benefits of doing such. Another > solution may be to have the MG wait for the Reply to the offhook > before providing dial tone, but this is kind of complex because the > Reply handling may be in a completely different entity and level than > event/signal handling. > > Thanks. > > John Stock > Systems Engineering > Advanced Fibre Communications > john.stock@afc.com > 707-792-6249 > > This message (including any attachments) is intended only for the use > of the named addressee(s), and may contain information that is legally > privileged, confidential or exempt from disclosure under applicable > law. If you are not a named addressee, you are hereby notified that > any use, dissemination, distribution or copying of this message is > strictly prohibited. If you have received this message in error, > please notify the original sender immediately by telephone or by > return E-mail and delete this message, along with any attachments, > from your computer. Thank you. > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Jan 27 15:17:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25286 for ; Mon, 27 Jan 2003 15:17:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RKbhm15609 for megaco-archive@odin.ietf.org; Mon, 27 Jan 2003 15:37:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RKbhJ15606 for ; Mon, 27 Jan 2003 15:37:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25283 for ; Mon, 27 Jan 2003 15:16:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RKUlJ14655; Mon, 27 Jan 2003 15:30:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RKPOJ14492 for ; Mon, 27 Jan 2003 15:25:24 -0500 Received: from zrtps06s.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24966 for ; Mon, 27 Jan 2003 15:04:17 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0RK7jg08631 for ; Mon, 27 Jan 2003 15:07:45 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Jan 2003 15:07:40 -0500 Message-ID: From: "Kevin Boyle" To: John Stock , "'megaco@ietf.org'" Subject: RE: [Megaco] RE: Glare condition when using embedded descriptors Date: Mon, 27 Jan 2003 15:07:38 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Actually, the offhook IS sent. Just because it has embedded descriptors does not relieve the MG of its responsibility to report detected events. Kevin -----Original Message----- From: John Stock [mailto:John.Stock@afc.com] Sent: Wednesday, January 22, 2003 5:32 PM To: John Stock; 'megaco@ietf.org' Subject: [Megaco] RE: Glare condition when using embedded descriptors Actually I just remember that an offhook event is not sent to the MG in the case of embedded descriptors. However this actually exacerbates the problem - there is actually a very large widow where this glare condition can occur. I'm certain this must have been discussed at some point, though couldn't find anything in looking through past emails. If such a discussion has taken place, can someone point me to the email thread? Thanks. > -----Original Message----- > From: John Stock > Sent: Wednesday, January 22, 2003 2:25 PM > To: 'megaco@ietf.org' > Subject: Glare condition when using embedded descriptors > > Hi all, > > I was wondering about handling of this situation: > > - Embedded descriptors are used, such that when a user goes offhook, > the MG will provide dialtone and begin digit collection without > waiting for additional signals from the MGC > - A glare condition happens, such that a ring-in on the phone from the > MGC side occurs at the same time as the offhook, such that the MG > sends the offhook notification before receiving the Add command on the > ring-in. > - Thus the MG will begin dial tone before getting the Add, and will cease > it when connecting the physical termination to the incoming call. > - The MGC will receive the offhook notification after sending the Add > command for the ring-in, thus sees it simply as a user answering a > terminating call. > > My questions are these: > > - Is it proper to handle it this way, such that the subscriber is > connected to the incoming call, instead of the alternative which is to > block the incoming call and to provide dial tone and collect digits > from the subscriber for a separate outgoing call? I believe this is > the way it works with other protocols, such as Q.931 in GR303. > - The odd thing is the brief spurt of dial tone, which may be > exacerbated by any MGC<->MG messaging delay. Does anyone know > anything that's proposed for handling this? Though it's probably not > a big deal since one would expect this to happen very very seldomly. > An obvious solution is to not use the embedded descriptors, however > this then of course removes the benefits of doing such. Another > solution may be to have the MG wait for the Reply to the offhook > before providing dial tone, but this is kind of complex because the > Reply handling may be in a completely different entity and level than > event/signal handling. > > Thanks. > > John Stock > Systems Engineering > Advanced Fibre Communications > john.stock@afc.com > 707-792-6249 > > This message (including any attachments) is intended only for the use > of the named addressee(s), and may contain information that is legally > privileged, confidential or exempt from disclosure under applicable > law. If you are not a named addressee, you are hereby notified that > any use, dissemination, distribution or copying of this message is > strictly prohibited. If you have received this message in error, > please notify the original sender immediately by telephone or by > return E-mail and delete this message, along with any attachments, > from your computer. Thank you. > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 28 12:46:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02130 for ; Tue, 28 Jan 2003 12:46:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SI0FJ06092; Tue, 28 Jan 2003 13:00:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SHs3J05830 for ; Tue, 28 Jan 2003 12:54:03 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01709 for ; Tue, 28 Jan 2003 12:32:28 -0500 (EST) From: svkumar@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0SHYbj01529 for ; Tue, 28 Jan 2003 23:04:38 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0SHYaM01525 for ; Tue, 28 Jan 2003 23:04:36 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h0SHar612428 for ; Tue, 28 Jan 2003 23:06:53 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CBC.005FFE66 ; Tue, 28 Jan 2003 22:58:30 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CBC.005FFDB3.00@sandesh.hss.hns.com> Date: Tue, 28 Jan 2003 23:08:16 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Auditing for list of context ids and termination ids Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 I wanted to confirm the following request/response PDUs for auditing to fetch the list of Context Ids and optionally the list of terminations in each context. If the MGC wishes to get a list of all context Ids and the terminations in these contexts, then the MGC should send an Audit command for ALL (this doesnt include NULL) contexts, with termination id as *. So as per Sec 7.2.5 of the RFC, will the request PDU look like the following ? MEGACO/1[123.231.111] Transaction = 24 { Context = * { AuditValue = * { Audit { } }}} And the response something like MEGACO/1[112.114.112] Reply = 24{ Context = 3 { AuditValue=Context {phy1, eph1} }, context = 4 { AuditValue=Context {phy2, eph2,eph3} }, context = 6{ AuditValue=Context {phy4,phy5,, eph1} } } Sending the Termination id list is triggered by the fact that in the Request, the Audit descriptor is empty. Again, as per Sec 7.2.5. Now if I dont want the list of termination ids, then, in the Transaction request, the Termination audited for is ROOT (instead of *). The protocol says that it should return the list of context ids (sec 7.2.5) , but there is no clear information as to what the reply looks like. I wanted to confirm if this is correct and the PDU would look like MEGACO/1[112.114.112] Reply = 24{ Context = 3 { AuditValue }, context = 4 { AuditValue }, context = 6{{114.112]f AuditValue } } Please comment. Regards Shiv Kumar Hughes Software Systems DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 28 12:46:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02151 for ; Tue, 28 Jan 2003 12:46:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SI81807050 for megaco-archive@odin.ietf.org; Tue, 28 Jan 2003 13:08:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SI81J07047 for ; Tue, 28 Jan 2003 13:08:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02145 for ; Tue, 28 Jan 2003 12:46:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SI0FJ06092; Tue, 28 Jan 2003 13:00:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SHs3J05830 for ; Tue, 28 Jan 2003 12:54:03 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01709 for ; Tue, 28 Jan 2003 12:32:28 -0500 (EST) From: svkumar@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0SHYbj01529 for ; Tue, 28 Jan 2003 23:04:38 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0SHYaM01525 for ; Tue, 28 Jan 2003 23:04:36 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h0SHar612428 for ; Tue, 28 Jan 2003 23:06:53 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CBC.005FFE66 ; Tue, 28 Jan 2003 22:58:30 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CBC.005FFDB3.00@sandesh.hss.hns.com> Date: Tue, 28 Jan 2003 23:08:16 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Auditing for list of context ids and termination ids Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 I wanted to confirm the following request/response PDUs for auditing to fetch the list of Context Ids and optionally the list of terminations in each context. If the MGC wishes to get a list of all context Ids and the terminations in these contexts, then the MGC should send an Audit command for ALL (this doesnt include NULL) contexts, with termination id as *. So as per Sec 7.2.5 of the RFC, will the request PDU look like the following ? MEGACO/1[123.231.111] Transaction = 24 { Context = * { AuditValue = * { Audit { } }}} And the response something like MEGACO/1[112.114.112] Reply = 24{ Context = 3 { AuditValue=Context {phy1, eph1} }, context = 4 { AuditValue=Context {phy2, eph2,eph3} }, context = 6{ AuditValue=Context {phy4,phy5,, eph1} } } Sending the Termination id list is triggered by the fact that in the Request, the Audit descriptor is empty. Again, as per Sec 7.2.5. Now if I dont want the list of termination ids, then, in the Transaction request, the Termination audited for is ROOT (instead of *). The protocol says that it should return the list of context ids (sec 7.2.5) , but there is no clear information as to what the reply looks like. I wanted to confirm if this is correct and the PDU would look like MEGACO/1[112.114.112] Reply = 24{ Context = 3 { AuditValue }, context = 4 { AuditValue }, context = 6{{114.112]f AuditValue } } Please comment. Regards Shiv Kumar Hughes Software Systems DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 28 13:47:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03445 for ; Tue, 28 Jan 2003 13:47:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJ5NJ09898; Tue, 28 Jan 2003 14:05:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJ26J09761 for ; Tue, 28 Jan 2003 14:02:06 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03346 for ; Tue, 28 Jan 2003 13:40:28 -0500 (EST) From: ckaushik@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0SIgcj07561 for ; Wed, 29 Jan 2003 00:12:38 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0SIgbM07557 for ; Wed, 29 Jan 2003 00:12:37 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h0SIisb14309 for ; Wed, 29 Jan 2003 00:14:54 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CBC.00663496 ; Wed, 29 Jan 2003 00:06:21 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CBC.00663395.00@sandesh.hss.hns.com> Date: Wed, 29 Jan 2003 00:16:08 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Query regarding ActionReply syntax Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, According to Protocol's ABNF grammar, following syntax for ActionReply is allowed: - actionReply = CtxToken EQUAL ContextID LBRKT ( errorDescriptor / commandReply ) / (commandReply COMMA errorDescriptor) ) RBRKT. Can anyone pls elaborate the purpose of including "commandReply COMMA errorDescriptor" syntax. Regards, Chintan... www.hssworld.com DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 28 13:47:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03467 for ; Tue, 28 Jan 2003 13:47:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SJ93R10661 for megaco-archive@odin.ietf.org; Tue, 28 Jan 2003 14:09:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJ93J10658 for ; Tue, 28 Jan 2003 14:09:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03459 for ; Tue, 28 Jan 2003 13:47:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJ5NJ09898; Tue, 28 Jan 2003 14:05:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJ26J09761 for ; Tue, 28 Jan 2003 14:02:06 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03346 for ; Tue, 28 Jan 2003 13:40:28 -0500 (EST) From: ckaushik@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0SIgcj07561 for ; Wed, 29 Jan 2003 00:12:38 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0SIgbM07557 for ; Wed, 29 Jan 2003 00:12:37 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h0SIisb14309 for ; Wed, 29 Jan 2003 00:14:54 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CBC.00663496 ; Wed, 29 Jan 2003 00:06:21 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CBC.00663395.00@sandesh.hss.hns.com> Date: Wed, 29 Jan 2003 00:16:08 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Query regarding ActionReply syntax Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, According to Protocol's ABNF grammar, following syntax for ActionReply is allowed: - actionReply = CtxToken EQUAL ContextID LBRKT ( errorDescriptor / commandReply ) / (commandReply COMMA errorDescriptor) ) RBRKT. Can anyone pls elaborate the purpose of including "commandReply COMMA errorDescriptor" syntax. Regards, Chintan... www.hssworld.com DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 28 14:15:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04243 for ; Tue, 28 Jan 2003 14:15:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJTSJ11650; Tue, 28 Jan 2003 14:29:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJR1J11547 for ; Tue, 28 Jan 2003 14:27:01 -0500 Received: from sparky.afc.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03915 for ; Tue, 28 Jan 2003 14:05:23 -0500 (EST) Received: (qmail 19993 invoked from network); 28 Jan 2003 19:04:38 -0000 Received: from unknown (HELO zzzconn03.fibre.com) (10.1.4.53) by 0 with SMTP; 28 Jan 2003 19:04:38 -0000 Received: FROM xconn01.fibre.com BY zzzconn03.fibre.com ; Tue Jan 28 11:09:16 2003 -0800 Received: by xconn01.fibre.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Jan 2003 11:08:04 -0800 Message-ID: From: John Stock To: "'Kevin Boyle'" , "'megaco@ietf.org'" Subject: RE: [Megaco] RE: Glare condition when using embedded descriptors Date: Tue, 28 Jan 2003 11:08:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C700.B31F5E20" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2C700.B31F5E20 Content-Type: text/plain; charset="iso-8859-1" The only place in the spec that I can see this addressed is in the example call flow. At the bottom of step 5, it says: Note that the embedded EventsDescriptor could have been used to combine steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7. Since steps 6 and 7 are the offhook Notify and its corresponding Reply, this to me means that there is not an intent to send the offhook as an observed event. Please let me know if there's somewhere else in the spec or annexes that addresses this, I haven't been able to find anything. Thanks. John -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] Sent: Monday, January 27, 2003 12:08 PM To: John Stock; 'megaco@ietf.org' Subject: RE: [Megaco] RE: Glare condition when using embedded descriptors Actually, the offhook IS sent. Just because it has embedded descriptors does not relieve the MG of its responsibility to report detected events. Kevin -----Original Message----- From: John Stock [ mailto:John.Stock@afc.com ] Sent: Wednesday, January 22, 2003 5:32 PM To: John Stock; 'megaco@ietf.org' Subject: [Megaco] RE: Glare condition when using embedded descriptors Actually I just remember that an offhook event is not sent to the MG in the case of embedded descriptors. However this actually exacerbates the problem - there is actually a very large widow where this glare condition can occur. I'm certain this must have been discussed at some point, though couldn't find anything in looking through past emails. If such a discussion has taken place, can someone point me to the email thread? Thanks. > -----Original Message----- > From: John Stock > Sent: Wednesday, January 22, 2003 2:25 PM > To: 'megaco@ietf.org' > Subject: Glare condition when using embedded descriptors > > Hi all, > > I was wondering about handling of this situation: > > - Embedded descriptors are used, such that when a user goes offhook, > the MG will provide dialtone and begin digit collection without > waiting for additional signals from the MGC > - A glare condition happens, such that a ring-in on the phone from the > MGC side occurs at the same time as the offhook, such that the MG > sends the offhook notification before receiving the Add command on the > ring-in. > - Thus the MG will begin dial tone before getting the Add, and will cease > it when connecting the physical termination to the incoming call. > - The MGC will receive the offhook notification after sending the Add > command for the ring-in, thus sees it simply as a user answering a > terminating call. > > My questions are these: > > - Is it proper to handle it this way, such that the subscriber is > connected to the incoming call, instead of the alternative which is to > block the incoming call and to provide dial tone and collect digits > from the subscriber for a separate outgoing call? I believe this is > the way it works with other protocols, such as Q.931 in GR303. > - The odd thing is the brief spurt of dial tone, which may be > exacerbated by any MGC<->MG messaging delay. Does anyone know > anything that's proposed for handling this? Though it's probably not > a big deal since one would expect this to happen very very seldomly. > An obvious solution is to not use the embedded descriptors, however > this then of course removes the benefits of doing such. Another > solution may be to have the MG wait for the Reply to the offhook > before providing dial tone, but this is kind of complex because the > Reply handling may be in a completely different entity and level than > event/signal handling. > > Thanks. > > John Stock > Systems Engineering > Advanced Fibre Communications > john.stock@afc.com > 707-792-6249 > > This message (including any attachments) is intended only for the use > of the named addressee(s), and may contain information that is legally > privileged, confidential or exempt from disclosure under applicable > law. If you are not a named addressee, you are hereby notified that > any use, dissemination, distribution or copying of this message is > strictly prohibited. If you have received this message in error, > please notify the original sender immediately by telephone or by > return E-mail and delete this message, along with any attachments, > from your computer. Thank you. > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C2C700.B31F5E20 Content-Type: text/html; charset="iso-8859-1" RE: [Megaco] RE: Glare condition when using embedded descriptors
The only place in the spec that I can see this addressed is in the example call flow.  At the bottom of step 5, it says:
 
Note that the embedded EventsDescriptor could have been used to combine steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7.
 
Since steps 6 and 7 are the offhook Notify and its corresponding Reply, this to me means that there is not an intent to send the offhook as an observed event.
 
Please let me know if there's somewhere else in the spec or annexes that addresses this, I haven't been able to find anything.  Thanks.
 
John
 
-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Monday, January 27, 2003 12:08 PM
To: John Stock; 'megaco@ietf.org'
Subject: RE: [Megaco] RE: Glare condition when using embedded descriptors

Actually, the offhook IS sent.  Just because it has embedded descriptors does not relieve the MG of its responsibility to report detected events.

Kevin

-----Original Message-----
From: John Stock [mailto:John.Stock@afc.com]
Sent: Wednesday, January 22, 2003 5:32 PM
To: John Stock; 'megaco@ietf.org'
Subject: [Megaco] RE: Glare condition when using embedded descriptors


Actually I just remember that an offhook event is not sent to the MG in the case of embedded descriptors.

However this actually exacerbates the problem - there is actually a very large widow where this glare condition can occur.  I'm certain this must have been discussed at some point, though couldn't find anything in looking through past emails.  If such a discussion has taken place, can someone point me to the email thread?

Thanks.

>  -----Original Message-----
> From:         John Stock 
> Sent: Wednesday, January 22, 2003 2:25 PM
> To:   'megaco@ietf.org'
> Subject:      Glare condition when using embedded descriptors
>
> Hi all,
>
> I was wondering about handling of this situation:
>
> - Embedded descriptors are used, such that when a user goes offhook,
> the MG will provide dialtone and begin digit collection without
> waiting for additional signals from the MGC
> - A glare condition happens, such that a ring-in on the phone from the
> MGC side occurs at the same time as the offhook, such that the MG
> sends the offhook notification before receiving the Add command on the
> ring-in.
> - Thus the MG will begin dial tone before getting the Add, and will cease
> it when connecting the physical termination to the incoming call.
> - The MGC will receive the offhook notification after sending the Add
> command for the ring-in, thus sees it simply as a user answering a
> terminating call.
>
> My questions are these:
>
> - Is it proper to handle it this way, such that the subscriber is
> connected to the incoming call, instead of the alternative which is to
> block the incoming call and to provide dial tone and collect digits
> from the subscriber for a separate outgoing call?  I believe this is
> the way it works with other protocols, such as Q.931 in GR303.
> - The odd thing is the brief spurt of dial tone, which may be
> exacerbated by any MGC<->MG messaging delay.  Does anyone know
> anything that's proposed for handling this?  Though it's probably not
> a big deal since one would expect this to happen very very seldomly. 
> An obvious solution is to not use the embedded descriptors, however
> this then of course removes the benefits of doing such.  Another
> solution may be to have the MG wait for the Reply to the offhook
> before providing dial tone, but this is kind of complex because the
> Reply handling may be in a completely different entity and level than
> event/signal handling.
>
> Thanks.
>
> John Stock
> Systems Engineering
> Advanced Fibre Communications
> john.stock@afc.com
> 707-792-6249
>
> This message (including any attachments) is intended only for the use
> of the named addressee(s), and may contain information that is legally
> privileged, confidential or exempt from disclosure under applicable
> law. If you are not a named addressee, you are hereby notified that
> any use, dissemination, distribution or copying of this message is
> strictly prohibited. If you have received this message in error,
> please notify the original sender immediately by telephone or by
> return E-mail and delete this message, along with any attachments,
> from your computer. Thank you.
>
>
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

------_=_NextPart_001_01C2C700.B31F5E20-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 28 14:15:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04265 for ; Tue, 28 Jan 2003 14:15:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SJaeJ11971 for megaco-archive@odin.ietf.org; Tue, 28 Jan 2003 14:36:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJaeJ11968 for ; Tue, 28 Jan 2003 14:36:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04257 for ; Tue, 28 Jan 2003 14:15:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJTSJ11650; Tue, 28 Jan 2003 14:29:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJR1J11547 for ; Tue, 28 Jan 2003 14:27:01 -0500 Received: from sparky.afc.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03915 for ; Tue, 28 Jan 2003 14:05:23 -0500 (EST) Received: (qmail 19993 invoked from network); 28 Jan 2003 19:04:38 -0000 Received: from unknown (HELO zzzconn03.fibre.com) (10.1.4.53) by 0 with SMTP; 28 Jan 2003 19:04:38 -0000 Received: FROM xconn01.fibre.com BY zzzconn03.fibre.com ; Tue Jan 28 11:09:16 2003 -0800 Received: by xconn01.fibre.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Jan 2003 11:08:04 -0800 Message-ID: From: John Stock To: "'Kevin Boyle'" , "'megaco@ietf.org'" Subject: RE: [Megaco] RE: Glare condition when using embedded descriptors Date: Tue, 28 Jan 2003 11:08:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C700.B31F5E20" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2C700.B31F5E20 Content-Type: text/plain; charset="iso-8859-1" The only place in the spec that I can see this addressed is in the example call flow. At the bottom of step 5, it says: Note that the embedded EventsDescriptor could have been used to combine steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7. Since steps 6 and 7 are the offhook Notify and its corresponding Reply, this to me means that there is not an intent to send the offhook as an observed event. Please let me know if there's somewhere else in the spec or annexes that addresses this, I haven't been able to find anything. Thanks. John -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] Sent: Monday, January 27, 2003 12:08 PM To: John Stock; 'megaco@ietf.org' Subject: RE: [Megaco] RE: Glare condition when using embedded descriptors Actually, the offhook IS sent. Just because it has embedded descriptors does not relieve the MG of its responsibility to report detected events. Kevin -----Original Message----- From: John Stock [ mailto:John.Stock@afc.com ] Sent: Wednesday, January 22, 2003 5:32 PM To: John Stock; 'megaco@ietf.org' Subject: [Megaco] RE: Glare condition when using embedded descriptors Actually I just remember that an offhook event is not sent to the MG in the case of embedded descriptors. However this actually exacerbates the problem - there is actually a very large widow where this glare condition can occur. I'm certain this must have been discussed at some point, though couldn't find anything in looking through past emails. If such a discussion has taken place, can someone point me to the email thread? Thanks. > -----Original Message----- > From: John Stock > Sent: Wednesday, January 22, 2003 2:25 PM > To: 'megaco@ietf.org' > Subject: Glare condition when using embedded descriptors > > Hi all, > > I was wondering about handling of this situation: > > - Embedded descriptors are used, such that when a user goes offhook, > the MG will provide dialtone and begin digit collection without > waiting for additional signals from the MGC > - A glare condition happens, such that a ring-in on the phone from the > MGC side occurs at the same time as the offhook, such that the MG > sends the offhook notification before receiving the Add command on the > ring-in. > - Thus the MG will begin dial tone before getting the Add, and will cease > it when connecting the physical termination to the incoming call. > - The MGC will receive the offhook notification after sending the Add > command for the ring-in, thus sees it simply as a user answering a > terminating call. > > My questions are these: > > - Is it proper to handle it this way, such that the subscriber is > connected to the incoming call, instead of the alternative which is to > block the incoming call and to provide dial tone and collect digits > from the subscriber for a separate outgoing call? I believe this is > the way it works with other protocols, such as Q.931 in GR303. > - The odd thing is the brief spurt of dial tone, which may be > exacerbated by any MGC<->MG messaging delay. Does anyone know > anything that's proposed for handling this? Though it's probably not > a big deal since one would expect this to happen very very seldomly. > An obvious solution is to not use the embedded descriptors, however > this then of course removes the benefits of doing such. Another > solution may be to have the MG wait for the Reply to the offhook > before providing dial tone, but this is kind of complex because the > Reply handling may be in a completely different entity and level than > event/signal handling. > > Thanks. > > John Stock > Systems Engineering > Advanced Fibre Communications > john.stock@afc.com > 707-792-6249 > > This message (including any attachments) is intended only for the use > of the named addressee(s), and may contain information that is legally > privileged, confidential or exempt from disclosure under applicable > law. If you are not a named addressee, you are hereby notified that > any use, dissemination, distribution or copying of this message is > strictly prohibited. If you have received this message in error, > please notify the original sender immediately by telephone or by > return E-mail and delete this message, along with any attachments, > from your computer. Thank you. > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C2C700.B31F5E20 Content-Type: text/html; charset="iso-8859-1" RE: [Megaco] RE: Glare condition when using embedded descriptors
The only place in the spec that I can see this addressed is in the example call flow.  At the bottom of step 5, it says:
 
Note that the embedded EventsDescriptor could have been used to combine steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7.
 
Since steps 6 and 7 are the offhook Notify and its corresponding Reply, this to me means that there is not an intent to send the offhook as an observed event.
 
Please let me know if there's somewhere else in the spec or annexes that addresses this, I haven't been able to find anything.  Thanks.
 
John
 
-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Monday, January 27, 2003 12:08 PM
To: John Stock; 'megaco@ietf.org'
Subject: RE: [Megaco] RE: Glare condition when using embedded descriptors

Actually, the offhook IS sent.  Just because it has embedded descriptors does not relieve the MG of its responsibility to report detected events.

Kevin

-----Original Message-----
From: John Stock [mailto:John.Stock@afc.com]
Sent: Wednesday, January 22, 2003 5:32 PM
To: John Stock; 'megaco@ietf.org'
Subject: [Megaco] RE: Glare condition when using embedded descriptors


Actually I just remember that an offhook event is not sent to the MG in the case of embedded descriptors.

However this actually exacerbates the problem - there is actually a very large widow where this glare condition can occur.  I'm certain this must have been discussed at some point, though couldn't find anything in looking through past emails.  If such a discussion has taken place, can someone point me to the email thread?

Thanks.

>  -----Original Message-----
> From:         John Stock 
> Sent: Wednesday, January 22, 2003 2:25 PM
> To:   'megaco@ietf.org'
> Subject:      Glare condition when using embedded descriptors
>
> Hi all,
>
> I was wondering about handling of this situation:
>
> - Embedded descriptors are used, such that when a user goes offhook,
> the MG will provide dialtone and begin digit collection without
> waiting for additional signals from the MGC
> - A glare condition happens, such that a ring-in on the phone from the
> MGC side occurs at the same time as the offhook, such that the MG
> sends the offhook notification before receiving the Add command on the
> ring-in.
> - Thus the MG will begin dial tone before getting the Add, and will cease
> it when connecting the physical termination to the incoming call.
> - The MGC will receive the offhook notification after sending the Add
> command for the ring-in, thus sees it simply as a user answering a
> terminating call.
>
> My questions are these:
>
> - Is it proper to handle it this way, such that the subscriber is
> connected to the incoming call, instead of the alternative which is to
> block the incoming call and to provide dial tone and collect digits
> from the subscriber for a separate outgoing call?  I believe this is
> the way it works with other protocols, such as Q.931 in GR303.
> - The odd thing is the brief spurt of dial tone, which may be
> exacerbated by any MGC<->MG messaging delay.  Does anyone know
> anything that's proposed for handling this?  Though it's probably not
> a big deal since one would expect this to happen very very seldomly. 
> An obvious solution is to not use the embedded descriptors, however
> this then of course removes the benefits of doing such.  Another
> solution may be to have the MG wait for the Reply to the offhook
> before providing dial tone, but this is kind of complex because the
> Reply handling may be in a completely different entity and level than
> event/signal handling.
>
> Thanks.
>
> John Stock
> Systems Engineering
> Advanced Fibre Communications
> john.stock@afc.com
> 707-792-6249
>
> This message (including any attachments) is intended only for the use
> of the named addressee(s), and may contain information that is legally
> privileged, confidential or exempt from disclosure under applicable
> law. If you are not a named addressee, you are hereby notified that
> any use, dissemination, distribution or copying of this message is
> strictly prohibited. If you have received this message in error,
> please notify the original sender immediately by telephone or by
> return E-mail and delete this message, along with any attachments,
> from your computer. Thank you.
>
>
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

------_=_NextPart_001_01C2C700.B31F5E20-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 28 15:19:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06060 for ; Tue, 28 Jan 2003 15:19:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SKb7J16384; Tue, 28 Jan 2003 15:37:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SKXNJ16057 for ; Tue, 28 Jan 2003 15:33:23 -0500 Received: from out001.verizon.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05837 for ; Tue, 28 Jan 2003 15:11:44 -0500 (EST) Received: from verizon.net ([138.89.124.43]) by out001.verizon.net (InterMail vM.5.01.05.20 201-253-122-126-120-20021101) with ESMTP id <20030128201513.UDGI23484.out001.verizon.net@verizon.net>; Tue, 28 Jan 2003 14:15:13 -0600 Message-ID: <3E36E4CB.2090700@verizon.net> Date: Tue, 28 Jan 2003 15:15:07 -0500 From: Terry L Anderson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Stock CC: "'Kevin Boyle'" , "'megaco@ietf.org'" Subject: Re: [Megaco] RE: Glare condition when using embedded descriptors References: Content-Type: multipart/alternative; boundary="------------090702060602080204080006" X-Authentication-Info: Submitted using SMTP AUTH at out001.verizon.net from [138.89.124.43] at Tue, 28 Jan 2003 14:15:12 -0600 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --------------090702060602080204080006 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The note to which you refer in step 3 (not step 5) is misleading and, since it occurs in an Appendix, is not normative. Events matching an active event descriptor (from a command or activated from an embedded events descriptor) always result in a Notify (unless suspended by LockStep or deferred by being absorbed into a current dial string). The note should read more like: Note that the embedded EventsDescriptor could have been used to combine steps 3 and 4 with steps 8 and 9, so that digit collection need not wait for steps 6 and 7. There is no way to activate an embedded events descriptor without triggering an event which also results in a Notify, but the embedded events descriptor allows the new events (and possibly new embedded signals) to be activated without waiting for a Notify, Reply, Command cycle. John Stock wrote: > The only place in the spec that I can see this addressed is in the > example call flow. At the bottom of step 5, it says: > > Note that the embedded EventsDescriptor could have been used to > combine steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7. > > Since steps 6 and 7 are the offhook Notify and its corresponding > Reply, this to me means that there is not an intent to send the > offhook as an observed event. > > Please let me know if there's somewhere else in the spec or annexes > that addresses this, I haven't been able to find anything. Thanks. > > John > > > -----Original Message----- > From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] > Sent: Monday, January 27, 2003 12:08 PM > To: John Stock; 'megaco@ietf.org' > Subject: RE: [Megaco] RE: Glare condition when using embedded > descriptors > > Actually, the offhook IS sent. Just because it has embedded > descriptors does not relieve the MG of its responsibility to > report detected events. > > Kevin > > -----Original Message----- > From: John Stock [mailto:John.Stock@afc.com] > Sent: Wednesday, January 22, 2003 5:32 PM > To: John Stock; 'megaco@ietf.org' > Subject: [Megaco] RE: Glare condition when using embedded descriptors > > > Actually I just remember that an offhook event is not sent to the > MG in the case of embedded descriptors. > > However this actually exacerbates the problem - there is actually > a very large widow where this glare condition can occur. I'm > certain this must have been discussed at some point, though > couldn't find anything in looking through past emails. If such a > discussion has taken place, can someone point me to the email thread? > > Thanks. > > > -----Original Message----- > > From: John Stock > > Sent: Wednesday, January 22, 2003 2:25 PM > > To: 'megaco@ietf.org' > > Subject: Glare condition when using embedded descriptors > > > > Hi all, > > > > I was wondering about handling of this situation: > > > > - Embedded descriptors are used, such that when a user goes > offhook, > > the MG will provide dialtone and begin digit collection without > > waiting for additional signals from the MGC > > - A glare condition happens, such that a ring-in on the phone > from the > > MGC side occurs at the same time as the offhook, such that the MG > > sends the offhook notification before receiving the Add command > on the > > ring-in. > > - Thus the MG will begin dial tone before getting the Add, and > will cease > > it when connecting the physical termination to the incoming call. > > - The MGC will receive the offhook notification after sending > the Add > > command for the ring-in, thus sees it simply as a user answering a > > terminating call. > > > > My questions are these: > > > > - Is it proper to handle it this way, such that the subscriber is > > connected to the incoming call, instead of the alternative which > is to > > block the incoming call and to provide dial tone and collect digits > > from the subscriber for a separate outgoing call? I believe > this is > > the way it works with other protocols, such as Q.931 in GR303. > > - The odd thing is the brief spurt of dial tone, which may be > > exacerbated by any MGC<->MG messaging delay. Does anyone know > > anything that's proposed for handling this? Though it's > probably not > > a big deal since one would expect this to happen very very > seldomly. > > An obvious solution is to not use the embedded descriptors, however > > this then of course removes the benefits of doing such. Another > > solution may be to have the MG wait for the Reply to the offhook > > before providing dial tone, but this is kind of complex because the > > Reply handling may be in a completely different entity and level > than > > event/signal handling. > > > > Thanks. > > > > John Stock > > Systems Engineering > > Advanced Fibre Communications > > john.stock@afc.com > > 707-792-6249 > > > > This message (including any attachments) is intended only for > the use > > of the named addressee(s), and may contain information that is > legally > > privileged, confidential or exempt from disclosure under applicable > > law. If you are not a named addressee, you are hereby notified that > > any use, dissemination, distribution or copying of this message is > > strictly prohibited. If you have received this message in error, > > please notify the original sender immediately by telephone or by > > return E-mail and delete this message, along with any attachments, > > from your computer. Thank you. > > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > -- ------------------------------------------------------- Terry L Anderson tlatla@verizon.net Voice: +1 908.766.4463 Mobile: +1 908.342.9595 http://www.gti.net/tla ------------------------------------------------------- --------------090702060602080204080006 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit The note to which you refer in step 3 (not step 5) is misleading and, since it occurs in an Appendix, is not normative.  Events matching an active event descriptor (from a command or activated from an embedded events descriptor) always result in a Notify (unless suspended by LockStep or deferred by being absorbed into a current dial string).  The note should read more like:
    Note that the embedded EventsDescriptor could have been used to combine steps 3 and 4 with
    steps 8 and 9, so that digit collection need not wait for steps 6 and 7.

There is no way to activate an embedded events descriptor without triggering an event which also results in a Notify, but the embedded events descriptor allows the new events (and possibly new embedded signals) to be activated without waiting for a Notify, Reply, Command cycle.

John Stock wrote:
RE: [Megaco] RE: Glare condition when using embedded descriptors
The only place in the spec that I can see this addressed is in the example call flow.  At the bottom of step 5, it says:
 
Note that the embedded EventsDescriptor could have been used to combine steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7.
 
Since steps 6 and 7 are the offhook Notify and its corresponding Reply, this to me means that there is not an intent to send the offhook as an observed event.
 
Please let me know if there's somewhere else in the spec or annexes that addresses this, I haven't been able to find anything.  Thanks.
 
John
 
-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Monday, January 27, 2003 12:08 PM
To: John Stock; 'megaco@ietf.org'
Subject: RE: [Megaco] RE: Glare condition when using embedded descriptors

Actually, the offhook IS sent.  Just because it has embedded descriptors does not relieve the MG of its responsibility to report detected events.

Kevin

-----Original Message-----
From: John Stock [mailto:John.Stock@afc.com]
Sent: Wednesday, January 22, 2003 5:32 PM
To: John Stock; 'megaco@ietf.org'
Subject: [Megaco] RE: Glare condition when using embedded descriptors


Actually I just remember that an offhook event is not sent to the MG in the case of embedded descriptors.

However this actually exacerbates the problem - there is actually a very large widow where this glare condition can occur.  I'm certain this must have been discussed at some point, though couldn't find anything in looking through past emails.  If such a discussion has taken place, can someone point me to the email thread?

Thanks.

>  -----Original Message-----
> From:         John Stock 
> Sent: Wednesday, January 22, 2003 2:25 PM
> To:   'megaco@ietf.org'
> Subject:      Glare condition when using embedded descriptors
>
> Hi all,
>
> I was wondering about handling of this situation:
>
> - Embedded descriptors are used, such that when a user goes offhook,
> the MG will provide dialtone and begin digit collection without
> waiting for additional signals from the MGC
> - A glare condition happens, such that a ring-in on the phone from the
> MGC side occurs at the same time as the offhook, such that the MG
> sends the offhook notification before receiving the Add command on the
> ring-in.
> - Thus the MG will begin dial tone before getting the Add, and will cease
> it when connecting the physical termination to the incoming call.
> - The MGC will receive the offhook notification after sending the Add
> command for the ring-in, thus sees it simply as a user answering a
> terminating call.
>
> My questions are these:
>
> - Is it proper to handle it this way, such that the subscriber is
> connected to the incoming call, instead of the alternative which is to
> block the incoming call and to provide dial tone and collect digits
> from the subscriber for a separate outgoing call?  I believe this is
> the way it works with other protocols, such as Q.931 in GR303.
> - The odd thing is the brief spurt of dial tone, which may be
> exacerbated by any MGC<->MG messaging delay.  Does anyone know
> anything that's proposed for handling this?  Though it's probably not
> a big deal since one would expect this to happen very very seldomly. 
> An obvious solution is to not use the embedded descriptors, however
> this then of course removes the benefits of doing such.  Another
> solution may be to have the MG wait for the Reply to the offhook
> before providing dial tone, but this is kind of complex because the
> Reply handling may be in a completely different entity and level than
> event/signal handling.
>
> Thanks.
>
> John Stock
> Systems Engineering
> Advanced Fibre Communications
> john.stock@afc.com
> 707-792-6249
>
> This message (including any attachments) is intended only for the use
> of the named addressee(s), and may contain information that is legally
> privileged, confidential or exempt from disclosure under applicable
> law. If you are not a named addressee, you are hereby notified that
> any use, dissemination, distribution or copying of this message is
> strictly prohibited. If you have received this message in error,
> please notify the original sender immediately by telephone or by
> return E-mail and delete this message, along with any attachments,
> from your computer. Thank you.
>
>
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco 


-- 
-------------------------------------------------------
Terry L Anderson                     tlatla@verizon.net
Voice: +1 908.766.4463	        Mobile: +1 908.342.9595
http://www.gti.net/tla
-------------------------------------------------------

--------------090702060602080204080006-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 28 15:19:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06083 for ; Tue, 28 Jan 2003 15:19:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SKex717065 for megaco-archive@odin.ietf.org; Tue, 28 Jan 2003 15:40:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SKexJ17062 for ; Tue, 28 Jan 2003 15:40:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06075 for ; Tue, 28 Jan 2003 15:19:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SKb7J16384; Tue, 28 Jan 2003 15:37:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SKXNJ16057 for ; Tue, 28 Jan 2003 15:33:23 -0500 Received: from out001.verizon.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05837 for ; Tue, 28 Jan 2003 15:11:44 -0500 (EST) Received: from verizon.net ([138.89.124.43]) by out001.verizon.net (InterMail vM.5.01.05.20 201-253-122-126-120-20021101) with ESMTP id <20030128201513.UDGI23484.out001.verizon.net@verizon.net>; Tue, 28 Jan 2003 14:15:13 -0600 Message-ID: <3E36E4CB.2090700@verizon.net> Date: Tue, 28 Jan 2003 15:15:07 -0500 From: Terry L Anderson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Stock CC: "'Kevin Boyle'" , "'megaco@ietf.org'" Subject: Re: [Megaco] RE: Glare condition when using embedded descriptors References: Content-Type: multipart/alternative; boundary="------------090702060602080204080006" X-Authentication-Info: Submitted using SMTP AUTH at out001.verizon.net from [138.89.124.43] at Tue, 28 Jan 2003 14:15:12 -0600 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --------------090702060602080204080006 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The note to which you refer in step 3 (not step 5) is misleading and, since it occurs in an Appendix, is not normative. Events matching an active event descriptor (from a command or activated from an embedded events descriptor) always result in a Notify (unless suspended by LockStep or deferred by being absorbed into a current dial string). The note should read more like: Note that the embedded EventsDescriptor could have been used to combine steps 3 and 4 with steps 8 and 9, so that digit collection need not wait for steps 6 and 7. There is no way to activate an embedded events descriptor without triggering an event which also results in a Notify, but the embedded events descriptor allows the new events (and possibly new embedded signals) to be activated without waiting for a Notify, Reply, Command cycle. John Stock wrote: > The only place in the spec that I can see this addressed is in the > example call flow. At the bottom of step 5, it says: > > Note that the embedded EventsDescriptor could have been used to > combine steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7. > > Since steps 6 and 7 are the offhook Notify and its corresponding > Reply, this to me means that there is not an intent to send the > offhook as an observed event. > > Please let me know if there's somewhere else in the spec or annexes > that addresses this, I haven't been able to find anything. Thanks. > > John > > > -----Original Message----- > From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] > Sent: Monday, January 27, 2003 12:08 PM > To: John Stock; 'megaco@ietf.org' > Subject: RE: [Megaco] RE: Glare condition when using embedded > descriptors > > Actually, the offhook IS sent. Just because it has embedded > descriptors does not relieve the MG of its responsibility to > report detected events. > > Kevin > > -----Original Message----- > From: John Stock [mailto:John.Stock@afc.com] > Sent: Wednesday, January 22, 2003 5:32 PM > To: John Stock; 'megaco@ietf.org' > Subject: [Megaco] RE: Glare condition when using embedded descriptors > > > Actually I just remember that an offhook event is not sent to the > MG in the case of embedded descriptors. > > However this actually exacerbates the problem - there is actually > a very large widow where this glare condition can occur. I'm > certain this must have been discussed at some point, though > couldn't find anything in looking through past emails. If such a > discussion has taken place, can someone point me to the email thread? > > Thanks. > > > -----Original Message----- > > From: John Stock > > Sent: Wednesday, January 22, 2003 2:25 PM > > To: 'megaco@ietf.org' > > Subject: Glare condition when using embedded descriptors > > > > Hi all, > > > > I was wondering about handling of this situation: > > > > - Embedded descriptors are used, such that when a user goes > offhook, > > the MG will provide dialtone and begin digit collection without > > waiting for additional signals from the MGC > > - A glare condition happens, such that a ring-in on the phone > from the > > MGC side occurs at the same time as the offhook, such that the MG > > sends the offhook notification before receiving the Add command > on the > > ring-in. > > - Thus the MG will begin dial tone before getting the Add, and > will cease > > it when connecting the physical termination to the incoming call. > > - The MGC will receive the offhook notification after sending > the Add > > command for the ring-in, thus sees it simply as a user answering a > > terminating call. > > > > My questions are these: > > > > - Is it proper to handle it this way, such that the subscriber is > > connected to the incoming call, instead of the alternative which > is to > > block the incoming call and to provide dial tone and collect digits > > from the subscriber for a separate outgoing call? I believe > this is > > the way it works with other protocols, such as Q.931 in GR303. > > - The odd thing is the brief spurt of dial tone, which may be > > exacerbated by any MGC<->MG messaging delay. Does anyone know > > anything that's proposed for handling this? Though it's > probably not > > a big deal since one would expect this to happen very very > seldomly. > > An obvious solution is to not use the embedded descriptors, however > > this then of course removes the benefits of doing such. Another > > solution may be to have the MG wait for the Reply to the offhook > > before providing dial tone, but this is kind of complex because the > > Reply handling may be in a completely different entity and level > than > > event/signal handling. > > > > Thanks. > > > > John Stock > > Systems Engineering > > Advanced Fibre Communications > > john.stock@afc.com > > 707-792-6249 > > > > This message (including any attachments) is intended only for > the use > > of the named addressee(s), and may contain information that is > legally > > privileged, confidential or exempt from disclosure under applicable > > law. If you are not a named addressee, you are hereby notified that > > any use, dissemination, distribution or copying of this message is > > strictly prohibited. If you have received this message in error, > > please notify the original sender immediately by telephone or by > > return E-mail and delete this message, along with any attachments, > > from your computer. Thank you. > > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > -- ------------------------------------------------------- Terry L Anderson tlatla@verizon.net Voice: +1 908.766.4463 Mobile: +1 908.342.9595 http://www.gti.net/tla ------------------------------------------------------- --------------090702060602080204080006 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit The note to which you refer in step 3 (not step 5) is misleading and, since it occurs in an Appendix, is not normative.  Events matching an active event descriptor (from a command or activated from an embedded events descriptor) always result in a Notify (unless suspended by LockStep or deferred by being absorbed into a current dial string).  The note should read more like:
    Note that the embedded EventsDescriptor could have been used to combine steps 3 and 4 with
    steps 8 and 9, so that digit collection need not wait for steps 6 and 7.

There is no way to activate an embedded events descriptor without triggering an event which also results in a Notify, but the embedded events descriptor allows the new events (and possibly new embedded signals) to be activated without waiting for a Notify, Reply, Command cycle.

John Stock wrote:
RE: [Megaco] RE: Glare condition when using embedded descriptors
The only place in the spec that I can see this addressed is in the example call flow.  At the bottom of step 5, it says:
 
Note that the embedded EventsDescriptor could have been used to combine steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7.
 
Since steps 6 and 7 are the offhook Notify and its corresponding Reply, this to me means that there is not an intent to send the offhook as an observed event.
 
Please let me know if there's somewhere else in the spec or annexes that addresses this, I haven't been able to find anything.  Thanks.
 
John
 
-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Monday, January 27, 2003 12:08 PM
To: John Stock; 'megaco@ietf.org'
Subject: RE: [Megaco] RE: Glare condition when using embedded descriptors

Actually, the offhook IS sent.  Just because it has embedded descriptors does not relieve the MG of its responsibility to report detected events.

Kevin

-----Original Message-----
From: John Stock [mailto:John.Stock@afc.com]
Sent: Wednesday, January 22, 2003 5:32 PM
To: John Stock; 'megaco@ietf.org'
Subject: [Megaco] RE: Glare condition when using embedded descriptors


Actually I just remember that an offhook event is not sent to the MG in the case of embedded descriptors.

However this actually exacerbates the problem - there is actually a very large widow where this glare condition can occur.  I'm certain this must have been discussed at some point, though couldn't find anything in looking through past emails.  If such a discussion has taken place, can someone point me to the email thread?

Thanks.

>  -----Original Message-----
> From:         John Stock 
> Sent: Wednesday, January 22, 2003 2:25 PM
> To:   'megaco@ietf.org'
> Subject:      Glare condition when using embedded descriptors
>
> Hi all,
>
> I was wondering about handling of this situation:
>
> - Embedded descriptors are used, such that when a user goes offhook,
> the MG will provide dialtone and begin digit collection without
> waiting for additional signals from the MGC
> - A glare condition happens, such that a ring-in on the phone from the
> MGC side occurs at the same time as the offhook, such that the MG
> sends the offhook notification before receiving the Add command on the
> ring-in.
> - Thus the MG will begin dial tone before getting the Add, and will cease
> it when connecting the physical termination to the incoming call.
> - The MGC will receive the offhook notification after sending the Add
> command for the ring-in, thus sees it simply as a user answering a
> terminating call.
>
> My questions are these:
>
> - Is it proper to handle it this way, such that the subscriber is
> connected to the incoming call, instead of the alternative which is to
> block the incoming call and to provide dial tone and collect digits
> from the subscriber for a separate outgoing call?  I believe this is
> the way it works with other protocols, such as Q.931 in GR303.
> - The odd thing is the brief spurt of dial tone, which may be
> exacerbated by any MGC<->MG messaging delay.  Does anyone know
> anything that's proposed for handling this?  Though it's probably not
> a big deal since one would expect this to happen very very seldomly. 
> An obvious solution is to not use the embedded descriptors, however
> this then of course removes the benefits of doing such.  Another
> solution may be to have the MG wait for the Reply to the offhook
> before providing dial tone, but this is kind of complex because the
> Reply handling may be in a completely different entity and level than
> event/signal handling.
>
> Thanks.
>
> John Stock
> Systems Engineering
> Advanced Fibre Communications
> john.stock@afc.com
> 707-792-6249
>
> This message (including any attachments) is intended only for the use
> of the named addressee(s), and may contain information that is legally
> privileged, confidential or exempt from disclosure under applicable
> law. If you are not a named addressee, you are hereby notified that
> any use, dissemination, distribution or copying of this message is
> strictly prohibited. If you have received this message in error,
> please notify the original sender immediately by telephone or by
> return E-mail and delete this message, along with any attachments,
> from your computer. Thank you.
>
>
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco 


-- 
-------------------------------------------------------
Terry L Anderson                     tlatla@verizon.net
Voice: +1 908.766.4463	        Mobile: +1 908.342.9595
http://www.gti.net/tla
-------------------------------------------------------

--------------090702060602080204080006-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 28 15:31:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06381 for ; Tue, 28 Jan 2003 15:31:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SKlBJ17416; Tue, 28 Jan 2003 15:47:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SKkwJ17385 for ; Tue, 28 Jan 2003 15:46:58 -0500 Received: from pop017.verizon.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06246 for ; Tue, 28 Jan 2003 15:25:20 -0500 (EST) Received: from verizon.net ([138.89.124.43]) by pop017.verizon.net (InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP id <20030128202851.YKAA10203.pop017.verizon.net@verizon.net>; Tue, 28 Jan 2003 14:28:51 -0600 Message-ID: <3E36E7FD.4080100@verizon.net> Date: Tue, 28 Jan 2003 15:28:45 -0500 From: Terry L Anderson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ckaushik@hss.hns.com CC: megaco@ietf.org Subject: Re: [Megaco] Query regarding ActionReply syntax References: <65256CBC.00663395.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop017.verizon.net from [138.89.124.43] at Tue, 28 Jan 2003 14:28:50 -0600 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This was added through the IG after a discussion on the list in Jan 2002, to make it match the ASN.1 and to allow a way to return an error for a syntactically bad command (say misspelled command name, eg, 'Ade') along with the responses for the previous, successfully completed commands in the transaction. The problem was pointed out in an email by sundareswarampv@netbrahma.com on Jan 22, 2002. ckaushik@hss.hns.com wrote: > >Hi, >According to Protocol's ABNF grammar, following syntax for ActionReply is >allowed: - >actionReply = CtxToken EQUAL ContextID LBRKT > ( errorDescriptor / commandReply ) / > (commandReply COMMA errorDescriptor) ) RBRKT. > >Can anyone pls elaborate the purpose of including "commandReply COMMA >errorDescriptor" syntax. > >Regards, >Chintan... >www.hssworld.com > > >DISCLAIMER: This message is proprietary to Hughes Software Systems >Limited (HSS) and is intended solely for the use of the individual >to whom it is addressed. It may contain privileged or confidential >information and should not be circulated or used for any purpose other >than for what it is intended. If you have received this message in error, >please notify the originator immediately. If you are not the intended >recipient, you are notified that you are strictly prohibited from using, >copying, altering, or disclosing the contents of this message. HSS accepts >no responsibility for loss or damage arising from the use of the information >transmitted by this email including damage from virus. > > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco > > > -- ------------------------------------------------------- Terry L Anderson tlatla@verizon.net Voice: +1 908.766.4463 Mobile: +1 908.342.9595 http://www.gti.net/tla ------------------------------------------------------- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 28 15:32:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06414 for ; Tue, 28 Jan 2003 15:32:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SKrH017713 for megaco-archive@odin.ietf.org; Tue, 28 Jan 2003 15:53:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SKrGJ17710 for ; Tue, 28 Jan 2003 15:53:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06397 for ; Tue, 28 Jan 2003 15:31:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SKlBJ17416; Tue, 28 Jan 2003 15:47:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SKkwJ17385 for ; Tue, 28 Jan 2003 15:46:58 -0500 Received: from pop017.verizon.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06246 for ; Tue, 28 Jan 2003 15:25:20 -0500 (EST) Received: from verizon.net ([138.89.124.43]) by pop017.verizon.net (InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP id <20030128202851.YKAA10203.pop017.verizon.net@verizon.net>; Tue, 28 Jan 2003 14:28:51 -0600 Message-ID: <3E36E7FD.4080100@verizon.net> Date: Tue, 28 Jan 2003 15:28:45 -0500 From: Terry L Anderson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ckaushik@hss.hns.com CC: megaco@ietf.org Subject: Re: [Megaco] Query regarding ActionReply syntax References: <65256CBC.00663395.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop017.verizon.net from [138.89.124.43] at Tue, 28 Jan 2003 14:28:50 -0600 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This was added through the IG after a discussion on the list in Jan 2002, to make it match the ASN.1 and to allow a way to return an error for a syntactically bad command (say misspelled command name, eg, 'Ade') along with the responses for the previous, successfully completed commands in the transaction. The problem was pointed out in an email by sundareswarampv@netbrahma.com on Jan 22, 2002. ckaushik@hss.hns.com wrote: > >Hi, >According to Protocol's ABNF grammar, following syntax for ActionReply is >allowed: - >actionReply = CtxToken EQUAL ContextID LBRKT > ( errorDescriptor / commandReply ) / > (commandReply COMMA errorDescriptor) ) RBRKT. > >Can anyone pls elaborate the purpose of including "commandReply COMMA >errorDescriptor" syntax. > >Regards, >Chintan... >www.hssworld.com > > >DISCLAIMER: This message is proprietary to Hughes Software Systems >Limited (HSS) and is intended solely for the use of the individual >to whom it is addressed. It may contain privileged or confidential >information and should not be circulated or used for any purpose other >than for what it is intended. If you have received this message in error, >please notify the originator immediately. If you are not the intended >recipient, you are notified that you are strictly prohibited from using, >copying, altering, or disclosing the contents of this message. HSS accepts >no responsibility for loss or damage arising from the use of the information >transmitted by this email including damage from virus. > > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco > > > -- ------------------------------------------------------- Terry L Anderson tlatla@verizon.net Voice: +1 908.766.4463 Mobile: +1 908.342.9595 http://www.gti.net/tla ------------------------------------------------------- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 28 19:41:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12735 for ; Tue, 28 Jan 2003 19:41:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T0uWJ01700; Tue, 28 Jan 2003 19:56:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T0s2J01599 for ; Tue, 28 Jan 2003 19:54:02 -0500 Received: from sparky.afc.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12578 for ; Tue, 28 Jan 2003 19:32:17 -0500 (EST) Received: (qmail 20321 invoked from network); 29 Jan 2003 00:31:29 -0000 Received: from unknown (HELO zzzconn03.fibre.com) (10.1.4.53) by 0 with SMTP; 29 Jan 2003 00:31:29 -0000 Received: FROM xconn01.fibre.com BY zzzconn03.fibre.com ; Tue Jan 28 16:36:09 2003 -0800 Received: by xconn01.fibre.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Jan 2003 16:34:57 -0800 Message-ID: From: John Stock To: "'Terry L Anderson'" , John Stock Cc: "'Kevin Boyle'" , "'megaco@ietf.org'" Subject: RE: [Megaco] RE: Glare condition when using embedded descriptors Date: Tue, 28 Jan 2003 16:35:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C72E.5DADF5E0" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2C72E.5DADF5E0 Content-Type: text/plain; charset="iso-8859-1" Oops, sorry for the wrong step #. Can the next version of the spec (Tom?) be updated per your recommendation, including a requirement in the spec itself stating as such? Thanks, John -----Original Message----- From: Terry L Anderson [mailto:tlatla@verizon.net] Sent: Tuesday, January 28, 2003 12:15 PM To: John Stock Cc: 'Kevin Boyle'; 'megaco@ietf.org' Subject: Re: [Megaco] RE: Glare condition when using embedded descriptors The note to which you refer in step 3 (not step 5) is misleading and, since it occurs in an Appendix, is not normative. Events matching an active event descriptor (from a command or activated from an embedded events descriptor) always result in a Notify (unless suspended by LockStep or deferred by being absorbed into a current dial string). The note should read more like: Note that the embedded EventsDescriptor could have been used to combine steps 3 and 4 with steps 8 and 9, so that digit collection need not wait for steps 6 and 7. There is no way to activate an embedded events descriptor without triggering an event which also results in a Notify, but the embedded events descriptor allows the new events (and possibly new embedded signals) to be activated without waiting for a Notify, Reply, Command cycle. John Stock wrote: The only place in the spec that I can see this addressed is in the example call flow. At the bottom of step 5, it says: Note that the embedded EventsDescriptor could have been used to combine steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7. Since steps 6 and 7 are the offhook Notify and its corresponding Reply, this to me means that there is not an intent to send the offhook as an observed event. Please let me know if there's somewhere else in the spec or annexes that addresses this, I haven't been able to find anything. Thanks. John -----Original Message----- From: Kevin Boyle [ mailto:kboyle@nortelnetworks.com ] Sent: Monday, January 27, 2003 12:08 PM To: John Stock; ' megaco@ietf.org ' Subject: RE: [Megaco] RE: Glare condition when using embedded descriptors Actually, the offhook IS sent. Just because it has embedded descriptors does not relieve the MG of its responsibility to report detected events. Kevin -----Original Message----- From: John Stock [ mailto:John.Stock@afc.com ] Sent: Wednesday, January 22, 2003 5:32 PM To: John Stock; ' megaco@ietf.org ' Subject: [Megaco] RE: Glare condition when using embedded descriptors Actually I just remember that an offhook event is not sent to the MG in the case of embedded descriptors. However this actually exacerbates the problem - there is actually a very large widow where this glare condition can occur. I'm certain this must have been discussed at some point, though couldn't find anything in looking through past emails. If such a discussion has taken place, can someone point me to the email thread? Thanks. > -----Original Message----- > From: John Stock > Sent: Wednesday, January 22, 2003 2:25 PM > To: ' megaco@ietf.org ' > Subject: Glare condition when using embedded descriptors > > Hi all, > > I was wondering about handling of this situation: > > - Embedded descriptors are used, such that when a user goes offhook, > the MG will provide dialtone and begin digit collection without > waiting for additional signals from the MGC > - A glare condition happens, such that a ring-in on the phone from the > MGC side occurs at the same time as the offhook, such that the MG > sends the offhook notification before receiving the Add command on the > ring-in. > - Thus the MG will begin dial tone before getting the Add, and will cease > it when connecting the physical termination to the incoming call. > - The MGC will receive the offhook notification after sending the Add > command for the ring-in, thus sees it simply as a user answering a > terminating call. > > My questions are these: > > - Is it proper to handle it this way, such that the subscriber is > connected to the incoming call, instead of the alternative which is to > block the incoming call and to provide dial tone and collect digits > from the subscriber for a separate outgoing call? I believe this is > the way it works with other protocols, such as Q.931 in GR303. > - The odd thing is the brief spurt of dial tone, which may be > exacerbated by any MGC<->MG messaging delay. Does anyone know > anything that's proposed for handling this? Though it's probably not > a big deal since one would expect this to happen very very seldomly. > An obvious solution is to not use the embedded descriptors, however > this then of course removes the benefits of doing such. Another > solution may be to have the MG wait for the Reply to the offhook > before providing dial tone, but this is kind of complex because the > Reply handling may be in a completely different entity and level than > event/signal handling. > > Thanks. > > John Stock > Systems Engineering > Advanced Fibre Communications > john.stock@afc.com > 707-792-6249 > > This message (including any attachments) is intended only for the use > of the named addressee(s), and may contain information that is legally > privileged, confidential or exempt from disclosure under applicable > law. If you are not a named addressee, you are hereby notified that > any use, dissemination, distribution or copying of this message is > strictly prohibited. If you have received this message in error, > please notify the original sender immediately by telephone or by > return E-mail and delete this message, along with any attachments, > from your computer. Thank you. > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco -- ------------------------------------------------------- Terry L Anderson tlatla@verizon.net Voice: +1 908.766.4463 Mobile: +1 908.342.9595 http://www.gti.net/tla ------------------------------------------------------- ------_=_NextPart_001_01C2C72E.5DADF5E0 Content-Type: text/html; charset="iso-8859-1"
Oops, sorry for the wrong step #.
 
Can the next version of the spec (Tom?) be updated per your recommendation, including a requirement in the spec itself stating as such?
 
Thanks,
John
-----Original Message-----
From: Terry L Anderson [mailto:tlatla@verizon.net]
Sent: Tuesday, January 28, 2003 12:15 PM
To: John Stock
Cc: 'Kevin Boyle'; 'megaco@ietf.org'
Subject: Re: [Megaco] RE: Glare condition when using embedded descriptors

The note to which you refer in step 3 (not step 5) is misleading and, since it occurs in an Appendix, is not normative.  Events matching an active event descriptor (from a command or activated from an embedded events descriptor) always result in a Notify (unless suspended by LockStep or deferred by being absorbed into a current dial string).  The note should read more like:
    Note that the embedded EventsDescriptor could have been used to combine steps 3 and 4 with
    steps 8 and 9, so that digit collection need not wait for steps 6 and 7.

There is no way to activate an embedded events descriptor without triggering an event which also results in a Notify, but the embedded events descriptor allows the new events (and possibly new embedded signals) to be activated without waiting for a Notify, Reply, Command cycle.

John Stock wrote:
The only place in the spec that I can see this addressed is in the example call flow.  At the bottom of step 5, it says:
 
Note that the embedded EventsDescriptor could have been used to combine steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7.
 
Since steps 6 and 7 are the offhook Notify and its corresponding Reply, this to me means that there is not an intent to send the offhook as an observed event.
 
Please let me know if there's somewhere else in the spec or annexes that addresses this, I haven't been able to find anything.  Thanks.
 
John
 
-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Monday, January 27, 2003 12:08 PM
To: John Stock; 'megaco@ietf.org'
Subject: RE: [Megaco] RE: Glare condition when using embedded descriptors

Actually, the offhook IS sent.  Just because it has embedded descriptors does not relieve the MG of its responsibility to report detected events.

Kevin

-----Original Message-----
From: John Stock [mailto:John.Stock@afc.com]
Sent: Wednesday, January 22, 2003 5:32 PM
To: John Stock; 'megaco@ietf.org'
Subject: [Megaco] RE: Glare condition when using embedded descriptors


Actually I just remember that an offhook event is not sent to the MG in the case of embedded descriptors.

However this actually exacerbates the problem - there is actually a very large widow where this glare condition can occur.  I'm certain this must have been discussed at some point, though couldn't find anything in looking through past emails.  If such a discussion has taken place, can someone point me to the email thread?

Thanks.

>  -----Original Message-----
> From:         John Stock 
> Sent: Wednesday, January 22, 2003 2:25 PM
> To:   'megaco@ietf.org'
> Subject:      Glare condition when using embedded descriptors
>
> Hi all,
>
> I was wondering about handling of this situation:
>
> - Embedded descriptors are used, such that when a user goes offhook,
> the MG will provide dialtone and begin digit collection without
> waiting for additional signals from the MGC
> - A glare condition happens, such that a ring-in on the phone from the
> MGC side occurs at the same time as the offhook, such that the MG
> sends the offhook notification before receiving the Add command on the
> ring-in.
> - Thus the MG will begin dial tone before getting the Add, and will cease
> it when connecting the physical termination to the incoming call.
> - The MGC will receive the offhook notification after sending the Add
> command for the ring-in, thus sees it simply as a user answering a
> terminating call.
>
> My questions are these:
>
> - Is it proper to handle it this way, such that the subscriber is
> connected to the incoming call, instead of the alternative which is to
> block the incoming call and to provide dial tone and collect digits
> from the subscriber for a separate outgoing call?  I believe this is
> the way it works with other protocols, such as Q.931 in GR303.
> - The odd thing is the brief spurt of dial tone, which may be
> exacerbated by any MGC<->MG messaging delay.  Does anyone know
> anything that's proposed for handling this?  Though it's probably not
> a big deal since one would expect this to happen very very seldomly. 
> An obvious solution is to not use the embedded descriptors, however
> this then of course removes the benefits of doing such.  Another
> solution may be to have the MG wait for the Reply to the offhook
> before providing dial tone, but this is kind of complex because the
> Reply handling may be in a completely different entity and level than
> event/signal handling.
>
> Thanks.
>
> John Stock
> Systems Engineering
> Advanced Fibre Communications
> john.stock@afc.com
> 707-792-6249
>
> This message (including any attachments) is intended only for the use
> of the named addressee(s), and may contain information that is legally
> privileged, confidential or exempt from disclosure under applicable
> law. If you are not a named addressee, you are hereby notified that
> any use, dissemination, distribution or copying of this message is
> strictly prohibited. If you have received this message in error,
> please notify the original sender immediately by telephone or by
> return E-mail and delete this message, along with any attachments,
> from your computer. Thank you.
>
>
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco 


-- 
-------------------------------------------------------
Terry L Anderson                     tlatla@verizon.net
Voice: +1 908.766.4463	        Mobile: +1 908.342.9595
http://www.gti.net/tla
-------------------------------------------------------

------_=_NextPart_001_01C2C72E.5DADF5E0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 28 19:41:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12766 for ; Tue, 28 Jan 2003 19:41:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0T130I01982 for megaco-archive@odin.ietf.org; Tue, 28 Jan 2003 20:03:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T130J01979 for ; Tue, 28 Jan 2003 20:03:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12749 for ; Tue, 28 Jan 2003 19:41:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T0uWJ01700; Tue, 28 Jan 2003 19:56:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T0s2J01599 for ; Tue, 28 Jan 2003 19:54:02 -0500 Received: from sparky.afc.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12578 for ; Tue, 28 Jan 2003 19:32:17 -0500 (EST) Received: (qmail 20321 invoked from network); 29 Jan 2003 00:31:29 -0000 Received: from unknown (HELO zzzconn03.fibre.com) (10.1.4.53) by 0 with SMTP; 29 Jan 2003 00:31:29 -0000 Received: FROM xconn01.fibre.com BY zzzconn03.fibre.com ; Tue Jan 28 16:36:09 2003 -0800 Received: by xconn01.fibre.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Jan 2003 16:34:57 -0800 Message-ID: From: John Stock To: "'Terry L Anderson'" , John Stock Cc: "'Kevin Boyle'" , "'megaco@ietf.org'" Subject: RE: [Megaco] RE: Glare condition when using embedded descriptors Date: Tue, 28 Jan 2003 16:35:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C72E.5DADF5E0" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2C72E.5DADF5E0 Content-Type: text/plain; charset="iso-8859-1" Oops, sorry for the wrong step #. Can the next version of the spec (Tom?) be updated per your recommendation, including a requirement in the spec itself stating as such? Thanks, John -----Original Message----- From: Terry L Anderson [mailto:tlatla@verizon.net] Sent: Tuesday, January 28, 2003 12:15 PM To: John Stock Cc: 'Kevin Boyle'; 'megaco@ietf.org' Subject: Re: [Megaco] RE: Glare condition when using embedded descriptors The note to which you refer in step 3 (not step 5) is misleading and, since it occurs in an Appendix, is not normative. Events matching an active event descriptor (from a command or activated from an embedded events descriptor) always result in a Notify (unless suspended by LockStep or deferred by being absorbed into a current dial string). The note should read more like: Note that the embedded EventsDescriptor could have been used to combine steps 3 and 4 with steps 8 and 9, so that digit collection need not wait for steps 6 and 7. There is no way to activate an embedded events descriptor without triggering an event which also results in a Notify, but the embedded events descriptor allows the new events (and possibly new embedded signals) to be activated without waiting for a Notify, Reply, Command cycle. John Stock wrote: The only place in the spec that I can see this addressed is in the example call flow. At the bottom of step 5, it says: Note that the embedded EventsDescriptor could have been used to combine steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7. Since steps 6 and 7 are the offhook Notify and its corresponding Reply, this to me means that there is not an intent to send the offhook as an observed event. Please let me know if there's somewhere else in the spec or annexes that addresses this, I haven't been able to find anything. Thanks. John -----Original Message----- From: Kevin Boyle [ mailto:kboyle@nortelnetworks.com ] Sent: Monday, January 27, 2003 12:08 PM To: John Stock; ' megaco@ietf.org ' Subject: RE: [Megaco] RE: Glare condition when using embedded descriptors Actually, the offhook IS sent. Just because it has embedded descriptors does not relieve the MG of its responsibility to report detected events. Kevin -----Original Message----- From: John Stock [ mailto:John.Stock@afc.com ] Sent: Wednesday, January 22, 2003 5:32 PM To: John Stock; ' megaco@ietf.org ' Subject: [Megaco] RE: Glare condition when using embedded descriptors Actually I just remember that an offhook event is not sent to the MG in the case of embedded descriptors. However this actually exacerbates the problem - there is actually a very large widow where this glare condition can occur. I'm certain this must have been discussed at some point, though couldn't find anything in looking through past emails. If such a discussion has taken place, can someone point me to the email thread? Thanks. > -----Original Message----- > From: John Stock > Sent: Wednesday, January 22, 2003 2:25 PM > To: ' megaco@ietf.org ' > Subject: Glare condition when using embedded descriptors > > Hi all, > > I was wondering about handling of this situation: > > - Embedded descriptors are used, such that when a user goes offhook, > the MG will provide dialtone and begin digit collection without > waiting for additional signals from the MGC > - A glare condition happens, such that a ring-in on the phone from the > MGC side occurs at the same time as the offhook, such that the MG > sends the offhook notification before receiving the Add command on the > ring-in. > - Thus the MG will begin dial tone before getting the Add, and will cease > it when connecting the physical termination to the incoming call. > - The MGC will receive the offhook notification after sending the Add > command for the ring-in, thus sees it simply as a user answering a > terminating call. > > My questions are these: > > - Is it proper to handle it this way, such that the subscriber is > connected to the incoming call, instead of the alternative which is to > block the incoming call and to provide dial tone and collect digits > from the subscriber for a separate outgoing call? I believe this is > the way it works with other protocols, such as Q.931 in GR303. > - The odd thing is the brief spurt of dial tone, which may be > exacerbated by any MGC<->MG messaging delay. Does anyone know > anything that's proposed for handling this? Though it's probably not > a big deal since one would expect this to happen very very seldomly. > An obvious solution is to not use the embedded descriptors, however > this then of course removes the benefits of doing such. Another > solution may be to have the MG wait for the Reply to the offhook > before providing dial tone, but this is kind of complex because the > Reply handling may be in a completely different entity and level than > event/signal handling. > > Thanks. > > John Stock > Systems Engineering > Advanced Fibre Communications > john.stock@afc.com > 707-792-6249 > > This message (including any attachments) is intended only for the use > of the named addressee(s), and may contain information that is legally > privileged, confidential or exempt from disclosure under applicable > law. If you are not a named addressee, you are hereby notified that > any use, dissemination, distribution or copying of this message is > strictly prohibited. If you have received this message in error, > please notify the original sender immediately by telephone or by > return E-mail and delete this message, along with any attachments, > from your computer. Thank you. > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco -- ------------------------------------------------------- Terry L Anderson tlatla@verizon.net Voice: +1 908.766.4463 Mobile: +1 908.342.9595 http://www.gti.net/tla ------------------------------------------------------- ------_=_NextPart_001_01C2C72E.5DADF5E0 Content-Type: text/html; charset="iso-8859-1"
Oops, sorry for the wrong step #.
 
Can the next version of the spec (Tom?) be updated per your recommendation, including a requirement in the spec itself stating as such?
 
Thanks,
John
-----Original Message-----
From: Terry L Anderson [mailto:tlatla@verizon.net]
Sent: Tuesday, January 28, 2003 12:15 PM
To: John Stock
Cc: 'Kevin Boyle'; 'megaco@ietf.org'
Subject: Re: [Megaco] RE: Glare condition when using embedded descriptors

The note to which you refer in step 3 (not step 5) is misleading and, since it occurs in an Appendix, is not normative.  Events matching an active event descriptor (from a command or activated from an embedded events descriptor) always result in a Notify (unless suspended by LockStep or deferred by being absorbed into a current dial string).  The note should read more like:
    Note that the embedded EventsDescriptor could have been used to combine steps 3 and 4 with
    steps 8 and 9, so that digit collection need not wait for steps 6 and 7.

There is no way to activate an embedded events descriptor without triggering an event which also results in a Notify, but the embedded events descriptor allows the new events (and possibly new embedded signals) to be activated without waiting for a Notify, Reply, Command cycle.

John Stock wrote:
The only place in the spec that I can see this addressed is in the example call flow.  At the bottom of step 5, it says:
 
Note that the embedded EventsDescriptor could have been used to combine steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7.
 
Since steps 6 and 7 are the offhook Notify and its corresponding Reply, this to me means that there is not an intent to send the offhook as an observed event.
 
Please let me know if there's somewhere else in the spec or annexes that addresses this, I haven't been able to find anything.  Thanks.
 
John
 
-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Monday, January 27, 2003 12:08 PM
To: John Stock; 'megaco@ietf.org'
Subject: RE: [Megaco] RE: Glare condition when using embedded descriptors

Actually, the offhook IS sent.  Just because it has embedded descriptors does not relieve the MG of its responsibility to report detected events.

Kevin

-----Original Message-----
From: John Stock [mailto:John.Stock@afc.com]
Sent: Wednesday, January 22, 2003 5:32 PM
To: John Stock; 'megaco@ietf.org'
Subject: [Megaco] RE: Glare condition when using embedded descriptors


Actually I just remember that an offhook event is not sent to the MG in the case of embedded descriptors.

However this actually exacerbates the problem - there is actually a very large widow where this glare condition can occur.  I'm certain this must have been discussed at some point, though couldn't find anything in looking through past emails.  If such a discussion has taken place, can someone point me to the email thread?

Thanks.

>  -----Original Message-----
> From:         John Stock 
> Sent: Wednesday, January 22, 2003 2:25 PM
> To:   'megaco@ietf.org'
> Subject:      Glare condition when using embedded descriptors
>
> Hi all,
>
> I was wondering about handling of this situation:
>
> - Embedded descriptors are used, such that when a user goes offhook,
> the MG will provide dialtone and begin digit collection without
> waiting for additional signals from the MGC
> - A glare condition happens, such that a ring-in on the phone from the
> MGC side occurs at the same time as the offhook, such that the MG
> sends the offhook notification before receiving the Add command on the
> ring-in.
> - Thus the MG will begin dial tone before getting the Add, and will cease
> it when connecting the physical termination to the incoming call.
> - The MGC will receive the offhook notification after sending the Add
> command for the ring-in, thus sees it simply as a user answering a
> terminating call.
>
> My questions are these:
>
> - Is it proper to handle it this way, such that the subscriber is
> connected to the incoming call, instead of the alternative which is to
> block the incoming call and to provide dial tone and collect digits
> from the subscriber for a separate outgoing call?  I believe this is
> the way it works with other protocols, such as Q.931 in GR303.
> - The odd thing is the brief spurt of dial tone, which may be
> exacerbated by any MGC<->MG messaging delay.  Does anyone know
> anything that's proposed for handling this?  Though it's probably not
> a big deal since one would expect this to happen very very seldomly. 
> An obvious solution is to not use the embedded descriptors, however
> this then of course removes the benefits of doing such.  Another
> solution may be to have the MG wait for the Reply to the offhook
> before providing dial tone, but this is kind of complex because the
> Reply handling may be in a completely different entity and level than
> event/signal handling.
>
> Thanks.
>
> John Stock
> Systems Engineering
> Advanced Fibre Communications
> john.stock@afc.com
> 707-792-6249
>
> This message (including any attachments) is intended only for the use
> of the named addressee(s), and may contain information that is legally
> privileged, confidential or exempt from disclosure under applicable
> law. If you are not a named addressee, you are hereby notified that
> any use, dissemination, distribution or copying of this message is
> strictly prohibited. If you have received this message in error,
> please notify the original sender immediately by telephone or by
> return E-mail and delete this message, along with any attachments,
> from your computer. Thank you.
>
>
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco 


-- 
-------------------------------------------------------
Terry L Anderson                     tlatla@verizon.net
Voice: +1 908.766.4463	        Mobile: +1 908.342.9595
http://www.gti.net/tla
-------------------------------------------------------

------_=_NextPart_001_01C2C72E.5DADF5E0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 28 19:47:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12887 for ; Tue, 28 Jan 2003 19:47:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T12RJ01952; Tue, 28 Jan 2003 20:02:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T116J01901 for ; Tue, 28 Jan 2003 20:01:06 -0500 Received: from out004.verizon.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12712 for ; Tue, 28 Jan 2003 19:39:21 -0500 (EST) Received: from verizon.net ([138.89.124.43]) by out004.verizon.net (InterMail vM.5.01.05.20 201-253-122-126-120-20021101) with ESMTP id <20030129004251.EPCE2505.out004.verizon.net@verizon.net>; Tue, 28 Jan 2003 18:42:51 -0600 Message-ID: <3E372384.8010601@verizon.net> Date: Tue, 28 Jan 2003 19:42:44 -0500 From: Terry L Anderson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Stock CC: "'Kevin Boyle'" , "'megaco@ietf.org'" Subject: Re: [Megaco] RE: Glare condition when using embedded descriptors References: Content-Type: multipart/alternative; boundary="------------070807000703000508020008" X-Authentication-Info: Submitted using SMTP AUTH at out004.verizon.net from [138.89.124.43] at Tue, 28 Jan 2003 18:42:49 -0600 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --------------070807000703000508020008 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I agree that the note could be corrected, but I am not sure that anything need change in the normative text. There is nothing that suggests events triggering replacement or the event descriptor by an embedded event descriptor should be different. I see no reason to explicitly state that there is no difference. John Stock wrote: > Oops, sorry for the wrong step #. > > Can the next version of the spec (Tom?) be updated per your > recommendation, including a requirement in the spec itself stating as > such? > > Thanks, > John > > -----Original Message----- > From: Terry L Anderson [mailto:tlatla@verizon.net] > Sent: Tuesday, January 28, 2003 12:15 PM > To: John Stock > Cc: 'Kevin Boyle'; 'megaco@ietf.org' > Subject: Re: [Megaco] RE: Glare condition when using embedded > descriptors > > The note to which you refer in step 3 (not step 5) is misleading > and, since it occurs in an Appendix, is not normative. Events > matching an active event descriptor (from a command or activated > from an embedded events descriptor) always result in a Notify > (unless suspended by LockStep or deferred by being absorbed into a > current dial string). The note should read more like: > Note that the embedded EventsDescriptor could have been used > to combine steps 3 and 4 with > steps 8 and 9, so that digit collection need not wait for > steps 6 and 7. > > There is no way to activate an embedded events descriptor without > triggering an event which also results in a Notify, but the > embedded events descriptor allows the new events (and possibly new > embedded signals) to be activated without waiting for a Notify, > Reply, Command cycle. > > John Stock wrote: > >> The only place in the spec that I can see this addressed is in >> the example call flow. At the bottom of step 5, it says: >> >> Note that the embedded EventsDescriptor could have been used to >> combine steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7. >> >> Since steps 6 and 7 are the offhook Notify and its corresponding >> Reply, this to me means that there is not an intent to send the >> offhook as an observed event. >> >> Please let me know if there's somewhere else in the spec or >> annexes that addresses this, I haven't been able to find >> anything. Thanks. >> >> John >> >> >> -----Original Message----- >> From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] >> Sent: Monday, January 27, 2003 12:08 PM >> To: John Stock; 'megaco@ietf.org' >> Subject: RE: [Megaco] RE: Glare condition when using embedded >> descriptors >> >> Actually, the offhook IS sent. Just because it has embedded >> descriptors does not relieve the MG of its responsibility to >> report detected events. >> >> Kevin >> >> -----Original Message----- >> From: John Stock [mailto:John.Stock@afc.com] >> Sent: Wednesday, January 22, 2003 5:32 PM >> To: John Stock; 'megaco@ietf.org' >> Subject: [Megaco] RE: Glare condition when using embedded >> descriptors >> >> >> Actually I just remember that an offhook event is not sent to >> the MG in the case of embedded descriptors. >> >> However this actually exacerbates the problem - there is >> actually a very large widow where this glare condition can >> occur. I'm certain this must have been discussed at some >> point, though couldn't find anything in looking through past >> emails. If such a discussion has taken place, can someone >> point me to the email thread? >> >> Thanks. >> >> > -----Original Message----- >> > From: John Stock >> > Sent: Wednesday, January 22, 2003 2:25 PM >> > To: 'megaco@ietf.org' >> > Subject: Glare condition when using embedded descriptors >> > >> > Hi all, >> > >> > I was wondering about handling of this situation: >> > >> > - Embedded descriptors are used, such that when a user goes >> offhook, >> > the MG will provide dialtone and begin digit collection >> without >> > waiting for additional signals from the MGC >> > - A glare condition happens, such that a ring-in on the >> phone from the >> > MGC side occurs at the same time as the offhook, such that >> the MG >> > sends the offhook notification before receiving the Add >> command on the >> > ring-in. >> > - Thus the MG will begin dial tone before getting the Add, >> and will cease >> > it when connecting the physical termination to the incoming >> call. >> > - The MGC will receive the offhook notification after >> sending the Add >> > command for the ring-in, thus sees it simply as a user >> answering a >> > terminating call. >> > >> > My questions are these: >> > >> > - Is it proper to handle it this way, such that the >> subscriber is >> > connected to the incoming call, instead of the alternative >> which is to >> > block the incoming call and to provide dial tone and >> collect digits >> > from the subscriber for a separate outgoing call? I >> believe this is >> > the way it works with other protocols, such as Q.931 in GR303. >> > - The odd thing is the brief spurt of dial tone, which may be >> > exacerbated by any MGC<->MG messaging delay. Does anyone know >> > anything that's proposed for handling this? Though it's >> probably not >> > a big deal since one would expect this to happen very very >> seldomly. >> > An obvious solution is to not use the embedded descriptors, >> however >> > this then of course removes the benefits of doing such. >> Another >> > solution may be to have the MG wait for the Reply to the >> offhook >> > before providing dial tone, but this is kind of complex >> because the >> > Reply handling may be in a completely different entity and >> level than >> > event/signal handling. >> > >> > Thanks. >> > >> > John Stock >> > Systems Engineering >> > Advanced Fibre Communications >> > john.stock@afc.com >> > 707-792-6249 >> > >> > This message (including any attachments) is intended only >> for the use >> > of the named addressee(s), and may contain information that >> is legally >> > privileged, confidential or exempt from disclosure under >> applicable >> > law. If you are not a named addressee, you are hereby >> notified that >> > any use, dissemination, distribution or copying of this >> message is >> > strictly prohibited. If you have received this message in >> error, >> > please notify the original sender immediately by telephone >> or by >> > return E-mail and delete this message, along with any >> attachments, >> > from your computer. Thank you. >> > >> > >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco >> > >-- >------------------------------------------------------- >Terry L Anderson tlatla@verizon.net >Voice: +1 908.766.4463 Mobile: +1 908.342.9595 >http://www.gti.net/tla >------------------------------------------------------- > > > -- ------------------------------------------------------- Terry L Anderson tlatla@verizon.net Voice: +1 908.766.4463 Mobile: +1 908.342.9595 http://www.gti.net/tla ------------------------------------------------------- --------------070807000703000508020008 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I agree that the note could be corrected, but I am not sure that anything need change in the normative text.  There is nothing that suggests events triggering replacement or the event descriptor by an embedded event descriptor should be different.  I see no reason to explicitly state that there is no difference.

John Stock wrote:
Oops, sorry for the wrong step #.
 
Can the next version of the spec (Tom?) be updated per your recommendation, including a requirement in the spec itself stating as such?
 
Thanks,
John
-----Original Message-----
From: Terry L Anderson [mailto:tlatla@verizon.net]
Sent: Tuesday, January 28, 2003 12:15 PM
To: John Stock
Cc: 'Kevin Boyle'; 'megaco@ietf.org'
Subject: Re: [Megaco] RE: Glare condition when using embedded descriptors

The note to which you refer in step 3 (not step 5) is misleading and, since it occurs in an Appendix, is not normative.  Events matching an active event descriptor (from a command or activated from an embedded events descriptor) always result in a Notify (unless suspended by LockStep or deferred by being absorbed into a current dial string).  The note should read more like:
    Note that the embedded EventsDescriptor could have been used to combine steps 3 and 4 with
    steps 8 and 9, so that digit collection need not wait for steps 6 and 7.

There is no way to activate an embedded events descriptor without triggering an event which also results in a Notify, but the embedded events descriptor allows the new events (and possibly new embedded signals) to be activated without waiting for a Notify, Reply, Command cycle.

John Stock wrote:
The only place in the spec that I can see this addressed is in the example call flow.  At the bottom of step 5, it says:
 
Note that the embedded EventsDescriptor could have been used to combine steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7.
 
Since steps 6 and 7 are the offhook Notify and its corresponding Reply, this to me means that there is not an intent to send the offhook as an observed event.
 
Please let me know if there's somewhere else in the spec or annexes that addresses this, I haven't been able to find anything.  Thanks.
 
John
 
-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Monday, January 27, 2003 12:08 PM
To: John Stock; 'megaco@ietf.org'
Subject: RE: [Megaco] RE: Glare condition when using embedded descriptors

Actually, the offhook IS sent.  Just because it has embedded descriptors does not relieve the MG of its responsibility to report detected events.

Kevin

-----Original Message-----
From: John Stock [mailto:John.Stock@afc.com]
Sent: Wednesday, January 22, 2003 5:32 PM
To: John Stock; 'megaco@ietf.org'
Subject: [Megaco] RE: Glare condition when using embedded descriptors


Actually I just remember that an offhook event is not sent to the MG in the case of embedded descriptors.

However this actually exacerbates the problem - there is actually a very large widow where this glare condition can occur.  I'm certain this must have been discussed at some point, though couldn't find anything in looking through past emails.  If such a discussion has taken place, can someone point me to the email thread?

Thanks.

>  -----Original Message-----
> From:         John Stock 
> Sent: Wednesday, January 22, 2003 2:25 PM
> To:   'megaco@ietf.org'
> Subject:      Glare condition when using embedded descriptors
>
> Hi all,
>
> I was wondering about handling of this situation:
>
> - Embedded descriptors are used, such that when a user goes offhook,
> the MG will provide dialtone and begin digit collection without
> waiting for additional signals from the MGC
> - A glare condition happens, such that a ring-in on the phone from the
> MGC side occurs at the same time as the offhook, such that the MG
> sends the offhook notification before receiving the Add command on the
> ring-in.
> - Thus the MG will begin dial tone before getting the Add, and will cease
> it when connecting the physical termination to the incoming call.
> - The MGC will receive the offhook notification after sending the Add
> command for the ring-in, thus sees it simply as a user answering a
> terminating call.
>
> My questions are these:
>
> - Is it proper to handle it this way, such that the subscriber is
> connected to the incoming call, instead of the alternative which is to
> block the incoming call and to provide dial tone and collect digits
> from the subscriber for a separate outgoing call?  I believe this is
> the way it works with other protocols, such as Q.931 in GR303.
> - The odd thing is the brief spurt of dial tone, which may be
> exacerbated by any MGC<->MG messaging delay.  Does anyone know
> anything that's proposed for handling this?  Though it's probably not
> a big deal since one would expect this to happen very very seldomly. 
> An obvious solution is to not use the embedded descriptors, however
> this then of course removes the benefits of doing such.  Another
> solution may be to have the MG wait for the Reply to the offhook
> before providing dial tone, but this is kind of complex because the
> Reply handling may be in a completely different entity and level than
> event/signal handling.
>
> Thanks.
>
> John Stock
> Systems Engineering
> Advanced Fibre Communications
> john.stock@afc.com
> 707-792-6249
>
> This message (including any attachments) is intended only for the use
> of the named addressee(s), and may contain information that is legally
> privileged, confidential or exempt from disclosure under applicable
> law. If you are not a named addressee, you are hereby notified that
> any use, dissemination, distribution or copying of this message is
> strictly prohibited. If you have received this message in error,
> please notify the original sender immediately by telephone or by
> return E-mail and delete this message, along with any attachments,
> from your computer. Thank you.
>
>
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco 


-- 
-------------------------------------------------------
Terry L Anderson                     tlatla@verizon.net
Voice: +1 908.766.4463	        Mobile: +1 908.342.9595
http://www.gti.net/tla
-------------------------------------------------------
    


-- 
-------------------------------------------------------
Terry L Anderson                     tlatla@verizon.net
Voice: +1 908.766.4463	        Mobile: +1 908.342.9595
http://www.gti.net/tla
-------------------------------------------------------

--------------070807000703000508020008-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 28 19:48:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12913 for ; Tue, 28 Jan 2003 19:48:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0T19MK02931 for megaco-archive@odin.ietf.org; Tue, 28 Jan 2003 20:09:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T19MJ02928 for ; Tue, 28 Jan 2003 20:09:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12901 for ; Tue, 28 Jan 2003 19:47:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T12RJ01952; Tue, 28 Jan 2003 20:02:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T116J01901 for ; Tue, 28 Jan 2003 20:01:06 -0500 Received: from out004.verizon.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12712 for ; Tue, 28 Jan 2003 19:39:21 -0500 (EST) Received: from verizon.net ([138.89.124.43]) by out004.verizon.net (InterMail vM.5.01.05.20 201-253-122-126-120-20021101) with ESMTP id <20030129004251.EPCE2505.out004.verizon.net@verizon.net>; Tue, 28 Jan 2003 18:42:51 -0600 Message-ID: <3E372384.8010601@verizon.net> Date: Tue, 28 Jan 2003 19:42:44 -0500 From: Terry L Anderson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Stock CC: "'Kevin Boyle'" , "'megaco@ietf.org'" Subject: Re: [Megaco] RE: Glare condition when using embedded descriptors References: Content-Type: multipart/alternative; boundary="------------070807000703000508020008" X-Authentication-Info: Submitted using SMTP AUTH at out004.verizon.net from [138.89.124.43] at Tue, 28 Jan 2003 18:42:49 -0600 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --------------070807000703000508020008 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I agree that the note could be corrected, but I am not sure that anything need change in the normative text. There is nothing that suggests events triggering replacement or the event descriptor by an embedded event descriptor should be different. I see no reason to explicitly state that there is no difference. John Stock wrote: > Oops, sorry for the wrong step #. > > Can the next version of the spec (Tom?) be updated per your > recommendation, including a requirement in the spec itself stating as > such? > > Thanks, > John > > -----Original Message----- > From: Terry L Anderson [mailto:tlatla@verizon.net] > Sent: Tuesday, January 28, 2003 12:15 PM > To: John Stock > Cc: 'Kevin Boyle'; 'megaco@ietf.org' > Subject: Re: [Megaco] RE: Glare condition when using embedded > descriptors > > The note to which you refer in step 3 (not step 5) is misleading > and, since it occurs in an Appendix, is not normative. Events > matching an active event descriptor (from a command or activated > from an embedded events descriptor) always result in a Notify > (unless suspended by LockStep or deferred by being absorbed into a > current dial string). The note should read more like: > Note that the embedded EventsDescriptor could have been used > to combine steps 3 and 4 with > steps 8 and 9, so that digit collection need not wait for > steps 6 and 7. > > There is no way to activate an embedded events descriptor without > triggering an event which also results in a Notify, but the > embedded events descriptor allows the new events (and possibly new > embedded signals) to be activated without waiting for a Notify, > Reply, Command cycle. > > John Stock wrote: > >> The only place in the spec that I can see this addressed is in >> the example call flow. At the bottom of step 5, it says: >> >> Note that the embedded EventsDescriptor could have been used to >> combine steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7. >> >> Since steps 6 and 7 are the offhook Notify and its corresponding >> Reply, this to me means that there is not an intent to send the >> offhook as an observed event. >> >> Please let me know if there's somewhere else in the spec or >> annexes that addresses this, I haven't been able to find >> anything. Thanks. >> >> John >> >> >> -----Original Message----- >> From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] >> Sent: Monday, January 27, 2003 12:08 PM >> To: John Stock; 'megaco@ietf.org' >> Subject: RE: [Megaco] RE: Glare condition when using embedded >> descriptors >> >> Actually, the offhook IS sent. Just because it has embedded >> descriptors does not relieve the MG of its responsibility to >> report detected events. >> >> Kevin >> >> -----Original Message----- >> From: John Stock [mailto:John.Stock@afc.com] >> Sent: Wednesday, January 22, 2003 5:32 PM >> To: John Stock; 'megaco@ietf.org' >> Subject: [Megaco] RE: Glare condition when using embedded >> descriptors >> >> >> Actually I just remember that an offhook event is not sent to >> the MG in the case of embedded descriptors. >> >> However this actually exacerbates the problem - there is >> actually a very large widow where this glare condition can >> occur. I'm certain this must have been discussed at some >> point, though couldn't find anything in looking through past >> emails. If such a discussion has taken place, can someone >> point me to the email thread? >> >> Thanks. >> >> > -----Original Message----- >> > From: John Stock >> > Sent: Wednesday, January 22, 2003 2:25 PM >> > To: 'megaco@ietf.org' >> > Subject: Glare condition when using embedded descriptors >> > >> > Hi all, >> > >> > I was wondering about handling of this situation: >> > >> > - Embedded descriptors are used, such that when a user goes >> offhook, >> > the MG will provide dialtone and begin digit collection >> without >> > waiting for additional signals from the MGC >> > - A glare condition happens, such that a ring-in on the >> phone from the >> > MGC side occurs at the same time as the offhook, such that >> the MG >> > sends the offhook notification before receiving the Add >> command on the >> > ring-in. >> > - Thus the MG will begin dial tone before getting the Add, >> and will cease >> > it when connecting the physical termination to the incoming >> call. >> > - The MGC will receive the offhook notification after >> sending the Add >> > command for the ring-in, thus sees it simply as a user >> answering a >> > terminating call. >> > >> > My questions are these: >> > >> > - Is it proper to handle it this way, such that the >> subscriber is >> > connected to the incoming call, instead of the alternative >> which is to >> > block the incoming call and to provide dial tone and >> collect digits >> > from the subscriber for a separate outgoing call? I >> believe this is >> > the way it works with other protocols, such as Q.931 in GR303. >> > - The odd thing is the brief spurt of dial tone, which may be >> > exacerbated by any MGC<->MG messaging delay. Does anyone know >> > anything that's proposed for handling this? Though it's >> probably not >> > a big deal since one would expect this to happen very very >> seldomly. >> > An obvious solution is to not use the embedded descriptors, >> however >> > this then of course removes the benefits of doing such. >> Another >> > solution may be to have the MG wait for the Reply to the >> offhook >> > before providing dial tone, but this is kind of complex >> because the >> > Reply handling may be in a completely different entity and >> level than >> > event/signal handling. >> > >> > Thanks. >> > >> > John Stock >> > Systems Engineering >> > Advanced Fibre Communications >> > john.stock@afc.com >> > 707-792-6249 >> > >> > This message (including any attachments) is intended only >> for the use >> > of the named addressee(s), and may contain information that >> is legally >> > privileged, confidential or exempt from disclosure under >> applicable >> > law. If you are not a named addressee, you are hereby >> notified that >> > any use, dissemination, distribution or copying of this >> message is >> > strictly prohibited. If you have received this message in >> error, >> > please notify the original sender immediately by telephone >> or by >> > return E-mail and delete this message, along with any >> attachments, >> > from your computer. Thank you. >> > >> > >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco >> > >-- >------------------------------------------------------- >Terry L Anderson tlatla@verizon.net >Voice: +1 908.766.4463 Mobile: +1 908.342.9595 >http://www.gti.net/tla >------------------------------------------------------- > > > -- ------------------------------------------------------- Terry L Anderson tlatla@verizon.net Voice: +1 908.766.4463 Mobile: +1 908.342.9595 http://www.gti.net/tla ------------------------------------------------------- --------------070807000703000508020008 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I agree that the note could be corrected, but I am not sure that anything need change in the normative text.  There is nothing that suggests events triggering replacement or the event descriptor by an embedded event descriptor should be different.  I see no reason to explicitly state that there is no difference.

John Stock wrote:
Oops, sorry for the wrong step #.
 
Can the next version of the spec (Tom?) be updated per your recommendation, including a requirement in the spec itself stating as such?
 
Thanks,
John
-----Original Message-----
From: Terry L Anderson [mailto:tlatla@verizon.net]
Sent: Tuesday, January 28, 2003 12:15 PM
To: John Stock
Cc: 'Kevin Boyle'; 'megaco@ietf.org'
Subject: Re: [Megaco] RE: Glare condition when using embedded descriptors

The note to which you refer in step 3 (not step 5) is misleading and, since it occurs in an Appendix, is not normative.  Events matching an active event descriptor (from a command or activated from an embedded events descriptor) always result in a Notify (unless suspended by LockStep or deferred by being absorbed into a current dial string).  The note should read more like:
    Note that the embedded EventsDescriptor could have been used to combine steps 3 and 4 with
    steps 8 and 9, so that digit collection need not wait for steps 6 and 7.

There is no way to activate an embedded events descriptor without triggering an event which also results in a Notify, but the embedded events descriptor allows the new events (and possibly new embedded signals) to be activated without waiting for a Notify, Reply, Command cycle.

John Stock wrote:
The only place in the spec that I can see this addressed is in the example call flow.  At the bottom of step 5, it says:
 
Note that the embedded EventsDescriptor could have been used to combine steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7.
 
Since steps 6 and 7 are the offhook Notify and its corresponding Reply, this to me means that there is not an intent to send the offhook as an observed event.
 
Please let me know if there's somewhere else in the spec or annexes that addresses this, I haven't been able to find anything.  Thanks.
 
John
 
-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Monday, January 27, 2003 12:08 PM
To: John Stock; 'megaco@ietf.org'
Subject: RE: [Megaco] RE: Glare condition when using embedded descriptors

Actually, the offhook IS sent.  Just because it has embedded descriptors does not relieve the MG of its responsibility to report detected events.

Kevin

-----Original Message-----
From: John Stock [mailto:John.Stock@afc.com]
Sent: Wednesday, January 22, 2003 5:32 PM
To: John Stock; 'megaco@ietf.org'
Subject: [Megaco] RE: Glare condition when using embedded descriptors


Actually I just remember that an offhook event is not sent to the MG in the case of embedded descriptors.

However this actually exacerbates the problem - there is actually a very large widow where this glare condition can occur.  I'm certain this must have been discussed at some point, though couldn't find anything in looking through past emails.  If such a discussion has taken place, can someone point me to the email thread?

Thanks.

>  -----Original Message-----
> From:         John Stock 
> Sent: Wednesday, January 22, 2003 2:25 PM
> To:   'megaco@ietf.org'
> Subject:      Glare condition when using embedded descriptors
>
> Hi all,
>
> I was wondering about handling of this situation:
>
> - Embedded descriptors are used, such that when a user goes offhook,
> the MG will provide dialtone and begin digit collection without
> waiting for additional signals from the MGC
> - A glare condition happens, such that a ring-in on the phone from the
> MGC side occurs at the same time as the offhook, such that the MG
> sends the offhook notification before receiving the Add command on the
> ring-in.
> - Thus the MG will begin dial tone before getting the Add, and will cease
> it when connecting the physical termination to the incoming call.
> - The MGC will receive the offhook notification after sending the Add
> command for the ring-in, thus sees it simply as a user answering a
> terminating call.
>
> My questions are these:
>
> - Is it proper to handle it this way, such that the subscriber is
> connected to the incoming call, instead of the alternative which is to
> block the incoming call and to provide dial tone and collect digits
> from the subscriber for a separate outgoing call?  I believe this is
> the way it works with other protocols, such as Q.931 in GR303.
> - The odd thing is the brief spurt of dial tone, which may be
> exacerbated by any MGC<->MG messaging delay.  Does anyone know
> anything that's proposed for handling this?  Though it's probably not
> a big deal since one would expect this to happen very very seldomly. 
> An obvious solution is to not use the embedded descriptors, however
> this then of course removes the benefits of doing such.  Another
> solution may be to have the MG wait for the Reply to the offhook
> before providing dial tone, but this is kind of complex because the
> Reply handling may be in a completely different entity and level than
> event/signal handling.
>
> Thanks.
>
> John Stock
> Systems Engineering
> Advanced Fibre Communications
> john.stock@afc.com
> 707-792-6249
>
> This message (including any attachments) is intended only for the use
> of the named addressee(s), and may contain information that is legally
> privileged, confidential or exempt from disclosure under applicable
> law. If you are not a named addressee, you are hereby notified that
> any use, dissemination, distribution or copying of this message is
> strictly prohibited. If you have received this message in error,
> please notify the original sender immediately by telephone or by
> return E-mail and delete this message, along with any attachments,
> from your computer. Thank you.
>
>
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco 


-- 
-------------------------------------------------------
Terry L Anderson                     tlatla@verizon.net
Voice: +1 908.766.4463	        Mobile: +1 908.342.9595
http://www.gti.net/tla
-------------------------------------------------------
    


-- 
-------------------------------------------------------
Terry L Anderson                     tlatla@verizon.net
Voice: +1 908.766.4463	        Mobile: +1 908.342.9595
http://www.gti.net/tla
-------------------------------------------------------

--------------070807000703000508020008-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Jan 28 20:22:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13370 for ; Tue, 28 Jan 2003 20:22:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T1eUJ04783; Tue, 28 Jan 2003 20:40:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T1d1J04698 for ; Tue, 28 Jan 2003 20:39:01 -0500 Received: from sparky.afc.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13306 for ; Tue, 28 Jan 2003 20:17:17 -0500 (EST) Received: (qmail 27258 invoked from network); 29 Jan 2003 01:16:30 -0000 Received: from unknown (HELO zzzconn03.fibre.com) (10.1.4.53) by 0 with SMTP; 29 Jan 2003 01:16:30 -0000 Received: FROM xconn01.fibre.com BY zzzconn03.fibre.com ; Tue Jan 28 17:21:09 2003 -0800 Received: by xconn01.fibre.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Jan 2003 17:19:57 -0800 Message-ID: From: John Stock To: "'Kevin Boyle'" , Anil Jangam , Terry L Anderson , Raphael Tryster Cc: Tom-PT Taylor , megaco@ietf.org, SHRI KUMAR Subject: RE: [Megaco] State of the termination after failure of a command. Date: Tue, 28 Jan 2003 17:20:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Along this line of discussion, I was wondering about this case that provides a twist - - MGC receives a ring-in, and sends Add commands to MG with the al/ri signal - The MG detects offhook before it receives the Add commands, resulting in a Notify with al/of to the MGC. The preferred result would probably be to connect the line with the incoming call, as is done in traditional PSTN. From the MGC's perspective, it just receives the offhook after sending the Adds for the ringin, so it just appears that the line is answering the ring. However the MG now is in a quandary. It should accept the Add commands from the MGC, possibly along with the al/ri signal. However you don't want to apply ringing to a line that's offhook, especially since the MGC will not know to give any indication to the MG to stop ringing. The MGC thinks the MG already stopped ringing due to the offhook event, however in the MG the offhook event preceded the ring signal. So the MG cannot apply this signal, due to its knowledge of the line state, and not due to any network or resource failures. Thus does the MG fail the ring signal? If so, does this mean the Add commands (in which the signal is embedded) also fail? What would be the value of the error descriptor (I couldn't find one that applies)? It seems in this case it may be appropriate for the MG to decide what is considered a failure, and just accept the ring signal even though it doesn't actually apply it. There are other ways to handle it too, like sending a Signal Completion event to the MGC, though this requires the MGC to ask for it in the Events descriptor. Thanks, John -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] Sent: Monday, October 21, 2002 8:12 AM To: Anil Jangam; Terry L Anderson; Raphael Tryster Cc: Tom-PT Taylor; megaco@ietf.org; SHRI KUMAR Subject: RE: [Megaco] State of the termination after failure of a command. More comments inline. [KJBII] Kevin -----Original Message----- From: Anil Jangam [mailto:anilj@mahindrabt.com] Sent: Monday, October 21, 2002 10:43 AM To: Terry L Anderson; Raphael Tryster Cc: Taylor, Tom-PT [CAR:B602:EXCH]; megaco@ietf.org; SHRI KUMAR; Boyle, Kevin [NCRTP:3R90:EXCH] Subject: Re: [Megaco] State of the termination after failure of a command. Hi Terry, see inline... headed with [anil]. /anil. ----- Original Message ----- From: "Terry L Anderson" To: "Raphael Tryster" Cc: "Tom-PT Taylor" ; "'Anil Jangam'" ; ; "SHRI KUMAR" ; "Kevin Boyle" Sent: Monday, October 21, 2002 5:59 PM Subject: Re: [Megaco] State of the termination after failure of a command. > I am not sure that we would want to make a narrow exception to the > general principle just for signals. I think if any descriptor "fails" > then the command fails. But that being said we DO have to be careful > of what is considered a failure. There are certainly things that can > fail about a signal well after the signal has begun playing that I > would not consider a error of the descriptor, just as failure of the > network is not an error in the Local/Remote descriptors. > [anil] I disagree to your approach. I think detecting something that has failed (say network failure) and doing nothing is of no use. What standard says about restoring the state of the Termination is the corrective mesures to be taken in case of the failure conditions. What is you have mentioned about accepting the descriptor (in other words validating the descriptor) is just a preventive measure. We have to take some actions when something goes wrong. [KJBII] Actually, you don't. It is the prerogative of the MGC to clean up after errors as it sees fit. The MG should "as far as possible" restore the previous state, and then wait for the MGC to act. Autonomous cleanup by the MG will most certainly lead to state mismatches between the MG and MGC. > In the specific case you raise, I would expect that the MG should > "reserve resources" for all signals when it accepts the descriptor. > If it has no ability to play cg/bt because it is not implemented or > some other resource limit as known at the time the descriptor is > received, then I would expect it to return an error failing the entire > command. On the other hand, if (as far as it knows when the > descriptor is > received) it can play them, it should return success immediately and > notify in any other appropriate way (if events are set) about any sort > of later failure. > [anil] I agree that once the validation (i.e. preventive measure) is done, you ask for the notification reporting the status of the execution. Say in the end, the execution of the signal has failed, then we can not leave it as it is. Take an example of call hold scenario. If you (the controlling leg) have toggled from one party to other, you would normally remove the hold tone on held party/termination and play hold tone on the active party/termination. Now you move from one context to another. Mean time the removal of the hold tone on the held party has failed, and still you try to talk to it, then what you (MG) would do???? In this case, can't we call the above failure condition as failure of the descriptor, and would try to restore (i.e. corrective measure) the state to the previous state??? [KJBII] You would hook the two parties up, and continue with the service. If the MGC asked for notification of signal completion for held tone, then the MG will send that notification to the MGC. Otherwise, the MG should not take ANY action on it's own, without explicit direction from the MGC. /anil. ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Jan 28 20:22:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13419 for ; Tue, 28 Jan 2003 20:22:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0T1hvG04930 for megaco-archive@odin.ietf.org; Tue, 28 Jan 2003 20:43:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T1hvJ04927 for ; Tue, 28 Jan 2003 20:43:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13380 for ; Tue, 28 Jan 2003 20:22:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T1eUJ04783; Tue, 28 Jan 2003 20:40:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T1d1J04698 for ; Tue, 28 Jan 2003 20:39:01 -0500 Received: from sparky.afc.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13306 for ; Tue, 28 Jan 2003 20:17:17 -0500 (EST) Received: (qmail 27258 invoked from network); 29 Jan 2003 01:16:30 -0000 Received: from unknown (HELO zzzconn03.fibre.com) (10.1.4.53) by 0 with SMTP; 29 Jan 2003 01:16:30 -0000 Received: FROM xconn01.fibre.com BY zzzconn03.fibre.com ; Tue Jan 28 17:21:09 2003 -0800 Received: by xconn01.fibre.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Jan 2003 17:19:57 -0800 Message-ID: From: John Stock To: "'Kevin Boyle'" , Anil Jangam , Terry L Anderson , Raphael Tryster Cc: Tom-PT Taylor , megaco@ietf.org, SHRI KUMAR Subject: RE: [Megaco] State of the termination after failure of a command. Date: Tue, 28 Jan 2003 17:20:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Along this line of discussion, I was wondering about this case that provides a twist - - MGC receives a ring-in, and sends Add commands to MG with the al/ri signal - The MG detects offhook before it receives the Add commands, resulting in a Notify with al/of to the MGC. The preferred result would probably be to connect the line with the incoming call, as is done in traditional PSTN. From the MGC's perspective, it just receives the offhook after sending the Adds for the ringin, so it just appears that the line is answering the ring. However the MG now is in a quandary. It should accept the Add commands from the MGC, possibly along with the al/ri signal. However you don't want to apply ringing to a line that's offhook, especially since the MGC will not know to give any indication to the MG to stop ringing. The MGC thinks the MG already stopped ringing due to the offhook event, however in the MG the offhook event preceded the ring signal. So the MG cannot apply this signal, due to its knowledge of the line state, and not due to any network or resource failures. Thus does the MG fail the ring signal? If so, does this mean the Add commands (in which the signal is embedded) also fail? What would be the value of the error descriptor (I couldn't find one that applies)? It seems in this case it may be appropriate for the MG to decide what is considered a failure, and just accept the ring signal even though it doesn't actually apply it. There are other ways to handle it too, like sending a Signal Completion event to the MGC, though this requires the MGC to ask for it in the Events descriptor. Thanks, John -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] Sent: Monday, October 21, 2002 8:12 AM To: Anil Jangam; Terry L Anderson; Raphael Tryster Cc: Tom-PT Taylor; megaco@ietf.org; SHRI KUMAR Subject: RE: [Megaco] State of the termination after failure of a command. More comments inline. [KJBII] Kevin -----Original Message----- From: Anil Jangam [mailto:anilj@mahindrabt.com] Sent: Monday, October 21, 2002 10:43 AM To: Terry L Anderson; Raphael Tryster Cc: Taylor, Tom-PT [CAR:B602:EXCH]; megaco@ietf.org; SHRI KUMAR; Boyle, Kevin [NCRTP:3R90:EXCH] Subject: Re: [Megaco] State of the termination after failure of a command. Hi Terry, see inline... headed with [anil]. /anil. ----- Original Message ----- From: "Terry L Anderson" To: "Raphael Tryster" Cc: "Tom-PT Taylor" ; "'Anil Jangam'" ; ; "SHRI KUMAR" ; "Kevin Boyle" Sent: Monday, October 21, 2002 5:59 PM Subject: Re: [Megaco] State of the termination after failure of a command. > I am not sure that we would want to make a narrow exception to the > general principle just for signals. I think if any descriptor "fails" > then the command fails. But that being said we DO have to be careful > of what is considered a failure. There are certainly things that can > fail about a signal well after the signal has begun playing that I > would not consider a error of the descriptor, just as failure of the > network is not an error in the Local/Remote descriptors. > [anil] I disagree to your approach. I think detecting something that has failed (say network failure) and doing nothing is of no use. What standard says about restoring the state of the Termination is the corrective mesures to be taken in case of the failure conditions. What is you have mentioned about accepting the descriptor (in other words validating the descriptor) is just a preventive measure. We have to take some actions when something goes wrong. [KJBII] Actually, you don't. It is the prerogative of the MGC to clean up after errors as it sees fit. The MG should "as far as possible" restore the previous state, and then wait for the MGC to act. Autonomous cleanup by the MG will most certainly lead to state mismatches between the MG and MGC. > In the specific case you raise, I would expect that the MG should > "reserve resources" for all signals when it accepts the descriptor. > If it has no ability to play cg/bt because it is not implemented or > some other resource limit as known at the time the descriptor is > received, then I would expect it to return an error failing the entire > command. On the other hand, if (as far as it knows when the > descriptor is > received) it can play them, it should return success immediately and > notify in any other appropriate way (if events are set) about any sort > of later failure. > [anil] I agree that once the validation (i.e. preventive measure) is done, you ask for the notification reporting the status of the execution. Say in the end, the execution of the signal has failed, then we can not leave it as it is. Take an example of call hold scenario. If you (the controlling leg) have toggled from one party to other, you would normally remove the hold tone on held party/termination and play hold tone on the active party/termination. Now you move from one context to another. Mean time the removal of the hold tone on the held party has failed, and still you try to talk to it, then what you (MG) would do???? In this case, can't we call the above failure condition as failure of the descriptor, and would try to restore (i.e. corrective measure) the state to the previous state??? [KJBII] You would hook the two parties up, and continue with the service. If the MGC asked for notification of signal completion for held tone, then the MG will send that notification to the MGC. Otherwise, the MG should not take ANY action on it's own, without explicit direction from the MGC. /anil. ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jan 29 05:18:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14856 for ; Wed, 29 Jan 2003 05:18:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TAbQJ13650; Wed, 29 Jan 2003 05:37:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TAXVJ12917 for ; Wed, 29 Jan 2003 05:33:31 -0500 Received: from sess01.rdp.asi.alcatel.es (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14800 for ; Wed, 29 Jan 2003 05:11:36 -0500 (EST) Received: from sers002.rpi.ses.alcatel.es (localhost [127.0.0.1]) by sess01.rdp.asi.alcatel.es (8.11.2/8.11.2) with ESMTP id h0TAEmT11678; Wed, 29 Jan 2003 11:14:48 +0100 (MET) Received: from alcatel.es (sevsf075 [159.23.195.75]) by sers002.rpi.ses.alcatel.es (8.8.8+Sun/8.8.8) with ESMTP id LAA19320; Wed, 29 Jan 2003 11:14:51 +0100 (MET) Message-ID: <3E37A99B.61920667@alcatel.es> Date: Wed, 29 Jan 2003 11:14:51 +0100 From: Fernando Vallejo Lazaro Organization: ALCATEL X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: John Stock CC: "'Kevin Boyle'" , Anil Jangam , Terry L Anderson , Raphael Tryster , Tom-PT Taylor , megaco@ietf.org, SHRI KUMAR Subject: Re: [Megaco] State of the termination after failure of a command. References: Content-Type: multipart/alternative; boundary="------------9951A7A53A53DE339C924B5B" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --------------9951A7A53A53DE339C924B5B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi John, See my comments below [FVL] John Stock wrote: > Along this line of discussion, I was wondering about this case that provides > a twist - > > - MGC receives a ring-in, and sends Add commands to MG with the al/ri signal > - The MG detects offhook before it receives the Add commands, resulting in a > Notify with al/of to the MGC. > > The preferred result would probably be to connect the line with the incoming > call, as is done in traditional PSTN. From the MGC's perspective, it just > receives the offhook after sending the Adds for the ringin, so it just > appears that the line is answering the ring. [FVL] The preferred result depends on the operator. Sometimes the terminating call has a higher priority, but in other cases it is originating priority. The Notify received by the MGC tells the context to which the termination belonged, so the MGC will know if it has been before applying ringing (termination in the NULL context) or after it (termination in the new context created by the Add) and it will be able to act accordingly. > > > However the MG now is in a quandary. It should accept the Add commands from > the MGC, possibly along with the al/ri signal. However you don't want to > apply ringing to a line that's offhook, especially since the MGC will not > know to give any indication to the MG to stop ringing. The MGC thinks the > MG already stopped ringing due to the offhook event, however in the MG the > offhook event preceded the ring signal. [FVL] If the al/ri is applied after the off hook, then I think that the MGC can indicate the MG to stop ringing immediately. > > > So the MG cannot apply this signal, due to its knowledge of the line state, > and not due to any network or resource failures. > > Thus does the MG fail the ring signal? If so, does this mean the Add > commands (in which the signal is embedded) also fail? What would be the > value of the error descriptor (I couldn't find one that applies)? > [FVL] In any case I think that the MG does not have to send an error although the situation is not coherent. It is up to the MGC to restore a good state. > > It seems in this case it may be appropriate for the MG to decide what is > considered a failure, and just accept the ring signal even though it doesn't > actually apply it. There are other ways to handle it too, like sending a > Signal Completion event to the MGC, though this requires the MGC to ask for > it in the Events descriptor. > > Thanks, > John Regards Fernando > > > -----Original Message----- > From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] > Sent: Monday, October 21, 2002 8:12 AM > To: Anil Jangam; Terry L Anderson; Raphael Tryster > Cc: Tom-PT Taylor; megaco@ietf.org; SHRI KUMAR > Subject: RE: [Megaco] State of the termination after failure of a > command. > > More comments inline. [KJBII] > > Kevin > > -----Original Message----- > From: Anil Jangam [mailto:anilj@mahindrabt.com] > Sent: Monday, October 21, 2002 10:43 AM > To: Terry L Anderson; Raphael Tryster > Cc: Taylor, Tom-PT [CAR:B602:EXCH]; megaco@ietf.org; SHRI KUMAR; Boyle, > Kevin [NCRTP:3R90:EXCH] > Subject: Re: [Megaco] State of the termination after failure of a command. > > Hi Terry, > > see inline... headed with [anil]. > > /anil. > > ----- Original Message ----- > From: "Terry L Anderson" > To: "Raphael Tryster" > Cc: "Tom-PT Taylor" ; "'Anil Jangam'" > ; ; "SHRI KUMAR" > ; "Kevin Boyle" > Sent: Monday, October 21, 2002 5:59 PM > Subject: Re: [Megaco] State of the termination after failure of a command. > > > I am not sure that we would want to make a narrow exception to the > > general principle just for signals. I think if any descriptor "fails" > > then the command fails. But that being said we DO have to be careful > > of what is considered a failure. There are certainly things that can > > fail about a signal well after the signal has begun playing that I > > would not consider a error of the descriptor, just as failure of the > > network is not an error in the Local/Remote descriptors. > > > [anil] I disagree to your approach. I think detecting something that has > failed (say network failure) and doing nothing is of no use. What standard > says about restoring the state of the Termination is the corrective mesures > to be taken in case of the failure conditions. What is you have mentioned > about accepting the descriptor (in other words validating the descriptor) is > just a preventive measure. We have to take some actions when something goes > wrong. > [KJBII] Actually, you don't. It is the prerogative of the MGC to clean up > after errors as it sees fit. The MG should "as far as possible" restore the > previous state, and then wait for the MGC to act. Autonomous cleanup by the > MG will most certainly lead to state mismatches between the MG and MGC. > > > In the specific case you raise, I would expect that the MG should > > "reserve resources" for all signals when it accepts the descriptor. > > If it has no ability to play cg/bt because it is not implemented or > > some other resource limit as known at the time the descriptor is > > received, then I would expect it to return an error failing the entire > > command. On the other hand, if (as far as it knows when the > > descriptor is > > received) it can play them, it should return success immediately and > > notify in any other appropriate way (if events are set) about any sort > > of later failure. > > > [anil] I agree that once the validation (i.e. preventive measure) is done, > you ask for the notification reporting the status of the execution. Say in > the end, the execution of the signal has failed, then we can not leave it as > it is. Take an example of call hold scenario. If you (the controlling leg) > have toggled from one party to other, you would normally remove the hold > tone on held party/termination and play hold tone on the active > party/termination. Now you move from one context to another. Mean time the > removal of the hold tone on the held party has failed, and still you try to > talk to it, then what you (MG) would do???? In this case, can't we call the > above failure condition as failure of the descriptor, and would try to > restore (i.e. corrective measure) the state to the previous state??? > [KJBII] You would hook the two parties up, and continue with the service. > If the MGC asked for notification of signal completion for held tone, then > the MG will send that notification to the MGC. Otherwise, the MG should not > take ANY action on it's own, without explicit direction from the MGC. > > /anil. > > ********************************************************* > Disclaimer > > This message (including any attachments) contains > confidential information intended for a specific > individual and purpose, and is protected by law. > If you are not the intended recipient, you should > delete this message and are hereby notified that > any disclosure, copying, or distribution of this > message, or the taking of any action based on it, > is strictly prohibited. > > ********************************************************* > Visit us at http://www.mahindrabt.com > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco -- Fernando Vallejo Lazaro Phone: +34 91 330 8279 SW Wireline ASD-Madrid ALCATEL --------------9951A7A53A53DE339C924B5B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi John,

See my comments below [FVL]

John Stock wrote:

Along this line of discussion, I was wondering about this case that provides
a twist -

- MGC receives a ring-in, and sends Add commands to MG with the al/ri signal
- The MG detects offhook before it receives the Add commands, resulting in a
Notify with al/of to the MGC.

The preferred result would probably be to connect the line with the incoming
call, as is done in traditional PSTN.  From the MGC's perspective, it just
receives the offhook after sending the Adds for the ringin, so it just
appears that the line is answering the ring.

[FVL] The preferred result depends on the operator. Sometimes the terminating
call has a higher priority, but in other cases it is originating priority.
The Notify received by the MGC tells the context to which the termination belonged,
so the MGC will know if it has been before applying ringing (termination in the NULL
context) or after it (termination in the new context created by the Add) and it will be
able to act accordingly.
 
 

However the MG now is in a quandary.  It should accept the Add commands from
the MGC, possibly along with the al/ri signal.  However you don't want to
apply ringing to a line that's offhook, especially since the MGC will not
know to give any indication to the MG to stop ringing.  The MGC thinks the
MG already stopped ringing due to the offhook event, however in the MG the
offhook event preceded the ring signal.

[FVL] If the al/ri is applied after the off hook, then I think that the MGC can indicate the MG
to stop ringing immediately.
 

So the MG cannot apply this signal, due to its knowledge of the line state,
and not due to any network or resource failures.

Thus does the MG fail the ring signal?  If so, does this mean the Add
commands (in which the signal is embedded) also fail?  What would be the
value of the error descriptor (I couldn't find one that applies)?
 

[FVL] In any case I think that the MG does not have to send an error although the
situation is not coherent. It is up to the MGC to restore a good state.
 
It seems in this case it may be appropriate for the MG to decide what is
considered a failure, and just accept the ring signal even though it doesn't
actually apply it.  There are other ways to handle it too, like sending a
Signal Completion event to the MGC, though this requires the MGC to ask for
it in the Events descriptor.

Thanks,
John


Regards
Fernando
 

 

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Monday, October 21, 2002 8:12 AM
To: Anil Jangam; Terry L Anderson; Raphael Tryster
Cc: Tom-PT Taylor; megaco@ietf.org; SHRI KUMAR
Subject: RE: [Megaco] State of the termination after failure of a
command.

More comments inline. [KJBII]

Kevin

-----Original Message-----
From: Anil Jangam [mailto:anilj@mahindrabt.com]
Sent: Monday, October 21, 2002 10:43 AM
To: Terry L Anderson; Raphael Tryster
Cc: Taylor, Tom-PT [CAR:B602:EXCH]; megaco@ietf.org; SHRI KUMAR; Boyle,
Kevin [NCRTP:3R90:EXCH]
Subject: Re: [Megaco] State of the termination after failure of a command.

Hi Terry,

see inline... headed with [anil].

/anil.

----- Original Message -----
From: "Terry L Anderson" <tlatla@verizon.net>
To: "Raphael Tryster" <raphael@tdsoft.com>
Cc: "Tom-PT Taylor" <taylor@nortelnetworks.com>; "'Anil Jangam'"
<anilj@mahindrabt.com>; <megaco@ietf.org>; "SHRI KUMAR"
<manikaran1947@yahoo.co.in>; "Kevin Boyle" <kboyle@nortelnetworks.com>
Sent: Monday, October 21, 2002 5:59 PM
Subject: Re: [Megaco] State of the termination after failure of a command.

> I am not sure that we would want to make a narrow exception to the
> general principle just for signals.  I think if any descriptor "fails"
> then the command fails.  But that being said we DO have to be careful
> of what is considered a failure.  There are certainly things that can
> fail about a signal well after the signal has begun playing that I
> would not consider a error of the descriptor, just as failure of the
> network is not an error in the Local/Remote descriptors.
>
[anil] I disagree to your approach. I think detecting something that has
failed (say network failure) and doing nothing is of no use. What standard
says about restoring the state of the Termination is the corrective mesures
to be taken in case of the failure conditions. What is you have mentioned
about accepting the descriptor (in other words validating the descriptor) is
just a preventive measure. We have to take some actions when something goes
wrong.
[KJBII] Actually, you don't.  It is the prerogative of the MGC to clean up
after errors as it sees fit.  The MG should "as far as possible" restore the
previous state, and then wait for the MGC to act.  Autonomous cleanup by the
MG will most certainly lead to state mismatches between the MG and MGC.

> In the specific case you raise, I would expect that the MG should
> "reserve resources" for all signals when it accepts the descriptor.
> If it has no ability to play cg/bt because it is not implemented or
> some other resource limit as known at the time the descriptor is
> received, then I would expect it to return an error failing the entire
> command.  On the other hand, if (as far as it knows when the
> descriptor is
> received) it can play them, it should return success immediately and
> notify in any other appropriate way (if events are set) about any sort
> of later failure.
>
[anil] I agree that once the validation (i.e. preventive measure) is done,
you ask for the notification reporting the status of the execution. Say in
the end, the execution of the signal has failed, then we can not leave it as
it is. Take an example of call hold scenario. If you (the controlling leg)
have toggled from one party to other, you would normally remove the hold
tone on held party/termination and play hold tone on the active
party/termination. Now you move from one context to another. Mean time the
removal of the hold tone on the held party has failed, and still you try to
talk to it, then what you (MG) would do???? In this case, can't we call the
above failure condition as failure of the descriptor, and would try to
restore (i.e. corrective measure) the state to the previous state???
[KJBII] You would hook the two parties up, and continue with the service.
If the MGC asked for notification of signal completion for held tone, then
the MG will send that notification to the MGC.  Otherwise, the MG should not
take ANY action on it's own, without explicit direction from the MGC.

/anil.

*********************************************************
Disclaimer

This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com

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

-- 
Fernando Vallejo Lazaro
Phone:  +34 91 330 8279
SW  Wireline ASD-Madrid
       ALCATEL
  --------------9951A7A53A53DE339C924B5B-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 29 05:18:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14876 for ; Wed, 29 Jan 2003 05:18:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0TAeJO13903 for megaco-archive@odin.ietf.org; Wed, 29 Jan 2003 05:40:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TAeJJ13900 for ; Wed, 29 Jan 2003 05:40:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14870 for ; Wed, 29 Jan 2003 05:18:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TAbQJ13650; Wed, 29 Jan 2003 05:37:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TAXVJ12917 for ; Wed, 29 Jan 2003 05:33:31 -0500 Received: from sess01.rdp.asi.alcatel.es (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14800 for ; Wed, 29 Jan 2003 05:11:36 -0500 (EST) Received: from sers002.rpi.ses.alcatel.es (localhost [127.0.0.1]) by sess01.rdp.asi.alcatel.es (8.11.2/8.11.2) with ESMTP id h0TAEmT11678; Wed, 29 Jan 2003 11:14:48 +0100 (MET) Received: from alcatel.es (sevsf075 [159.23.195.75]) by sers002.rpi.ses.alcatel.es (8.8.8+Sun/8.8.8) with ESMTP id LAA19320; Wed, 29 Jan 2003 11:14:51 +0100 (MET) Message-ID: <3E37A99B.61920667@alcatel.es> Date: Wed, 29 Jan 2003 11:14:51 +0100 From: Fernando Vallejo Lazaro Organization: ALCATEL X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: John Stock CC: "'Kevin Boyle'" , Anil Jangam , Terry L Anderson , Raphael Tryster , Tom-PT Taylor , megaco@ietf.org, SHRI KUMAR Subject: Re: [Megaco] State of the termination after failure of a command. References: Content-Type: multipart/alternative; boundary="------------9951A7A53A53DE339C924B5B" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --------------9951A7A53A53DE339C924B5B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi John, See my comments below [FVL] John Stock wrote: > Along this line of discussion, I was wondering about this case that provides > a twist - > > - MGC receives a ring-in, and sends Add commands to MG with the al/ri signal > - The MG detects offhook before it receives the Add commands, resulting in a > Notify with al/of to the MGC. > > The preferred result would probably be to connect the line with the incoming > call, as is done in traditional PSTN. From the MGC's perspective, it just > receives the offhook after sending the Adds for the ringin, so it just > appears that the line is answering the ring. [FVL] The preferred result depends on the operator. Sometimes the terminating call has a higher priority, but in other cases it is originating priority. The Notify received by the MGC tells the context to which the termination belonged, so the MGC will know if it has been before applying ringing (termination in the NULL context) or after it (termination in the new context created by the Add) and it will be able to act accordingly. > > > However the MG now is in a quandary. It should accept the Add commands from > the MGC, possibly along with the al/ri signal. However you don't want to > apply ringing to a line that's offhook, especially since the MGC will not > know to give any indication to the MG to stop ringing. The MGC thinks the > MG already stopped ringing due to the offhook event, however in the MG the > offhook event preceded the ring signal. [FVL] If the al/ri is applied after the off hook, then I think that the MGC can indicate the MG to stop ringing immediately. > > > So the MG cannot apply this signal, due to its knowledge of the line state, > and not due to any network or resource failures. > > Thus does the MG fail the ring signal? If so, does this mean the Add > commands (in which the signal is embedded) also fail? What would be the > value of the error descriptor (I couldn't find one that applies)? > [FVL] In any case I think that the MG does not have to send an error although the situation is not coherent. It is up to the MGC to restore a good state. > > It seems in this case it may be appropriate for the MG to decide what is > considered a failure, and just accept the ring signal even though it doesn't > actually apply it. There are other ways to handle it too, like sending a > Signal Completion event to the MGC, though this requires the MGC to ask for > it in the Events descriptor. > > Thanks, > John Regards Fernando > > > -----Original Message----- > From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] > Sent: Monday, October 21, 2002 8:12 AM > To: Anil Jangam; Terry L Anderson; Raphael Tryster > Cc: Tom-PT Taylor; megaco@ietf.org; SHRI KUMAR > Subject: RE: [Megaco] State of the termination after failure of a > command. > > More comments inline. [KJBII] > > Kevin > > -----Original Message----- > From: Anil Jangam [mailto:anilj@mahindrabt.com] > Sent: Monday, October 21, 2002 10:43 AM > To: Terry L Anderson; Raphael Tryster > Cc: Taylor, Tom-PT [CAR:B602:EXCH]; megaco@ietf.org; SHRI KUMAR; Boyle, > Kevin [NCRTP:3R90:EXCH] > Subject: Re: [Megaco] State of the termination after failure of a command. > > Hi Terry, > > see inline... headed with [anil]. > > /anil. > > ----- Original Message ----- > From: "Terry L Anderson" > To: "Raphael Tryster" > Cc: "Tom-PT Taylor" ; "'Anil Jangam'" > ; ; "SHRI KUMAR" > ; "Kevin Boyle" > Sent: Monday, October 21, 2002 5:59 PM > Subject: Re: [Megaco] State of the termination after failure of a command. > > > I am not sure that we would want to make a narrow exception to the > > general principle just for signals. I think if any descriptor "fails" > > then the command fails. But that being said we DO have to be careful > > of what is considered a failure. There are certainly things that can > > fail about a signal well after the signal has begun playing that I > > would not consider a error of the descriptor, just as failure of the > > network is not an error in the Local/Remote descriptors. > > > [anil] I disagree to your approach. I think detecting something that has > failed (say network failure) and doing nothing is of no use. What standard > says about restoring the state of the Termination is the corrective mesures > to be taken in case of the failure conditions. What is you have mentioned > about accepting the descriptor (in other words validating the descriptor) is > just a preventive measure. We have to take some actions when something goes > wrong. > [KJBII] Actually, you don't. It is the prerogative of the MGC to clean up > after errors as it sees fit. The MG should "as far as possible" restore the > previous state, and then wait for the MGC to act. Autonomous cleanup by the > MG will most certainly lead to state mismatches between the MG and MGC. > > > In the specific case you raise, I would expect that the MG should > > "reserve resources" for all signals when it accepts the descriptor. > > If it has no ability to play cg/bt because it is not implemented or > > some other resource limit as known at the time the descriptor is > > received, then I would expect it to return an error failing the entire > > command. On the other hand, if (as far as it knows when the > > descriptor is > > received) it can play them, it should return success immediately and > > notify in any other appropriate way (if events are set) about any sort > > of later failure. > > > [anil] I agree that once the validation (i.e. preventive measure) is done, > you ask for the notification reporting the status of the execution. Say in > the end, the execution of the signal has failed, then we can not leave it as > it is. Take an example of call hold scenario. If you (the controlling leg) > have toggled from one party to other, you would normally remove the hold > tone on held party/termination and play hold tone on the active > party/termination. Now you move from one context to another. Mean time the > removal of the hold tone on the held party has failed, and still you try to > talk to it, then what you (MG) would do???? In this case, can't we call the > above failure condition as failure of the descriptor, and would try to > restore (i.e. corrective measure) the state to the previous state??? > [KJBII] You would hook the two parties up, and continue with the service. > If the MGC asked for notification of signal completion for held tone, then > the MG will send that notification to the MGC. Otherwise, the MG should not > take ANY action on it's own, without explicit direction from the MGC. > > /anil. > > ********************************************************* > Disclaimer > > This message (including any attachments) contains > confidential information intended for a specific > individual and purpose, and is protected by law. > If you are not the intended recipient, you should > delete this message and are hereby notified that > any disclosure, copying, or distribution of this > message, or the taking of any action based on it, > is strictly prohibited. > > ********************************************************* > Visit us at http://www.mahindrabt.com > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco -- Fernando Vallejo Lazaro Phone: +34 91 330 8279 SW Wireline ASD-Madrid ALCATEL --------------9951A7A53A53DE339C924B5B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi John,

See my comments below [FVL]

John Stock wrote:

Along this line of discussion, I was wondering about this case that provides
a twist -

- MGC receives a ring-in, and sends Add commands to MG with the al/ri signal
- The MG detects offhook before it receives the Add commands, resulting in a
Notify with al/of to the MGC.

The preferred result would probably be to connect the line with the incoming
call, as is done in traditional PSTN.  From the MGC's perspective, it just
receives the offhook after sending the Adds for the ringin, so it just
appears that the line is answering the ring.

[FVL] The preferred result depends on the operator. Sometimes the terminating
call has a higher priority, but in other cases it is originating priority.
The Notify received by the MGC tells the context to which the termination belonged,
so the MGC will know if it has been before applying ringing (termination in the NULL
context) or after it (termination in the new context created by the Add) and it will be
able to act accordingly.
 
 

However the MG now is in a quandary.  It should accept the Add commands from
the MGC, possibly along with the al/ri signal.  However you don't want to
apply ringing to a line that's offhook, especially since the MGC will not
know to give any indication to the MG to stop ringing.  The MGC thinks the
MG already stopped ringing due to the offhook event, however in the MG the
offhook event preceded the ring signal.

[FVL] If the al/ri is applied after the off hook, then I think that the MGC can indicate the MG
to stop ringing immediately.
 

So the MG cannot apply this signal, due to its knowledge of the line state,
and not due to any network or resource failures.

Thus does the MG fail the ring signal?  If so, does this mean the Add
commands (in which the signal is embedded) also fail?  What would be the
value of the error descriptor (I couldn't find one that applies)?
 

[FVL] In any case I think that the MG does not have to send an error although the
situation is not coherent. It is up to the MGC to restore a good state.
 
It seems in this case it may be appropriate for the MG to decide what is
considered a failure, and just accept the ring signal even though it doesn't
actually apply it.  There are other ways to handle it too, like sending a
Signal Completion event to the MGC, though this requires the MGC to ask for
it in the Events descriptor.

Thanks,
John


Regards
Fernando
 

 

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Monday, October 21, 2002 8:12 AM
To: Anil Jangam; Terry L Anderson; Raphael Tryster
Cc: Tom-PT Taylor; megaco@ietf.org; SHRI KUMAR
Subject: RE: [Megaco] State of the termination after failure of a
command.

More comments inline. [KJBII]

Kevin

-----Original Message-----
From: Anil Jangam [mailto:anilj@mahindrabt.com]
Sent: Monday, October 21, 2002 10:43 AM
To: Terry L Anderson; Raphael Tryster
Cc: Taylor, Tom-PT [CAR:B602:EXCH]; megaco@ietf.org; SHRI KUMAR; Boyle,
Kevin [NCRTP:3R90:EXCH]
Subject: Re: [Megaco] State of the termination after failure of a command.

Hi Terry,

see inline... headed with [anil].

/anil.

----- Original Message -----
From: "Terry L Anderson" <tlatla@verizon.net>
To: "Raphael Tryster" <raphael@tdsoft.com>
Cc: "Tom-PT Taylor" <taylor@nortelnetworks.com>; "'Anil Jangam'"
<anilj@mahindrabt.com>; <megaco@ietf.org>; "SHRI KUMAR"
<manikaran1947@yahoo.co.in>; "Kevin Boyle" <kboyle@nortelnetworks.com>
Sent: Monday, October 21, 2002 5:59 PM
Subject: Re: [Megaco] State of the termination after failure of a command.

> I am not sure that we would want to make a narrow exception to the
> general principle just for signals.  I think if any descriptor "fails"
> then the command fails.  But that being said we DO have to be careful
> of what is considered a failure.  There are certainly things that can
> fail about a signal well after the signal has begun playing that I
> would not consider a error of the descriptor, just as failure of the
> network is not an error in the Local/Remote descriptors.
>
[anil] I disagree to your approach. I think detecting something that has
failed (say network failure) and doing nothing is of no use. What standard
says about restoring the state of the Termination is the corrective mesures
to be taken in case of the failure conditions. What is you have mentioned
about accepting the descriptor (in other words validating the descriptor) is
just a preventive measure. We have to take some actions when something goes
wrong.
[KJBII] Actually, you don't.  It is the prerogative of the MGC to clean up
after errors as it sees fit.  The MG should "as far as possible" restore the
previous state, and then wait for the MGC to act.  Autonomous cleanup by the
MG will most certainly lead to state mismatches between the MG and MGC.

> In the specific case you raise, I would expect that the MG should
> "reserve resources" for all signals when it accepts the descriptor.
> If it has no ability to play cg/bt because it is not implemented or
> some other resource limit as known at the time the descriptor is
> received, then I would expect it to return an error failing the entire
> command.  On the other hand, if (as far as it knows when the
> descriptor is
> received) it can play them, it should return success immediately and
> notify in any other appropriate way (if events are set) about any sort
> of later failure.
>
[anil] I agree that once the validation (i.e. preventive measure) is done,
you ask for the notification reporting the status of the execution. Say in
the end, the execution of the signal has failed, then we can not leave it as
it is. Take an example of call hold scenario. If you (the controlling leg)
have toggled from one party to other, you would normally remove the hold
tone on held party/termination and play hold tone on the active
party/termination. Now you move from one context to another. Mean time the
removal of the hold tone on the held party has failed, and still you try to
talk to it, then what you (MG) would do???? In this case, can't we call the
above failure condition as failure of the descriptor, and would try to
restore (i.e. corrective measure) the state to the previous state???
[KJBII] You would hook the two parties up, and continue with the service.
If the MGC asked for notification of signal completion for held tone, then
the MG will send that notification to the MGC.  Otherwise, the MG should not
take ANY action on it's own, without explicit direction from the MGC.

/anil.

*********************************************************
Disclaimer

This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com

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

-- 
Fernando Vallejo Lazaro
Phone:  +34 91 330 8279
SW  Wireline ASD-Madrid
       ALCATEL
  --------------9951A7A53A53DE339C924B5B-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jan 29 10:12:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21031 for ; Wed, 29 Jan 2003 10:12:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TFVAJ00500; Wed, 29 Jan 2003 10:31:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TFQnJ00336 for ; Wed, 29 Jan 2003 10:26:49 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20923 for ; Wed, 29 Jan 2003 10:04:47 -0500 (EST) From: assingh@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0TF6xj00976 for ; Wed, 29 Jan 2003 20:36:59 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0TF6wM00970 for ; Wed, 29 Jan 2003 20:36:58 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h0TF9Hc07994 for ; Wed, 29 Jan 2003 20:39:17 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CBD.005279FD ; Wed, 29 Jan 2003 20:30:51 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CBD.005279D8.00@sandesh.hss.hns.com> Date: Wed, 29 Jan 2003 20:40:39 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Sequential Signal List Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, A sequential signal list consists of a signal list identifier and a sequence of signals to be played sequentially. Each Signal of this list consists of signal name along with optional parameters like Stream id, Signal type, Signal duration, Notify Completion reasons and Keep Active flag. I am listing down my queries below. 1) Protocol Grammar allows the use of Notify Completion reasons with the signals in Sequential signal list. Is there any practical scenario, in which MGC is interested in getting Signal Completion notification after completion of each signal of sequential list. Rather MGC will be interested in getting Signal Completion notification after completion of whole sequential list. Since Notify Completion reason is attached with indivisual signals and not with sequential list, so how will MGC indicate MG to do so. 2) Protocol Grammar allows the use of different stream ids with the signals in Sequential signal list. But is there any practical scenario, in which a sequential signal list contains signals to be played on different streams. or All signals in sequential signal list shall refer to the same stream. 3) What is significance of Keep active flag with each signal of sequential list? Thanks in advance. Thanks N Regards Ashish Singh Hughes Software Systems DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 29 10:13:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21049 for ; Wed, 29 Jan 2003 10:13:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0TFYqg00694 for megaco-archive@odin.ietf.org; Wed, 29 Jan 2003 10:34:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TFYqJ00691 for ; Wed, 29 Jan 2003 10:34:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21045 for ; Wed, 29 Jan 2003 10:12:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TFVAJ00500; Wed, 29 Jan 2003 10:31:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TFQnJ00336 for ; Wed, 29 Jan 2003 10:26:49 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20923 for ; Wed, 29 Jan 2003 10:04:47 -0500 (EST) From: assingh@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0TF6xj00976 for ; Wed, 29 Jan 2003 20:36:59 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0TF6wM00970 for ; Wed, 29 Jan 2003 20:36:58 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h0TF9Hc07994 for ; Wed, 29 Jan 2003 20:39:17 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CBD.005279FD ; Wed, 29 Jan 2003 20:30:51 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CBD.005279D8.00@sandesh.hss.hns.com> Date: Wed, 29 Jan 2003 20:40:39 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Sequential Signal List Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, A sequential signal list consists of a signal list identifier and a sequence of signals to be played sequentially. Each Signal of this list consists of signal name along with optional parameters like Stream id, Signal type, Signal duration, Notify Completion reasons and Keep Active flag. I am listing down my queries below. 1) Protocol Grammar allows the use of Notify Completion reasons with the signals in Sequential signal list. Is there any practical scenario, in which MGC is interested in getting Signal Completion notification after completion of each signal of sequential list. Rather MGC will be interested in getting Signal Completion notification after completion of whole sequential list. Since Notify Completion reason is attached with indivisual signals and not with sequential list, so how will MGC indicate MG to do so. 2) Protocol Grammar allows the use of different stream ids with the signals in Sequential signal list. But is there any practical scenario, in which a sequential signal list contains signals to be played on different streams. or All signals in sequential signal list shall refer to the same stream. 3) What is significance of Keep active flag with each signal of sequential list? Thanks in advance. Thanks N Regards Ashish Singh Hughes Software Systems DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Jan 29 11:57:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23513 for ; Wed, 29 Jan 2003 11:57:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0THGCJ07996; Wed, 29 Jan 2003 12:16:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0THEjJ07927 for ; Wed, 29 Jan 2003 12:14:45 -0500 Received: from sparky.afc.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23431 for ; Wed, 29 Jan 2003 11:52:41 -0500 (EST) Received: (qmail 30231 invoked from network); 29 Jan 2003 16:51:50 -0000 Received: from unknown (HELO zzzconn03.fibre.com) (10.1.4.53) by 0 with SMTP; 29 Jan 2003 16:51:50 -0000 Received: FROM xconn01.fibre.com BY zzzconn03.fibre.com ; Wed Jan 29 08:56:34 2003 -0800 Received: by xconn01.fibre.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Jan 2003 08:55:20 -0800 Message-ID: From: John Stock To: "'Fernando Vallejo Lazaro'" , John Stock Cc: "'Kevin Boyle'" , Anil Jangam , Terry L Anderson , Raphael Tryster , Tom-PT Taylor , megaco@ietf.org, SHRI KUMAR Subject: RE: [Megaco] State of the termination after failure of a command. Date: Wed, 29 Jan 2003 08:56:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C7B7.528E8650" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2C7B7.528E8650 Content-Type: text/plain; charset="iso-8859-1" Thanks for your description and correction - I forgot the context ID would be different for the two offhook cases. W/regards to the incoming vs. outgoing priority, I had heard this was an operator-provisionable option in the V5.N protocol (non-North America). In the North American GR303 protocol it is not provisionable, at least as it affects the Q.931 (resource management) part of the protocol; internally in the Class 5 switch I'm not sure about. Like you say this is the MGC's concern though. Thanks, John -----Original Message----- From: Fernando Vallejo Lazaro [mailto:Fernando.Vallejo_Lazaro@alcatel.es] Sent: Wednesday, January 29, 2003 2:15 AM To: John Stock Cc: 'Kevin Boyle'; Anil Jangam; Terry L Anderson; Raphael Tryster; Tom-PT Taylor; megaco@ietf.org; SHRI KUMAR Subject: Re: [Megaco] State of the termination after failure of a command. Hi John, See my comments below [FVL] John Stock wrote: Along this line of discussion, I was wondering about this case that provides a twist - - MGC receives a ring-in, and sends Add commands to MG with the al/ri signal - The MG detects offhook before it receives the Add commands, resulting in a Notify with al/of to the MGC. The preferred result would probably be to connect the line with the incoming call, as is done in traditional PSTN. From the MGC's perspective, it just receives the offhook after sending the Adds for the ringin, so it just appears that the line is answering the ring. [FVL] The preferred result depends on the operator. Sometimes the terminating call has a higher priority, but in other cases it is originating priority. The Notify received by the MGC tells the context to which the termination belonged, so the MGC will know if it has been before applying ringing (termination in the NULL context) or after it (termination in the new context created by the Add) and it will be able to act accordingly. However the MG now is in a quandary. It should accept the Add commands from the MGC, possibly along with the al/ri signal. However you don't want to apply ringing to a line that's offhook, especially since the MGC will not know to give any indication to the MG to stop ringing. The MGC thinks the MG already stopped ringing due to the offhook event, however in the MG the offhook event preceded the ring signal. [FVL] If the al/ri is applied after the off hook, then I think that the MGC can indicate the MG to stop ringing immediately. So the MG cannot apply this signal, due to its knowledge of the line state, and not due to any network or resource failures. Thus does the MG fail the ring signal? If so, does this mean the Add commands (in which the signal is embedded) also fail? What would be the value of the error descriptor (I couldn't find one that applies)? [FVL] In any case I think that the MG does not have to send an error although the situation is not coherent. It is up to the MGC to restore a good state. It seems in this case it may be appropriate for the MG to decide what is considered a failure, and just accept the ring signal even though it doesn't actually apply it. There are other ways to handle it too, like sending a Signal Completion event to the MGC, though this requires the MGC to ask for it in the Events descriptor. Thanks, John Regards Fernando -----Original Message----- From: Kevin Boyle [ mailto:kboyle@nortelnetworks.com ] Sent: Monday, October 21, 2002 8:12 AM To: Anil Jangam; Terry L Anderson; Raphael Tryster Cc: Tom-PT Taylor; megaco@ietf.org; SHRI KUMAR Subject: RE: [Megaco] State of the termination after failure of a command. More comments inline. [KJBII] Kevin -----Original Message----- From: Anil Jangam [ mailto:anilj@mahindrabt.com ] Sent: Monday, October 21, 2002 10:43 AM To: Terry L Anderson; Raphael Tryster Cc: Taylor, Tom-PT [CAR:B602:EXCH]; megaco@ietf.org; SHRI KUMAR; Boyle, Kevin [NCRTP:3R90:EXCH] Subject: Re: [Megaco] State of the termination after failure of a command. Hi Terry, see inline... headed with [anil]. /anil. ----- Original Message ----- From: "Terry L Anderson" To: "Raphael Tryster" Cc: "Tom-PT Taylor" ; "'Anil Jangam'" ; ; "SHRI KUMAR" ; "Kevin Boyle" Sent: Monday, October 21, 2002 5:59 PM Subject: Re: [Megaco] State of the termination after failure of a command. > I am not sure that we would want to make a narrow exception to the > general principle just for signals. I think if any descriptor "fails" > then the command fails. But that being said we DO have to be careful > of what is considered a failure. There are certainly things that can > fail about a signal well after the signal has begun playing that I > would not consider a error of the descriptor, just as failure of the > network is not an error in the Local/Remote descriptors. > [anil] I disagree to your approach. I think detecting something that has failed (say network failure) and doing nothing is of no use. What standard says about restoring the state of the Termination is the corrective mesures to be taken in case of the failure conditions. What is you have mentioned about accepting the descriptor (in other words validating the descriptor) is just a preventive measure. We have to take some actions when something goes wrong. [KJBII] Actually, you don't. It is the prerogative of the MGC to clean up after errors as it sees fit. The MG should "as far as possible" restore the previous state, and then wait for the MGC to act. Autonomous cleanup by the MG will most certainly lead to state mismatches between the MG and MGC. > In the specific case you raise, I would expect that the MG should > "reserve resources" for all signals when it accepts the descriptor. > If it has no ability to play cg/bt because it is not implemented or > some other resource limit as known at the time the descriptor is > received, then I would expect it to return an error failing the entire > command. On the other hand, if (as far as it knows when the > descriptor is > received) it can play them, it should return success immediately and > notify in any other appropriate way (if events are set) about any sort > of later failure. > [anil] I agree that once the validation (i.e. preventive measure) is done, you ask for the notification reporting the status of the execution. Say in the end, the execution of the signal has failed, then we can not leave it as it is. Take an example of call hold scenario. If you (the controlling leg) have toggled from one party to other, you would normally remove the hold tone on held party/termination and play hold tone on the active party/termination. Now you move from one context to another. Mean time the removal of the hold tone on the held party has failed, and still you try to talk to it, then what you (MG) would do???? In this case, can't we call the above failure condition as failure of the descriptor, and would try to restore (i.e. corrective measure) the state to the previous state??? [KJBII] You would hook the two parties up, and continue with the service. If the MGC asked for notification of signal completion for held tone, then the MG will send that notification to the MGC. Otherwise, the MG should not take ANY action on it's own, without explicit direction from the MGC. /anil. ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco -- Fernando Vallejo Lazaro Phone: +34 91 330 8279 SW Wireline ASD-Madrid ALCATEL ------_=_NextPart_001_01C2C7B7.528E8650 Content-Type: text/html; charset="iso-8859-1"
Thanks for your description and correction - I forgot the context ID would be different for the two offhook cases.
 
W/regards to the incoming vs. outgoing priority, I had heard this was an operator-provisionable option in the V5.N protocol (non-North America).  In the North American GR303 protocol it is not provisionable, at least as it affects the Q.931 (resource management) part of the protocol; internally in the Class 5 switch I'm not sure about.  Like you say this is the MGC's concern though.
 
Thanks,
John
-----Original Message-----
From: Fernando Vallejo Lazaro [mailto:Fernando.Vallejo_Lazaro@alcatel.es]
Sent: Wednesday, January 29, 2003 2:15 AM
To: John Stock
Cc: 'Kevin Boyle'; Anil Jangam; Terry L Anderson; Raphael Tryster; Tom-PT Taylor; megaco@ietf.org; SHRI KUMAR
Subject: Re: [Megaco] State of the termination after failure of a command.

Hi John,

See my comments below [FVL]

John Stock wrote:

Along this line of discussion, I was wondering about this case that provides
a twist -

- MGC receives a ring-in, and sends Add commands to MG with the al/ri signal
- The MG detects offhook before it receives the Add commands, resulting in a
Notify with al/of to the MGC.

The preferred result would probably be to connect the line with the incoming
call, as is done in traditional PSTN.  From the MGC's perspective, it just
receives the offhook after sending the Adds for the ringin, so it just
appears that the line is answering the ring.

[FVL] The preferred result depends on the operator. Sometimes the terminating
call has a higher priority, but in other cases it is originating priority.
The Notify received by the MGC tells the context to which the termination belonged,
so the MGC will know if it has been before applying ringing (termination in the NULL
context) or after it (termination in the new context created by the Add) and it will be
able to act accordingly.
 
 

However the MG now is in a quandary.  It should accept the Add commands from
the MGC, possibly along with the al/ri signal.  However you don't want to
apply ringing to a line that's offhook, especially since the MGC will not
know to give any indication to the MG to stop ringing.  The MGC thinks the
MG already stopped ringing due to the offhook event, however in the MG the
offhook event preceded the ring signal.

[FVL] If the al/ri is applied after the off hook, then I think that the MGC can indicate the MG
to stop ringing immediately.
 

So the MG cannot apply this signal, due to its knowledge of the line state,
and not due to any network or resource failures.

Thus does the MG fail the ring signal?  If so, does this mean the Add
commands (in which the signal is embedded) also fail?  What would be the
value of the error descriptor (I couldn't find one that applies)?
 

[FVL] In any case I think that the MG does not have to send an error although the
situation is not coherent. It is up to the MGC to restore a good state.

It seems in this case it may be appropriate for the MG to decide what is
considered a failure, and just accept the ring signal even though it doesn't
actually apply it.  There are other ways to handle it too, like sending a
Signal Completion event to the MGC, though this requires the MGC to ask for
it in the Events descriptor.

Thanks,
John


Regards
Fernando
 

 

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Monday, October 21, 2002 8:12 AM
To: Anil Jangam; Terry L Anderson; Raphael Tryster
Cc: Tom-PT Taylor; megaco@ietf.org; SHRI KUMAR
Subject: RE: [Megaco] State of the termination after failure of a
command.

More comments inline. [KJBII]

Kevin

-----Original Message-----
From: Anil Jangam [mailto:anilj@mahindrabt.com]
Sent: Monday, October 21, 2002 10:43 AM
To: Terry L Anderson; Raphael Tryster
Cc: Taylor, Tom-PT [CAR:B602:EXCH]; megaco@ietf.org; SHRI KUMAR; Boyle,
Kevin [NCRTP:3R90:EXCH]
Subject: Re: [Megaco] State of the termination after failure of a command.

Hi Terry,

see inline... headed with [anil].

/anil.

----- Original Message -----
From: "Terry L Anderson" <tlatla@verizon.net>
To: "Raphael Tryster" <raphael@tdsoft.com>
Cc: "Tom-PT Taylor" <taylor@nortelnetworks.com>; "'Anil Jangam'"
<anilj@mahindrabt.com>; <megaco@ietf.org>; "SHRI KUMAR"
<manikaran1947@yahoo.co.in>; "Kevin Boyle" <kboyle@nortelnetworks.com>
Sent: Monday, October 21, 2002 5:59 PM
Subject: Re: [Megaco] State of the termination after failure of a command.

> I am not sure that we would want to make a narrow exception to the
> general principle just for signals.  I think if any descriptor "fails"
> then the command fails.  But that being said we DO have to be careful
> of what is considered a failure.  There are certainly things that can
> fail about a signal well after the signal has begun playing that I
> would not consider a error of the descriptor, just as failure of the
> network is not an error in the Local/Remote descriptors.
>
[anil] I disagree to your approach. I think detecting something that has
failed (say network failure) and doing nothing is of no use. What standard
says about restoring the state of the Termination is the corrective mesures
to be taken in case of the failure conditions. What is you have mentioned
about accepting the descriptor (in other words validating the descriptor) is
just a preventive measure. We have to take some actions when something goes
wrong.
[KJBII] Actually, you don't.  It is the prerogative of the MGC to clean up
after errors as it sees fit.  The MG should "as far as possible" restore the
previous state, and then wait for the MGC to act.  Autonomous cleanup by the
MG will most certainly lead to state mismatches between the MG and MGC.

> In the specific case you raise, I would expect that the MG should
> "reserve resources" for all signals when it accepts the descriptor.
> If it has no ability to play cg/bt because it is not implemented or
> some other resource limit as known at the time the descriptor is
> received, then I would expect it to return an error failing the entire
> command.  On the other hand, if (as far as it knows when the
> descriptor is
> received) it can play them, it should return success immediately and
> notify in any other appropriate way (if events are set) about any sort
> of later failure.
>
[anil] I agree that once the validation (i.e. preventive measure) is done,
you ask for the notification reporting the status of the execution. Say in
the end, the execution of the signal has failed, then we can not leave it as
it is. Take an example of call hold scenario. If you (the controlling leg)
have toggled from one party to other, you would normally remove the hold
tone on held party/termination and play hold tone on the active
party/termination. Now you move from one context to another. Mean time the
removal of the hold tone on the held party has failed, and still you try to
talk to it, then what you (MG) would do???? In this case, can't we call the
above failure condition as failure of the descriptor, and would try to
restore (i.e. corrective measure) the state to the previous state???
[KJBII] You would hook the two parties up, and continue with the service.
If the MGC asked for notification of signal completion for held tone, then
the MG will send that notification to the MGC.  Otherwise, the MG should not
take ANY action on it's own, without explicit direction from the MGC.

/anil.

*********************************************************
Disclaimer

This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com

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

-- 
Fernando Vallejo Lazaro
Phone:  +34 91 330 8279
SW  Wireline ASD-Madrid
       ALCATEL
 
------_=_NextPart_001_01C2C7B7.528E8650-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Jan 29 11:57:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23543 for ; Wed, 29 Jan 2003 11:57:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0THJAI08175 for megaco-archive@odin.ietf.org; Wed, 29 Jan 2003 12:19:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0THJAJ08172 for ; Wed, 29 Jan 2003 12:19:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23530 for ; Wed, 29 Jan 2003 11:57:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0THGCJ07996; Wed, 29 Jan 2003 12:16:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0THEjJ07927 for ; Wed, 29 Jan 2003 12:14:45 -0500 Received: from sparky.afc.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23431 for ; Wed, 29 Jan 2003 11:52:41 -0500 (EST) Received: (qmail 30231 invoked from network); 29 Jan 2003 16:51:50 -0000 Received: from unknown (HELO zzzconn03.fibre.com) (10.1.4.53) by 0 with SMTP; 29 Jan 2003 16:51:50 -0000 Received: FROM xconn01.fibre.com BY zzzconn03.fibre.com ; Wed Jan 29 08:56:34 2003 -0800 Received: by xconn01.fibre.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Jan 2003 08:55:20 -0800 Message-ID: From: John Stock To: "'Fernando Vallejo Lazaro'" , John Stock Cc: "'Kevin Boyle'" , Anil Jangam , Terry L Anderson , Raphael Tryster , Tom-PT Taylor , megaco@ietf.org, SHRI KUMAR Subject: RE: [Megaco] State of the termination after failure of a command. Date: Wed, 29 Jan 2003 08:56:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C7B7.528E8650" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2C7B7.528E8650 Content-Type: text/plain; charset="iso-8859-1" Thanks for your description and correction - I forgot the context ID would be different for the two offhook cases. W/regards to the incoming vs. outgoing priority, I had heard this was an operator-provisionable option in the V5.N protocol (non-North America). In the North American GR303 protocol it is not provisionable, at least as it affects the Q.931 (resource management) part of the protocol; internally in the Class 5 switch I'm not sure about. Like you say this is the MGC's concern though. Thanks, John -----Original Message----- From: Fernando Vallejo Lazaro [mailto:Fernando.Vallejo_Lazaro@alcatel.es] Sent: Wednesday, January 29, 2003 2:15 AM To: John Stock Cc: 'Kevin Boyle'; Anil Jangam; Terry L Anderson; Raphael Tryster; Tom-PT Taylor; megaco@ietf.org; SHRI KUMAR Subject: Re: [Megaco] State of the termination after failure of a command. Hi John, See my comments below [FVL] John Stock wrote: Along this line of discussion, I was wondering about this case that provides a twist - - MGC receives a ring-in, and sends Add commands to MG with the al/ri signal - The MG detects offhook before it receives the Add commands, resulting in a Notify with al/of to the MGC. The preferred result would probably be to connect the line with the incoming call, as is done in traditional PSTN. From the MGC's perspective, it just receives the offhook after sending the Adds for the ringin, so it just appears that the line is answering the ring. [FVL] The preferred result depends on the operator. Sometimes the terminating call has a higher priority, but in other cases it is originating priority. The Notify received by the MGC tells the context to which the termination belonged, so the MGC will know if it has been before applying ringing (termination in the NULL context) or after it (termination in the new context created by the Add) and it will be able to act accordingly. However the MG now is in a quandary. It should accept the Add commands from the MGC, possibly along with the al/ri signal. However you don't want to apply ringing to a line that's offhook, especially since the MGC will not know to give any indication to the MG to stop ringing. The MGC thinks the MG already stopped ringing due to the offhook event, however in the MG the offhook event preceded the ring signal. [FVL] If the al/ri is applied after the off hook, then I think that the MGC can indicate the MG to stop ringing immediately. So the MG cannot apply this signal, due to its knowledge of the line state, and not due to any network or resource failures. Thus does the MG fail the ring signal? If so, does this mean the Add commands (in which the signal is embedded) also fail? What would be the value of the error descriptor (I couldn't find one that applies)? [FVL] In any case I think that the MG does not have to send an error although the situation is not coherent. It is up to the MGC to restore a good state. It seems in this case it may be appropriate for the MG to decide what is considered a failure, and just accept the ring signal even though it doesn't actually apply it. There are other ways to handle it too, like sending a Signal Completion event to the MGC, though this requires the MGC to ask for it in the Events descriptor. Thanks, John Regards Fernando -----Original Message----- From: Kevin Boyle [ mailto:kboyle@nortelnetworks.com ] Sent: Monday, October 21, 2002 8:12 AM To: Anil Jangam; Terry L Anderson; Raphael Tryster Cc: Tom-PT Taylor; megaco@ietf.org; SHRI KUMAR Subject: RE: [Megaco] State of the termination after failure of a command. More comments inline. [KJBII] Kevin -----Original Message----- From: Anil Jangam [ mailto:anilj@mahindrabt.com ] Sent: Monday, October 21, 2002 10:43 AM To: Terry L Anderson; Raphael Tryster Cc: Taylor, Tom-PT [CAR:B602:EXCH]; megaco@ietf.org; SHRI KUMAR; Boyle, Kevin [NCRTP:3R90:EXCH] Subject: Re: [Megaco] State of the termination after failure of a command. Hi Terry, see inline... headed with [anil]. /anil. ----- Original Message ----- From: "Terry L Anderson" To: "Raphael Tryster" Cc: "Tom-PT Taylor" ; "'Anil Jangam'" ; ; "SHRI KUMAR" ; "Kevin Boyle" Sent: Monday, October 21, 2002 5:59 PM Subject: Re: [Megaco] State of the termination after failure of a command. > I am not sure that we would want to make a narrow exception to the > general principle just for signals. I think if any descriptor "fails" > then the command fails. But that being said we DO have to be careful > of what is considered a failure. There are certainly things that can > fail about a signal well after the signal has begun playing that I > would not consider a error of the descriptor, just as failure of the > network is not an error in the Local/Remote descriptors. > [anil] I disagree to your approach. I think detecting something that has failed (say network failure) and doing nothing is of no use. What standard says about restoring the state of the Termination is the corrective mesures to be taken in case of the failure conditions. What is you have mentioned about accepting the descriptor (in other words validating the descriptor) is just a preventive measure. We have to take some actions when something goes wrong. [KJBII] Actually, you don't. It is the prerogative of the MGC to clean up after errors as it sees fit. The MG should "as far as possible" restore the previous state, and then wait for the MGC to act. Autonomous cleanup by the MG will most certainly lead to state mismatches between the MG and MGC. > In the specific case you raise, I would expect that the MG should > "reserve resources" for all signals when it accepts the descriptor. > If it has no ability to play cg/bt because it is not implemented or > some other resource limit as known at the time the descriptor is > received, then I would expect it to return an error failing the entire > command. On the other hand, if (as far as it knows when the > descriptor is > received) it can play them, it should return success immediately and > notify in any other appropriate way (if events are set) about any sort > of later failure. > [anil] I agree that once the validation (i.e. preventive measure) is done, you ask for the notification reporting the status of the execution. Say in the end, the execution of the signal has failed, then we can not leave it as it is. Take an example of call hold scenario. If you (the controlling leg) have toggled from one party to other, you would normally remove the hold tone on held party/termination and play hold tone on the active party/termination. Now you move from one context to another. Mean time the removal of the hold tone on the held party has failed, and still you try to talk to it, then what you (MG) would do???? In this case, can't we call the above failure condition as failure of the descriptor, and would try to restore (i.e. corrective measure) the state to the previous state??? [KJBII] You would hook the two parties up, and continue with the service. If the MGC asked for notification of signal completion for held tone, then the MG will send that notification to the MGC. Otherwise, the MG should not take ANY action on it's own, without explicit direction from the MGC. /anil. ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco -- Fernando Vallejo Lazaro Phone: +34 91 330 8279 SW Wireline ASD-Madrid ALCATEL ------_=_NextPart_001_01C2C7B7.528E8650 Content-Type: text/html; charset="iso-8859-1"
Thanks for your description and correction - I forgot the context ID would be different for the two offhook cases.
 
W/regards to the incoming vs. outgoing priority, I had heard this was an operator-provisionable option in the V5.N protocol (non-North America).  In the North American GR303 protocol it is not provisionable, at least as it affects the Q.931 (resource management) part of the protocol; internally in the Class 5 switch I'm not sure about.  Like you say this is the MGC's concern though.
 
Thanks,
John
-----Original Message-----
From: Fernando Vallejo Lazaro [mailto:Fernando.Vallejo_Lazaro@alcatel.es]
Sent: Wednesday, January 29, 2003 2:15 AM
To: John Stock
Cc: 'Kevin Boyle'; Anil Jangam; Terry L Anderson; Raphael Tryster; Tom-PT Taylor; megaco@ietf.org; SHRI KUMAR
Subject: Re: [Megaco] State of the termination after failure of a command.

Hi John,

See my comments below [FVL]

John Stock wrote:

Along this line of discussion, I was wondering about this case that provides
a twist -

- MGC receives a ring-in, and sends Add commands to MG with the al/ri signal
- The MG detects offhook before it receives the Add commands, resulting in a
Notify with al/of to the MGC.

The preferred result would probably be to connect the line with the incoming
call, as is done in traditional PSTN.  From the MGC's perspective, it just
receives the offhook after sending the Adds for the ringin, so it just
appears that the line is answering the ring.

[FVL] The preferred result depends on the operator. Sometimes the terminating
call has a higher priority, but in other cases it is originating priority.
The Notify received by the MGC tells the context to which the termination belonged,
so the MGC will know if it has been before applying ringing (termination in the NULL
context) or after it (termination in the new context created by the Add) and it will be
able to act accordingly.
 
 

However the MG now is in a quandary.  It should accept the Add commands from
the MGC, possibly along with the al/ri signal.  However you don't want to
apply ringing to a line that's offhook, especially since the MGC will not
know to give any indication to the MG to stop ringing.  The MGC thinks the
MG already stopped ringing due to the offhook event, however in the MG the
offhook event preceded the ring signal.

[FVL] If the al/ri is applied after the off hook, then I think that the MGC can indicate the MG
to stop ringing immediately.
 

So the MG cannot apply this signal, due to its knowledge of the line state,
and not due to any network or resource failures.

Thus does the MG fail the ring signal?  If so, does this mean the Add
commands (in which the signal is embedded) also fail?  What would be the
value of the error descriptor (I couldn't find one that applies)?
 

[FVL] In any case I think that the MG does not have to send an error although the
situation is not coherent. It is up to the MGC to restore a good state.

It seems in this case it may be appropriate for the MG to decide what is
considered a failure, and just accept the ring signal even though it doesn't
actually apply it.  There are other ways to handle it too, like sending a
Signal Completion event to the MGC, though this requires the MGC to ask for
it in the Events descriptor.

Thanks,
John


Regards
Fernando
 

 

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Monday, October 21, 2002 8:12 AM
To: Anil Jangam; Terry L Anderson; Raphael Tryster
Cc: Tom-PT Taylor; megaco@ietf.org; SHRI KUMAR
Subject: RE: [Megaco] State of the termination after failure of a
command.

More comments inline. [KJBII]

Kevin

-----Original Message-----
From: Anil Jangam [mailto:anilj@mahindrabt.com]
Sent: Monday, October 21, 2002 10:43 AM
To: Terry L Anderson; Raphael Tryster
Cc: Taylor, Tom-PT [CAR:B602:EXCH]; megaco@ietf.org; SHRI KUMAR; Boyle,
Kevin [NCRTP:3R90:EXCH]
Subject: Re: [Megaco] State of the termination after failure of a command.

Hi Terry,

see inline... headed with [anil].

/anil.

----- Original Message -----
From: "Terry L Anderson" <tlatla@verizon.net>
To: "Raphael Tryster" <raphael@tdsoft.com>
Cc: "Tom-PT Taylor" <taylor@nortelnetworks.com>; "'Anil Jangam'"
<anilj@mahindrabt.com>; <megaco@ietf.org>; "SHRI KUMAR"
<manikaran1947@yahoo.co.in>; "Kevin Boyle" <kboyle@nortelnetworks.com>
Sent: Monday, October 21, 2002 5:59 PM
Subject: Re: [Megaco] State of the termination after failure of a command.

> I am not sure that we would want to make a narrow exception to the
> general principle just for signals.  I think if any descriptor "fails"
> then the command fails.  But that being said we DO have to be careful
> of what is considered a failure.  There are certainly things that can
> fail about a signal well after the signal has begun playing that I
> would not consider a error of the descriptor, just as failure of the
> network is not an error in the Local/Remote descriptors.
>
[anil] I disagree to your approach. I think detecting something that has
failed (say network failure) and doing nothing is of no use. What standard
says about restoring the state of the Termination is the corrective mesures
to be taken in case of the failure conditions. What is you have mentioned
about accepting the descriptor (in other words validating the descriptor) is
just a preventive measure. We have to take some actions when something goes
wrong.
[KJBII] Actually, you don't.  It is the prerogative of the MGC to clean up
after errors as it sees fit.  The MG should "as far as possible" restore the
previous state, and then wait for the MGC to act.  Autonomous cleanup by the
MG will most certainly lead to state mismatches between the MG and MGC.

> In the specific case you raise, I would expect that the MG should
> "reserve resources" for all signals when it accepts the descriptor.
> If it has no ability to play cg/bt because it is not implemented or
> some other resource limit as known at the time the descriptor is
> received, then I would expect it to return an error failing the entire
> command.  On the other hand, if (as far as it knows when the
> descriptor is
> received) it can play them, it should return success immediately and
> notify in any other appropriate way (if events are set) about any sort
> of later failure.
>
[anil] I agree that once the validation (i.e. preventive measure) is done,
you ask for the notification reporting the status of the execution. Say in
the end, the execution of the signal has failed, then we can not leave it as
it is. Take an example of call hold scenario. If you (the controlling leg)
have toggled from one party to other, you would normally remove the hold
tone on held party/termination and play hold tone on the active
party/termination. Now you move from one context to another. Mean time the
removal of the hold tone on the held party has failed, and still you try to
talk to it, then what you (MG) would do???? In this case, can't we call the
above failure condition as failure of the descriptor, and would try to
restore (i.e. corrective measure) the state to the previous state???
[KJBII] You would hook the two parties up, and continue with the service.
If the MGC asked for notification of signal completion for held tone, then
the MG will send that notification to the MGC.  Otherwise, the MG should not
take ANY action on it's own, without explicit direction from the MGC.

/anil.

*********************************************************
Disclaimer

This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com

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

-- 
Fernando Vallejo Lazaro
Phone:  +34 91 330 8279
SW  Wireline ASD-Madrid
       ALCATEL
 
------_=_NextPart_001_01C2C7B7.528E8650-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jan 30 01:17:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10011 for ; Thu, 30 Jan 2003 01:17:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0U2qBB13396 for megaco-archive@odin.ietf.org; Wed, 29 Jan 2003 21:52:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U2qAJ13393 for ; Wed, 29 Jan 2003 21:52:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05991 for ; Wed, 29 Jan 2003 21:29:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U2o8J13301; Wed, 29 Jan 2003 21:50:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U2iwJ13083 for ; Wed, 29 Jan 2003 21:44:58 -0500 Received: from ish7.ericsson.com.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05933 for ; Wed, 29 Jan 2003 21:22:42 -0500 (EST) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id h0U2O0G02934; Thu, 30 Jan 2003 13:24:00 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h0U2QBE13493; Thu, 30 Jan 2003 13:26:11 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.194]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DZ356WBY; Thu, 30 Jan 2003 13:26:09 +1100 Message-ID: <3E387BB9.27BD0F1C@ericsson.com.au> Date: Thu, 30 Jan 2003 12:11:21 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: shbansal@hss.hns.com CC: manfred.volz@nokia.com, megaco@ietf.org Subject: Re: [Megaco] ALL in Topology descriptor and CHOOSE in command References: <65256CB8.00312C83.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, I stand by what I stated you need it inspect the topology descriptor first. ie. "The Topology descriptor occurs before the commands in an action." To complete the topology descriptor you may need to look ahead in subsequent commands in the case their is a "?" to get the relevant TID or the topology triple contains a TID that is introduced to the context by an additional ADD command. So you need to be sure at least that the TID is available. To successfully execute the topology descriptor. The commands themselves are then executed. If they fail then a TID will be returned with the error message and the MGC can then fix the set topology if need be. Regards, Christian shbansal@hss.hns.com wrote: > > Hi Chris, > > In earlier mails it was stated that > > Section 7.1.18 means that you must consider the topology descriptor before > addressing the > commands. You should then use the information that is in the topology descriptor > when you process the commands in the message. > > Now with this implementation the final result should be > T1 is isolated from T2 and > T1 is isolated from T3 and > T2 is bothway connected to T3 > > Correct me if I have some wrong interpretation > > Thanks and regards > Shobhit > > Christian Groves on 01/22/2003 05:36:36 AM > > To: manfred.volz@nokia.com > cc: megaco@ietf.org (bcc: Shobhit Bansal/HSS) > > Subject: Re: [Megaco] ALL in Topology descriptor and CHOOSE in command > > Hello Manfred, > > In accordance to 7.1.18 "The Topology descriptor occurs before the commands in > an action." it would be b). > > Christian > > manfred.volz@NOKIA.COM wrote: > > > > Hi all, > > > > Let's assume we have 2 terminations T1 and T2 which are oneway connected. > > Now we add a new termination T3 with the following topology settings. > > > > Topology (T1,ALL,isolate) > > ADD $ > > > > Which of the following results is correct? > > > > a.) T1 is isolated from T2 and > > T1 is isolated from T3 and > > T2 is bothway connected to T3 > > b.) T1 is isolated from T2 and > > T1 is bothway connected to T3 and > > T2 is bothway connected to T3 > > > > Thanks for your help. > > > > best regards Manfred > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jan 30 01:18:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10034 for ; Thu, 30 Jan 2003 01:18:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0U2qLm13416 for megaco-archive@odin.ietf.org; Wed, 29 Jan 2003 21:52:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U2qLJ13413 for ; Wed, 29 Jan 2003 21:52:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05997 for ; Wed, 29 Jan 2003 21:30:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U2ndJ13259; Wed, 29 Jan 2003 21:49:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U2iuJ13077 for ; Wed, 29 Jan 2003 21:44:56 -0500 Received: from ish7.ericsson.com.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05931 for ; Wed, 29 Jan 2003 21:22:40 -0500 (EST) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id h0U2NwG02926; Thu, 30 Jan 2003 13:23:58 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h0U2Q9E13488; Thu, 30 Jan 2003 13:26:09 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.194]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DZ356WBV; Thu, 30 Jan 2003 13:26:07 +1100 Message-ID: <3E387A6D.426E91DD@ericsson.com.au> Date: Thu, 30 Jan 2003 12:05:49 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: assingh@hss.hns.com CC: megaco@ietf.org Subject: Re: [Megaco] Sequential Signal List References: <65256CBD.005279D8.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Please see my comments below. Regards, Christian assingh@hss.hns.com wrote: > > Hi List, > > A sequential signal list consists of a signal list identifier and a sequence of > signals to be played sequentially. > Each Signal of this list consists of signal name along with optional parameters > like Stream id, Signal type, Signal duration, Notify Completion reasons and > Keep Active flag. > > I am listing down my queries below. > > 1) Protocol Grammar allows the use of Notify Completion reasons with the signals > in Sequential signal list. Is there any practical scenario, in which MGC is > interested in getting Signal Completion notification after completion of each > signal of sequential list. [CHG] I don't know of a practical reason to do so, but in the development of the protocol a signal list was seen as a list of individual signals with all the capabilities of stand alone signals. > > Rather MGC will be interested in getting Signal Completion notification after > completion of whole sequential list. Since Notify Completion reason is attached > with indivisual signals and not with sequential list, so how will MGC indicate > MG to do so. [CHG] Just put notify completion on the last signal in the list. > > 2) Protocol Grammar allows the use of different stream ids with the signals in > Sequential signal list. But is there any practical scenario, in which a > sequential signal list contains signals to be played on different streams. or > All signals in sequential signal list shall refer to the same stream. [CHG] I don't know of any practical usage in PSTN/ISDN telephony that would need this but for multimedia I could see a case where you would synchronise between video and voice streams. > > 3) What is significance of Keep active flag with each signal of sequential list? [CHG] None, as a replacement with the same SignalListID ensures that the signals continue to play. > > Thanks in advance. > > Thanks N Regards > Ashish Singh > Hughes Software Systems > > DISCLAIMER: This message is proprietary to Hughes Software Systems > Limited (HSS) and is intended solely for the use of the individual > to whom it is addressed. It may contain privileged or confidential > information and should not be circulated or used for any purpose other > than for what it is intended. If you have received this message in error, > please notify the originator immediately. If you are not the intended > recipient, you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. HSS accepts > no responsibility for loss or damage arising from the use of the information > transmitted by this email including damage from virus. > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jan 30 01:56:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10865 for ; Thu, 30 Jan 2003 01:56:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U2o8J13301; Wed, 29 Jan 2003 21:50:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U2iwJ13083 for ; Wed, 29 Jan 2003 21:44:58 -0500 Received: from ish7.ericsson.com.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05933 for ; Wed, 29 Jan 2003 21:22:42 -0500 (EST) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id h0U2O0G02934; Thu, 30 Jan 2003 13:24:00 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h0U2QBE13493; Thu, 30 Jan 2003 13:26:11 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.194]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DZ356WBY; Thu, 30 Jan 2003 13:26:09 +1100 Message-ID: <3E387BB9.27BD0F1C@ericsson.com.au> Date: Thu, 30 Jan 2003 12:11:21 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: shbansal@hss.hns.com CC: manfred.volz@nokia.com, megaco@ietf.org Subject: Re: [Megaco] ALL in Topology descriptor and CHOOSE in command References: <65256CB8.00312C83.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello, I stand by what I stated you need it inspect the topology descriptor first. ie. "The Topology descriptor occurs before the commands in an action." To complete the topology descriptor you may need to look ahead in subsequent commands in the case their is a "?" to get the relevant TID or the topology triple contains a TID that is introduced to the context by an additional ADD command. So you need to be sure at least that the TID is available. To successfully execute the topology descriptor. The commands themselves are then executed. If they fail then a TID will be returned with the error message and the MGC can then fix the set topology if need be. Regards, Christian shbansal@hss.hns.com wrote: > > Hi Chris, > > In earlier mails it was stated that > > Section 7.1.18 means that you must consider the topology descriptor before > addressing the > commands. You should then use the information that is in the topology descriptor > when you process the commands in the message. > > Now with this implementation the final result should be > T1 is isolated from T2 and > T1 is isolated from T3 and > T2 is bothway connected to T3 > > Correct me if I have some wrong interpretation > > Thanks and regards > Shobhit > > Christian Groves on 01/22/2003 05:36:36 AM > > To: manfred.volz@nokia.com > cc: megaco@ietf.org (bcc: Shobhit Bansal/HSS) > > Subject: Re: [Megaco] ALL in Topology descriptor and CHOOSE in command > > Hello Manfred, > > In accordance to 7.1.18 "The Topology descriptor occurs before the commands in > an action." it would be b). > > Christian > > manfred.volz@NOKIA.COM wrote: > > > > Hi all, > > > > Let's assume we have 2 terminations T1 and T2 which are oneway connected. > > Now we add a new termination T3 with the following topology settings. > > > > Topology (T1,ALL,isolate) > > ADD $ > > > > Which of the following results is correct? > > > > a.) T1 is isolated from T2 and > > T1 is isolated from T3 and > > T2 is bothway connected to T3 > > b.) T1 is isolated from T2 and > > T1 is bothway connected to T3 and > > T2 is bothway connected to T3 > > > > Thanks for your help. > > > > best regards Manfred > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jan 30 01:57:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10886 for ; Thu, 30 Jan 2003 01:57:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U2ndJ13259; Wed, 29 Jan 2003 21:49:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U2iuJ13077 for ; Wed, 29 Jan 2003 21:44:56 -0500 Received: from ish7.ericsson.com.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05931 for ; Wed, 29 Jan 2003 21:22:40 -0500 (EST) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id h0U2NwG02926; Thu, 30 Jan 2003 13:23:58 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h0U2Q9E13488; Thu, 30 Jan 2003 13:26:09 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.194]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DZ356WBV; Thu, 30 Jan 2003 13:26:07 +1100 Message-ID: <3E387A6D.426E91DD@ericsson.com.au> Date: Thu, 30 Jan 2003 12:05:49 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: assingh@hss.hns.com CC: megaco@ietf.org Subject: Re: [Megaco] Sequential Signal List References: <65256CBD.005279D8.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello, Please see my comments below. Regards, Christian assingh@hss.hns.com wrote: > > Hi List, > > A sequential signal list consists of a signal list identifier and a sequence of > signals to be played sequentially. > Each Signal of this list consists of signal name along with optional parameters > like Stream id, Signal type, Signal duration, Notify Completion reasons and > Keep Active flag. > > I am listing down my queries below. > > 1) Protocol Grammar allows the use of Notify Completion reasons with the signals > in Sequential signal list. Is there any practical scenario, in which MGC is > interested in getting Signal Completion notification after completion of each > signal of sequential list. [CHG] I don't know of a practical reason to do so, but in the development of the protocol a signal list was seen as a list of individual signals with all the capabilities of stand alone signals. > > Rather MGC will be interested in getting Signal Completion notification after > completion of whole sequential list. Since Notify Completion reason is attached > with indivisual signals and not with sequential list, so how will MGC indicate > MG to do so. [CHG] Just put notify completion on the last signal in the list. > > 2) Protocol Grammar allows the use of different stream ids with the signals in > Sequential signal list. But is there any practical scenario, in which a > sequential signal list contains signals to be played on different streams. or > All signals in sequential signal list shall refer to the same stream. [CHG] I don't know of any practical usage in PSTN/ISDN telephony that would need this but for multimedia I could see a case where you would synchronise between video and voice streams. > > 3) What is significance of Keep active flag with each signal of sequential list? [CHG] None, as a replacement with the same SignalListID ensures that the signals continue to play. > > Thanks in advance. > > Thanks N Regards > Ashish Singh > Hughes Software Systems > > DISCLAIMER: This message is proprietary to Hughes Software Systems > Limited (HSS) and is intended solely for the use of the individual > to whom it is addressed. It may contain privileged or confidential > information and should not be circulated or used for any purpose other > than for what it is intended. If you have received this message in error, > please notify the originator immediately. If you are not the intended > recipient, you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. HSS accepts > no responsibility for loss or damage arising from the use of the information > transmitted by this email including damage from virus. > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jan 30 03:56:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22346 for ; Thu, 30 Jan 2003 03:56:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U9FNJ15903; Thu, 30 Jan 2003 04:15:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U99fJ15603 for ; Thu, 30 Jan 2003 04:09:41 -0500 Received: from rediffmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA22295 for ; Thu, 30 Jan 2003 03:47:18 -0500 (EST) Received: (qmail 10079 invoked by uid 510); 30 Jan 2003 08:58:19 -0000 Date: 30 Jan 2003 08:58:19 -0000 Message-ID: <20030130085819.10078.qmail@webmail32.rediffmail.com> Received: from unknown (202.144.91.188) by rediffmail.com via HTTP; 30 jan 2003 08:58:19 -0000 MIME-Version: 1.0 From: "Simran Chadha" Reply-To: "Simran Chadha" To: megaco@ietf.org Content-type: multipart/alternative; boundary="Next_1043917099---0-203.199.83.32-10059" Subject: [Megaco] Usage of LocalControl,Local and Remote Descriptors ! Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multipart mime message --Next_1043917099---0-203.199.83.32-10059 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
Hi List,
=0A =0A
Can you = please help me with clarifications in my understanding of sections 7.1.7 an= d 7.1.8 on the use of LocalControl,Local and Remote Descriptors.=0A
 
=0A
A= s per draft-ietf-megaco-3015corr-03, in section 7.1.7,
=0A
= =0A

If the value of a Reserve property is True, the MG SHA= LL reserve resources for all alternatives specified in the Local and/or Rem= ote descriptors for which it currently has resources available. It SHALL re= spond with the alternatives for which it reserves resources. If it cannot n= ot support any of the alternatives, it SHALL respond with a reply to the MG= C that contains empty Local and/or Remote descriptors.

=0A=
The use of two negations -= "cannot not" in the last statement will imply that - If i= t can support any of the alternatives, it SHALL respond with a reply to the= MGC that contains empty Local and/or Remote descriptors.
=0AI don't think this is what i= s meant to be conveyed here. 
=0A
 
=0A
= Also in section 7.1.7 the first= para starts - If the value of a Reserve property is= True, .....
=0A
while the second para starts - If = the value of a Reserve property is False, ....
= =0A
Now as there are two Re= serve properties - one Reserve Group and the other Reserve Value, One could be False and the other = could be True. Then in this case what will be the inferenc= e - Should para 1 apply or para 2 ? Both the paras would seem to be mutuall= y exclusive in what is needed to be done.
=0A
 
= =0A
Also statements like "<= STRONG>if it cannot support any of the alternatives ... " - will h= ave two meanings.
=0A
1. Any -  Not even one - NONE of the alternatives is supported.=
=0A
2. Any -&n= bsp; Atleast one   - While a few alternatives can be supported, a= few might not be.
=0A
 
=0A
The protocol needs to be more clear on such asp= ects in the documents henceforth. The English language is understood in dif= ferent parts of the world. Variations to agreed usage of the language terms= will make it difficult for new users of Megaco protocol, like me.=0A
 
=0A
Can someone please educate me on the exact usage and meaning of LocalContr= ol,Local and Remote Descriptors ?
=0A
 
=0A
<= FONT color=3D#0000ff face=3DArial size=3D2>Thanks and awaiting comments and= clarifications
=0A
 
=0A
Simran Chadha
--Next_1043917099---0-203.199.83.32-10059 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi List,=0D=0A=0D=0ACan you please help me with clarifications in my unders= tanding of sections 7.1.7 and 7.1.8 on the use of LocalControl,Local and Re= mote Descriptors.=0D=0A=0D=0AAs per draft-ietf-megaco-3015corr-03, in secti= on 7.1.7,=0D=0AIf the value of a Reserve property is True, the MG SHALL res= erve resources for all alternatives specified in the Local and/or Remote de= scriptors for which it currently has resources available. It SHALL respond = with the alternatives for which it reserves resources. If it cannot not sup= port any of the alternatives, it SHALL respond with a reply to the MGC that= contains empty Local and/or Remote descriptors. =0D=0AThe use of two negat= ions - "cannot not" in the last statement will imply that - If it can suppo= rt any of the alternatives, it SHALL respond with a reply to the MGC that c= ontains empty Local and/or Remote descriptors.=0D=0AI don't think this is w= hat is meant to be conveyed here. =0D=0A=0D=0AAlso in section 7.1.7 the fir= st para starts - If the value of a Reserve property is True, .....=0D=0Awhi= le the second para starts - If the value of a Reserve property is False, ..= ..=0D=0ANow as there are two Reserve properties - one Reserve Group and the= other Reserve Value, One could be False and the other could be True. Then = in this case what will be the inference - Should para 1 apply or para 2 ? B= oth the paras would seem to be mutually exclusive in what is needed to be d= one.=0D=0A=0D=0AAlso statements like "if it cannot support any of the alter= natives ... " - will have two meanings.=0D=0A1. Any - Not even one - NONE = of the alternatives is supported.=0D=0A2. Any - Atleast one - While a fe= w alternatives can be supported, a few might not be.=0D=0A=0D=0AThe protoco= l needs to be more clear on such aspects in the documents henceforth. The E= nglish language is understood in different parts of the world. Variations t= o agreed usage of the language terms will make it difficult for new users o= f Megaco protocol, like me.=0D=0A=0D=0ACan someone please educate me on the= exact usage and meaning of LocalControl,Local and Remote Descriptors ?=0D= =0A=0D=0AThanks and awaiting comments and clarifications=0D=0A=0D=0ASimran = Chadha --Next_1043917099---0-203.199.83.32-10059-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jan 30 03:56:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22363 for ; Thu, 30 Jan 2003 03:56:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0U9IX816017 for megaco-archive@odin.ietf.org; Thu, 30 Jan 2003 04:18:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U9IXJ16014 for ; Thu, 30 Jan 2003 04:18:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22354 for ; Thu, 30 Jan 2003 03:56:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U9FNJ15903; Thu, 30 Jan 2003 04:15:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U99fJ15603 for ; Thu, 30 Jan 2003 04:09:41 -0500 Received: from rediffmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA22295 for ; Thu, 30 Jan 2003 03:47:18 -0500 (EST) Received: (qmail 10079 invoked by uid 510); 30 Jan 2003 08:58:19 -0000 Date: 30 Jan 2003 08:58:19 -0000 Message-ID: <20030130085819.10078.qmail@webmail32.rediffmail.com> Received: from unknown (202.144.91.188) by rediffmail.com via HTTP; 30 jan 2003 08:58:19 -0000 MIME-Version: 1.0 From: "Simran Chadha" Reply-To: "Simran Chadha" To: megaco@ietf.org Content-type: multipart/alternative; boundary="Next_1043917099---0-203.199.83.32-10059" Subject: [Megaco] Usage of LocalControl,Local and Remote Descriptors ! Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multipart mime message --Next_1043917099---0-203.199.83.32-10059 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
Hi List,
=0A 
=0A
Can you = please help me with clarifications in my understanding of sections 7.1.7 an= d 7.1.8 on the use of LocalControl,Local and Remote Descriptors.=0A
 
=0A
A= s per draft-ietf-megaco-3015corr-03, in section 7.1.7,
=0A
= =0A

If the value of a Reserve property is True, the MG SHA= LL reserve resources for all alternatives specified in the Local and/or Rem= ote descriptors for which it currently has resources available. It SHALL re= spond with the alternatives for which it reserves resources. If it cannot n= ot support any of the alternatives, it SHALL respond with a reply to the MG= C that contains empty Local and/or Remote descriptors.

=0A=
The use of two negations -= "cannot not" in the last statement will imply that - If i= t can support any of the alternatives, it SHALL respond with a reply to the= MGC that contains empty Local and/or Remote descriptors.
=0AI don't think this is what i= s meant to be conveyed here. 
=0A
 
=0A
= Also in section 7.1.7 the first= para starts - If the value of a Reserve property is= True, .....
=0A
while the second para starts - If = the value of a Reserve property is False, ....
= =0A
Now as there are two Re= serve properties - one Reserve Group and the other Reserve Value, One could be False and the other = could be True. Then in this case what will be the inferenc= e - Should para 1 apply or para 2 ? Both the paras would seem to be mutuall= y exclusive in what is needed to be done.
=0A
 
= =0A
Also statements like "<= STRONG>if it cannot support any of the alternatives ... " - will h= ave two meanings.
=0A
1. Any -  Not even one - NONE of the alternatives is supported.=
=0A
2. Any -&n= bsp; Atleast one   - While a few alternatives can be supported, a= few might not be.
=0A
 
=0A
The protocol needs to be more clear on such asp= ects in the documents henceforth. The English language is understood in dif= ferent parts of the world. Variations to agreed usage of the language terms= will make it difficult for new users of Megaco protocol, like me.=0A
 
=0A
Can someone please educate me on the exact usage and meaning of LocalContr= ol,Local and Remote Descriptors ?
=0A
 
=0A
<= FONT color=3D#0000ff face=3DArial size=3D2>Thanks and awaiting comments and= clarifications
=0A
 
=0A
Simran Chadha
--Next_1043917099---0-203.199.83.32-10059 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi List,=0D=0A=0D=0ACan you please help me with clarifications in my unders= tanding of sections 7.1.7 and 7.1.8 on the use of LocalControl,Local and Re= mote Descriptors.=0D=0A=0D=0AAs per draft-ietf-megaco-3015corr-03, in secti= on 7.1.7,=0D=0AIf the value of a Reserve property is True, the MG SHALL res= erve resources for all alternatives specified in the Local and/or Remote de= scriptors for which it currently has resources available. It SHALL respond = with the alternatives for which it reserves resources. If it cannot not sup= port any of the alternatives, it SHALL respond with a reply to the MGC that= contains empty Local and/or Remote descriptors. =0D=0AThe use of two negat= ions - "cannot not" in the last statement will imply that - If it can suppo= rt any of the alternatives, it SHALL respond with a reply to the MGC that c= ontains empty Local and/or Remote descriptors.=0D=0AI don't think this is w= hat is meant to be conveyed here. =0D=0A=0D=0AAlso in section 7.1.7 the fir= st para starts - If the value of a Reserve property is True, .....=0D=0Awhi= le the second para starts - If the value of a Reserve property is False, ..= ..=0D=0ANow as there are two Reserve properties - one Reserve Group and the= other Reserve Value, One could be False and the other could be True. Then = in this case what will be the inference - Should para 1 apply or para 2 ? B= oth the paras would seem to be mutually exclusive in what is needed to be d= one.=0D=0A=0D=0AAlso statements like "if it cannot support any of the alter= natives ... " - will have two meanings.=0D=0A1. Any - Not even one - NONE = of the alternatives is supported.=0D=0A2. Any - Atleast one - While a fe= w alternatives can be supported, a few might not be.=0D=0A=0D=0AThe protoco= l needs to be more clear on such aspects in the documents henceforth. The E= nglish language is understood in different parts of the world. Variations t= o agreed usage of the language terms will make it difficult for new users o= f Megaco protocol, like me.=0D=0A=0D=0ACan someone please educate me on the= exact usage and meaning of LocalControl,Local and Remote Descriptors ?=0D= =0A=0D=0AThanks and awaiting comments and clarifications=0D=0A=0D=0ASimran = Chadha --Next_1043917099---0-203.199.83.32-10059-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Jan 30 08:12:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26650 for ; Thu, 30 Jan 2003 08:12:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UDX1J30850; Thu, 30 Jan 2003 08:33:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UDUkJ30747 for ; Thu, 30 Jan 2003 08:30:46 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26569 for ; Thu, 30 Jan 2003 08:08:17 -0500 (EST) From: shbansal@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0UDASj13028 for ; Thu, 30 Jan 2003 18:40:28 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0UDARM13024; Thu, 30 Jan 2003 18:40:27 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h0UDCi509109; Thu, 30 Jan 2003 18:42:46 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CBE.0047CD46 ; Thu, 30 Jan 2003 18:34:16 +0530 X-Lotus-FromDomain: HSS To: Christian Groves cc: megaco@ietf.org Message-ID: <65256CBE.0047CB86.00@sandesh.hss.hns.com> Date: Thu, 30 Jan 2003 18:44:01 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Re: Topology Descriptor Processing Logic Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Chris, I have gone through the mailing list discussions But I still have some doubts in topology descriptor procressing I will be really very thankful and obliged if you help in resolving them Assuming that we have a context C1 with terminations T1, T2 and T3 and command comes like Action C1 Topolgy ( T1, T3, Isolate) Command Modify T1 Command Modify T2 In this case: Will the topology (T1, T3, Isolate) be applied before the command execution starts i.e. tuples of specified terminations will get applied before any command execution starts. If this understanding is correct, topology will get applied before execution of MODIFY T1 OR Will the topology application be deffered till the command execution starts for the respective terminations that are present in tuples. If this understanding is correct, after MODIFY T1 gets executed, topology would be applied in conjunction thereof. Further after that, MODIFY T2 will get executed. Thanking you in advance Shobhit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Jan 30 08:13:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26684 for ; Thu, 30 Jan 2003 08:13:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UDZGo30947 for megaco-archive@odin.ietf.org; Thu, 30 Jan 2003 08:35:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UDZGJ30944 for ; Thu, 30 Jan 2003 08:35:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26664 for ; Thu, 30 Jan 2003 08:12:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UDX1J30850; Thu, 30 Jan 2003 08:33:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UDUkJ30747 for ; Thu, 30 Jan 2003 08:30:46 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26569 for ; Thu, 30 Jan 2003 08:08:17 -0500 (EST) From: shbansal@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0UDASj13028 for ; Thu, 30 Jan 2003 18:40:28 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0UDARM13024; Thu, 30 Jan 2003 18:40:27 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h0UDCi509109; Thu, 30 Jan 2003 18:42:46 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CBE.0047CD46 ; Thu, 30 Jan 2003 18:34:16 +0530 X-Lotus-FromDomain: HSS To: Christian Groves cc: megaco@ietf.org Message-ID: <65256CBE.0047CB86.00@sandesh.hss.hns.com> Date: Thu, 30 Jan 2003 18:44:01 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Re: Topology Descriptor Processing Logic Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Chris, I have gone through the mailing list discussions But I still have some doubts in topology descriptor procressing I will be really very thankful and obliged if you help in resolving them Assuming that we have a context C1 with terminations T1, T2 and T3 and command comes like Action C1 Topolgy ( T1, T3, Isolate) Command Modify T1 Command Modify T2 In this case: Will the topology (T1, T3, Isolate) be applied before the command execution starts i.e. tuples of specified terminations will get applied before any command execution starts. If this understanding is correct, topology will get applied before execution of MODIFY T1 OR Will the topology application be deffered till the command execution starts for the respective terminations that are present in tuples. If this understanding is correct, after MODIFY T1 gets executed, topology would be applied in conjunction thereof. Further after that, MODIFY T2 will get executed. Thanking you in advance Shobhit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Jan 31 12:19:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12607 for ; Fri, 31 Jan 2003 12:19:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VHLhJ07178; Fri, 31 Jan 2003 12:21:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VHJrJ07110 for ; Fri, 31 Jan 2003 12:19:53 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12479 for ; Fri, 31 Jan 2003 12:15:46 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h0VHJsSD015799 for ; Fri, 31 Jan 2003 10:19:54 -0700 (MST) Received: [from az33exm05.corp.mot.com (az33exm05.corp.mot.com [199.2.84.25]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA19120 for ; Fri, 31 Jan 2003 10:18:16 -0700 (MST)] Received: by az33exm05.corp.mot.com with Internet Mail Service (5.5.2656.59) id ; Fri, 31 Jan 2003 10:18:33 -0700 Message-ID: <7FD24C15A06DD511BF9E00D0B73E99520713931E@az33exm05.corp.mot.com> From: Maschoff Mark-P53708 To: megaco@ietf.org Date: Fri, 31 Jan 2003 10:18:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C94C.C6BC9970" Subject: [Megaco] Jitter Statistics Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2C94C.C6BC9970 Content-Type: text/plain; charset="iso-8859-1" All, Consider the case where there is a MG between two IP networks and a requirement to report the average jitter for each direction (call leg) per call. Is there a public package available that supports this requirement? I've consider the RTP package but it only reports a single jitter statistic. Thanks, Mark ------_=_NextPart_001_01C2C94C.C6BC9970 Content-Type: text/html; charset="iso-8859-1"
All,
 
Consider the case where there is a MG between two IP networks and a requirement to report the average jitter for each direction (call leg) per call.  Is there a public package available that supports this requirement?  I've consider the RTP package but it only reports a single jitter statistic.
 
Thanks,
 
Mark
------_=_NextPart_001_01C2C94C.C6BC9970-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Jan 31 12:20:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12637 for ; Fri, 31 Jan 2003 12:20:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VHNj907238 for megaco-archive@odin.ietf.org; Fri, 31 Jan 2003 12:23:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VHNjJ07235 for ; Fri, 31 Jan 2003 12:23:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12618 for ; Fri, 31 Jan 2003 12:19:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VHLhJ07178; Fri, 31 Jan 2003 12:21:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VHJrJ07110 for ; Fri, 31 Jan 2003 12:19:53 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12479 for ; Fri, 31 Jan 2003 12:15:46 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h0VHJsSD015799 for ; Fri, 31 Jan 2003 10:19:54 -0700 (MST) Received: [from az33exm05.corp.mot.com (az33exm05.corp.mot.com [199.2.84.25]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA19120 for ; Fri, 31 Jan 2003 10:18:16 -0700 (MST)] Received: by az33exm05.corp.mot.com with Internet Mail Service (5.5.2656.59) id ; Fri, 31 Jan 2003 10:18:33 -0700 Message-ID: <7FD24C15A06DD511BF9E00D0B73E99520713931E@az33exm05.corp.mot.com> From: Maschoff Mark-P53708 To: megaco@ietf.org Date: Fri, 31 Jan 2003 10:18:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C94C.C6BC9970" Subject: [Megaco] Jitter Statistics Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2C94C.C6BC9970 Content-Type: text/plain; charset="iso-8859-1" All, Consider the case where there is a MG between two IP networks and a requirement to report the average jitter for each direction (call leg) per call. Is there a public package available that supports this requirement? I've consider the RTP package but it only reports a single jitter statistic. Thanks, Mark ------_=_NextPart_001_01C2C94C.C6BC9970 Content-Type: text/html; charset="iso-8859-1"
All,
 
Consider the case where there is a MG between two IP networks and a requirement to report the average jitter for each direction (call leg) per call.  Is there a public package available that supports this requirement?  I've consider the RTP package but it only reports a single jitter statistic.
 
Thanks,
 
Mark
------_=_NextPart_001_01C2C94C.C6BC9970-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Jan 31 12:33:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13111 for ; Fri, 31 Jan 2003 12:33:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VHZHJ07635; Fri, 31 Jan 2003 12:35:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VHZ0J07605 for ; Fri, 31 Jan 2003 12:35:00 -0500 Received: from out003.verizon.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13029 for ; Fri, 31 Jan 2003 12:30:52 -0500 (EST) Received: from verizon.net ([138.89.124.43]) by out003.verizon.net (InterMail vM.5.01.05.20 201-253-122-126-120-20021101) with ESMTP id <20030131173426.OAGZ3094.out003.verizon.net@verizon.net>; Fri, 31 Jan 2003 11:34:26 -0600 Message-ID: <3E3AB39F.7040201@verizon.net> Date: Fri, 31 Jan 2003 12:34:23 -0500 From: Terry L Anderson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Maschoff Mark-P53708 CC: megaco@ietf.org Subject: Re: [Megaco] Jitter Statistics References: <7FD24C15A06DD511BF9E00D0B73E99520713931E@az33exm05.corp.mot.com> Content-Type: multipart/alternative; boundary="------------080004040709040702090007" X-Authentication-Info: Submitted using SMTP AUTH at out003.verizon.net from [138.89.124.43] at Fri, 31 Jan 2003 11:34:25 -0600 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --------------080004040709040702090007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The rtp package (like all packages) applies to a termination. The case you site will still have two ephemeral terminations each of which can support the rtp package, so there are two jitter statistics. Maschoff Mark-P53708 wrote: > All, > > Consider the case where there is a MG between two IP networks and a > requirement to report the average jitter for each direction (call > leg) per call. Is there a public package available that supports this > requirement? I've consider the RTP package but it only reports a > single jitter statistic. > > Thanks, > > Mark -- ------------------------------------------------------- Terry L Anderson tlatla@verizon.net Voice: +1 908.766.4463 Mobile: +1 908.342.9595 http://www.gti.net/tla ------------------------------------------------------- --------------080004040709040702090007 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit The rtp package (like all packages) applies to a termination.  The case you site will still have two ephemeral terminations each of which can support the rtp package, so there are two jitter statistics.

Maschoff Mark-P53708 wrote:
All,
 
Consider the case where there is a MG between two IP networks and a requirement to report the average jitter for each direction (call leg) per call.  Is there a public package available that supports this requirement?  I've consider the RTP package but it only reports a single jitter statistic.
 
Thanks,
 
Mark

-- 
-------------------------------------------------------
Terry L Anderson                     tlatla@verizon.net
Voice: +1 908.766.4463	        Mobile: +1 908.342.9595
http://www.gti.net/tla
-------------------------------------------------------

--------------080004040709040702090007-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Jan 31 12:33:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13153 for ; Fri, 31 Jan 2003 12:33:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VHbLp08121 for megaco-archive@odin.ietf.org; Fri, 31 Jan 2003 12:37:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VHbKJ08118 for ; Fri, 31 Jan 2003 12:37:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13121 for ; Fri, 31 Jan 2003 12:33:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VHZHJ07635; Fri, 31 Jan 2003 12:35:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VHZ0J07605 for ; Fri, 31 Jan 2003 12:35:00 -0500 Received: from out003.verizon.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13029 for ; Fri, 31 Jan 2003 12:30:52 -0500 (EST) Received: from verizon.net ([138.89.124.43]) by out003.verizon.net (InterMail vM.5.01.05.20 201-253-122-126-120-20021101) with ESMTP id <20030131173426.OAGZ3094.out003.verizon.net@verizon.net>; Fri, 31 Jan 2003 11:34:26 -0600 Message-ID: <3E3AB39F.7040201@verizon.net> Date: Fri, 31 Jan 2003 12:34:23 -0500 From: Terry L Anderson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Maschoff Mark-P53708 CC: megaco@ietf.org Subject: Re: [Megaco] Jitter Statistics References: <7FD24C15A06DD511BF9E00D0B73E99520713931E@az33exm05.corp.mot.com> Content-Type: multipart/alternative; boundary="------------080004040709040702090007" X-Authentication-Info: Submitted using SMTP AUTH at out003.verizon.net from [138.89.124.43] at Fri, 31 Jan 2003 11:34:25 -0600 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --------------080004040709040702090007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The rtp package (like all packages) applies to a termination. The case you site will still have two ephemeral terminations each of which can support the rtp package, so there are two jitter statistics. Maschoff Mark-P53708 wrote: > All, > > Consider the case where there is a MG between two IP networks and a > requirement to report the average jitter for each direction (call > leg) per call. Is there a public package available that supports this > requirement? I've consider the RTP package but it only reports a > single jitter statistic. > > Thanks, > > Mark -- ------------------------------------------------------- Terry L Anderson tlatla@verizon.net Voice: +1 908.766.4463 Mobile: +1 908.342.9595 http://www.gti.net/tla ------------------------------------------------------- --------------080004040709040702090007 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit The rtp package (like all packages) applies to a termination.  The case you site will still have two ephemeral terminations each of which can support the rtp package, so there are two jitter statistics.

Maschoff Mark-P53708 wrote:
All,
 
Consider the case where there is a MG between two IP networks and a requirement to report the average jitter for each direction (call leg) per call.  Is there a public package available that supports this requirement?  I've consider the RTP package but it only reports a single jitter statistic.
 
Thanks,
 
Mark

-- 
-------------------------------------------------------
Terry L Anderson                     tlatla@verizon.net
Voice: +1 908.766.4463	        Mobile: +1 908.342.9595
http://www.gti.net/tla
-------------------------------------------------------

--------------080004040709040702090007-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco