From mailman-admin@ietf.org Sat Mar 1 10:26: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 KAA08490 for ; Sat, 1 Mar 2003 10:26: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 h21FZmp29408 for ; Sat, 1 Mar 2003 10:35:48 -0500 Date: Sat, 01 Mar 2003 10:35:48 -0500 Message-ID: <20030301153548.26394.28312.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: megaco-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, megaco-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for megaco-archive@lists.ietf.org: List Password // URL ---- -------- megaco@ietf.org rFKd https://www1.ietf.org/mailman/options/megaco/megaco-archive%40lists.ietf.org From megaco-admin@ietf.org Mon Mar 3 00:37: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 AAA27430 for ; Mon, 3 Mar 2003 00:37: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 h235kUp00475; Mon, 3 Mar 2003 00:46: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 h235hPp00354 for ; Mon, 3 Mar 2003 00:43:25 -0500 Received: from web10702.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27373 for ; Mon, 3 Mar 2003 00:33:04 -0500 (EST) Message-ID: <20030303053504.1430.qmail@web10702.mail.yahoo.com> Received: from [203.124.158.2] by web10702.mail.yahoo.com via HTTP; Mon, 03 Mar 2003 16:35:04 EST Date: Mon, 3 Mar 2003 16:35:04 +1100 (EST) From: =?iso-8859-1?q?petric=20john?= To: megaco@ietf.org Cc: taylor@nortelnetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Megaco] tools. Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 List, Are there available any tools to test the protocol? The test tool can be in any form right from message composer/generator or load generator. any help in this regard would be of great help. I guess the community still lacks few handy tools unlike few other protocols (may be in form of UA, Composer etc) towards this. Otherwise conformance testing itself is an enormous job. thenks in advance! Cheers! ===== ~|~ o John http://mobile.yahoo.com.au - Yahoo! Mobile - Exchange IMs with Messenger friends on your Telstra or Vodafone mobile phone. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Mar 3 00:38: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 AAA27575 for ; Mon, 3 Mar 2003 00:38:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h235mDc00781 for megaco-archive@odin.ietf.org; Mon, 3 Mar 2003 00:48:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h235mDp00778 for ; Mon, 3 Mar 2003 00:48: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 AAA27526 for ; Mon, 3 Mar 2003 00:37: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 h235kUp00475; Mon, 3 Mar 2003 00:46: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 h235hPp00354 for ; Mon, 3 Mar 2003 00:43:25 -0500 Received: from web10702.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27373 for ; Mon, 3 Mar 2003 00:33:04 -0500 (EST) Message-ID: <20030303053504.1430.qmail@web10702.mail.yahoo.com> Received: from [203.124.158.2] by web10702.mail.yahoo.com via HTTP; Mon, 03 Mar 2003 16:35:04 EST Date: Mon, 3 Mar 2003 16:35:04 +1100 (EST) From: =?iso-8859-1?q?petric=20john?= To: megaco@ietf.org Cc: taylor@nortelnetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Megaco] tools. Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 List, Are there available any tools to test the protocol? The test tool can be in any form right from message composer/generator or load generator. any help in this regard would be of great help. I guess the community still lacks few handy tools unlike few other protocols (may be in form of UA, Composer etc) towards this. Otherwise conformance testing itself is an enormous job. thenks in advance! Cheers! ===== ~|~ o John http://mobile.yahoo.com.au - Yahoo! Mobile - Exchange IMs with Messenger friends on your Telstra or Vodafone mobile phone. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Mar 3 01:34: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 BAA28867 for ; Mon, 3 Mar 2003 01:34: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 h236fgp04853; Mon, 3 Mar 2003 01:41: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 h236ejp04808 for ; Mon, 3 Mar 2003 01:40: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 BAA28770 for ; Mon, 3 Mar 2003 01:30:17 -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 h236Ubs21116 for ; Mon, 3 Mar 2003 12:00:37 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5] (may be forged)) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h236UW221096; Mon, 3 Mar 2003 12:00:32 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h236X7W12034; Mon, 3 Mar 2003 12:03:08 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CDE.00232A7C ; Mon, 3 Mar 2003 11:54:06 +0530 X-Lotus-FromDomain: HSS To: madhu@syndeocorp.com cc: megaco@ietf.org Message-ID: <65256CDE.0023281C.00@sandesh.hss.hns.com> Date: Mon, 3 Mar 2003 11:59:08 +0530 Subject: RE: [Megaco] I-D ACTION:draft-ietf-megaco-r2package-03.txt 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: , Madhu, The manyfolks CAS package comprises of the base package for CAS and the same draft includes some of the derived packages for other CAS signaling but not R2. That was the decision. So R2 package still remains valid as a derived package of the "bcas" package. It includes the events/signals for R2 specific compelled signaling. regards, Kushanava "Madhu Babu Brahmanapally" on 02/28/2003 10:52:20 PM Please respond to madhu@syndeocorp.com To: megaco@ietf.org cc: (bcc: Kushanava Laha/HSS) Subject: RE: [Megaco] I-D ACTION:draft-ietf-megaco-r2package-03.txt Hi all, Earlier I remember that decision was taken to merge R2 package in CAS packages (by foster) and a "manyfolks" draft was submitted. Now it is appearing as a seperate draft?? Regards Madhubabu Brahmanapally -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Friday, February 28, 2003 4:26 AM To: IETF-Announce: Cc: megaco@ietf.org Subject: [Megaco] I-D ACTION:draft-ietf-megaco-r2package-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Media Gateway Control Working Group of the IETF. Title : Megaco/H.248 R2 Package Author(s) : K. Laha, V. Nair Filename : draft-ietf-megaco-r2package-03.txt Pages : 19 Date : 2003-2-27 This document is work in progress and defines the R2 package for the Megaco/H.248 Protocol that can be used to exchange call setup supervisory and control information between a Media Gateway (MG) and a Media Gateway Controller (MGC) to realize Signaling System R2 at a VoIP Gateway. It is intended to satisfy the requirements in section 12 of the Megaco/H.248 protocol [2]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-megaco-r2package-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-megaco-r2package-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Mar 3 01:35: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 BAA28898 for ; Mon, 3 Mar 2003 01:35:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h236jUs05086 for megaco-archive@odin.ietf.org; Mon, 3 Mar 2003 01: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 h236jUp05083 for ; Mon, 3 Mar 2003 01:45: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 BAA28895 for ; Mon, 3 Mar 2003 01:35: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 h236fgp04853; Mon, 3 Mar 2003 01:41: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 h236ejp04808 for ; Mon, 3 Mar 2003 01:40: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 BAA28770 for ; Mon, 3 Mar 2003 01:30:17 -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 h236Ubs21116 for ; Mon, 3 Mar 2003 12:00:37 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5] (may be forged)) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h236UW221096; Mon, 3 Mar 2003 12:00:32 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h236X7W12034; Mon, 3 Mar 2003 12:03:08 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CDE.00232A7C ; Mon, 3 Mar 2003 11:54:06 +0530 X-Lotus-FromDomain: HSS To: madhu@syndeocorp.com cc: megaco@ietf.org Message-ID: <65256CDE.0023281C.00@sandesh.hss.hns.com> Date: Mon, 3 Mar 2003 11:59:08 +0530 Subject: RE: [Megaco] I-D ACTION:draft-ietf-megaco-r2package-03.txt 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: , Madhu, The manyfolks CAS package comprises of the base package for CAS and the same draft includes some of the derived packages for other CAS signaling but not R2. That was the decision. So R2 package still remains valid as a derived package of the "bcas" package. It includes the events/signals for R2 specific compelled signaling. regards, Kushanava "Madhu Babu Brahmanapally" on 02/28/2003 10:52:20 PM Please respond to madhu@syndeocorp.com To: megaco@ietf.org cc: (bcc: Kushanava Laha/HSS) Subject: RE: [Megaco] I-D ACTION:draft-ietf-megaco-r2package-03.txt Hi all, Earlier I remember that decision was taken to merge R2 package in CAS packages (by foster) and a "manyfolks" draft was submitted. Now it is appearing as a seperate draft?? Regards Madhubabu Brahmanapally -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Friday, February 28, 2003 4:26 AM To: IETF-Announce: Cc: megaco@ietf.org Subject: [Megaco] I-D ACTION:draft-ietf-megaco-r2package-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Media Gateway Control Working Group of the IETF. Title : Megaco/H.248 R2 Package Author(s) : K. Laha, V. Nair Filename : draft-ietf-megaco-r2package-03.txt Pages : 19 Date : 2003-2-27 This document is work in progress and defines the R2 package for the Megaco/H.248 Protocol that can be used to exchange call setup supervisory and control information between a Media Gateway (MG) and a Media Gateway Controller (MGC) to realize Signaling System R2 at a VoIP Gateway. It is intended to satisfy the requirements in section 12 of the Megaco/H.248 protocol [2]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-megaco-r2package-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-megaco-r2package-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Mar 3 12:23: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 MAA03822 for ; Mon, 3 Mar 2003 12:23: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 h23HMkp05259; Mon, 3 Mar 2003 12:22: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 h23HLgp05209 for ; Mon, 3 Mar 2003 12:21:42 -0500 Received: from bos-exch01.winphoria.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03382 for ; Mon, 3 Mar 2003 12:11:07 -0500 (EST) Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 3 Mar 2003 12:13:05 -0500 Message-Id: <5.2.0.9.0.20030303111733.02b49be0@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 03 Mar 2003 12:13:20 -0500 To: vnair@hss.hns.com, megaco@ietf.org From: Aleksandr Ryabin Cc: klaha@hss.hns.com In-Reply-To: <65256CDE.00436E55.00@sandesh.hss.hns.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 03 Mar 2003 17:13:05.0938 (UTC) FILETIME=[27DD8720:01C2E1A8] Subject: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : Difference from previous revision Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, These are pretty big changes. I know the previous version was a draft, but its been out there for a while now, so there are implementations which use it. That seem to be a good reason to bump the version of the package for new revision of draft. Questions: 1. Now that block/unblock signals/events have been removed I'd think bcas package should be handling these supervisory signal procedures, but I can't seem to find any reference to these procedures in bcas. Can you clarify on how block/unblock are to be implemented now? 2. I can't seem to find a way to send/receive to/from MGC (currently spare) R2 Group B backward digits from B-11 to B-15? One way would be to have them in possible values of cplc and their descriptions specified as "spare B-xx". Another way would be to add "Spare Called Party Line Condition Value" parameter to cprs event and signal with int value equal of the B signal received/to send. 3. I can't seem to find a way to implement "Metering Pulse" procedure defined for some R2 variants using ether bcas or R2 packages? For example, one of the definitions of such a pulse is a "seizure ack" pulse from a terminating end on a circuit in connected/answer state. Thanks Aleks At 07:21 AM 3/3/2003, vnair@hss.hns.com wrote: >Changes between version 03 over version 02 of R2 package > >1. Changed the wording of Abstract section. > >2. Changed the wording of Introduction section to reflect that R2 package is >derived package of bcas package. Also, it touches upon the new signal and >event >"r2addr" which is added in this derived r2 package. > >3. Rephrased assumption b) in Assumptions section (section 5). > >4. Corrected sequence numbering of 4th assumption to d) in Assumptions section >(section 5) > >5. Section 6.1: R2 package definition modified so as to extend bcas package. >Changed the wording in description so as to clarify that R2 package extends >bcas. Version 02 advocated it being used in conjunction with bcas package. > >6. Section 6.2 > - Removed property "clear back signal validation time" > - Changed Property Id from "callen" to "snl" for Property Name "Source > Number >Length" > - Removed the wordings mentioning the procedure to collect source number. > - Removed property "source number time-out" > - Removed property "subscriber line status flag" > - Removed property "trunk direction" > - Added property "Compelling Sequence Keepalive Timer" > >7. Section 6.3 > - Removed event "Unblock" > - ObservedEventDescriptor of r2addr event > + Changed description for possible values of dimeth parameter > + Removed procedure for collecting source number in si parameter > description > + Added parameter "Source Number Termination Method" > + Changed description of sc parameter to align the language used throughout > + Changed description of es parameter to align the language used throughout > + Changed description of cc parameter to align the language used throughout > + Removed procedure for collecting country code in cc parameter description > + Changed description of disc parameter to align the language used > throughout > + Changed description of nac parameter to align the language used > throughout > - Renamed "Subscriber Line Status" to "Called Party Reachability Status" to >clarify the meaning for the event > - Changed the wording in R2 Failure event description. Also, changed the >possible value for this event > - Changed description for possible values of dimeth parameter under >ObservedEventDescriptor of di event. > - Changed description si parameter under ObservedEventDescriptor of si > event. > - Added Source Number Termination method parameter under >ObservedEventDescriptor of si event > - Added Congestion Event > >8. Section 6.4 > - Removed Block signal > - Removed Unblock signal > - Renamed signal "Subscriber Line Status" to "Called Party Reachability >Status". Also, modified the description for this signal > >9. Section 6.5 > - Removed Call Duration statistics defined by this package. > >10. Section 7 > - Removed description of property parameters defined in section 7.1 of > version >02 > - Removed procedures for exchanging supervisory signals > - Removed procedures for exchanging call set-up control information > - Removed call flows for incoming MG > - Removed call flows for outgoing MG > - Added procedure for Termination of Called Party Number digit collection at >incoming MG > - Added procedure for Termination of Calling Party Number collection at >incoming MG > - Added procedure for Termination of Country Code digit collection at > incoming >MG > - Added procedure for Termination of Compelling Sequence > >11. Section 8 > - Modified reference number [4] for newer version of bcas draft referred > >12. Section 9 > - Modified Author's Address to reflect new contact phone numbers > >13. The usage of keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >NOT", >"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are >corrected all >across the draft. > >Thanks >- Vikram Nair >www.hssworld.com > >DISCLAIMER: This message is proprietary to Hughes Software Systems >Limited (HSS) and is intended solely for the use of the individual >to whom it is addressed. It may contain privileged or confidential >information and should not be circulated or used for any purpose other >than for what it is intended. If you have received this message in error, >please notify the originator immediately. If you are not the intended >recipient, you are notified that you are strictly prohibited from using, >copying, altering, or disclosing the contents of this message. HSS accepts >no responsibility for loss or damage arising from the use of the information >transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Mar 3 12:24: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 MAA03876 for ; Mon, 3 Mar 2003 12:24:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23HYW206170 for megaco-archive@odin.ietf.org; Mon, 3 Mar 2003 12:34: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 h23HYWp06167 for ; Mon, 3 Mar 2003 12:34: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 MAA03865 for ; Mon, 3 Mar 2003 12:23: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 h23HMkp05259; Mon, 3 Mar 2003 12:22: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 h23HLgp05209 for ; Mon, 3 Mar 2003 12:21:42 -0500 Received: from bos-exch01.winphoria.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03382 for ; Mon, 3 Mar 2003 12:11:07 -0500 (EST) Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 3 Mar 2003 12:13:05 -0500 Message-Id: <5.2.0.9.0.20030303111733.02b49be0@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 03 Mar 2003 12:13:20 -0500 To: vnair@hss.hns.com, megaco@ietf.org From: Aleksandr Ryabin Cc: klaha@hss.hns.com In-Reply-To: <65256CDE.00436E55.00@sandesh.hss.hns.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 03 Mar 2003 17:13:05.0938 (UTC) FILETIME=[27DD8720:01C2E1A8] Subject: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : Difference from previous revision Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, These are pretty big changes. I know the previous version was a draft, but its been out there for a while now, so there are implementations which use it. That seem to be a good reason to bump the version of the package for new revision of draft. Questions: 1. Now that block/unblock signals/events have been removed I'd think bcas package should be handling these supervisory signal procedures, but I can't seem to find any reference to these procedures in bcas. Can you clarify on how block/unblock are to be implemented now? 2. I can't seem to find a way to send/receive to/from MGC (currently spare) R2 Group B backward digits from B-11 to B-15? One way would be to have them in possible values of cplc and their descriptions specified as "spare B-xx". Another way would be to add "Spare Called Party Line Condition Value" parameter to cprs event and signal with int value equal of the B signal received/to send. 3. I can't seem to find a way to implement "Metering Pulse" procedure defined for some R2 variants using ether bcas or R2 packages? For example, one of the definitions of such a pulse is a "seizure ack" pulse from a terminating end on a circuit in connected/answer state. Thanks Aleks At 07:21 AM 3/3/2003, vnair@hss.hns.com wrote: >Changes between version 03 over version 02 of R2 package > >1. Changed the wording of Abstract section. > >2. Changed the wording of Introduction section to reflect that R2 package is >derived package of bcas package. Also, it touches upon the new signal and >event >"r2addr" which is added in this derived r2 package. > >3. Rephrased assumption b) in Assumptions section (section 5). > >4. Corrected sequence numbering of 4th assumption to d) in Assumptions section >(section 5) > >5. Section 6.1: R2 package definition modified so as to extend bcas package. >Changed the wording in description so as to clarify that R2 package extends >bcas. Version 02 advocated it being used in conjunction with bcas package. > >6. Section 6.2 > - Removed property "clear back signal validation time" > - Changed Property Id from "callen" to "snl" for Property Name "Source > Number >Length" > - Removed the wordings mentioning the procedure to collect source number. > - Removed property "source number time-out" > - Removed property "subscriber line status flag" > - Removed property "trunk direction" > - Added property "Compelling Sequence Keepalive Timer" > >7. Section 6.3 > - Removed event "Unblock" > - ObservedEventDescriptor of r2addr event > + Changed description for possible values of dimeth parameter > + Removed procedure for collecting source number in si parameter > description > + Added parameter "Source Number Termination Method" > + Changed description of sc parameter to align the language used throughout > + Changed description of es parameter to align the language used throughout > + Changed description of cc parameter to align the language used throughout > + Removed procedure for collecting country code in cc parameter description > + Changed description of disc parameter to align the language used > throughout > + Changed description of nac parameter to align the language used > throughout > - Renamed "Subscriber Line Status" to "Called Party Reachability Status" to >clarify the meaning for the event > - Changed the wording in R2 Failure event description. Also, changed the >possible value for this event > - Changed description for possible values of dimeth parameter under >ObservedEventDescriptor of di event. > - Changed description si parameter under ObservedEventDescriptor of si > event. > - Added Source Number Termination method parameter under >ObservedEventDescriptor of si event > - Added Congestion Event > >8. Section 6.4 > - Removed Block signal > - Removed Unblock signal > - Renamed signal "Subscriber Line Status" to "Called Party Reachability >Status". Also, modified the description for this signal > >9. Section 6.5 > - Removed Call Duration statistics defined by this package. > >10. Section 7 > - Removed description of property parameters defined in section 7.1 of > version >02 > - Removed procedures for exchanging supervisory signals > - Removed procedures for exchanging call set-up control information > - Removed call flows for incoming MG > - Removed call flows for outgoing MG > - Added procedure for Termination of Called Party Number digit collection at >incoming MG > - Added procedure for Termination of Calling Party Number collection at >incoming MG > - Added procedure for Termination of Country Code digit collection at > incoming >MG > - Added procedure for Termination of Compelling Sequence > >11. Section 8 > - Modified reference number [4] for newer version of bcas draft referred > >12. Section 9 > - Modified Author's Address to reflect new contact phone numbers > >13. The usage of keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >NOT", >"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are >corrected all >across the draft. > >Thanks >- Vikram Nair >www.hssworld.com > >DISCLAIMER: This message is proprietary to Hughes Software Systems >Limited (HSS) and is intended solely for the use of the individual >to whom it is addressed. It may contain privileged or confidential >information and should not be circulated or used for any purpose other >than for what it is intended. If you have received this message in error, >please notify the originator immediately. If you are not the intended >recipient, you are notified that you are strictly prohibited from using, >copying, altering, or disclosing the contents of this message. HSS accepts >no responsibility for loss or damage arising from the use of the information >transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Mar 3 13:20: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 NAA06218 for ; Mon, 3 Mar 2003 13:20: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 h23ITmp11996; Mon, 3 Mar 2003 13:29: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 h23CXCp11556 for ; Mon, 3 Mar 2003 07:33:12 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20587 for ; Mon, 3 Mar 2003 07:22:41 -0500 (EST) From: vnair@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 h23CN2s03458 for ; Mon, 3 Mar 2003 17:53:02 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5] (may be forged)) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h23CN0203446; Mon, 3 Mar 2003 17:53:00 +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 h23CPbH16031; Mon, 3 Mar 2003 17:55:37 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CDE.00437048 ; Mon, 3 Mar 2003 17:46:36 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org cc: kengr@winphoria.com, vnair@hss.hns.com, klaha@hss.hns.com Message-ID: <65256CDE.00436E55.00@sandesh.hss.hns.com> Date: Mon, 3 Mar 2003 17:51:41 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] draft-ietf-megaco-r2package-03.txt : Difference from previous revision Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Changes between version 03 over version 02 of R2 package 1. Changed the wording of Abstract section. 2. Changed the wording of Introduction section to reflect that R2 package is derived package of bcas package. Also, it touches upon the new signal and event "r2addr" which is added in this derived r2 package. 3. Rephrased assumption b) in Assumptions section (section 5). 4. Corrected sequence numbering of 4th assumption to d) in Assumptions section (section 5) 5. Section 6.1: R2 package definition modified so as to extend bcas package. Changed the wording in description so as to clarify that R2 package extends bcas. Version 02 advocated it being used in conjunction with bcas package. 6. Section 6.2 - Removed property "clear back signal validation time" - Changed Property Id from "callen" to "snl" for Property Name "Source Number Length" - Removed the wordings mentioning the procedure to collect source number. - Removed property "source number time-out" - Removed property "subscriber line status flag" - Removed property "trunk direction" - Added property "Compelling Sequence Keepalive Timer" 7. Section 6.3 - Removed event "Unblock" - ObservedEventDescriptor of r2addr event + Changed description for possible values of dimeth parameter + Removed procedure for collecting source number in si parameter description + Added parameter "Source Number Termination Method" + Changed description of sc parameter to align the language used throughout + Changed description of es parameter to align the language used throughout + Changed description of cc parameter to align the language used throughout + Removed procedure for collecting country code in cc parameter description + Changed description of disc parameter to align the language used throughout + Changed description of nac parameter to align the language used throughout - Renamed "Subscriber Line Status" to "Called Party Reachability Status" to clarify the meaning for the event - Changed the wording in R2 Failure event description. Also, changed the possible value for this event - Changed description for possible values of dimeth parameter under ObservedEventDescriptor of di event. - Changed description si parameter under ObservedEventDescriptor of si event. - Added Source Number Termination method parameter under ObservedEventDescriptor of si event - Added Congestion Event 8. Section 6.4 - Removed Block signal - Removed Unblock signal - Renamed signal "Subscriber Line Status" to "Called Party Reachability Status". Also, modified the description for this signal 9. Section 6.5 - Removed Call Duration statistics defined by this package. 10. Section 7 - Removed description of property parameters defined in section 7.1 of version 02 - Removed procedures for exchanging supervisory signals - Removed procedures for exchanging call set-up control information - Removed call flows for incoming MG - Removed call flows for outgoing MG - Added procedure for Termination of Called Party Number digit collection at incoming MG - Added procedure for Termination of Calling Party Number collection at incoming MG - Added procedure for Termination of Country Code digit collection at incoming MG - Added procedure for Termination of Compelling Sequence 11. Section 8 - Modified reference number [4] for newer version of bcas draft referred 12. Section 9 - Modified Author's Address to reflect new contact phone numbers 13. The usage of keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are corrected all across the draft. Thanks - Vikram Nair www.hssworld.com DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Mar 3 13:21: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 NAA06243 for ; Mon, 3 Mar 2003 13:21:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23IViR12186 for megaco-archive@odin.ietf.org; Mon, 3 Mar 2003 13:31: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 h23IVip12183 for ; Mon, 3 Mar 2003 13:31: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 NAA06238 for ; Mon, 3 Mar 2003 13:21:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23ITmp11996; Mon, 3 Mar 2003 13:29: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 h23CXCp11556 for ; Mon, 3 Mar 2003 07:33:12 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20587 for ; Mon, 3 Mar 2003 07:22:41 -0500 (EST) From: vnair@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 h23CN2s03458 for ; Mon, 3 Mar 2003 17:53:02 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5] (may be forged)) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h23CN0203446; Mon, 3 Mar 2003 17:53:00 +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 h23CPbH16031; Mon, 3 Mar 2003 17:55:37 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CDE.00437048 ; Mon, 3 Mar 2003 17:46:36 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org cc: kengr@winphoria.com, vnair@hss.hns.com, klaha@hss.hns.com Message-ID: <65256CDE.00436E55.00@sandesh.hss.hns.com> Date: Mon, 3 Mar 2003 17:51:41 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] draft-ietf-megaco-r2package-03.txt : Difference from previous revision Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Changes between version 03 over version 02 of R2 package 1. Changed the wording of Abstract section. 2. Changed the wording of Introduction section to reflect that R2 package is derived package of bcas package. Also, it touches upon the new signal and event "r2addr" which is added in this derived r2 package. 3. Rephrased assumption b) in Assumptions section (section 5). 4. Corrected sequence numbering of 4th assumption to d) in Assumptions section (section 5) 5. Section 6.1: R2 package definition modified so as to extend bcas package. Changed the wording in description so as to clarify that R2 package extends bcas. Version 02 advocated it being used in conjunction with bcas package. 6. Section 6.2 - Removed property "clear back signal validation time" - Changed Property Id from "callen" to "snl" for Property Name "Source Number Length" - Removed the wordings mentioning the procedure to collect source number. - Removed property "source number time-out" - Removed property "subscriber line status flag" - Removed property "trunk direction" - Added property "Compelling Sequence Keepalive Timer" 7. Section 6.3 - Removed event "Unblock" - ObservedEventDescriptor of r2addr event + Changed description for possible values of dimeth parameter + Removed procedure for collecting source number in si parameter description + Added parameter "Source Number Termination Method" + Changed description of sc parameter to align the language used throughout + Changed description of es parameter to align the language used throughout + Changed description of cc parameter to align the language used throughout + Removed procedure for collecting country code in cc parameter description + Changed description of disc parameter to align the language used throughout + Changed description of nac parameter to align the language used throughout - Renamed "Subscriber Line Status" to "Called Party Reachability Status" to clarify the meaning for the event - Changed the wording in R2 Failure event description. Also, changed the possible value for this event - Changed description for possible values of dimeth parameter under ObservedEventDescriptor of di event. - Changed description si parameter under ObservedEventDescriptor of si event. - Added Source Number Termination method parameter under ObservedEventDescriptor of si event - Added Congestion Event 8. Section 6.4 - Removed Block signal - Removed Unblock signal - Renamed signal "Subscriber Line Status" to "Called Party Reachability Status". Also, modified the description for this signal 9. Section 6.5 - Removed Call Duration statistics defined by this package. 10. Section 7 - Removed description of property parameters defined in section 7.1 of version 02 - Removed procedures for exchanging supervisory signals - Removed procedures for exchanging call set-up control information - Removed call flows for incoming MG - Removed call flows for outgoing MG - Added procedure for Termination of Called Party Number digit collection at incoming MG - Added procedure for Termination of Calling Party Number collection at incoming MG - Added procedure for Termination of Country Code digit collection at incoming MG - Added procedure for Termination of Compelling Sequence 11. Section 8 - Modified reference number [4] for newer version of bcas draft referred 12. Section 9 - Modified Author's Address to reflect new contact phone numbers 13. The usage of keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are corrected all across the draft. Thanks - Vikram Nair www.hssworld.com DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Mar 3 13:23: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 NAA06294 for ; Mon, 3 Mar 2003 13:23: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 h23IThp11973; Mon, 3 Mar 2003 13:29: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 h23BvMp08561 for ; Mon, 3 Mar 2003 06:57:22 -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 GAA18184 for ; Mon, 3 Mar 2003 06:46:52 -0500 (EST) From: anarora@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 h23BlDs27290 for ; Mon, 3 Mar 2003 17:17:14 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5] (may be forged)) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h23BlC227286 for ; Mon, 3 Mar 2003 17:17:12 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h23BnnB13018 for ; Mon, 3 Mar 2003 17:19:50 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CDE.004027A8 ; Mon, 3 Mar 2003 17:10:44 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org cc: samittal@hss.hns.com, prjain@hss.hns.com, shbansal@hss.hns.com Message-ID: <65256CDE.00402697.00@sandesh.hss.hns.com> Date: Mon, 3 Mar 2003 17:15:06 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Rollback Support in Topology Descriptor Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi I have a query regarding rollback of topology if one of the commands in the action fails... Consider the following e.g. T1, T2 and T3 are already present in the context: MEGACO/1 [111.111.111.4]:222 Transaction = 23{ Context = 1 { Topology { T1. T2, assoc} Modify = T3 {Media...., Event..., Signal}, Modify = T1 {Media...., Event..., Signal}, Modify = T2 {Media...., Event..., Signal} } } If the commands in the action are executed in the following order 1. Modify = T3 2. Topology (T1, T2, assoc) 3. Modify T1 4. Modify T2 then if Modify T1 or Modify T2 fails, should Topology should be rollbacked to previous value? thanks and regards Anjana Arora 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 Mon Mar 3 13:24: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 NAA06341 for ; Mon, 3 Mar 2003 13:24:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23IYMD12363 for megaco-archive@odin.ietf.org; Mon, 3 Mar 2003 13:34: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 h23IYLp12360 for ; Mon, 3 Mar 2003 13:34: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 NAA06319 for ; Mon, 3 Mar 2003 13:23: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 h23IThp11973; Mon, 3 Mar 2003 13:29: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 h23BvMp08561 for ; Mon, 3 Mar 2003 06:57:22 -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 GAA18184 for ; Mon, 3 Mar 2003 06:46:52 -0500 (EST) From: anarora@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 h23BlDs27290 for ; Mon, 3 Mar 2003 17:17:14 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5] (may be forged)) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h23BlC227286 for ; Mon, 3 Mar 2003 17:17:12 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h23BnnB13018 for ; Mon, 3 Mar 2003 17:19:50 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CDE.004027A8 ; Mon, 3 Mar 2003 17:10:44 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org cc: samittal@hss.hns.com, prjain@hss.hns.com, shbansal@hss.hns.com Message-ID: <65256CDE.00402697.00@sandesh.hss.hns.com> Date: Mon, 3 Mar 2003 17:15:06 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Rollback Support in Topology Descriptor Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi I have a query regarding rollback of topology if one of the commands in the action fails... Consider the following e.g. T1, T2 and T3 are already present in the context: MEGACO/1 [111.111.111.4]:222 Transaction = 23{ Context = 1 { Topology { T1. T2, assoc} Modify = T3 {Media...., Event..., Signal}, Modify = T1 {Media...., Event..., Signal}, Modify = T2 {Media...., Event..., Signal} } } If the commands in the action are executed in the following order 1. Modify = T3 2. Topology (T1, T2, assoc) 3. Modify T1 4. Modify T2 then if Modify T1 or Modify T2 fails, should Topology should be rollbacked to previous value? thanks and regards Anjana Arora 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 Mon Mar 3 15:52: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 PAA12446 for ; Mon, 3 Mar 2003 15:52: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 h23L2Kp25274; Mon, 3 Mar 2003 16:02: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 h23L0bp25189 for ; Mon, 3 Mar 2003 16:00:37 -0500 Received: from wench.telica.com ([4.19.224.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12383 for ; Mon, 3 Mar 2003 15:49:58 -0500 (EST) Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Mar 2003 15:47:34 -0500 Message-ID: From: Carl Rutter To: megaco@ietf.org Date: Mon, 3 Mar 2003 15:47: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] SDP Reply 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: , Question on what SDP reply information is required by MEGACO Say someone specifies in a Local or Remote Descriptor a fully qualified attribute ie) a=ptime:30 for the Transaction Request In the Reply that goes back should the descriptor contain the attribute a=ptime:30 ie) Page 171-172 of MEGACO V1 with Corrections does not. Also fully qualified Remote Descriptors are not replied back. Isn't the intent to reply with ONLY SDP information that was altered/chosen by the MG? Is it optional to reply with the specified information? Could you point me to the section dealing with this in either RFC 2327 or 3015? 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 Mon Mar 3 15:54:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12529 for ; Mon, 3 Mar 2003 15:54:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23L4OP25450 for megaco-archive@odin.ietf.org; Mon, 3 Mar 2003 16:04: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 h23L4Np25447 for ; Mon, 3 Mar 2003 16:04:23 -0500 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12487 for ; Mon, 3 Mar 2003 15:53:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23L2Kp25274; Mon, 3 Mar 2003 16:02: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 h23L0bp25189 for ; Mon, 3 Mar 2003 16:00:37 -0500 Received: from wench.telica.com ([4.19.224.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12383 for ; Mon, 3 Mar 2003 15:49:58 -0500 (EST) Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Mar 2003 15:47:34 -0500 Message-ID: From: Carl Rutter To: megaco@ietf.org Date: Mon, 3 Mar 2003 15:47: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] SDP Reply 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: , Question on what SDP reply information is required by MEGACO Say someone specifies in a Local or Remote Descriptor a fully qualified attribute ie) a=ptime:30 for the Transaction Request In the Reply that goes back should the descriptor contain the attribute a=ptime:30 ie) Page 171-172 of MEGACO V1 with Corrections does not. Also fully qualified Remote Descriptors are not replied back. Isn't the intent to reply with ONLY SDP information that was altered/chosen by the MG? Is it optional to reply with the specified information? Could you point me to the section dealing with this in either RFC 2327 or 3015? 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 Mon Mar 3 23:31: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 XAA23432 for ; Mon, 3 Mar 2003 23:31: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 h244bsp22728; Mon, 3 Mar 2003 23:37: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 h244ajp21929 for ; Mon, 3 Mar 2003 23:36: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 XAA23373 for ; Mon, 3 Mar 2003 23:25:54 -0500 (EST) From: anarora@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 h244QHs01150 for ; Tue, 4 Mar 2003 09:56:17 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5] (may be forged)) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h244QG201146 for ; Tue, 4 Mar 2003 09:56:17 +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 h244Ssn05986 for ; Tue, 4 Mar 2003 09:58:54 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CDF.0017CA59 ; Tue, 4 Mar 2003 09:49:51 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org cc: samittal@hss.hns.com, prjain@hss.hns.com, shbansal@hss.hns.com Message-ID: <65256CDF.0017CA1A.00@sandesh.hss.hns.com> Date: Tue, 4 Mar 2003 09:55:00 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Rollback Support in Topology Descriptor Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi I have a query regarding rollback of topology if one of the commands in the action fails... Consider the following e.g. T1, T2 and T3 are already present in the context: MEGACO/1 [111.111.111.4]:222 Transaction = 23{ Context = 1 { Topology { T1. T2, assoc} Modify = T3 {Media...., Event..., Signal}, Modify = T1 {Media...., Event..., Signal}, Modify = T2 {Media...., Event..., Signal} } } If the commands in the action are executed in the following order 1. Modify = T3 2. Topology (T1, T2, assoc) 3. Modify T1 4. Modify T2 then if Modify T1 or Modify T2 fails, should Topology should be rollbacked to previous value? thanks and regards Anjana Arora 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 Mon Mar 3 23:32: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 XAA23466 for ; Mon, 3 Mar 2003 23:32:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h244glc22896 for megaco-archive@odin.ietf.org; Mon, 3 Mar 2003 23:42: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 h244glp22893 for ; Mon, 3 Mar 2003 23:42: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 XAA23453 for ; Mon, 3 Mar 2003 23:31: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 h244bsp22728; Mon, 3 Mar 2003 23:37: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 h244ajp21929 for ; Mon, 3 Mar 2003 23:36: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 XAA23373 for ; Mon, 3 Mar 2003 23:25:54 -0500 (EST) From: anarora@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 h244QHs01150 for ; Tue, 4 Mar 2003 09:56:17 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5] (may be forged)) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h244QG201146 for ; Tue, 4 Mar 2003 09:56:17 +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 h244Ssn05986 for ; Tue, 4 Mar 2003 09:58:54 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CDF.0017CA59 ; Tue, 4 Mar 2003 09:49:51 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org cc: samittal@hss.hns.com, prjain@hss.hns.com, shbansal@hss.hns.com Message-ID: <65256CDF.0017CA1A.00@sandesh.hss.hns.com> Date: Tue, 4 Mar 2003 09:55:00 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Rollback Support in Topology Descriptor Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi I have a query regarding rollback of topology if one of the commands in the action fails... Consider the following e.g. T1, T2 and T3 are already present in the context: MEGACO/1 [111.111.111.4]:222 Transaction = 23{ Context = 1 { Topology { T1. T2, assoc} Modify = T3 {Media...., Event..., Signal}, Modify = T1 {Media...., Event..., Signal}, Modify = T2 {Media...., Event..., Signal} } } If the commands in the action are executed in the following order 1. Modify = T3 2. Topology (T1, T2, assoc) 3. Modify T1 4. Modify T2 then if Modify T1 or Modify T2 fails, should Topology should be rollbacked to previous value? thanks and regards Anjana Arora 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 Mon Mar 3 23:42: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 XAA23674 for ; Mon, 3 Mar 2003 23:42: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 h244q8p23221; Mon, 3 Mar 2003 23:52: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 h244p9p23180 for ; Mon, 3 Mar 2003 23:51:09 -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 XAA23622 for ; Mon, 3 Mar 2003 23:40:17 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h244g9nS024374; Tue, 4 Mar 2003 05:42:09 +0100 (MET) Received: from brsf10.epa.ericsson.se ([146.11.8.4]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id F5W897BQ; Tue, 4 Mar 2003 05:42:08 +0100 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 h244g4a27111; Tue, 4 Mar 2003 15:42:04 +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 DZ363X9V; Tue, 4 Mar 2003 15:42:04 +1100 Message-ID: <3E6410FD.FD85FA9C@ericsson.com.au> Date: Tue, 04 Mar 2003 13:35:41 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Aleksandr Ryabin CC: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : Difference fromprevious revision References: <5.2.0.9.0.20030303111733.02b49be0@imap.winphoria.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 I would prefer that the revision of the packages is not changed. A stepping of revision still means the changes are backwards compatible however from a quick glance it appears that the proposed changes are not backwards compatible. If people have a concern about implementing according to a draft (they should expect changes if they do this) then I would rename the packages. I note also that the packages should be registered with IANA and that where a package extends another package it should make reference to the version. Christian Aleksandr Ryabin wrote: > > Hi, > > These are pretty big changes. I know the previous version was a draft, > but its been out there for a while now, so there are implementations > which use it. That seem to be a good reason to bump the version > of the package for new revision of draft. > > Questions: > > 1. Now that block/unblock signals/events have been removed I'd think > bcas package should be handling these supervisory signal procedures, > but I can't seem to find any reference to these procedures in bcas. > Can you clarify on how block/unblock are to be implemented now? > > 2. I can't seem to find a way to send/receive to/from MGC (currently spare) R2 > Group B backward digits from B-11 to B-15? > One way would be to have them in possible values of cplc and their > descriptions > specified as "spare B-xx". Another way would be to add "Spare Called Party > Line Condition Value" parameter to cprs event and signal with int value equal > of the B signal received/to send. > > 3. I can't seem to find a way to implement "Metering Pulse" procedure defined > for some R2 variants using ether bcas or R2 packages? For example, one > of the definitions of such a pulse is a "seizure ack" pulse from a terminating > end on a circuit in connected/answer state. > > Thanks > Aleks > > At 07:21 AM 3/3/2003, vnair@hss.hns.com wrote: > > >Changes between version 03 over version 02 of R2 package > > > >1. Changed the wording of Abstract section. > > > >2. Changed the wording of Introduction section to reflect that R2 package is > >derived package of bcas package. Also, it touches upon the new signal and > >event > >"r2addr" which is added in this derived r2 package. > > > >3. Rephrased assumption b) in Assumptions section (section 5). > > > >4. Corrected sequence numbering of 4th assumption to d) in Assumptions section > >(section 5) > > > >5. Section 6.1: R2 package definition modified so as to extend bcas package. > >Changed the wording in description so as to clarify that R2 package extends > >bcas. Version 02 advocated it being used in conjunction with bcas package. > > > >6. Section 6.2 > > - Removed property "clear back signal validation time" > > - Changed Property Id from "callen" to "snl" for Property Name "Source > > Number > >Length" > > - Removed the wordings mentioning the procedure to collect source number. > > - Removed property "source number time-out" > > - Removed property "subscriber line status flag" > > - Removed property "trunk direction" > > - Added property "Compelling Sequence Keepalive Timer" > > > >7. Section 6.3 > > - Removed event "Unblock" > > - ObservedEventDescriptor of r2addr event > > + Changed description for possible values of dimeth parameter > > + Removed procedure for collecting source number in si parameter > > description > > + Added parameter "Source Number Termination Method" > > + Changed description of sc parameter to align the language used throughout > > + Changed description of es parameter to align the language used throughout > > + Changed description of cc parameter to align the language used throughout > > + Removed procedure for collecting country code in cc parameter description > > + Changed description of disc parameter to align the language used > > throughout > > + Changed description of nac parameter to align the language used > > throughout > > - Renamed "Subscriber Line Status" to "Called Party Reachability Status" to > >clarify the meaning for the event > > - Changed the wording in R2 Failure event description. Also, changed the > >possible value for this event > > - Changed description for possible values of dimeth parameter under > >ObservedEventDescriptor of di event. > > - Changed description si parameter under ObservedEventDescriptor of si > > event. > > - Added Source Number Termination method parameter under > >ObservedEventDescriptor of si event > > - Added Congestion Event > > > >8. Section 6.4 > > - Removed Block signal > > - Removed Unblock signal > > - Renamed signal "Subscriber Line Status" to "Called Party Reachability > >Status". Also, modified the description for this signal > > > >9. Section 6.5 > > - Removed Call Duration statistics defined by this package. > > > >10. Section 7 > > - Removed description of property parameters defined in section 7.1 of > > version > >02 > > - Removed procedures for exchanging supervisory signals > > - Removed procedures for exchanging call set-up control information > > - Removed call flows for incoming MG > > - Removed call flows for outgoing MG > > - Added procedure for Termination of Called Party Number digit collection at > >incoming MG > > - Added procedure for Termination of Calling Party Number collection at > >incoming MG > > - Added procedure for Termination of Country Code digit collection at > > incoming > >MG > > - Added procedure for Termination of Compelling Sequence > > > >11. Section 8 > > - Modified reference number [4] for newer version of bcas draft referred > > > >12. Section 9 > > - Modified Author's Address to reflect new contact phone numbers > > > >13. The usage of keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > >NOT", > >"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are > >corrected all > >across the draft. > > > >Thanks > >- Vikram Nair > >www.hssworld.com > > > >DISCLAIMER: This message is proprietary to Hughes Software Systems > >Limited (HSS) and is intended solely for the use of the individual > >to whom it is addressed. It may contain privileged or confidential > >information and should not be circulated or used for any purpose other > >than for what it is intended. If you have received this message in error, > >please notify the originator immediately. If you are not the intended > >recipient, you are notified that you are strictly prohibited from using, > >copying, altering, or disclosing the contents of this message. HSS accepts > >no responsibility for loss or damage arising from the use of the information > >transmitted by this email including damage from virus. > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Mar 3 23:43: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 XAA23699 for ; Mon, 3 Mar 2003 23:43:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h244sF023279 for megaco-archive@odin.ietf.org; Mon, 3 Mar 2003 23:54: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 h244sFp23276 for ; Mon, 3 Mar 2003 23:54:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23688 for ; Mon, 3 Mar 2003 23:43: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 h244q8p23221; Mon, 3 Mar 2003 23:52: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 h244p9p23180 for ; Mon, 3 Mar 2003 23:51:09 -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 XAA23622 for ; Mon, 3 Mar 2003 23:40:17 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h244g9nS024374; Tue, 4 Mar 2003 05:42:09 +0100 (MET) Received: from brsf10.epa.ericsson.se ([146.11.8.4]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id F5W897BQ; Tue, 4 Mar 2003 05:42:08 +0100 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 h244g4a27111; Tue, 4 Mar 2003 15:42:04 +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 DZ363X9V; Tue, 4 Mar 2003 15:42:04 +1100 Message-ID: <3E6410FD.FD85FA9C@ericsson.com.au> Date: Tue, 04 Mar 2003 13:35:41 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Aleksandr Ryabin CC: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : Difference fromprevious revision References: <5.2.0.9.0.20030303111733.02b49be0@imap.winphoria.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 I would prefer that the revision of the packages is not changed. A stepping of revision still means the changes are backwards compatible however from a quick glance it appears that the proposed changes are not backwards compatible. If people have a concern about implementing according to a draft (they should expect changes if they do this) then I would rename the packages. I note also that the packages should be registered with IANA and that where a package extends another package it should make reference to the version. Christian Aleksandr Ryabin wrote: > > Hi, > > These are pretty big changes. I know the previous version was a draft, > but its been out there for a while now, so there are implementations > which use it. That seem to be a good reason to bump the version > of the package for new revision of draft. > > Questions: > > 1. Now that block/unblock signals/events have been removed I'd think > bcas package should be handling these supervisory signal procedures, > but I can't seem to find any reference to these procedures in bcas. > Can you clarify on how block/unblock are to be implemented now? > > 2. I can't seem to find a way to send/receive to/from MGC (currently spare) R2 > Group B backward digits from B-11 to B-15? > One way would be to have them in possible values of cplc and their > descriptions > specified as "spare B-xx". Another way would be to add "Spare Called Party > Line Condition Value" parameter to cprs event and signal with int value equal > of the B signal received/to send. > > 3. I can't seem to find a way to implement "Metering Pulse" procedure defined > for some R2 variants using ether bcas or R2 packages? For example, one > of the definitions of such a pulse is a "seizure ack" pulse from a terminating > end on a circuit in connected/answer state. > > Thanks > Aleks > > At 07:21 AM 3/3/2003, vnair@hss.hns.com wrote: > > >Changes between version 03 over version 02 of R2 package > > > >1. Changed the wording of Abstract section. > > > >2. Changed the wording of Introduction section to reflect that R2 package is > >derived package of bcas package. Also, it touches upon the new signal and > >event > >"r2addr" which is added in this derived r2 package. > > > >3. Rephrased assumption b) in Assumptions section (section 5). > > > >4. Corrected sequence numbering of 4th assumption to d) in Assumptions section > >(section 5) > > > >5. Section 6.1: R2 package definition modified so as to extend bcas package. > >Changed the wording in description so as to clarify that R2 package extends > >bcas. Version 02 advocated it being used in conjunction with bcas package. > > > >6. Section 6.2 > > - Removed property "clear back signal validation time" > > - Changed Property Id from "callen" to "snl" for Property Name "Source > > Number > >Length" > > - Removed the wordings mentioning the procedure to collect source number. > > - Removed property "source number time-out" > > - Removed property "subscriber line status flag" > > - Removed property "trunk direction" > > - Added property "Compelling Sequence Keepalive Timer" > > > >7. Section 6.3 > > - Removed event "Unblock" > > - ObservedEventDescriptor of r2addr event > > + Changed description for possible values of dimeth parameter > > + Removed procedure for collecting source number in si parameter > > description > > + Added parameter "Source Number Termination Method" > > + Changed description of sc parameter to align the language used throughout > > + Changed description of es parameter to align the language used throughout > > + Changed description of cc parameter to align the language used throughout > > + Removed procedure for collecting country code in cc parameter description > > + Changed description of disc parameter to align the language used > > throughout > > + Changed description of nac parameter to align the language used > > throughout > > - Renamed "Subscriber Line Status" to "Called Party Reachability Status" to > >clarify the meaning for the event > > - Changed the wording in R2 Failure event description. Also, changed the > >possible value for this event > > - Changed description for possible values of dimeth parameter under > >ObservedEventDescriptor of di event. > > - Changed description si parameter under ObservedEventDescriptor of si > > event. > > - Added Source Number Termination method parameter under > >ObservedEventDescriptor of si event > > - Added Congestion Event > > > >8. Section 6.4 > > - Removed Block signal > > - Removed Unblock signal > > - Renamed signal "Subscriber Line Status" to "Called Party Reachability > >Status". Also, modified the description for this signal > > > >9. Section 6.5 > > - Removed Call Duration statistics defined by this package. > > > >10. Section 7 > > - Removed description of property parameters defined in section 7.1 of > > version > >02 > > - Removed procedures for exchanging supervisory signals > > - Removed procedures for exchanging call set-up control information > > - Removed call flows for incoming MG > > - Removed call flows for outgoing MG > > - Added procedure for Termination of Called Party Number digit collection at > >incoming MG > > - Added procedure for Termination of Calling Party Number collection at > >incoming MG > > - Added procedure for Termination of Country Code digit collection at > > incoming > >MG > > - Added procedure for Termination of Compelling Sequence > > > >11. Section 8 > > - Modified reference number [4] for newer version of bcas draft referred > > > >12. Section 9 > > - Modified Author's Address to reflect new contact phone numbers > > > >13. The usage of keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > >NOT", > >"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are > >corrected all > >across the draft. > > > >Thanks > >- Vikram Nair > >www.hssworld.com > > > >DISCLAIMER: This message is proprietary to Hughes Software Systems > >Limited (HSS) and is intended solely for the use of the individual > >to whom it is addressed. It may contain privileged or confidential > >information and should not be circulated or used for any purpose other > >than for what it is intended. If you have received this message in error, > >please notify the originator immediately. If you are not the intended > >recipient, you are notified that you are strictly prohibited from using, > >copying, altering, or disclosing the contents of this message. HSS accepts > >no responsibility for loss or damage arising from the use of the information > >transmitted by this email including damage from virus. > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Mar 4 02:25: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 CAA08078 for ; Tue, 4 Mar 2003 02:25: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 h247Xrp10674; Tue, 4 Mar 2003 02: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 h247TUp10440 for ; Tue, 4 Mar 2003 02:29:30 -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 CAA07977 for ; Tue, 4 Mar 2003 02:18:33 -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 h247Irs03988 for ; Tue, 4 Mar 2003 12:48:53 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5] (may be forged)) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h247Ip203971; Tue, 4 Mar 2003 12:48:51 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h247LR621412; Tue, 4 Mar 2003 12:51:28 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CDF.00279846 ; Tue, 4 Mar 2003 12:42:28 +0530 X-Lotus-FromDomain: HSS To: Aleksandr Ryabin cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com Message-ID: <65256CDF.0027977D.00@sandesh.hss.hns.com> Date: Tue, 4 Mar 2003 12:47:37 +0530 Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : Difference from previous revision 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: , Aleks, Response inline [Kushanava] regards, Kushanava Aleksandr Ryabin on 03/03/2003 10:43:20 PM To: Vikram Nair/HSS@HSS, megaco@ietf.org cc: Kushanava Laha/HSS@HSS Subject: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : Difference from previous revision Hi, These are pretty big changes. I know the previous version was a draft, but its been out there for a while now, so there are implementations which use it. That seem to be a good reason to bump the version of the package for new revision of draft. [Kushanava] The previous R2 package version had its limitations as pointed out by this mailing list. Moreover there was a strong urge to align it with the "bcas" package and make "r2" package a derived package of "bcas". We believe the suggestions were valid and this new revision was inevitable. We had waited this long for "bcas" to become an RFC, so that there is a stable "bcas" package version which "r2" can derive. But till now we still await the standardization of "bcas". Questions: 1. Now that block/unblock signals/events have been removed I'd think bcas package should be handling these supervisory signal procedures, but I can't seem to find any reference to these procedures in bcas. Can you clarify on how block/unblock are to be implemented now? [Kushanava] CAS Trunk Blocking/Unblocking is not specific to R2. Again it may not be mandatory for all CAS signaling to realize trunk blocking/ unblocking procedures. So "bcas" may not be the right place for it. Neither is "r2". A separate package draft ("casmntc") has been submitted to IETF to this effect. I am expecting it to be out within the next few days. 2. I can't seem to find a way to send/receive to/from MGC (currently spare) R2 Group B backward digits from B-11 to B-15? One way would be to have them in possible values of cplc and their descriptions specified as "spare B-xx". Another way would be to add "Spare Called Party Line Condition Value" parameter to cprs event and signal with int value equal of the B signal received/to send. [Kushanava] The advised solution to this is to extend this R2 package and introduce new enums for "cplc". This could be true even for parameters other than "cplc" where variants have a role to play. I anticipate a derived r2 package for each variant that has something different to offer. This R2 package offers the basic skeleton to move forward towards implementing variant peculiarities, if not already covered by this package. 3. I can't seem to find a way to implement "Metering Pulse" procedure defined for some R2 variants using ether bcas or R2 packages? For example, one of the definitions of such a pulse is a "seizure ack" pulse from a terminating end on a circuit in connected/answer state. [Kushanava] Metering is not specific to R2. It may be present in any CAS signaling. Moreover not all flavours of R2 permit metering to be mandatory. There should be therefore a general philosophy of attacking this problem common to all CAS signaling. The solution should be sensitive to a) Realizing that MGC is the master for collecting and generating charging information b) Interworking of the CAS "metering pulse" signals with other signaling (both PDN and PSTN) c) Optimizing the network traffic if metering information is transported to and fro between MGC and MG d) Latency, if metering information is transported to and fro between MGC and MG We are working towards a separate package that addresses this issue. Any suggestions? Thanks Aleks At 07:21 AM 3/3/2003, vnair@hss.hns.com wrote: >Changes between version 03 over version 02 of R2 package > >1. Changed the wording of Abstract section. > >2. Changed the wording of Introduction section to reflect that R2 package is >derived package of bcas package. Also, it touches upon the new signal and >event >"r2addr" which is added in this derived r2 package. > >3. Rephrased assumption b) in Assumptions section (section 5). > >4. Corrected sequence numbering of 4th assumption to d) in Assumptions section >(section 5) > >5. Section 6.1: R2 package definition modified so as to extend bcas package. >Changed the wording in description so as to clarify that R2 package extends >bcas. Version 02 advocated it being used in conjunction with bcas package. > >6. Section 6.2 > - Removed property "clear back signal validation time" > - Changed Property Id from "callen" to "snl" for Property Name "Source > Number >Length" > - Removed the wordings mentioning the procedure to collect source number. > - Removed property "source number time-out" > - Removed property "subscriber line status flag" > - Removed property "trunk direction" > - Added property "Compelling Sequence Keepalive Timer" > >7. Section 6.3 > - Removed event "Unblock" > - ObservedEventDescriptor of r2addr event > + Changed description for possible values of dimeth parameter > + Removed procedure for collecting source number in si parameter > description > + Added parameter "Source Number Termination Method" > + Changed description of sc parameter to align the language used throughout > + Changed description of es parameter to align the language used throughout > + Changed description of cc parameter to align the language used throughout > + Removed procedure for collecting country code in cc parameter description > + Changed description of disc parameter to align the language used > throughout > + Changed description of nac parameter to align the language used > throughout > - Renamed "Subscriber Line Status" to "Called Party Reachability Status" to >clarify the meaning for the event > - Changed the wording in R2 Failure event description. Also, changed the >possible value for this event > - Changed description for possible values of dimeth parameter under >ObservedEventDescriptor of di event. > - Changed description si parameter under ObservedEventDescriptor of si > event. > - Added Source Number Termination method parameter under >ObservedEventDescriptor of si event > - Added Congestion Event > >8. Section 6.4 > - Removed Block signal > - Removed Unblock signal > - Renamed signal "Subscriber Line Status" to "Called Party Reachability >Status". Also, modified the description for this signal > >9. Section 6.5 > - Removed Call Duration statistics defined by this package. > >10. Section 7 > - Removed description of property parameters defined in section 7.1 of > version >02 > - Removed procedures for exchanging supervisory signals > - Removed procedures for exchanging call set-up control information > - Removed call flows for incoming MG > - Removed call flows for outgoing MG > - Added procedure for Termination of Called Party Number digit collection at >incoming MG > - Added procedure for Termination of Calling Party Number collection at >incoming MG > - Added procedure for Termination of Country Code digit collection at > incoming >MG > - Added procedure for Termination of Compelling Sequence > >11. Section 8 > - Modified reference number [4] for newer version of bcas draft referred > >12. Section 9 > - Modified Author's Address to reflect new contact phone numbers > >13. The usage of keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >NOT", >"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are >corrected all >across the draft. > >Thanks >- Vikram Nair >www.hssworld.com > >DISCLAIMER: This message is proprietary to Hughes Software Systems >Limited (HSS) and is intended solely for the use of the individual >to whom it is addressed. It may contain privileged or confidential >information and should not be circulated or used for any purpose other >than for what it is intended. If you have received this message in error, >please notify the originator immediately. If you are not the intended >recipient, you are notified that you are strictly prohibited from using, >copying, altering, or disclosing the contents of this message. HSS accepts >no responsibility for loss or damage arising from the use of the information >transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Mar 4 02:26: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 CAA08128 for ; Tue, 4 Mar 2003 02:26:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h247adD10851 for megaco-archive@odin.ietf.org; Tue, 4 Mar 2003 02: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 h247adp10848 for ; Tue, 4 Mar 2003 02: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 CAA08113 for ; Tue, 4 Mar 2003 02:25: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 h247Xrp10674; Tue, 4 Mar 2003 02: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 h247TUp10440 for ; Tue, 4 Mar 2003 02:29:30 -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 CAA07977 for ; Tue, 4 Mar 2003 02:18:33 -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 h247Irs03988 for ; Tue, 4 Mar 2003 12:48:53 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5] (may be forged)) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h247Ip203971; Tue, 4 Mar 2003 12:48:51 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h247LR621412; Tue, 4 Mar 2003 12:51:28 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CDF.00279846 ; Tue, 4 Mar 2003 12:42:28 +0530 X-Lotus-FromDomain: HSS To: Aleksandr Ryabin cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com Message-ID: <65256CDF.0027977D.00@sandesh.hss.hns.com> Date: Tue, 4 Mar 2003 12:47:37 +0530 Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : Difference from previous revision 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: , Aleks, Response inline [Kushanava] regards, Kushanava Aleksandr Ryabin on 03/03/2003 10:43:20 PM To: Vikram Nair/HSS@HSS, megaco@ietf.org cc: Kushanava Laha/HSS@HSS Subject: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : Difference from previous revision Hi, These are pretty big changes. I know the previous version was a draft, but its been out there for a while now, so there are implementations which use it. That seem to be a good reason to bump the version of the package for new revision of draft. [Kushanava] The previous R2 package version had its limitations as pointed out by this mailing list. Moreover there was a strong urge to align it with the "bcas" package and make "r2" package a derived package of "bcas". We believe the suggestions were valid and this new revision was inevitable. We had waited this long for "bcas" to become an RFC, so that there is a stable "bcas" package version which "r2" can derive. But till now we still await the standardization of "bcas". Questions: 1. Now that block/unblock signals/events have been removed I'd think bcas package should be handling these supervisory signal procedures, but I can't seem to find any reference to these procedures in bcas. Can you clarify on how block/unblock are to be implemented now? [Kushanava] CAS Trunk Blocking/Unblocking is not specific to R2. Again it may not be mandatory for all CAS signaling to realize trunk blocking/ unblocking procedures. So "bcas" may not be the right place for it. Neither is "r2". A separate package draft ("casmntc") has been submitted to IETF to this effect. I am expecting it to be out within the next few days. 2. I can't seem to find a way to send/receive to/from MGC (currently spare) R2 Group B backward digits from B-11 to B-15? One way would be to have them in possible values of cplc and their descriptions specified as "spare B-xx". Another way would be to add "Spare Called Party Line Condition Value" parameter to cprs event and signal with int value equal of the B signal received/to send. [Kushanava] The advised solution to this is to extend this R2 package and introduce new enums for "cplc". This could be true even for parameters other than "cplc" where variants have a role to play. I anticipate a derived r2 package for each variant that has something different to offer. This R2 package offers the basic skeleton to move forward towards implementing variant peculiarities, if not already covered by this package. 3. I can't seem to find a way to implement "Metering Pulse" procedure defined for some R2 variants using ether bcas or R2 packages? For example, one of the definitions of such a pulse is a "seizure ack" pulse from a terminating end on a circuit in connected/answer state. [Kushanava] Metering is not specific to R2. It may be present in any CAS signaling. Moreover not all flavours of R2 permit metering to be mandatory. There should be therefore a general philosophy of attacking this problem common to all CAS signaling. The solution should be sensitive to a) Realizing that MGC is the master for collecting and generating charging information b) Interworking of the CAS "metering pulse" signals with other signaling (both PDN and PSTN) c) Optimizing the network traffic if metering information is transported to and fro between MGC and MG d) Latency, if metering information is transported to and fro between MGC and MG We are working towards a separate package that addresses this issue. Any suggestions? Thanks Aleks At 07:21 AM 3/3/2003, vnair@hss.hns.com wrote: >Changes between version 03 over version 02 of R2 package > >1. Changed the wording of Abstract section. > >2. Changed the wording of Introduction section to reflect that R2 package is >derived package of bcas package. Also, it touches upon the new signal and >event >"r2addr" which is added in this derived r2 package. > >3. Rephrased assumption b) in Assumptions section (section 5). > >4. Corrected sequence numbering of 4th assumption to d) in Assumptions section >(section 5) > >5. Section 6.1: R2 package definition modified so as to extend bcas package. >Changed the wording in description so as to clarify that R2 package extends >bcas. Version 02 advocated it being used in conjunction with bcas package. > >6. Section 6.2 > - Removed property "clear back signal validation time" > - Changed Property Id from "callen" to "snl" for Property Name "Source > Number >Length" > - Removed the wordings mentioning the procedure to collect source number. > - Removed property "source number time-out" > - Removed property "subscriber line status flag" > - Removed property "trunk direction" > - Added property "Compelling Sequence Keepalive Timer" > >7. Section 6.3 > - Removed event "Unblock" > - ObservedEventDescriptor of r2addr event > + Changed description for possible values of dimeth parameter > + Removed procedure for collecting source number in si parameter > description > + Added parameter "Source Number Termination Method" > + Changed description of sc parameter to align the language used throughout > + Changed description of es parameter to align the language used throughout > + Changed description of cc parameter to align the language used throughout > + Removed procedure for collecting country code in cc parameter description > + Changed description of disc parameter to align the language used > throughout > + Changed description of nac parameter to align the language used > throughout > - Renamed "Subscriber Line Status" to "Called Party Reachability Status" to >clarify the meaning for the event > - Changed the wording in R2 Failure event description. Also, changed the >possible value for this event > - Changed description for possible values of dimeth parameter under >ObservedEventDescriptor of di event. > - Changed description si parameter under ObservedEventDescriptor of si > event. > - Added Source Number Termination method parameter under >ObservedEventDescriptor of si event > - Added Congestion Event > >8. Section 6.4 > - Removed Block signal > - Removed Unblock signal > - Renamed signal "Subscriber Line Status" to "Called Party Reachability >Status". Also, modified the description for this signal > >9. Section 6.5 > - Removed Call Duration statistics defined by this package. > >10. Section 7 > - Removed description of property parameters defined in section 7.1 of > version >02 > - Removed procedures for exchanging supervisory signals > - Removed procedures for exchanging call set-up control information > - Removed call flows for incoming MG > - Removed call flows for outgoing MG > - Added procedure for Termination of Called Party Number digit collection at >incoming MG > - Added procedure for Termination of Calling Party Number collection at >incoming MG > - Added procedure for Termination of Country Code digit collection at > incoming >MG > - Added procedure for Termination of Compelling Sequence > >11. Section 8 > - Modified reference number [4] for newer version of bcas draft referred > >12. Section 9 > - Modified Author's Address to reflect new contact phone numbers > >13. The usage of keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >NOT", >"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are >corrected all >across the draft. > >Thanks >- Vikram Nair >www.hssworld.com > >DISCLAIMER: This message is proprietary to Hughes Software Systems >Limited (HSS) and is intended solely for the use of the individual >to whom it is addressed. It may contain privileged or confidential >information and should not be circulated or used for any purpose other >than for what it is intended. If you have received this message in error, >please notify the originator immediately. If you are not the intended >recipient, you are notified that you are strictly prohibited from using, >copying, altering, or disclosing the contents of this message. HSS accepts >no responsibility for loss or damage arising from the use of the information >transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Mar 4 04:28: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 EAA10101 for ; Tue, 4 Mar 2003 04:28: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 h249bkp19804; Tue, 4 Mar 2003 04:37: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 h249atp19009 for ; Tue, 4 Mar 2003 04:36: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 EAA10065 for ; Tue, 4 Mar 2003 04:25:57 -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 h249QJs26162 for ; Tue, 4 Mar 2003 14:56:19 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5] (may be forged)) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h249QD226153; Tue, 4 Mar 2003 14:56:13 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h249Spt02144; Tue, 4 Mar 2003 14:58:51 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CDF.0033419C ; Tue, 4 Mar 2003 14:49:51 +0530 X-Lotus-FromDomain: HSS To: zhaobo cc: vnair@hss.hns.com, megaco@ietf.org Message-ID: <65256CDF.00334129.00@sandesh.hss.hns.com> Date: Tue, 4 Mar 2003 14:55:00 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Re: Dual seize procedure and draft-ietf-megaco-r2package-03.txt Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Yes it is as per the bcas procedures. regards, Kushanava zhaobo on 03/04/2003 02:35:48 PM To: Kushanava Laha/HSS@HSS, Vikram Nair/HSS@HSS cc: Subject: Dual seize procedure and draft-ietf-megaco-r2package-03.txt Hi: Dual seize procedure has been removed from draft-ietf-megaco-r2package-03.txt. Then, what shall the MG do when dual seize happens? As per the procedure defined in bcas package? Best regards Zhaobo Huawei Technologies, China 2003/03/04 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Mar 4 04:29: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 EAA10133 for ; Tue, 4 Mar 2003 04:29:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h249djG19901 for megaco-archive@odin.ietf.org; Tue, 4 Mar 2003 04:39: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 h249dip19898 for ; Tue, 4 Mar 2003 04:39: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 EAA10128 for ; Tue, 4 Mar 2003 04:28: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 h249bkp19804; Tue, 4 Mar 2003 04:37: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 h249atp19009 for ; Tue, 4 Mar 2003 04:36: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 EAA10065 for ; Tue, 4 Mar 2003 04:25:57 -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 h249QJs26162 for ; Tue, 4 Mar 2003 14:56:19 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5] (may be forged)) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h249QD226153; Tue, 4 Mar 2003 14:56:13 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h249Spt02144; Tue, 4 Mar 2003 14:58:51 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CDF.0033419C ; Tue, 4 Mar 2003 14:49:51 +0530 X-Lotus-FromDomain: HSS To: zhaobo cc: vnair@hss.hns.com, megaco@ietf.org Message-ID: <65256CDF.00334129.00@sandesh.hss.hns.com> Date: Tue, 4 Mar 2003 14:55:00 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Re: Dual seize procedure and draft-ietf-megaco-r2package-03.txt Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Yes it is as per the bcas procedures. regards, Kushanava zhaobo on 03/04/2003 02:35:48 PM To: Kushanava Laha/HSS@HSS, Vikram Nair/HSS@HSS cc: Subject: Dual seize procedure and draft-ietf-megaco-r2package-03.txt Hi: Dual seize procedure has been removed from draft-ietf-megaco-r2package-03.txt. Then, what shall the MG do when dual seize happens? As per the procedure defined in bcas package? Best regards Zhaobo Huawei Technologies, China 2003/03/04 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Mar 4 10:36: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 KAA27308 for ; Tue, 4 Mar 2003 10:36: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 h24Fk2p14244; Tue, 4 Mar 2003 10:46: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 h24FiRp14182 for ; Tue, 4 Mar 2003 10:44:27 -0500 Received: from ihemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27243 for ; Tue, 4 Mar 2003 10:33:24 -0500 (EST) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by ihemail2.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h24FZQM01586 for ; Tue, 4 Mar 2003 10:35:26 -0500 (EST) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA14210; Tue, 4 Mar 2003 10:35:23 -0500 (EST) Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA14206; Tue, 4 Mar 2003 10:35:22 -0500 (EST) Message-ID: <3E64C70D.3030108@bell-labs.com> Date: Tue, 04 Mar 2003 10:32:29 -0500 From: Troy Cauble User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MEGACO list Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] OT: "equivalent" codecs Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit If a gateway is asked to use G729A, which it doesn't have, but it has a G729 implementation, should it use it? And vice versa? -troy _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Mar 4 10:37: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 KAA27367 for ; Tue, 4 Mar 2003 10:37:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24FloE14347 for megaco-archive@odin.ietf.org; Tue, 4 Mar 2003 10:47: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 h24Flop14344 for ; Tue, 4 Mar 2003 10:47: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 KAA27353 for ; Tue, 4 Mar 2003 10:36: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 h24Fk2p14244; Tue, 4 Mar 2003 10:46: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 h24FiRp14182 for ; Tue, 4 Mar 2003 10:44:27 -0500 Received: from ihemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27243 for ; Tue, 4 Mar 2003 10:33:24 -0500 (EST) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by ihemail2.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h24FZQM01586 for ; Tue, 4 Mar 2003 10:35:26 -0500 (EST) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA14210; Tue, 4 Mar 2003 10:35:23 -0500 (EST) Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA14206; Tue, 4 Mar 2003 10:35:22 -0500 (EST) Message-ID: <3E64C70D.3030108@bell-labs.com> Date: Tue, 04 Mar 2003 10:32:29 -0500 From: Troy Cauble User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MEGACO list Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] OT: "equivalent" codecs Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit If a gateway is asked to use G729A, which it doesn't have, but it has a G729 implementation, should it use it? And vice versa? -troy _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Mar 4 10:54:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28114 for ; Tue, 4 Mar 2003 10:54:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24G49p15278; Tue, 4 Mar 2003 11:04:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24G3Xp15238 for ; Tue, 4 Mar 2003 11:03:33 -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 KAA28047 for ; Tue, 4 Mar 2003 10:52:30 -0500 (EST) Received: from balanew ([172.16.40.43]) by mail.utstar.com (8.11.3/8.11.3) with ESMTP id h24Fslp11918; Tue, 4 Mar 2003 10:54:47 -0500 (EST) Reply-To: From: "Balasubramanian Pitchandi" To: "'Troy Cauble'" , "'MEGACO list'" Subject: RE: [Megaco] OT: "equivalent" codecs Date: Tue, 4 Mar 2003 10:54:57 -0500 Organization: UTStarcom Inc Message-ID: <003201c2e266$68816fd0$2b2810ac@balanew> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3E64C70D.3030108@bell-labs.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h24G3Xp15239 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 G.729 and G.729A are fully inter-operable with each other and are not required to be distinguishable from one another. Refer section 4.5.6 of draft-ietf-avt-profile-new-12.txt. Also per the AVT Profile, there's no payload type as well as string which represents G729A separately from G729 (whose payload type is 18). Hence I don't see how the gateway would be asked to use G.729A in the first place. Thanks, Bala -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of Troy Cauble Sent: Tuesday, March 04, 2003 10:32 AM To: MEGACO list Subject: [Megaco] OT: "equivalent" codecs If a gateway is asked to use G729A, which it doesn't have, but it has a G729 implementation, should it use it? And vice versa? -troy _______________________________________________ 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 Mar 4 10:55: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 KAA28160 for ; Tue, 4 Mar 2003 10:55:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24G5pP15385 for megaco-archive@odin.ietf.org; Tue, 4 Mar 2003 11:05: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 h24G5pp15382 for ; Tue, 4 Mar 2003 11:05: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 KAA28149 for ; Tue, 4 Mar 2003 10:54: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 h24G49p15278; Tue, 4 Mar 2003 11:04:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24G3Xp15238 for ; Tue, 4 Mar 2003 11:03:33 -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 KAA28047 for ; Tue, 4 Mar 2003 10:52:30 -0500 (EST) Received: from balanew ([172.16.40.43]) by mail.utstar.com (8.11.3/8.11.3) with ESMTP id h24Fslp11918; Tue, 4 Mar 2003 10:54:47 -0500 (EST) Reply-To: From: "Balasubramanian Pitchandi" To: "'Troy Cauble'" , "'MEGACO list'" Subject: RE: [Megaco] OT: "equivalent" codecs Date: Tue, 4 Mar 2003 10:54:57 -0500 Organization: UTStarcom Inc Message-ID: <003201c2e266$68816fd0$2b2810ac@balanew> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3E64C70D.3030108@bell-labs.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h24G3Xp15239 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 G.729 and G.729A are fully inter-operable with each other and are not required to be distinguishable from one another. Refer section 4.5.6 of draft-ietf-avt-profile-new-12.txt. Also per the AVT Profile, there's no payload type as well as string which represents G729A separately from G729 (whose payload type is 18). Hence I don't see how the gateway would be asked to use G.729A in the first place. Thanks, Bala -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of Troy Cauble Sent: Tuesday, March 04, 2003 10:32 AM To: MEGACO list Subject: [Megaco] OT: "equivalent" codecs If a gateway is asked to use G729A, which it doesn't have, but it has a G729 implementation, should it use it? And vice versa? -troy _______________________________________________ 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 Mar 4 11:04: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 LAA28601 for ; Tue, 4 Mar 2003 11:04: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 h24GE8p16632; Tue, 4 Mar 2003 11:14: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 h24GBgp16493 for ; Tue, 4 Mar 2003 11:11:42 -0500 Received: from bos-exch01.winphoria.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28417 for ; Tue, 4 Mar 2003 11:00:38 -0500 (EST) Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 4 Mar 2003 11:02:39 -0500 Message-Id: <5.2.0.9.0.20030304101754.01cf47d0@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 04 Mar 2003 11:00:52 -0500 To: klaha@hss.hns.com, megaco@ietf.org From: Aleksandr Ryabin Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : Difference from previous revision Cc: vnair@hss.hns.com In-Reply-To: <65256CDF.0027977D.00@sandesh.hss.hns.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 04 Mar 2003 16:02:39.0649 (UTC) FILETIME=[7B36C110:01C2E267] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, It would be nice to have "Blocking/Unblocking" and "Metering Pulse" packages in manyfolks CAS draft since they are common to CAS. Regarding B11- B15. I understand that everything can be extended in extension packages, but specifically for this case I think they should be present in "base" R2 package since they present in corresponding "base" definition of R2 Q.411 More over since there is enormous number of different R2 variants (well, at least one for each country) I think it is not feasible to have an extension package for each variant. I think in this case it would be much better to have "base" R2 package that can cover as much as it can. And since we know that meaning of a specific R2 signal is unique (that is not ambiguous) in any given R2 variant it is safe to have all spare/unused signals in base R2 package and let the call agent deal with the meaning of the signal. More over the R2 package can have an appendix which will define the meanings for a specific variant (just for reference). Thus I think that "base" R2 package should define signals/events without specific variant in mind using as much generic meaning as possible for R2 signals. Then MGC can map them to a specific meaning depending on R2 variant in use. If necessary the draft can define R2 extension packages which will define meaning of the R2 signals in similar way it is defined for current r2 package. For example, draft can define r2-itu package with explicit parameter values which will correspond to ITU definition of these values. With all that said it also seems that the base R2 package should have a read only property (per termination) which lists variants currently supported/loaded, or maybe better yet it should have two properties. One (read only) property will list all variants a termination can support and another (read/write) property will allow to set the variant to be used for a termination. IANA registry can be used for a specific values of R2 variants. Thanks. Aleks At 02:17 AM 3/4/2003, klaha@hss.hns.com wrote: >Aleks, > >Response inline [Kushanava] > >regards, >Kushanava > > > > > >Aleksandr Ryabin on 03/03/2003 10:43:20 PM > >To: Vikram Nair/HSS@HSS, megaco@ietf.org >cc: Kushanava Laha/HSS@HSS > >Subject: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : Difference from > previous revision > > > > >Hi, > >These are pretty big changes. I know the previous version was a draft, >but its been out there for a while now, so there are implementations >which use it. That seem to be a good reason to bump the version >of the package for new revision of draft. > >[Kushanava] The previous R2 package version had its limitations as pointed >out by this mailing list. Moreover there was a strong urge to align >it with the "bcas" package and make "r2" package a derived package of >"bcas". We believe the suggestions were valid and this new revision >was inevitable. We had waited this long for "bcas" to become an RFC, >so that there is a stable "bcas" package version which "r2" can derive. >But till now we still await the standardization of "bcas". > >Questions: > >1. Now that block/unblock signals/events have been removed I'd think >bcas package should be handling these supervisory signal procedures, >but I can't seem to find any reference to these procedures in bcas. >Can you clarify on how block/unblock are to be implemented now? > >[Kushanava] CAS Trunk Blocking/Unblocking is not specific to R2. Again >it may not be mandatory for all CAS signaling to realize trunk blocking/ >unblocking procedures. So "bcas" may not be the right place for it. >Neither is "r2". A separate package draft ("casmntc") has been submitted >to IETF to this effect. I am expecting it to be out within the next few days. > >2. I can't seem to find a way to send/receive to/from MGC (currently spare) R2 >Group B backward digits from B-11 to B-15? >One way would be to have them in possible values of cplc and their >descriptions >specified as "spare B-xx". Another way would be to add "Spare Called Party >Line Condition Value" parameter to cprs event and signal with int value equal >of the B signal received/to send. > >[Kushanava] The advised solution to this is to extend this R2 package and >introduce new enums for "cplc". This could be true even for parameters other >than "cplc" where variants have a role to play. I anticipate a derived >r2 package for each variant that has something different to offer. This R2 >package offers the basic skeleton to move forward towards implementing >variant peculiarities, if not already covered by this package. > >3. I can't seem to find a way to implement "Metering Pulse" procedure defined >for some R2 variants using ether bcas or R2 packages? For example, one >of the definitions of such a pulse is a "seizure ack" pulse from a terminating >end on a circuit in connected/answer state. > >[Kushanava] Metering is not specific to R2. It may be present in any CAS >signaling. Moreover not all flavours of R2 permit metering to be mandatory. >There should be therefore a general philosophy of attacking this problem >common to all CAS signaling. The solution should be sensitive to >a) Realizing that MGC is the master for collecting and generating charging >information >b) Interworking of the CAS "metering pulse" signals with other signaling >(both PDN and PSTN) >c) Optimizing the network traffic if metering information is transported to >and fro between MGC and MG >d) Latency, if metering information is transported to and fro between MGC >and MG >We are working towards a separate package that addresses this issue. >Any suggestions? > >Thanks > Aleks > >At 07:21 AM 3/3/2003, vnair@hss.hns.com wrote: > > > >Changes between version 03 over version 02 of R2 package > > > >1. Changed the wording of Abstract section. > > > >2. Changed the wording of Introduction section to reflect that R2 package is > >derived package of bcas package. Also, it touches upon the new signal and > >event > >"r2addr" which is added in this derived r2 package. > > > >3. Rephrased assumption b) in Assumptions section (section 5). > > > >4. Corrected sequence numbering of 4th assumption to d) in Assumptions > section > >(section 5) > > > >5. Section 6.1: R2 package definition modified so as to extend bcas package. > >Changed the wording in description so as to clarify that R2 package extends > >bcas. Version 02 advocated it being used in conjunction with bcas package. > > > >6. Section 6.2 > > - Removed property "clear back signal validation time" > > - Changed Property Id from "callen" to "snl" for Property Name "Source > > Number > >Length" > > - Removed the wordings mentioning the procedure to collect source number. > > - Removed property "source number time-out" > > - Removed property "subscriber line status flag" > > - Removed property "trunk direction" > > - Added property "Compelling Sequence Keepalive Timer" > > > >7. Section 6.3 > > - Removed event "Unblock" > > - ObservedEventDescriptor of r2addr event > > + Changed description for possible values of dimeth parameter > > + Removed procedure for collecting source number in si parameter > > description > > + Added parameter "Source Number Termination Method" > > + Changed description of sc parameter to align the language used > throughout > > + Changed description of es parameter to align the language used > throughout > > + Changed description of cc parameter to align the language used > throughout > > + Removed procedure for collecting country code in cc parameter > description > > + Changed description of disc parameter to align the language used > > throughout > > + Changed description of nac parameter to align the language used > > throughout > > - Renamed "Subscriber Line Status" to "Called Party Reachability > Status" to > >clarify the meaning for the event > > - Changed the wording in R2 Failure event description. Also, changed the > >possible value for this event > > - Changed description for possible values of dimeth parameter under > >ObservedEventDescriptor of di event. > > - Changed description si parameter under ObservedEventDescriptor of si > > event. > > - Added Source Number Termination method parameter under > >ObservedEventDescriptor of si event > > - Added Congestion Event > > > >8. Section 6.4 > > - Removed Block signal > > - Removed Unblock signal > > - Renamed signal "Subscriber Line Status" to "Called Party Reachability > >Status". Also, modified the description for this signal > > > >9. Section 6.5 > > - Removed Call Duration statistics defined by this package. > > > >10. Section 7 > > - Removed description of property parameters defined in section 7.1 of > > version > >02 > > - Removed procedures for exchanging supervisory signals > > - Removed procedures for exchanging call set-up control information > > - Removed call flows for incoming MG > > - Removed call flows for outgoing MG > > - Added procedure for Termination of Called Party Number digit > collection at > >incoming MG > > - Added procedure for Termination of Calling Party Number collection at > >incoming MG > > - Added procedure for Termination of Country Code digit collection at > > incoming > >MG > > - Added procedure for Termination of Compelling Sequence > > > >11. Section 8 > > - Modified reference number [4] for newer version of bcas draft referred > > > >12. Section 9 > > - Modified Author's Address to reflect new contact phone numbers > > > >13. The usage of keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > >NOT", > >"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are > >corrected all > >across the draft. > > > >Thanks > >- Vikram Nair > >www.hssworld.com > > > >DISCLAIMER: This message is proprietary to Hughes Software Systems > >Limited (HSS) and is intended solely for the use of the individual > >to whom it is addressed. It may contain privileged or confidential > >information and should not be circulated or used for any purpose other > >than for what it is intended. If you have received this message in error, > >please notify the originator immediately. If you are not the intended > >recipient, you are notified that you are strictly prohibited from using, > >copying, altering, or disclosing the contents of this message. HSS accepts > >no responsibility for loss or damage arising from the use of the information > >transmitted by this email including damage from virus. > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Mar 4 11:05: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 LAA28665 for ; Tue, 4 Mar 2003 11:05:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24GFrh16792 for megaco-archive@odin.ietf.org; Tue, 4 Mar 2003 11:15: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 h24GFrp16789 for ; Tue, 4 Mar 2003 11:15: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 LAA28649 for ; Tue, 4 Mar 2003 11:04: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 h24GE8p16632; Tue, 4 Mar 2003 11:14: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 h24GBgp16493 for ; Tue, 4 Mar 2003 11:11:42 -0500 Received: from bos-exch01.winphoria.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28417 for ; Tue, 4 Mar 2003 11:00:38 -0500 (EST) Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 4 Mar 2003 11:02:39 -0500 Message-Id: <5.2.0.9.0.20030304101754.01cf47d0@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 04 Mar 2003 11:00:52 -0500 To: klaha@hss.hns.com, megaco@ietf.org From: Aleksandr Ryabin Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : Difference from previous revision Cc: vnair@hss.hns.com In-Reply-To: <65256CDF.0027977D.00@sandesh.hss.hns.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 04 Mar 2003 16:02:39.0649 (UTC) FILETIME=[7B36C110:01C2E267] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, It would be nice to have "Blocking/Unblocking" and "Metering Pulse" packages in manyfolks CAS draft since they are common to CAS. Regarding B11- B15. I understand that everything can be extended in extension packages, but specifically for this case I think they should be present in "base" R2 package since they present in corresponding "base" definition of R2 Q.411 More over since there is enormous number of different R2 variants (well, at least one for each country) I think it is not feasible to have an extension package for each variant. I think in this case it would be much better to have "base" R2 package that can cover as much as it can. And since we know that meaning of a specific R2 signal is unique (that is not ambiguous) in any given R2 variant it is safe to have all spare/unused signals in base R2 package and let the call agent deal with the meaning of the signal. More over the R2 package can have an appendix which will define the meanings for a specific variant (just for reference). Thus I think that "base" R2 package should define signals/events without specific variant in mind using as much generic meaning as possible for R2 signals. Then MGC can map them to a specific meaning depending on R2 variant in use. If necessary the draft can define R2 extension packages which will define meaning of the R2 signals in similar way it is defined for current r2 package. For example, draft can define r2-itu package with explicit parameter values which will correspond to ITU definition of these values. With all that said it also seems that the base R2 package should have a read only property (per termination) which lists variants currently supported/loaded, or maybe better yet it should have two properties. One (read only) property will list all variants a termination can support and another (read/write) property will allow to set the variant to be used for a termination. IANA registry can be used for a specific values of R2 variants. Thanks. Aleks At 02:17 AM 3/4/2003, klaha@hss.hns.com wrote: >Aleks, > >Response inline [Kushanava] > >regards, >Kushanava > > > > > >Aleksandr Ryabin on 03/03/2003 10:43:20 PM > >To: Vikram Nair/HSS@HSS, megaco@ietf.org >cc: Kushanava Laha/HSS@HSS > >Subject: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : Difference from > previous revision > > > > >Hi, > >These are pretty big changes. I know the previous version was a draft, >but its been out there for a while now, so there are implementations >which use it. That seem to be a good reason to bump the version >of the package for new revision of draft. > >[Kushanava] The previous R2 package version had its limitations as pointed >out by this mailing list. Moreover there was a strong urge to align >it with the "bcas" package and make "r2" package a derived package of >"bcas". We believe the suggestions were valid and this new revision >was inevitable. We had waited this long for "bcas" to become an RFC, >so that there is a stable "bcas" package version which "r2" can derive. >But till now we still await the standardization of "bcas". > >Questions: > >1. Now that block/unblock signals/events have been removed I'd think >bcas package should be handling these supervisory signal procedures, >but I can't seem to find any reference to these procedures in bcas. >Can you clarify on how block/unblock are to be implemented now? > >[Kushanava] CAS Trunk Blocking/Unblocking is not specific to R2. Again >it may not be mandatory for all CAS signaling to realize trunk blocking/ >unblocking procedures. So "bcas" may not be the right place for it. >Neither is "r2". A separate package draft ("casmntc") has been submitted >to IETF to this effect. I am expecting it to be out within the next few days. > >2. I can't seem to find a way to send/receive to/from MGC (currently spare) R2 >Group B backward digits from B-11 to B-15? >One way would be to have them in possible values of cplc and their >descriptions >specified as "spare B-xx". Another way would be to add "Spare Called Party >Line Condition Value" parameter to cprs event and signal with int value equal >of the B signal received/to send. > >[Kushanava] The advised solution to this is to extend this R2 package and >introduce new enums for "cplc". This could be true even for parameters other >than "cplc" where variants have a role to play. I anticipate a derived >r2 package for each variant that has something different to offer. This R2 >package offers the basic skeleton to move forward towards implementing >variant peculiarities, if not already covered by this package. > >3. I can't seem to find a way to implement "Metering Pulse" procedure defined >for some R2 variants using ether bcas or R2 packages? For example, one >of the definitions of such a pulse is a "seizure ack" pulse from a terminating >end on a circuit in connected/answer state. > >[Kushanava] Metering is not specific to R2. It may be present in any CAS >signaling. Moreover not all flavours of R2 permit metering to be mandatory. >There should be therefore a general philosophy of attacking this problem >common to all CAS signaling. The solution should be sensitive to >a) Realizing that MGC is the master for collecting and generating charging >information >b) Interworking of the CAS "metering pulse" signals with other signaling >(both PDN and PSTN) >c) Optimizing the network traffic if metering information is transported to >and fro between MGC and MG >d) Latency, if metering information is transported to and fro between MGC >and MG >We are working towards a separate package that addresses this issue. >Any suggestions? > >Thanks > Aleks > >At 07:21 AM 3/3/2003, vnair@hss.hns.com wrote: > > > >Changes between version 03 over version 02 of R2 package > > > >1. Changed the wording of Abstract section. > > > >2. Changed the wording of Introduction section to reflect that R2 package is > >derived package of bcas package. Also, it touches upon the new signal and > >event > >"r2addr" which is added in this derived r2 package. > > > >3. Rephrased assumption b) in Assumptions section (section 5). > > > >4. Corrected sequence numbering of 4th assumption to d) in Assumptions > section > >(section 5) > > > >5. Section 6.1: R2 package definition modified so as to extend bcas package. > >Changed the wording in description so as to clarify that R2 package extends > >bcas. Version 02 advocated it being used in conjunction with bcas package. > > > >6. Section 6.2 > > - Removed property "clear back signal validation time" > > - Changed Property Id from "callen" to "snl" for Property Name "Source > > Number > >Length" > > - Removed the wordings mentioning the procedure to collect source number. > > - Removed property "source number time-out" > > - Removed property "subscriber line status flag" > > - Removed property "trunk direction" > > - Added property "Compelling Sequence Keepalive Timer" > > > >7. Section 6.3 > > - Removed event "Unblock" > > - ObservedEventDescriptor of r2addr event > > + Changed description for possible values of dimeth parameter > > + Removed procedure for collecting source number in si parameter > > description > > + Added parameter "Source Number Termination Method" > > + Changed description of sc parameter to align the language used > throughout > > + Changed description of es parameter to align the language used > throughout > > + Changed description of cc parameter to align the language used > throughout > > + Removed procedure for collecting country code in cc parameter > description > > + Changed description of disc parameter to align the language used > > throughout > > + Changed description of nac parameter to align the language used > > throughout > > - Renamed "Subscriber Line Status" to "Called Party Reachability > Status" to > >clarify the meaning for the event > > - Changed the wording in R2 Failure event description. Also, changed the > >possible value for this event > > - Changed description for possible values of dimeth parameter under > >ObservedEventDescriptor of di event. > > - Changed description si parameter under ObservedEventDescriptor of si > > event. > > - Added Source Number Termination method parameter under > >ObservedEventDescriptor of si event > > - Added Congestion Event > > > >8. Section 6.4 > > - Removed Block signal > > - Removed Unblock signal > > - Renamed signal "Subscriber Line Status" to "Called Party Reachability > >Status". Also, modified the description for this signal > > > >9. Section 6.5 > > - Removed Call Duration statistics defined by this package. > > > >10. Section 7 > > - Removed description of property parameters defined in section 7.1 of > > version > >02 > > - Removed procedures for exchanging supervisory signals > > - Removed procedures for exchanging call set-up control information > > - Removed call flows for incoming MG > > - Removed call flows for outgoing MG > > - Added procedure for Termination of Called Party Number digit > collection at > >incoming MG > > - Added procedure for Termination of Calling Party Number collection at > >incoming MG > > - Added procedure for Termination of Country Code digit collection at > > incoming > >MG > > - Added procedure for Termination of Compelling Sequence > > > >11. Section 8 > > - Modified reference number [4] for newer version of bcas draft referred > > > >12. Section 9 > > - Modified Author's Address to reflect new contact phone numbers > > > >13. The usage of keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > >NOT", > >"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are > >corrected all > >across the draft. > > > >Thanks > >- Vikram Nair > >www.hssworld.com > > > >DISCLAIMER: This message is proprietary to Hughes Software Systems > >Limited (HSS) and is intended solely for the use of the individual > >to whom it is addressed. It may contain privileged or confidential > >information and should not be circulated or used for any purpose other > >than for what it is intended. If you have received this message in error, > >please notify the originator immediately. If you are not the intended > >recipient, you are notified that you are strictly prohibited from using, > >copying, altering, or disclosing the contents of this message. HSS accepts > >no responsibility for loss or damage arising from the use of the information > >transmitted by this email including damage from virus. > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Mar 4 11:07: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 LAA28707 for ; Tue, 4 Mar 2003 11:07: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 h24GH7p16878; Tue, 4 Mar 2003 11:17: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 h24GGGp16831 for ; Tue, 4 Mar 2003 11:16:16 -0500 Received: from host4.imagelinkusa.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28660 for ; Tue, 4 Mar 2003 11:05:13 -0500 (EST) Received: from packetiz by host4.imagelinkusa.net with local (Exim 3.36 #1) id 18qEwm-0002aY-00 for megaco@ietf.org; Tue, 04 Mar 2003 11:07:16 -0500 From: "Paul Long" To: MEGACO list Subject: Re: [Megaco] OT: "equivalent" codecs X-Mailer: NeoMail 1.25 X-IPAddress: 216.54.151.127 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-Id: Date: Tue, 04 Mar 2003 11:07:16 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host4.imagelinkusa.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [746 747] / [746 747] X-AntiAbuse: Sender Address Domain - host4.imagelinkusa.net Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Troy, G.729 and G.729a put the same bits on the wire, so the receiver cannot distinguish between the two; therefore, they can be used interchangeably. G.729a just defines a reduced-complexity _implementation_ of G.729. Signaling protocols should never have introduced Annex A as an audio codec distinct from the base standard. It causes needless confusion such as what you're experiencing. Paul > > If a gateway is asked to use G729A, which it doesn't have, > but it has a G729 implementation, should it use it? > > And vice versa? > > -troy > > > _______________________________________________ > 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 Mar 4 11:08: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 LAA28758 for ; Tue, 4 Mar 2003 11:08:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24GIoH16963 for megaco-archive@odin.ietf.org; Tue, 4 Mar 2003 11:18: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 h24GIop16960 for ; Tue, 4 Mar 2003 11:18: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 LAA28744 for ; Tue, 4 Mar 2003 11:07: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 h24GH7p16878; Tue, 4 Mar 2003 11:17: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 h24GGGp16831 for ; Tue, 4 Mar 2003 11:16:16 -0500 Received: from host4.imagelinkusa.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28660 for ; Tue, 4 Mar 2003 11:05:13 -0500 (EST) Received: from packetiz by host4.imagelinkusa.net with local (Exim 3.36 #1) id 18qEwm-0002aY-00 for megaco@ietf.org; Tue, 04 Mar 2003 11:07:16 -0500 From: "Paul Long" To: MEGACO list Subject: Re: [Megaco] OT: "equivalent" codecs X-Mailer: NeoMail 1.25 X-IPAddress: 216.54.151.127 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-Id: Date: Tue, 04 Mar 2003 11:07:16 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host4.imagelinkusa.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [746 747] / [746 747] X-AntiAbuse: Sender Address Domain - host4.imagelinkusa.net Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Troy, G.729 and G.729a put the same bits on the wire, so the receiver cannot distinguish between the two; therefore, they can be used interchangeably. G.729a just defines a reduced-complexity _implementation_ of G.729. Signaling protocols should never have introduced Annex A as an audio codec distinct from the base standard. It causes needless confusion such as what you're experiencing. Paul > > If a gateway is asked to use G729A, which it doesn't have, > but it has a G729 implementation, should it use it? > > And vice versa? > > -troy > > > _______________________________________________ > 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 Mar 4 11:48: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 LAA00500 for ; Tue, 4 Mar 2003 11:48: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 h24Gwap20268; Tue, 4 Mar 2003 11:58: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 h24Gvpp20092 for ; Tue, 4 Mar 2003 11:57:51 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00257 for ; Tue, 4 Mar 2003 11:46:46 -0500 (EST) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by hoemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h24GmlP21240 for ; Tue, 4 Mar 2003 11:48:47 -0500 (EST) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id LAA14880; Tue, 4 Mar 2003 11:48:46 -0500 (EST) Cc: MEGACO list Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id LAA14866; Tue, 4 Mar 2003 11:48:45 -0500 (EST) Message-ID: <3E64D83E.1060704@bell-labs.com> Date: Tue, 04 Mar 2003 11:45:50 -0500 From: Troy Cauble User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Long Original-CC: MEGACO list Subject: Re: [Megaco] OT: "equivalent" codecs References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Just playing devil's advocate... There is a voice quality tradeoff for the complexity, yes? What about the notion of the RGC wanting control over the voice quality level and the RG's resources? The RGC may require G729 voice quality not G729A. The RGC may require G729A resource consumption not G729. -troy Paul Long wrote: > Troy, > > G.729 and G.729a put the same bits on the wire, so the receiver cannot > distinguish between the two; therefore, they can be used > interchangeably. G.729a just defines a reduced-complexity > _implementation_ of G.729. Signaling protocols should never have > introduced Annex A as an audio codec distinct from the base standard. > It causes needless confusion such as what you're experiencing. > > Paul > > >>If a gateway is asked to use G729A, which it doesn't have, >>but it has a G729 implementation, should it use it? >> >>And vice versa? _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Mar 4 11:49: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 LAA00564 for ; Tue, 4 Mar 2003 11:49:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24H0U320422 for megaco-archive@odin.ietf.org; Tue, 4 Mar 2003 12:00: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 h24H0Up20419 for ; Tue, 4 Mar 2003 12:00: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 LAA00556 for ; Tue, 4 Mar 2003 11:49: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 h24Gwap20268; Tue, 4 Mar 2003 11:58: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 h24Gvpp20092 for ; Tue, 4 Mar 2003 11:57:51 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00257 for ; Tue, 4 Mar 2003 11:46:46 -0500 (EST) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by hoemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h24GmlP21240 for ; Tue, 4 Mar 2003 11:48:47 -0500 (EST) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id LAA14880; Tue, 4 Mar 2003 11:48:46 -0500 (EST) Cc: MEGACO list Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id LAA14866; Tue, 4 Mar 2003 11:48:45 -0500 (EST) Message-ID: <3E64D83E.1060704@bell-labs.com> Date: Tue, 04 Mar 2003 11:45:50 -0500 From: Troy Cauble User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Long Original-CC: MEGACO list Subject: Re: [Megaco] OT: "equivalent" codecs References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Just playing devil's advocate... There is a voice quality tradeoff for the complexity, yes? What about the notion of the RGC wanting control over the voice quality level and the RG's resources? The RGC may require G729 voice quality not G729A. The RGC may require G729A resource consumption not G729. -troy Paul Long wrote: > Troy, > > G.729 and G.729a put the same bits on the wire, so the receiver cannot > distinguish between the two; therefore, they can be used > interchangeably. G.729a just defines a reduced-complexity > _implementation_ of G.729. Signaling protocols should never have > introduced Annex A as an audio codec distinct from the base standard. > It causes needless confusion such as what you're experiencing. > > Paul > > >>If a gateway is asked to use G729A, which it doesn't have, >>but it has a G729 implementation, should it use it? >> >>And vice versa? _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Mar 4 12:58: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 MAA03847 for ; Tue, 4 Mar 2003 12:58: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 h24I8sp28229; Tue, 4 Mar 2003 13:08: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 h24I7kp28199 for ; Tue, 4 Mar 2003 13:07:46 -0500 Received: from host4.imagelinkusa.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03782 for ; Tue, 4 Mar 2003 12:56:42 -0500 (EST) Received: from packetiz by host4.imagelinkusa.net with local (Exim 3.36 #1) id 18qGge-0006jp-00 for megaco@ietf.org; Tue, 04 Mar 2003 12:58:44 -0500 From: "Paul Long" To: MEGACO list Subject: Re: [Megaco] OT: "equivalent" codecs X-Mailer: NeoMail 1.25 X-IPAddress: 216.54.151.127 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-Id: Date: Tue, 04 Mar 2003 12:58:44 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host4.imagelinkusa.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [746 747] / [746 747] X-AntiAbuse: Sender Address Domain - host4.imagelinkusa.net Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Troy, I have no personal experience comparing G.729 and G.729a but have always heard that the quality difference is neglible. This description in a Nortel white paper backs that up (http://www.nortelnetworks.com/products/01/succession/es/collateral/tb_g 729.pdf): "Both G.729 and G.729A provide the same speech quality during normal operation, the data rate and frame sizes are the same, and they are fully interoperable. There is confusion between the two standards because they are identical except for complexity. The only detectable performance difference occurs during multiple tandem encoding (encoding and decoding the signal repeatedly). The speech quality of G.729A suffers slightly compared with G.729, however, tandem encoding causes speech quality degradation for all Code Excited Linear Prediction(CELP) codecs and is not enough of a concern to deter anyone from using G.729A." Conversely, this white paper notes an MOS score difference of 3.9 and 3.7 (http://www.adaptivedigital.com/prod/wh_pap/jan_07.htm): "G.729 Annex A is a reduced complexity version of G.729. It requires about half the CPU power to operate G.729, with the drawback that it has slightly reduced speech quality. G.729 is rated at 3.9 on the MOS (Mean Opinion Score) scale, which is a subjective measure of voice quality. G.729 Annex A (or G.729A) achieves an MOS score of 3.7. This is usually considered an acceptable trade-off in order to achieve half the CPU requirements. The G.729 and G.729A bit streams are compatible and interoperable, but not identical." Practically speaking, unless one has really extraordinary needs and plenty of available MIPS, one should always implement G.729a. I'm guessing that the MOS difference between implementations is greater than the MOS difference between G.729 and G.729a. Paul > Just playing devil's advocate... > > There is a voice quality tradeoff for the complexity, yes? > > What about the notion of the RGC wanting control over > the voice quality level and the RG's resources? > The RGC may require G729 voice quality not G729A. > The RGC may require G729A resource consumption not G729. > > -troy > > Paul Long wrote: > > Troy, > > > > G.729 and G.729a put the same bits on the wire, so the receiver cannot > > distinguish between the two; therefore, they can be used > > interchangeably. G.729a just defines a reduced-complexity > > _implementation_ of G.729. Signaling protocols should never have > > introduced Annex A as an audio codec distinct from the base standard. > > It causes needless confusion such as what you're experiencing. > > > > Paul > > > > > >>If a gateway is asked to use G729A, which it doesn't have, > >>but it has a G729 implementation, should it use it? > >> > >>And vice versa? _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Mar 4 13:00: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 NAA03896 for ; Tue, 4 Mar 2003 13:00:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24IAf628314 for megaco-archive@odin.ietf.org; Tue, 4 Mar 2003 13:10: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 h24IAfp28311 for ; Tue, 4 Mar 2003 13:10: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 MAA03867 for ; Tue, 4 Mar 2003 12:59: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 h24I8sp28229; Tue, 4 Mar 2003 13:08: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 h24I7kp28199 for ; Tue, 4 Mar 2003 13:07:46 -0500 Received: from host4.imagelinkusa.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03782 for ; Tue, 4 Mar 2003 12:56:42 -0500 (EST) Received: from packetiz by host4.imagelinkusa.net with local (Exim 3.36 #1) id 18qGge-0006jp-00 for megaco@ietf.org; Tue, 04 Mar 2003 12:58:44 -0500 From: "Paul Long" To: MEGACO list Subject: Re: [Megaco] OT: "equivalent" codecs X-Mailer: NeoMail 1.25 X-IPAddress: 216.54.151.127 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-Id: Date: Tue, 04 Mar 2003 12:58:44 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host4.imagelinkusa.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [746 747] / [746 747] X-AntiAbuse: Sender Address Domain - host4.imagelinkusa.net Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Troy, I have no personal experience comparing G.729 and G.729a but have always heard that the quality difference is neglible. This description in a Nortel white paper backs that up (http://www.nortelnetworks.com/products/01/succession/es/collateral/tb_g 729.pdf): "Both G.729 and G.729A provide the same speech quality during normal operation, the data rate and frame sizes are the same, and they are fully interoperable. There is confusion between the two standards because they are identical except for complexity. The only detectable performance difference occurs during multiple tandem encoding (encoding and decoding the signal repeatedly). The speech quality of G.729A suffers slightly compared with G.729, however, tandem encoding causes speech quality degradation for all Code Excited Linear Prediction(CELP) codecs and is not enough of a concern to deter anyone from using G.729A." Conversely, this white paper notes an MOS score difference of 3.9 and 3.7 (http://www.adaptivedigital.com/prod/wh_pap/jan_07.htm): "G.729 Annex A is a reduced complexity version of G.729. It requires about half the CPU power to operate G.729, with the drawback that it has slightly reduced speech quality. G.729 is rated at 3.9 on the MOS (Mean Opinion Score) scale, which is a subjective measure of voice quality. G.729 Annex A (or G.729A) achieves an MOS score of 3.7. This is usually considered an acceptable trade-off in order to achieve half the CPU requirements. The G.729 and G.729A bit streams are compatible and interoperable, but not identical." Practically speaking, unless one has really extraordinary needs and plenty of available MIPS, one should always implement G.729a. I'm guessing that the MOS difference between implementations is greater than the MOS difference between G.729 and G.729a. Paul > Just playing devil's advocate... > > There is a voice quality tradeoff for the complexity, yes? > > What about the notion of the RGC wanting control over > the voice quality level and the RG's resources? > The RGC may require G729 voice quality not G729A. > The RGC may require G729A resource consumption not G729. > > -troy > > Paul Long wrote: > > Troy, > > > > G.729 and G.729a put the same bits on the wire, so the receiver cannot > > distinguish between the two; therefore, they can be used > > interchangeably. G.729a just defines a reduced-complexity > > _implementation_ of G.729. Signaling protocols should never have > > introduced Annex A as an audio codec distinct from the base standard. > > It causes needless confusion such as what you're experiencing. > > > > Paul > > > > > >>If a gateway is asked to use G729A, which it doesn't have, > >>but it has a G729 implementation, should it use it? > >> > >>And vice versa? _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Mar 5 02:24: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 CAA14111 for ; Wed, 5 Mar 2003 02:24: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 h257WA531996; Wed, 5 Mar 2003 02:32: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 h257RY531788 for ; Wed, 5 Mar 2003 02:27:34 -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 CAA06827 for ; Wed, 5 Mar 2003 02:16:09 -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 h257GUs07891 for ; Wed, 5 Mar 2003 12:46:30 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5] (may be forged)) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h257GP207878 for ; Wed, 5 Mar 2003 12:46:30 +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 h257J4u25131 for ; Wed, 5 Mar 2003 12:49:04 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CE0.00275C46 ; Wed, 5 Mar 2003 12:39:55 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CE0.00275C21.00@sandesh.hss.hns.com> Date: Wed, 5 Mar 2003 12:50:10 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Clarification Required in Section 7.1.18 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, In section 7.1.18, It is mentioned that "(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. " Now which of the following combinations are valid and which can be ignored (Assuming a context have terminations T11 and T12) 1. (*,*,Oneway) 2. (T1*, *, Oneway) 3. (T12*, *, Oneway) 4. (T11, *, Oneway) : In this * will resolve to both T11 and T12 can The tuple (T11, T11, Oneway) be ignored or is it to be treated as invalid 5. (T11, T11, Oneway) Also here in (2) and (3) Partial ALL WC have been used in tuples. Is that allowed ? 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 Wed Mar 5 02:26: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 CAA16476 for ; Wed, 5 Mar 2003 02:26:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h257b6f32367 for megaco-archive@odin.ietf.org; Wed, 5 Mar 2003 02:37: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 h257b6532364 for ; Wed, 5 Mar 2003 02:37:06 -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 CAA15799 for ; Wed, 5 Mar 2003 02:25: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 h257WA531996; Wed, 5 Mar 2003 02:32: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 h257RY531788 for ; Wed, 5 Mar 2003 02:27:34 -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 CAA06827 for ; Wed, 5 Mar 2003 02:16:09 -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 h257GUs07891 for ; Wed, 5 Mar 2003 12:46:30 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5] (may be forged)) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h257GP207878 for ; Wed, 5 Mar 2003 12:46:30 +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 h257J4u25131 for ; Wed, 5 Mar 2003 12:49:04 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CE0.00275C46 ; Wed, 5 Mar 2003 12:39:55 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CE0.00275C21.00@sandesh.hss.hns.com> Date: Wed, 5 Mar 2003 12:50:10 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Clarification Required in Section 7.1.18 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, In section 7.1.18, It is mentioned that "(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. " Now which of the following combinations are valid and which can be ignored (Assuming a context have terminations T11 and T12) 1. (*,*,Oneway) 2. (T1*, *, Oneway) 3. (T12*, *, Oneway) 4. (T11, *, Oneway) : In this * will resolve to both T11 and T12 can The tuple (T11, T11, Oneway) be ignored or is it to be treated as invalid 5. (T11, T11, Oneway) Also here in (2) and (3) Partial ALL WC have been used in tuples. Is that allowed ? 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 Wed Mar 5 11:29: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 LAA10900 for ; Wed, 5 Mar 2003 11:29:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Gdp511378; Wed, 5 Mar 2003 11:39: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 h25GcW511288 for ; Wed, 5 Mar 2003 11:38:32 -0500 Received: from auds952.usa.alcatel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10791 for ; Wed, 5 Mar 2003 11:26:59 -0500 (EST) Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.6/8.12.6) with ESMTP id h25GT1qe029932 for ; Wed, 5 Mar 2003 10:29:02 -0600 (CST) Received: from axws59 ([10.255.5.109]) by ssd.usa.alcatel.com (8.11.1/8.11.1) with SMTP id h25GSlF26289 for ; Wed, 5 Mar 2003 10:28:48 -0600 (CST) Message-ID: <017e01c2e336$4d850ea0$6d05ff0a@axws59> From: "Selvam.V" To: "Megaco" References: <3E314AC1.79AC798C@cisco.com> Date: Wed, 5 Mar 2003 22:13:06 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Subject: [Megaco] Clearing Remote SDP Data Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi All, I want to release/clear the Remote SDP for a Termination, and ADD a new Remote SDP for that Termination. CASE 1: Subtract the Ephmeral Termination and Add the Ephemeral Termiantion with new Remote SDP Data. CASE 2: Send a Modify with Empty Remote Descriptor to release the the resources and then send another modify with new Remote Descriptor. Can any one, Tell me which of the above cases will work. if CASE 2 will work, wether the mode of the Termination should be changed to receive only. Thanks in Advance, selva. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Mar 5 11:30: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 LAA11019 for ; Wed, 5 Mar 2003 11:30:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25GfLX12001 for megaco-archive@odin.ietf.org; Wed, 5 Mar 2003 11:41: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 h25GfL511998 for ; Wed, 5 Mar 2003 11:41: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 LAA10964 for ; Wed, 5 Mar 2003 11:29: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 h25Gdp511378; Wed, 5 Mar 2003 11:39: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 h25GcW511288 for ; Wed, 5 Mar 2003 11:38:32 -0500 Received: from auds952.usa.alcatel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10791 for ; Wed, 5 Mar 2003 11:26:59 -0500 (EST) Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.6/8.12.6) with ESMTP id h25GT1qe029932 for ; Wed, 5 Mar 2003 10:29:02 -0600 (CST) Received: from axws59 ([10.255.5.109]) by ssd.usa.alcatel.com (8.11.1/8.11.1) with SMTP id h25GSlF26289 for ; Wed, 5 Mar 2003 10:28:48 -0600 (CST) Message-ID: <017e01c2e336$4d850ea0$6d05ff0a@axws59> From: "Selvam.V" To: "Megaco" References: <3E314AC1.79AC798C@cisco.com> Date: Wed, 5 Mar 2003 22:13:06 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Subject: [Megaco] Clearing Remote SDP Data Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi All, I want to release/clear the Remote SDP for a Termination, and ADD a new Remote SDP for that Termination. CASE 1: Subtract the Ephmeral Termination and Add the Ephemeral Termiantion with new Remote SDP Data. CASE 2: Send a Modify with Empty Remote Descriptor to release the the resources and then send another modify with new Remote Descriptor. Can any one, Tell me which of the above cases will work. if CASE 2 will work, wether the mode of the Termination should be changed to receive only. Thanks in Advance, selva. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Mar 5 14:10: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 OAA22380 for ; Wed, 5 Mar 2003 14:10: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 h25JIYO09783; Wed, 5 Mar 2003 14:18: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 h25IcxO06980 for ; Wed, 5 Mar 2003 13:38:59 -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 NAA20163 for ; Wed, 5 Mar 2003 13:27:48 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h25ITjn13661; Wed, 5 Mar 2003 13:29:45 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Mar 2003 13:29:46 -0500 Message-ID: From: "Kevin Boyle" To: shbansal@hss.hns.com, megaco@ietf.org Subject: RE: [Megaco] Clarification Required in Section 7.1.18 Date: Wed, 5 Mar 2003 13:29:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E345.31CD2CF6" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2E345.31CD2CF6 Content-Type: text/plain >From the current version of the IG: 6.13 Wildcarding in the Topology Descriptor Description: During discussions on the Megaco Mailing list an ambiguity was recognized in the text describing how wildcarding work in the case of a one way topology descriptor. It was thought that a "*" wildcard was not allowed to be used in the topology triple (T1,T2,oneway). This is incorrect as a "*" wildcard may be used in one termination ID but not both. Reference: Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 Date: Tue, 14 Jan 2003 13:31:54 -0500 From: "Kevin Boyle" [Begin Correction] 7.1.18 Topology Descriptor ... * (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 either T1 or T2 but not both is allowed. ... [End Correction] So, using * in both places is not allowed. However, restricting one of the two terms to a specific termID means you can use any wildcard in the other. Using partially specified termIDs are allowed, as long as you can't get one term to match both termIDs. Does that help? Kevin -----Original Message----- From: shbansal@hss.hns.com [mailto:shbansal@hss.hns.com] Sent: Wednesday, March 05, 2003 2:20 AM To: megaco@ietf.org Subject: [Megaco] Clarification Required in Section 7.1.18 Hi list, In section 7.1.18, It is mentioned that "(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. " Now which of the following combinations are valid and which can be ignored (Assuming a context have terminations T11 and T12) 1. (*,*,Oneway) 2. (T1*, *, Oneway) 3. (T12*, *, Oneway) 4. (T11, *, Oneway) : In this * will resolve to both T11 and T12 can The tuple (T11, T11, Oneway) be ignored or is it to be treated as invalid 5. (T11, T11, Oneway) Also here in (2) and (3) Partial ALL WC have been used in tuples. Is that allowed ? 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 ------_=_NextPart_001_01C2E345.31CD2CF6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Megaco] Clarification Required in Section 7.1.18

From the current version of the IG:

6.13    Wildcarding in the Topology = Descriptor

Description:    During discussions on = the Megaco Mailing list an ambiguity was recognized in the text = describing how wildcarding work in the case of a one way topology = descriptor. It was thought that a "*" wildcard was not = allowed to be used in the topology triple (T1,T2,oneway). This is = incorrect as a "*" wildcard may be used in one termination ID = but not both.

Reference:      Subject: RE: = [Megaco] Question on Section 7.1.18 Megaco V2
Date: Tue, 14 Jan 2003 13:31:54 -0500
From: "Kevin Boyle" = <kboyle@nortelnetworks.com>

[Begin Correction]
7.1.18  Topology Descriptor
...
*       (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 either T1 = or T2 but not both is allowed.

...
[End Correction]

So, using * in both places is not allowed.  = However, restricting one of the two terms to a specific termID means = you can use any wildcard in the other.  Using partially specified = termIDs are allowed, as long as you can't get one term to match both = termIDs.

Does that help?

Kevin

-----Original Message-----
From: shbansal@hss.hns.com [mailto:shbansal@hss.hns.com] =
Sent: Wednesday, March 05, 2003 2:20 AM
To: megaco@ietf.org
Subject: [Megaco] Clarification Required in Section = 7.1.18





Hi list,

In section 7.1.18, It is mentioned that

"(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. "

Now which of the following combinations are valid and = which can be ignored (Assuming a context have terminations T11 and = T12)

1.   (*,*,Oneway)
2.   (T1*, *, Oneway)
3.   (T12*, *, Oneway)
4.   (T11, *, Oneway)  :
     In this * will resolve to = both T11 and T12 can The tuple (T11, T11, Oneway) be ignored or is it = to be treated as invalid

5.   (T11, T11, Oneway)


Also here in (2) and (3)  Partial ALL WC have = been used in tuples. Is that allowed ?

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

------_=_NextPart_001_01C2E345.31CD2CF6-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Mar 5 14: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 OAA22454 for ; Wed, 5 Mar 2003 14:12:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25JN0610042 for megaco-archive@odin.ietf.org; Wed, 5 Mar 2003 14:23: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 h25JMxO10039 for ; Wed, 5 Mar 2003 14:22: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 OAA22429 for ; Wed, 5 Mar 2003 14:11: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 h25JIYO09783; Wed, 5 Mar 2003 14:18: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 h25IcxO06980 for ; Wed, 5 Mar 2003 13:38:59 -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 NAA20163 for ; Wed, 5 Mar 2003 13:27:48 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h25ITjn13661; Wed, 5 Mar 2003 13:29:45 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Mar 2003 13:29:46 -0500 Message-ID: From: "Kevin Boyle" To: shbansal@hss.hns.com, megaco@ietf.org Subject: RE: [Megaco] Clarification Required in Section 7.1.18 Date: Wed, 5 Mar 2003 13:29:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E345.31CD2CF6" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2E345.31CD2CF6 Content-Type: text/plain >From the current version of the IG: 6.13 Wildcarding in the Topology Descriptor Description: During discussions on the Megaco Mailing list an ambiguity was recognized in the text describing how wildcarding work in the case of a one way topology descriptor. It was thought that a "*" wildcard was not allowed to be used in the topology triple (T1,T2,oneway). This is incorrect as a "*" wildcard may be used in one termination ID but not both. Reference: Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 Date: Tue, 14 Jan 2003 13:31:54 -0500 From: "Kevin Boyle" [Begin Correction] 7.1.18 Topology Descriptor ... * (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 either T1 or T2 but not both is allowed. ... [End Correction] So, using * in both places is not allowed. However, restricting one of the two terms to a specific termID means you can use any wildcard in the other. Using partially specified termIDs are allowed, as long as you can't get one term to match both termIDs. Does that help? Kevin -----Original Message----- From: shbansal@hss.hns.com [mailto:shbansal@hss.hns.com] Sent: Wednesday, March 05, 2003 2:20 AM To: megaco@ietf.org Subject: [Megaco] Clarification Required in Section 7.1.18 Hi list, In section 7.1.18, It is mentioned that "(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. " Now which of the following combinations are valid and which can be ignored (Assuming a context have terminations T11 and T12) 1. (*,*,Oneway) 2. (T1*, *, Oneway) 3. (T12*, *, Oneway) 4. (T11, *, Oneway) : In this * will resolve to both T11 and T12 can The tuple (T11, T11, Oneway) be ignored or is it to be treated as invalid 5. (T11, T11, Oneway) Also here in (2) and (3) Partial ALL WC have been used in tuples. Is that allowed ? 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 ------_=_NextPart_001_01C2E345.31CD2CF6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Megaco] Clarification Required in Section 7.1.18

From the current version of the IG:

6.13    Wildcarding in the Topology = Descriptor

Description:    During discussions on = the Megaco Mailing list an ambiguity was recognized in the text = describing how wildcarding work in the case of a one way topology = descriptor. It was thought that a "*" wildcard was not = allowed to be used in the topology triple (T1,T2,oneway). This is = incorrect as a "*" wildcard may be used in one termination ID = but not both.

Reference:      Subject: RE: = [Megaco] Question on Section 7.1.18 Megaco V2
Date: Tue, 14 Jan 2003 13:31:54 -0500
From: "Kevin Boyle" = <kboyle@nortelnetworks.com>

[Begin Correction]
7.1.18  Topology Descriptor
...
*       (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 either T1 = or T2 but not both is allowed.

...
[End Correction]

So, using * in both places is not allowed.  = However, restricting one of the two terms to a specific termID means = you can use any wildcard in the other.  Using partially specified = termIDs are allowed, as long as you can't get one term to match both = termIDs.

Does that help?

Kevin

-----Original Message-----
From: shbansal@hss.hns.com [mailto:shbansal@hss.hns.com] =
Sent: Wednesday, March 05, 2003 2:20 AM
To: megaco@ietf.org
Subject: [Megaco] Clarification Required in Section = 7.1.18





Hi list,

In section 7.1.18, It is mentioned that

"(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. "

Now which of the following combinations are valid and = which can be ignored (Assuming a context have terminations T11 and = T12)

1.   (*,*,Oneway)
2.   (T1*, *, Oneway)
3.   (T12*, *, Oneway)
4.   (T11, *, Oneway)  :
     In this * will resolve to = both T11 and T12 can The tuple (T11, T11, Oneway) be ignored or is it = to be treated as invalid

5.   (T11, T11, Oneway)


Also here in (2) and (3)  Partial ALL WC have = been used in tuples. Is that allowed ?

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

------_=_NextPart_001_01C2E345.31CD2CF6-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Mar 5 16:59: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 QAA01897 for ; Wed, 5 Mar 2003 16:59: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 h25M7JO26770; Wed, 5 Mar 2003 17:07: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 h25M35O26143 for ; Wed, 5 Mar 2003 17:03:05 -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 QAA01510 for ; Wed, 5 Mar 2003 16:51:52 -0500 (EST) Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Mar 2003 16:49:27 -0500 Message-ID: From: Carl Rutter To: megaco@ietf.org Date: Wed, 5 Mar 2003 16:49:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Megaco] Request ID = 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: , Is the use of Request ID = 0 now accepted? Would it be fair to say that for any and all Notify requests from the MG that were not explicitly Requested by the MGC(hence no Request ID) RequestId=0 should be used? Packages such as the Congestion Handling Package M.2.5 indicate the events could be preprovisoned in the MG, if that is the case RequestID = 0 should be used? 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 Mar 5 17:00: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 RAA02017 for ; Wed, 5 Mar 2003 17:00:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25MBbV27414 for megaco-archive@odin.ietf.org; Wed, 5 Mar 2003 17:11: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 h25MBaO27411 for ; Wed, 5 Mar 2003 17:11: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 RAA02002 for ; Wed, 5 Mar 2003 17:00: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 h25M7JO26770; Wed, 5 Mar 2003 17:07: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 h25M35O26143 for ; Wed, 5 Mar 2003 17:03:05 -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 QAA01510 for ; Wed, 5 Mar 2003 16:51:52 -0500 (EST) Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Mar 2003 16:49:27 -0500 Message-ID: From: Carl Rutter To: megaco@ietf.org Date: Wed, 5 Mar 2003 16:49:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Megaco] Request ID = 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: , Is the use of Request ID = 0 now accepted? Would it be fair to say that for any and all Notify requests from the MG that were not explicitly Requested by the MGC(hence no Request ID) RequestId=0 should be used? Packages such as the Congestion Handling Package M.2.5 indicate the events could be preprovisoned in the MG, if that is the case RequestID = 0 should be used? 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 Wed Mar 5 17:57: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 RAA04246 for ; Wed, 5 Mar 2003 17: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 h25N51O31566; Wed, 5 Mar 2003 18:05: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 h25N15O31294 for ; Wed, 5 Mar 2003 18:01:05 -0500 Received: from bos-exch01.winphoria.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03921 for ; Wed, 5 Mar 2003 17:49:49 -0500 (EST) Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 5 Mar 2003 17:51:50 -0500 Message-Id: <5.2.0.9.0.20030305174040.02a8eea8@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 05 Mar 2003 17:51:11 -0500 To: "Kevin Boyle" , megaco@ietf.org From: Aleksandr Ryabin Subject: RE: [Megaco] Clarification Required in Section 7.1.18 Cc: shbansal@hss.hns.com In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_-1875003032==.ALT" X-OriginalArrivalTime: 05 Mar 2003 22:51:50.0288 (UTC) FILETIME=[CEF2B900:01C2E369] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --=====================_-1875003032==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, I'd say that a combination such as (T1, T1, oneway) is meaningless and should always be silently ignored. If we take that into consideration then we can cross out "as long as you can't get one term to match both termIDs." in your last sentence below and thus we could allow constructions like (T1, *, oneway) which can be very useful when T1 can not be separated out from the rest of the wildcard. Just an idea. Thanks Aleks At 01:29 PM 3/5/2003, Kevin Boyle wrote: > From the current version of the IG: > >6.13 Wildcarding in the Topology Descriptor > >Description: During discussions on the Megaco Mailing list an ambiguity >was recognized in the text describing how wildcarding work in the case of >a one way topology descriptor. It was thought that a "*" wildcard was not >allowed to be used in the topology triple (T1,T2,oneway). This is >incorrect as a "*" wildcard may be used in one termination ID but not both. > >Reference: Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 >Date: Tue, 14 Jan 2003 13:31:54 -0500 >From: "Kevin Boyle" > >[Begin Correction] >7.1.18 Topology Descriptor >... >* (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 either >T1 or T2 but not both is allowed. > >... >[End Correction] > >So, using * in both places is not allowed. However, restricting one of >the two terms to a specific termID means you can use any wildcard in the >other. Using partially specified termIDs are allowed, as long as you >can't get one term to match both termIDs. > >Does that help? > >Kevin > >-----Original Message----- >From: shbansal@hss.hns.com >[mailto:shbansal@hss.hns.com] >Sent: Wednesday, March 05, 2003 2:20 AM >To: megaco@ietf.org >Subject: [Megaco] Clarification Required in Section 7.1.18 > > > > >Hi list, > >In section 7.1.18, It is mentioned that > >"(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. " > >Now which of the following combinations are valid and which can be ignored >(Assuming a context have terminations T11 and T12) > >1. (*,*,Oneway) >2. (T1*, *, Oneway) >3. (T12*, *, Oneway) >4. (T11, *, Oneway) : > In this * will resolve to both T11 and T12 can The tuple (T11, T11, > Oneway) be ignored or is it to be treated as invalid > >5. (T11, T11, Oneway) > >Also here in (2) and (3) Partial ALL WC have been used in tuples. Is that >allowed ? > >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 > --=====================_-1875003032==.ALT Content-Type: text/html; charset="us-ascii" Hi,

I'd say that a combination such as (T1, T1, oneway) is meaningless
and should always be silently ignored.
If we take that into consideration then we can cross out "as long as you can't
get one term to match both termIDs." in your last sentence below and thus
we could allow constructions like (T1, *, oneway) which can be very useful
when T1 can not be separated out from the rest of the wildcard.

Just an idea.
Thanks
        Aleks

At 01:29 PM 3/5/2003, Kevin Boyle wrote:

From the current version of the IG:

6.13    Wildcarding in the Topology Descriptor

Description:    During discussions on the Megaco Mailing list an ambiguity was recognized in the text describing how wildcarding work in the case of a one way topology descriptor. It was thought that a "*" wildcard was not allowed to be used in the topology triple (T1,T2,oneway). This is incorrect as a "*" wildcard may be used in one termination ID but not both.

Reference:      Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2
Date: Tue, 14 Jan 2003 13:31:54 -0500
From: "Kevin Boyle" <kboyle@nortelnetworks.com>

[Begin Correction]
7.1.18  Topology Descriptor
...
*       (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 either T1 or T2 but not both is allowed.

...
[End Correction]

So, using * in both places is not allowed.  However, restricting one of the two terms to a specific termID means you can use any wildcard in the other.  Using partially specified termIDs are allowed, as long as you can't get one term to match both termIDs.

Does that help?

Kevin

-----Original Message-----
From: shbansal@hss.hns.com [mailto:shbansal@hss.hns.com]
Sent: Wednesday, March 05, 2003 2:20 AM
To: megaco@ietf.org
Subject: [Megaco] Clarification Required in Section 7.1.18




Hi list,

In section 7.1.18, It is mentioned that

"(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. "

Now which of the following combinations are valid and which can be ignored (Assuming a context have terminations T11 and T12)

1.   (*,*,Oneway)
2.   (T1*, *, Oneway)
3.   (T12*, *, Oneway)
4.   (T11, *, Oneway)  :
     In this * will resolve to both T11 and T12 can The tuple (T11, T11, Oneway) be ignored or is it to be treated as invalid

5.   (T11, T11, Oneway)

Also here in (2) and (3)  Partial ALL WC have been used in tuples. Is that allowed ?

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
--=====================_-1875003032==.ALT-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Mar 5 17:58: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 RAA04306 for ; Wed, 5 Mar 2003 17:58:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25N9SF32681 for megaco-archive@odin.ietf.org; Wed, 5 Mar 2003 18:09: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 h25N9SO32678 for ; Wed, 5 Mar 2003 18:09: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 RAA04300 for ; Wed, 5 Mar 2003 17:58: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 h25N51O31566; Wed, 5 Mar 2003 18:05: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 h25N15O31294 for ; Wed, 5 Mar 2003 18:01:05 -0500 Received: from bos-exch01.winphoria.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03921 for ; Wed, 5 Mar 2003 17:49:49 -0500 (EST) Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 5 Mar 2003 17:51:50 -0500 Message-Id: <5.2.0.9.0.20030305174040.02a8eea8@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 05 Mar 2003 17:51:11 -0500 To: "Kevin Boyle" , megaco@ietf.org From: Aleksandr Ryabin Subject: RE: [Megaco] Clarification Required in Section 7.1.18 Cc: shbansal@hss.hns.com In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_-1875003032==.ALT" X-OriginalArrivalTime: 05 Mar 2003 22:51:50.0288 (UTC) FILETIME=[CEF2B900:01C2E369] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --=====================_-1875003032==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, I'd say that a combination such as (T1, T1, oneway) is meaningless and should always be silently ignored. If we take that into consideration then we can cross out "as long as you can't get one term to match both termIDs." in your last sentence below and thus we could allow constructions like (T1, *, oneway) which can be very useful when T1 can not be separated out from the rest of the wildcard. Just an idea. Thanks Aleks At 01:29 PM 3/5/2003, Kevin Boyle wrote: > From the current version of the IG: > >6.13 Wildcarding in the Topology Descriptor > >Description: During discussions on the Megaco Mailing list an ambiguity >was recognized in the text describing how wildcarding work in the case of >a one way topology descriptor. It was thought that a "*" wildcard was not >allowed to be used in the topology triple (T1,T2,oneway). This is >incorrect as a "*" wildcard may be used in one termination ID but not both. > >Reference: Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2 >Date: Tue, 14 Jan 2003 13:31:54 -0500 >From: "Kevin Boyle" > >[Begin Correction] >7.1.18 Topology Descriptor >... >* (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 either >T1 or T2 but not both is allowed. > >... >[End Correction] > >So, using * in both places is not allowed. However, restricting one of >the two terms to a specific termID means you can use any wildcard in the >other. Using partially specified termIDs are allowed, as long as you >can't get one term to match both termIDs. > >Does that help? > >Kevin > >-----Original Message----- >From: shbansal@hss.hns.com >[mailto:shbansal@hss.hns.com] >Sent: Wednesday, March 05, 2003 2:20 AM >To: megaco@ietf.org >Subject: [Megaco] Clarification Required in Section 7.1.18 > > > > >Hi list, > >In section 7.1.18, It is mentioned that > >"(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. " > >Now which of the following combinations are valid and which can be ignored >(Assuming a context have terminations T11 and T12) > >1. (*,*,Oneway) >2. (T1*, *, Oneway) >3. (T12*, *, Oneway) >4. (T11, *, Oneway) : > In this * will resolve to both T11 and T12 can The tuple (T11, T11, > Oneway) be ignored or is it to be treated as invalid > >5. (T11, T11, Oneway) > >Also here in (2) and (3) Partial ALL WC have been used in tuples. Is that >allowed ? > >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 > --=====================_-1875003032==.ALT Content-Type: text/html; charset="us-ascii" Hi,

I'd say that a combination such as (T1, T1, oneway) is meaningless
and should always be silently ignored.
If we take that into consideration then we can cross out "as long as you can't
get one term to match both termIDs." in your last sentence below and thus
we could allow constructions like (T1, *, oneway) which can be very useful
when T1 can not be separated out from the rest of the wildcard.

Just an idea.
Thanks
        Aleks

At 01:29 PM 3/5/2003, Kevin Boyle wrote:

From the current version of the IG:

6.13    Wildcarding in the Topology Descriptor

Description:    During discussions on the Megaco Mailing list an ambiguity was recognized in the text describing how wildcarding work in the case of a one way topology descriptor. It was thought that a "*" wildcard was not allowed to be used in the topology triple (T1,T2,oneway). This is incorrect as a "*" wildcard may be used in one termination ID but not both.

Reference:      Subject: RE: [Megaco] Question on Section 7.1.18 Megaco V2
Date: Tue, 14 Jan 2003 13:31:54 -0500
From: "Kevin Boyle" <kboyle@nortelnetworks.com>

[Begin Correction]
7.1.18  Topology Descriptor
...
*       (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 either T1 or T2 but not both is allowed.

...
[End Correction]

So, using * in both places is not allowed.  However, restricting one of the two terms to a specific termID means you can use any wildcard in the other.  Using partially specified termIDs are allowed, as long as you can't get one term to match both termIDs.

Does that help?

Kevin

-----Original Message-----
From: shbansal@hss.hns.com [mailto:shbansal@hss.hns.com]
Sent: Wednesday, March 05, 2003 2:20 AM
To: megaco@ietf.org
Subject: [Megaco] Clarification Required in Section 7.1.18




Hi list,

In section 7.1.18, It is mentioned that

"(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. "

Now which of the following combinations are valid and which can be ignored (Assuming a context have terminations T11 and T12)

1.   (*,*,Oneway)
2.   (T1*, *, Oneway)
3.   (T12*, *, Oneway)
4.   (T11, *, Oneway)  :
     In this * will resolve to both T11 and T12 can The tuple (T11, T11, Oneway) be ignored or is it to be treated as invalid

5.   (T11, T11, Oneway)

Also here in (2) and (3)  Partial ALL WC have been used in tuples. Is that allowed ?

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
--=====================_-1875003032==.ALT-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Mar 6 00:51: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 AAA13982 for ; Thu, 6 Mar 2003 00:51: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 h2661PO25059; Thu, 6 Mar 2003 01:01: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 h265vgO24925 for ; Thu, 6 Mar 2003 00:57:42 -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 AAA13939 for ; Thu, 6 Mar 2003 00:46:17 -0500 (EST) From: knayar@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h265kds05112 for ; Thu, 6 Mar 2003 11:16:39 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5] (may be forged)) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h265kc205102; Thu, 6 Mar 2003 11:16:38 +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 h265nHK21096; Thu, 6 Mar 2003 11:19:17 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CE1.001F23DC ; Thu, 6 Mar 2003 11:10:07 +0530 X-Lotus-FromDomain: HSS To: "Selvam.V" cc: "Megaco" Message-ID: <65256CE1.001F2193.00@sandesh.hss.hns.com> Date: Thu, 6 Mar 2003 11:15:13 +0530 Subject: Re: [Megaco] Clearing Remote SDP Data 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 Selva Another possible case can be: CASE 3: Send a Modify with New Remote Descriptor to release the old resources and also allocate new resources, since the new Remote Descriptor completely replaces the old one. The mode of the stream should understandably be changed to receive-only in CASE 2 as indicated by you. BTW, the question you asked is with reference to IP terminations or ATM terminations? For, IP terminations this may simply map to changing the destination address/ payload type for media. But, in case of ATM it may need further investigation. thanks, -kapil nayar Hughes Software Systems Ltd. http://www.hssworld.com "Selvam.V" on 03/05/2003 10:13:06 PM To: "Megaco" cc: (bcc: Kapil Nayar/HSS) Subject: [Megaco] Clearing Remote SDP Data Hi All, I want to release/clear the Remote SDP for a Termination, and ADD a new Remote SDP for that Termination. CASE 1: Subtract the Ephmeral Termination and Add the Ephemeral Termiantion with new Remote SDP Data. CASE 2: Send a Modify with Empty Remote Descriptor to release the the resources and then send another modify with new Remote Descriptor. Can any one, Tell me which of the above cases will work. if CASE 2 will work, wether the mode of the Termination should be changed to receive only. Thanks in Advance, selva. _______________________________________________ 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 Mar 6 00:52: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 AAA14011 for ; Thu, 6 Mar 2003 00:52:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2663Vk25125 for megaco-archive@odin.ietf.org; Thu, 6 Mar 2003 01:03: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 h2663UO25122 for ; Thu, 6 Mar 2003 01:03: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 AAA14004 for ; Thu, 6 Mar 2003 00:52: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 h2661PO25059; Thu, 6 Mar 2003 01:01: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 h265vgO24925 for ; Thu, 6 Mar 2003 00:57:42 -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 AAA13939 for ; Thu, 6 Mar 2003 00:46:17 -0500 (EST) From: knayar@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h265kds05112 for ; Thu, 6 Mar 2003 11:16:39 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5] (may be forged)) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h265kc205102; Thu, 6 Mar 2003 11:16:38 +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 h265nHK21096; Thu, 6 Mar 2003 11:19:17 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CE1.001F23DC ; Thu, 6 Mar 2003 11:10:07 +0530 X-Lotus-FromDomain: HSS To: "Selvam.V" cc: "Megaco" Message-ID: <65256CE1.001F2193.00@sandesh.hss.hns.com> Date: Thu, 6 Mar 2003 11:15:13 +0530 Subject: Re: [Megaco] Clearing Remote SDP Data 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 Selva Another possible case can be: CASE 3: Send a Modify with New Remote Descriptor to release the old resources and also allocate new resources, since the new Remote Descriptor completely replaces the old one. The mode of the stream should understandably be changed to receive-only in CASE 2 as indicated by you. BTW, the question you asked is with reference to IP terminations or ATM terminations? For, IP terminations this may simply map to changing the destination address/ payload type for media. But, in case of ATM it may need further investigation. thanks, -kapil nayar Hughes Software Systems Ltd. http://www.hssworld.com "Selvam.V" on 03/05/2003 10:13:06 PM To: "Megaco" cc: (bcc: Kapil Nayar/HSS) Subject: [Megaco] Clearing Remote SDP Data Hi All, I want to release/clear the Remote SDP for a Termination, and ADD a new Remote SDP for that Termination. CASE 1: Subtract the Ephmeral Termination and Add the Ephemeral Termiantion with new Remote SDP Data. CASE 2: Send a Modify with Empty Remote Descriptor to release the the resources and then send another modify with new Remote Descriptor. Can any one, Tell me which of the above cases will work. if CASE 2 will work, wether the mode of the Termination should be changed to receive only. Thanks in Advance, selva. _______________________________________________ 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 Mar 6 00:53: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 AAA14042 for ; Thu, 6 Mar 2003 00:53: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 h26644O25160; Thu, 6 Mar 2003 01:04: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 h2661aO25068 for ; Thu, 6 Mar 2003 01:01:36 -0500 Received: from mail1.lge.co.kr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13959 for ; Thu, 6 Mar 2003 00:50:07 -0500 (EST) Received: from [150.150.53.206] (sungyoon@lge.com) by mail1.lge.co.kr (Terrace Internet Messaging Server) with ESMTP id 2003030614:47:31:175194.17971.241 for ; Thu, 06 Mar 2003 14:47:31 +0900 (KST) Message-ID: <006a01c2e3a5$8839e600$ce359696@lge.com> From: =?ks_c_5601-1987?B?sei8usCx?= To: Subject: [Megaco] Digit Map expression Date: Thu, 6 Mar 2003 14:59:21 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01C2E3F0.F7FFFC40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_0067_01C2E3F0.F7FFFC40 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgYWxsICENCkkgd29uZGVyIERpZ2l0IE1hcCBleHByZXNzaW9uICENCg0Kd2FudCB0byBjb250 cm9sIHBob25lIG51bWJlciBpcyAzMjAtZGlnaXQgbnVtLSMNCmRpZ2l0IG51bSBjb250YWlucyBh bnkgZGlnaXQgJiBhbnkgbGVuZ3RocyggZXg6IDEyMzQsIDEyMzQ1LDEyMzQ1NjcpDQpIb3cgY2Fu IEkgZXhwcmVzcyB0aGlzIGluIERpZ2l0IE1hcD8NCkkgZ3Vlc3MgLi4uLi4zMjB4LiMgPC0tIGlz IHRoaXMgcmlnaHQ/DQoNCkkgaG9wZSB5b3VyIGFuc3dlciAuLi5UaGFua3MhIQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClN1bmctWW91biBLaW0NCkFzc29jaWF0ZSBSZXNlYXJjaCBFbmdpbmVlcg0K U1dJVENISU5HIFNPRlRXQVJFDQpESUdJVEFMIFNXSVRDSElORyBTWVNURU0gTEFCT1JBVE9SWQ0K TEcgSW5mb3JtYXRpb24gJiBDb21tdW5pY2F0aW9uLkx0ZA0KKDgyLTMxKTQ1MC03Mzc2DQplLW1h aWwgc3VuZ3lvb25AbGdlLmNvbQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0K ------=_NextPart_000_0067_01C2E3F0.F7FFFC40 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI3MTIuMzAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9I RUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+SGkgYWxsICE8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JIHdvbmRlciBEaWdpdCBNYXAgZXhwcmVz c2lvbiAhPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+d2FudCB0byZuYnNwO2NvbnRyb2wgcGhvbmUgbnVtYmVyIGlz Jm5ic3A7MzIwLWRpZ2l0IA0KbnVtLSM8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5k aWdpdCBudW0gY29udGFpbnMgYW55IGRpZ2l0ICZhbXA7IGFueSBsZW5ndGhzKCBleDogMTIzNCwg DQoxMjM0NSwxMjM0NTY3KTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhvdyBjYW4g SSBleHByZXNzIHRoaXMgaW4gRGlnaXQgTWFwPzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPkkgZ3Vlc3MgLi4uLi4zMjB4LiMgJmx0Oy0tIGlzIHRoaXMgcmlnaHQ/PC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTI+SSBob3BlIHlvdXIgYW5zd2VyIC4uLlRoYW5rcyEhPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCANCnNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo8L0ZPTlQ+PEZPTlQgc2l6ZT0yPjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08QlI+U3VuZy1Zb3VuIA0KS2ltPEJSPkFzc29jaWF0ZSBSZXNlYXJjaCBFbmdp bmVlcjxCUj5TV0lUQ0hJTkcgU09GVFdBUkU8QlI+RElHSVRBTCBTV0lUQ0hJTkcgDQpTWVNURU0g TEFCT1JBVE9SWTxCUj5MRyBJbmZvcm1hdGlvbiAmYW1wOyANCkNvbW11bmljYXRpb24uTHRkPEJS Pig4Mi0zMSk0NTAtNzM3NjxCUj5lLW1haWwgPEEgDQpocmVmPSJtYWlsdG86c3VuZ3lvb25AbGdl LmNvbSI+c3VuZ3lvb25AbGdlLmNvbTwvQT48QlI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0067_01C2E3F0.F7FFFC40-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Mar 6 00:55: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 AAA14064 for ; Thu, 6 Mar 2003 00:55:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26665a25239 for megaco-archive@odin.ietf.org; Thu, 6 Mar 2003 01:06: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 h26665O25236 for ; Thu, 6 Mar 2003 01:06:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14057 for ; Thu, 6 Mar 2003 00:54: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 h26644O25160; Thu, 6 Mar 2003 01:04: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 h2661aO25068 for ; Thu, 6 Mar 2003 01:01:36 -0500 Received: from mail1.lge.co.kr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13959 for ; Thu, 6 Mar 2003 00:50:07 -0500 (EST) Received: from [150.150.53.206] (sungyoon@lge.com) by mail1.lge.co.kr (Terrace Internet Messaging Server) with ESMTP id 2003030614:47:31:175194.17971.241 for ; Thu, 06 Mar 2003 14:47:31 +0900 (KST) Message-ID: <006a01c2e3a5$8839e600$ce359696@lge.com> From: =?ks_c_5601-1987?B?sei8usCx?= To: Subject: [Megaco] Digit Map expression Date: Thu, 6 Mar 2003 14:59:21 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01C2E3F0.F7FFFC40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_0067_01C2E3F0.F7FFFC40 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgYWxsICENCkkgd29uZGVyIERpZ2l0IE1hcCBleHByZXNzaW9uICENCg0Kd2FudCB0byBjb250 cm9sIHBob25lIG51bWJlciBpcyAzMjAtZGlnaXQgbnVtLSMNCmRpZ2l0IG51bSBjb250YWlucyBh bnkgZGlnaXQgJiBhbnkgbGVuZ3RocyggZXg6IDEyMzQsIDEyMzQ1LDEyMzQ1NjcpDQpIb3cgY2Fu IEkgZXhwcmVzcyB0aGlzIGluIERpZ2l0IE1hcD8NCkkgZ3Vlc3MgLi4uLi4zMjB4LiMgPC0tIGlz IHRoaXMgcmlnaHQ/DQoNCkkgaG9wZSB5b3VyIGFuc3dlciAuLi5UaGFua3MhIQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClN1bmctWW91biBLaW0NCkFzc29jaWF0ZSBSZXNlYXJjaCBFbmdpbmVlcg0K U1dJVENISU5HIFNPRlRXQVJFDQpESUdJVEFMIFNXSVRDSElORyBTWVNURU0gTEFCT1JBVE9SWQ0K TEcgSW5mb3JtYXRpb24gJiBDb21tdW5pY2F0aW9uLkx0ZA0KKDgyLTMxKTQ1MC03Mzc2DQplLW1h aWwgc3VuZ3lvb25AbGdlLmNvbQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0K ------=_NextPart_000_0067_01C2E3F0.F7FFFC40 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI3MTIuMzAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9I RUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+SGkgYWxsICE8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JIHdvbmRlciBEaWdpdCBNYXAgZXhwcmVz c2lvbiAhPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+d2FudCB0byZuYnNwO2NvbnRyb2wgcGhvbmUgbnVtYmVyIGlz Jm5ic3A7MzIwLWRpZ2l0IA0KbnVtLSM8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5k aWdpdCBudW0gY29udGFpbnMgYW55IGRpZ2l0ICZhbXA7IGFueSBsZW5ndGhzKCBleDogMTIzNCwg DQoxMjM0NSwxMjM0NTY3KTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhvdyBjYW4g SSBleHByZXNzIHRoaXMgaW4gRGlnaXQgTWFwPzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPkkgZ3Vlc3MgLi4uLi4zMjB4LiMgJmx0Oy0tIGlzIHRoaXMgcmlnaHQ/PC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTI+SSBob3BlIHlvdXIgYW5zd2VyIC4uLlRoYW5rcyEhPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCANCnNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo8L0ZPTlQ+PEZPTlQgc2l6ZT0yPjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08QlI+U3VuZy1Zb3VuIA0KS2ltPEJSPkFzc29jaWF0ZSBSZXNlYXJjaCBFbmdp bmVlcjxCUj5TV0lUQ0hJTkcgU09GVFdBUkU8QlI+RElHSVRBTCBTV0lUQ0hJTkcgDQpTWVNURU0g TEFCT1JBVE9SWTxCUj5MRyBJbmZvcm1hdGlvbiAmYW1wOyANCkNvbW11bmljYXRpb24uTHRkPEJS Pig4Mi0zMSk0NTAtNzM3NjxCUj5lLW1haWwgPEEgDQpocmVmPSJtYWlsdG86c3VuZ3lvb25AbGdl LmNvbSI+c3VuZ3lvb25AbGdlLmNvbTwvQT48QlI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0067_01C2E3F0.F7FFFC40-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Mar 6 02:01: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 CAA16516 for ; Thu, 6 Mar 2003 02:01: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 h2679HO01299; Thu, 6 Mar 2003 02:09: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 h2674ZO28585 for ; Thu, 6 Mar 2003 02:04:35 -0500 Received: from auds951.usa.alcatel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14976 for ; Thu, 6 Mar 2003 01:53:09 -0500 (EST) Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.6/8.12.6) with ESMTP id h266t4BK026180; Thu, 6 Mar 2003 00:55:07 -0600 (CST) Received: from axws59 ([10.255.5.109]) by ssd.usa.alcatel.com (8.11.1/8.11.1) with SMTP id h266sAF09709; Thu, 6 Mar 2003 00:54:10 -0600 (CST) Message-ID: <008801c2e3af$3da990e0$6d05ff0a@axws59> From: "Selvam.V" To: Cc: "Megaco" References: <65256CE1.001F2193.00@sandesh.hss.hns.com> Subject: Re: [Megaco] Clearing Remote SDP Data Date: Thu, 6 Mar 2003 12:38:48 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 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 Nayar, I have asked for Both . Can you tell me what will be the effect if the GATEWAY is supporting ATM Terminations. Thanks & Regards, selva ----- Original Message ----- From: To: Selvam.V Cc: Megaco Sent: Thursday, March 06, 2003 11:15 AM Subject: Re: [Megaco] Clearing Remote SDP Data > > > Hi Selva > > Another possible case can be: > CASE 3: > Send a Modify with New Remote Descriptor to release the > old resources and also allocate new resources, since the > new Remote Descriptor completely replaces the old one. > > The mode of the stream should understandably be changed to receive-only in CASE > 2 > as indicated by you. > > BTW, the question you asked is with reference to IP terminations or ATM > terminations? > For, IP terminations this may simply map to changing the destination address/ > payload > type for media. But, in case of ATM it may need further investigation. > > thanks, > -kapil nayar > Hughes Software Systems Ltd. > http://www.hssworld.com > > > > > > "Selvam.V" on 03/05/2003 10:13:06 PM > > To: "Megaco" > cc: (bcc: Kapil Nayar/HSS) > > Subject: [Megaco] Clearing Remote SDP Data > > > > > Hi All, > I want to release/clear the Remote SDP for a Termination, and > ADD a new Remote SDP for that Termination. > > CASE 1: > > Subtract the Ephmeral Termination and Add the > Ephemeral > Termiantion with new Remote SDP Data. > > CASE 2: > > Send a Modify with Empty Remote Descriptor to > release the > the resources and then send another modify with new > Remote Descriptor. > > Can any one, Tell me which of the above cases will work. > > if CASE 2 will work, wether the mode of the Termination should > be > changed to receive only. > > Thanks in Advance, > > selva. > > > > > _______________________________________________ > 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 Mar 6 02:03: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 CAA18593 for ; Thu, 6 Mar 2003 02:03:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h267E7I06847 for megaco-archive@odin.ietf.org; Thu, 6 Mar 2003 02:14: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 h267E6O06844 for ; Thu, 6 Mar 2003 02:14:06 -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 CAA18005 for ; Thu, 6 Mar 2003 02:02: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 h2679HO01299; Thu, 6 Mar 2003 02:09: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 h2674ZO28585 for ; Thu, 6 Mar 2003 02:04:35 -0500 Received: from auds951.usa.alcatel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14976 for ; Thu, 6 Mar 2003 01:53:09 -0500 (EST) Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.6/8.12.6) with ESMTP id h266t4BK026180; Thu, 6 Mar 2003 00:55:07 -0600 (CST) Received: from axws59 ([10.255.5.109]) by ssd.usa.alcatel.com (8.11.1/8.11.1) with SMTP id h266sAF09709; Thu, 6 Mar 2003 00:54:10 -0600 (CST) Message-ID: <008801c2e3af$3da990e0$6d05ff0a@axws59> From: "Selvam.V" To: Cc: "Megaco" References: <65256CE1.001F2193.00@sandesh.hss.hns.com> Subject: Re: [Megaco] Clearing Remote SDP Data Date: Thu, 6 Mar 2003 12:38:48 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 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 Nayar, I have asked for Both . Can you tell me what will be the effect if the GATEWAY is supporting ATM Terminations. Thanks & Regards, selva ----- Original Message ----- From: To: Selvam.V Cc: Megaco Sent: Thursday, March 06, 2003 11:15 AM Subject: Re: [Megaco] Clearing Remote SDP Data > > > Hi Selva > > Another possible case can be: > CASE 3: > Send a Modify with New Remote Descriptor to release the > old resources and also allocate new resources, since the > new Remote Descriptor completely replaces the old one. > > The mode of the stream should understandably be changed to receive-only in CASE > 2 > as indicated by you. > > BTW, the question you asked is with reference to IP terminations or ATM > terminations? > For, IP terminations this may simply map to changing the destination address/ > payload > type for media. But, in case of ATM it may need further investigation. > > thanks, > -kapil nayar > Hughes Software Systems Ltd. > http://www.hssworld.com > > > > > > "Selvam.V" on 03/05/2003 10:13:06 PM > > To: "Megaco" > cc: (bcc: Kapil Nayar/HSS) > > Subject: [Megaco] Clearing Remote SDP Data > > > > > Hi All, > I want to release/clear the Remote SDP for a Termination, and > ADD a new Remote SDP for that Termination. > > CASE 1: > > Subtract the Ephmeral Termination and Add the > Ephemeral > Termiantion with new Remote SDP Data. > > CASE 2: > > Send a Modify with Empty Remote Descriptor to > release the > the resources and then send another modify with new > Remote Descriptor. > > Can any one, Tell me which of the above cases will work. > > if CASE 2 will work, wether the mode of the Termination should > be > changed to receive only. > > Thanks in Advance, > > selva. > > > > > _______________________________________________ > 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 Mar 6 02:27: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 CAA26592 for ; Thu, 6 Mar 2003 02:27: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 h267YUO08341; Thu, 6 Mar 2003 02:34: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 h267VFO08235 for ; Thu, 6 Mar 2003 02:31:15 -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 CAA26484 for ; Thu, 6 Mar 2003 02:19:49 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h267Lq013193 for ; Thu, 6 Mar 2003 02:21:52 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 02:21:53 -0500 Message-ID: From: "Kevin Boyle" To: ??? , megaco@ietf.org Subject: RE: [Megaco] Digit Map expression Date: Thu, 6 Mar 2003 02:21:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Correct. Kevin -----Original Message----- From: sungyoon@lge.com [mailto:sungyoon@lge.com] Sent: Thursday, March 06, 2003 12:59 AM To: megaco@ietf.org Subject: [Megaco] Digit Map expression Hi all ! I wonder Digit Map expression ! want to control phone number is 320-digit num-# digit num contains any digit & any lengths( ex: 1234, 12345,1234567) How can I express this in Digit Map? I guess .....320x.# <-- is this right? I hope your answer ...Thanks!! ------------------------------------------- Sung-Youn Kim Associate Research Engineer SWITCHING SOFTWARE DIGITAL SWITCHING SYSTEM LABORATORY LG Information & Communication.Ltd (82-31)450-7376 e-mail sungyoon@lge.com ------------------------------------------- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Mar 6 02:29: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 CAA26646 for ; Thu, 6 Mar 2003 02:29:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h267e5O09398 for megaco-archive@odin.ietf.org; Thu, 6 Mar 2003 02:40: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 h267e4O09395 for ; Thu, 6 Mar 2003 02:40: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 CAA26631 for ; Thu, 6 Mar 2003 02:28: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 h267YUO08341; Thu, 6 Mar 2003 02:34: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 h267VFO08235 for ; Thu, 6 Mar 2003 02:31:15 -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 CAA26484 for ; Thu, 6 Mar 2003 02:19:49 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h267Lq013193 for ; Thu, 6 Mar 2003 02:21:52 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 02:21:53 -0500 Message-ID: From: "Kevin Boyle" To: ??? , megaco@ietf.org Subject: RE: [Megaco] Digit Map expression Date: Thu, 6 Mar 2003 02:21:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Correct. Kevin -----Original Message----- From: sungyoon@lge.com [mailto:sungyoon@lge.com] Sent: Thursday, March 06, 2003 12:59 AM To: megaco@ietf.org Subject: [Megaco] Digit Map expression Hi all ! I wonder Digit Map expression ! want to control phone number is 320-digit num-# digit num contains any digit & any lengths( ex: 1234, 12345,1234567) How can I express this in Digit Map? I guess .....320x.# <-- is this right? I hope your answer ...Thanks!! ------------------------------------------- Sung-Youn Kim Associate Research Engineer SWITCHING SOFTWARE DIGITAL SWITCHING SYSTEM LABORATORY LG Information & Communication.Ltd (82-31)450-7376 e-mail sungyoon@lge.com ------------------------------------------- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Mar 6 03:17: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 DAA27823 for ; Thu, 6 Mar 2003 03:17: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 h268NEO11999; Thu, 6 Mar 2003 03:23: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 h268GgO11801 for ; Thu, 6 Mar 2003 03:16:42 -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 DAA27626 for ; Thu, 6 Mar 2003 03:05:17 -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 h2687Iv10264; Thu, 6 Mar 2003 09:07:18 +0100 (MET) Received: from alcatel.es (sers5021 [159.23.115.21]) by sers002.rpi.ses.alcatel.es (8.8.8+Sun/8.8.8) with ESMTP id JAA26245; Thu, 6 Mar 2003 09:07:26 +0100 (MET) Message-ID: <3E6701BE.E4EBC871@alcatel.es> Date: Thu, 06 Mar 2003 09:07:26 +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: =?EUC-KR?B?sei8usCx?= CC: megaco@ietf.org Subject: Re: [Megaco] Digit Map expression References: <006a01c2e3a5$8839e600$ce359696@lge.com> Content-Type: multipart/alternative; boundary="------------5D753370AE81072A7BE4A788" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --------------5D753370AE81072A7BE4A788 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, Yes, I think so. Regards Fernando Who wrote??? just kidding. ^ ±è¼ºÀ± wrote: > Hi all !I wonder Digit Map expression ! want to control phone number > is 320-digit num-#digit num contains any digit & any lengths( ex: > 1234, 12345,1234567)How can I express this in Digit Map?I guess > .....320x.# <-- is this right? I hope your answer ...Thanks!! > ------------------------------------------- > Sung-Youn Kim > Associate Research Engineer > SWITCHING SOFTWARE > DIGITAL SWITCHING SYSTEM LABORATORY > LG Information & Communication.Ltd > (82-31)450-7376 > e-mail sungyoon@lge.com > ------------------------------------------- -- Fernando Vallejo Lazaro Phone: +34 91 330 8279 SW Wireline ASD-Madrid ALCATEL --------------5D753370AE81072A7BE4A788 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi,

Yes, I think so.

Regards
Fernando
 

Who wrote??? just kidding.
^
±è¼ºÀ± wrote:

Hi all !I wonder Digit Map expression ! want to control phone number is 320-digit num-#digit num contains any digit & any lengths( ex: 1234, 12345,1234567)How can I express this in Digit Map?I guess .....320x.# <-- is this right? I hope your answer ...Thanks!! -------------------------------------------
Sung-Youn Kim
Associate Research Engineer
SWITCHING SOFTWARE
DIGITAL SWITCHING SYSTEM LABORATORY
LG Information & Communication.Ltd
(82-31)450-7376
e-mail sungyoon@lge.com
-------------------------------------------
-- 
Fernando Vallejo Lazaro
Phone:  +34 91 330 8279
SW  Wireline ASD-Madrid
       ALCATEL
  --------------5D753370AE81072A7BE4A788-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Mar 6 03:19: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 DAA27891 for ; Thu, 6 Mar 2003 03:19:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h268UTn12307 for megaco-archive@odin.ietf.org; Thu, 6 Mar 2003 03:30: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 h268USO12304 for ; Thu, 6 Mar 2003 03:30: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 DAA27875 for ; Thu, 6 Mar 2003 03:19: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 h268NEO11999; Thu, 6 Mar 2003 03:23: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 h268GgO11801 for ; Thu, 6 Mar 2003 03:16:42 -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 DAA27626 for ; Thu, 6 Mar 2003 03:05:17 -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 h2687Iv10264; Thu, 6 Mar 2003 09:07:18 +0100 (MET) Received: from alcatel.es (sers5021 [159.23.115.21]) by sers002.rpi.ses.alcatel.es (8.8.8+Sun/8.8.8) with ESMTP id JAA26245; Thu, 6 Mar 2003 09:07:26 +0100 (MET) Message-ID: <3E6701BE.E4EBC871@alcatel.es> Date: Thu, 06 Mar 2003 09:07:26 +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: =?EUC-KR?B?sei8usCx?= CC: megaco@ietf.org Subject: Re: [Megaco] Digit Map expression References: <006a01c2e3a5$8839e600$ce359696@lge.com> Content-Type: multipart/alternative; boundary="------------5D753370AE81072A7BE4A788" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --------------5D753370AE81072A7BE4A788 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, Yes, I think so. Regards Fernando Who wrote??? just kidding. ^ ±è¼ºÀ± wrote: > Hi all !I wonder Digit Map expression ! want to control phone number > is 320-digit num-#digit num contains any digit & any lengths( ex: > 1234, 12345,1234567)How can I express this in Digit Map?I guess > .....320x.# <-- is this right? I hope your answer ...Thanks!! > ------------------------------------------- > Sung-Youn Kim > Associate Research Engineer > SWITCHING SOFTWARE > DIGITAL SWITCHING SYSTEM LABORATORY > LG Information & Communication.Ltd > (82-31)450-7376 > e-mail sungyoon@lge.com > ------------------------------------------- -- Fernando Vallejo Lazaro Phone: +34 91 330 8279 SW Wireline ASD-Madrid ALCATEL --------------5D753370AE81072A7BE4A788 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi,

Yes, I think so.

Regards
Fernando
 

Who wrote??? just kidding.
^
±è¼ºÀ± wrote:

Hi all !I wonder Digit Map expression ! want to control phone number is 320-digit num-#digit num contains any digit & any lengths( ex: 1234, 12345,1234567)How can I express this in Digit Map?I guess .....320x.# <-- is this right? I hope your answer ...Thanks!! -------------------------------------------
Sung-Youn Kim
Associate Research Engineer
SWITCHING SOFTWARE
DIGITAL SWITCHING SYSTEM LABORATORY
LG Information & Communication.Ltd
(82-31)450-7376
e-mail sungyoon@lge.com
-------------------------------------------
-- 
Fernando Vallejo Lazaro
Phone:  +34 91 330 8279
SW  Wireline ASD-Madrid
       ALCATEL
  --------------5D753370AE81072A7BE4A788-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Mar 6 18:32: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 SAA18476 for ; Thu, 6 Mar 2003 18:32: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 h26NgpO27110; Thu, 6 Mar 2003 18:42: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 h26NeCO27045 for ; Thu, 6 Mar 2003 18:40:12 -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 SAA18400 for ; Thu, 6 Mar 2003 18:28:26 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h26NUTB3017661; Fri, 7 Mar 2003 00:30:29 +0100 (MET) Received: from brsf10.epa.ericsson.se ([146.11.8.4]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4JM85X; Fri, 7 Mar 2003 00:30:28 +0100 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 h26NUNL05392; Fri, 7 Mar 2003 10:30:24 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.243]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DZ36QTT2; Fri, 7 Mar 2003 10:30:20 +1100 Message-ID: <3E67DA08.31E94B74@ericsson.com.au> Date: Fri, 07 Mar 2003 10:30:16 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Carl Rutter CC: megaco@ietf.org Subject: Re: [Megaco] Request ID = 0 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 Hello Carl, Yes I would say Request ID = 0 is accepted. The main use is for the Event Buffer Full event. I would say that for any Notify requests from the MG that were not explicitly Requested by the MGC should use RequestID=0 unless provisioned otherwise. Regards, Christian Carl Rutter wrote: > > Is the use of Request ID = 0 now accepted? > Would it be fair to say that for any and all Notify requests from the MG > that were not explicitly Requested by the MGC(hence no Request ID) > RequestId=0 should be used? > Packages such as the Congestion Handling Package M.2.5 > indicate the events could be preprovisoned in the MG, if that is the case > RequestID = 0 should be used? > > 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 Thu Mar 6 18:34: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 SAA18570 for ; Thu, 6 Mar 2003 18:34:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26NjE027248 for megaco-archive@odin.ietf.org; Thu, 6 Mar 2003 18:45: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 h26NjEO27245 for ; Thu, 6 Mar 2003 18:45:14 -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 SAA18543 for ; Thu, 6 Mar 2003 18:33:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26NgpO27110; Thu, 6 Mar 2003 18:42: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 h26NeCO27045 for ; Thu, 6 Mar 2003 18:40:12 -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 SAA18400 for ; Thu, 6 Mar 2003 18:28:26 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h26NUTB3017661; Fri, 7 Mar 2003 00:30:29 +0100 (MET) Received: from brsf10.epa.ericsson.se ([146.11.8.4]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4JM85X; Fri, 7 Mar 2003 00:30:28 +0100 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 h26NUNL05392; Fri, 7 Mar 2003 10:30:24 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.243]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DZ36QTT2; Fri, 7 Mar 2003 10:30:20 +1100 Message-ID: <3E67DA08.31E94B74@ericsson.com.au> Date: Fri, 07 Mar 2003 10:30:16 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Carl Rutter CC: megaco@ietf.org Subject: Re: [Megaco] Request ID = 0 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 Hello Carl, Yes I would say Request ID = 0 is accepted. The main use is for the Event Buffer Full event. I would say that for any Notify requests from the MG that were not explicitly Requested by the MGC should use RequestID=0 unless provisioned otherwise. Regards, Christian Carl Rutter wrote: > > Is the use of Request ID = 0 now accepted? > Would it be fair to say that for any and all Notify requests from the MG > that were not explicitly Requested by the MGC(hence no Request ID) > RequestId=0 should be used? > Packages such as the Congestion Handling Package M.2.5 > indicate the events could be preprovisoned in the MG, if that is the case > RequestID = 0 should be used? > > 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 Thu Mar 6 19:47: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 TAA21971 for ; Thu, 6 Mar 2003 19:47: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 h270vAO00930; Thu, 6 Mar 2003 19:57: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 h270tiO00870 for ; Thu, 6 Mar 2003 19:55:44 -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 TAA21911 for ; Thu, 6 Mar 2003 19:43:56 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h270juwv015762; Fri, 7 Mar 2003 01:45:56 +0100 (MET) Received: from brsf10.epa.ericsson.se ([146.11.8.4]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4JNH51; Fri, 7 Mar 2003 01:45:55 +0100 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 h270jqL03032; Fri, 7 Mar 2003 11:45:52 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.243]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DZ36QVVV; Fri, 7 Mar 2003 11:45:49 +1100 Message-ID: <3E67EBB7.89B232CC@ericsson.com.au> Date: Fri, 07 Mar 2003 11:45:43 +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 Subject: Re: [Megaco] Re: Topology Descriptor Processing Logic References: <65256CCC.003D3B98.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 Prashant, Please see my answers below. Regards, Christian shbansal@hss.hns.com wrote: > > Hi Christian/list, > > We didn't get any reply/ comments on this mail. > >From the earlier discussions on the mailing list, it seems that there > definitely are some existing implementations supporting Topology descriptor. > I would request them to provide some clarity on these issues in the interest > of the MEGACO interoperability. > Unless the questions/ issues raised in this mail are inconsequential and > grossly missing something, in which case please indicate so. > > Thanks in advance > Shobhit > (HSS MEGACO Team) > > prjain@hss.hns.com on 02/03/2003 08:13:29 PM > > To: Christian Groves > cc: Shobhit Bansal/HSS@HSS, megaco@ietf.org (bcc: megaco_maillist) > > Subject: Re: [Megaco] Re: Topology Descriptor Processing Logic > > Hi Christian/list, > Thanks a lot for clarifying all the doubts. In addition to what you have > said, I have two more questions as asked below. I beg your pardon in case these > questions have already been discussed or asked on the list before. > > <> > You have told that in case the topology tuple happens to be fully specified > (except $), the topology descriptor would be executed first (at the action level > befoe any command processing starts, even though the protocol command like ADD > or MODIFY with fully-specified terminations were there in the context further, > for the corresponding terminations in the topology tuples). > > If the above statement holds true, does it imply that the topology > descriptor would always be first descriptor in the entire descriptor processing > sequence that would get executed, taking into account the other descriptors > processing like events, signals, stream descriptors (for all descriptors except > topology, the processing sequence can be specified by MGC) etc. ?? [CHG] Yes this would be a fair statement. > > Is this implication about the "sequence of processing" valid whether MG > executes topology descriptor at the action level or at the command level (in > case of ADD $) ?? [CHG] Not sure what the question is here. Topology is always at an action action level as its not a command. It does however have implications on commands. > > <> > > Thanks and Regards, > Prashant Jain > > Christian Groves on 02/03/2003 08:34:04 AM > > To: Shobhit Bansal/HSS@HSS > cc: megaco@ietf.org (bcc: Prashant Jain/HSS) > > Subject: [Megaco] Re: Topology Descriptor Processing Logic > > Hello Shobhit, > > As everything is fully specified I believe it is your first description. > > Christian > > shbansal@hss.hns.com wrote: > > > > Hi Chris, > > > > I have gone through the mailing list discussions > > But I still have some doubts in topology descriptor procressing > > I will be really very thankful and obliged if you help in resolving them > > > > Assuming that we have a context C1 with terminations T1, T2 and T3 > > and command comes like > > > > Action C1 Topolgy ( T1, T3, Isolate) > > Command Modify T1 > > Command Modify T2 > > > > In this case: > > > > Will the topology (T1, T3, Isolate) be applied before the > > command execution starts i.e. tuples of specified terminations > > will get applied before any command execution starts. > > If this understanding is correct, topology will get applied > > before execution of MODIFY T1 > > > > OR > > > > Will the topology application be deffered till the command > > execution starts for the respective terminations that are present in tuples. > > If this understanding is correct, after MODIFY T1 gets executed, > > topology would be applied in conjunction thereof. > > Further after that, MODIFY T2 will get executed. > > > > Thanking you in advance > > Shobhit > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > DISCLAIMER: This message is proprietary to Hughes Software Systems > Limited (HSS) and is intended solely for the use of the individual > to whom it is addressed. It may contain privileged or confidential > information and should not be circulated or used for any purpose other > than for what it is intended. If you have received this message in error, > please notify the originator immediately. If you are not the intended > recipient, you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. HSS accepts > no responsibility for loss or damage arising from the use of the information > transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Mar 6 19:48: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 TAA22019 for ; Thu, 6 Mar 2003 19:48:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h270xom01060 for megaco-archive@odin.ietf.org; Thu, 6 Mar 2003 19:59: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 h270xoO01057 for ; Thu, 6 Mar 2003 19:59: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 TAA22000 for ; Thu, 6 Mar 2003 19:48: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 h270vAO00930; Thu, 6 Mar 2003 19:57: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 h270tiO00870 for ; Thu, 6 Mar 2003 19:55:44 -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 TAA21911 for ; Thu, 6 Mar 2003 19:43:56 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h270juwv015762; Fri, 7 Mar 2003 01:45:56 +0100 (MET) Received: from brsf10.epa.ericsson.se ([146.11.8.4]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4JNH51; Fri, 7 Mar 2003 01:45:55 +0100 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 h270jqL03032; Fri, 7 Mar 2003 11:45:52 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.243]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DZ36QVVV; Fri, 7 Mar 2003 11:45:49 +1100 Message-ID: <3E67EBB7.89B232CC@ericsson.com.au> Date: Fri, 07 Mar 2003 11:45:43 +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 Subject: Re: [Megaco] Re: Topology Descriptor Processing Logic References: <65256CCC.003D3B98.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 Prashant, Please see my answers below. Regards, Christian shbansal@hss.hns.com wrote: > > Hi Christian/list, > > We didn't get any reply/ comments on this mail. > >From the earlier discussions on the mailing list, it seems that there > definitely are some existing implementations supporting Topology descriptor. > I would request them to provide some clarity on these issues in the interest > of the MEGACO interoperability. > Unless the questions/ issues raised in this mail are inconsequential and > grossly missing something, in which case please indicate so. > > Thanks in advance > Shobhit > (HSS MEGACO Team) > > prjain@hss.hns.com on 02/03/2003 08:13:29 PM > > To: Christian Groves > cc: Shobhit Bansal/HSS@HSS, megaco@ietf.org (bcc: megaco_maillist) > > Subject: Re: [Megaco] Re: Topology Descriptor Processing Logic > > Hi Christian/list, > Thanks a lot for clarifying all the doubts. In addition to what you have > said, I have two more questions as asked below. I beg your pardon in case these > questions have already been discussed or asked on the list before. > > <> > You have told that in case the topology tuple happens to be fully specified > (except $), the topology descriptor would be executed first (at the action level > befoe any command processing starts, even though the protocol command like ADD > or MODIFY with fully-specified terminations were there in the context further, > for the corresponding terminations in the topology tuples). > > If the above statement holds true, does it imply that the topology > descriptor would always be first descriptor in the entire descriptor processing > sequence that would get executed, taking into account the other descriptors > processing like events, signals, stream descriptors (for all descriptors except > topology, the processing sequence can be specified by MGC) etc. ?? [CHG] Yes this would be a fair statement. > > Is this implication about the "sequence of processing" valid whether MG > executes topology descriptor at the action level or at the command level (in > case of ADD $) ?? [CHG] Not sure what the question is here. Topology is always at an action action level as its not a command. It does however have implications on commands. > > <> > > Thanks and Regards, > Prashant Jain > > Christian Groves on 02/03/2003 08:34:04 AM > > To: Shobhit Bansal/HSS@HSS > cc: megaco@ietf.org (bcc: Prashant Jain/HSS) > > Subject: [Megaco] Re: Topology Descriptor Processing Logic > > Hello Shobhit, > > As everything is fully specified I believe it is your first description. > > Christian > > shbansal@hss.hns.com wrote: > > > > Hi Chris, > > > > I have gone through the mailing list discussions > > But I still have some doubts in topology descriptor procressing > > I will be really very thankful and obliged if you help in resolving them > > > > Assuming that we have a context C1 with terminations T1, T2 and T3 > > and command comes like > > > > Action C1 Topolgy ( T1, T3, Isolate) > > Command Modify T1 > > Command Modify T2 > > > > In this case: > > > > Will the topology (T1, T3, Isolate) be applied before the > > command execution starts i.e. tuples of specified terminations > > will get applied before any command execution starts. > > If this understanding is correct, topology will get applied > > before execution of MODIFY T1 > > > > OR > > > > Will the topology application be deffered till the command > > execution starts for the respective terminations that are present in tuples. > > If this understanding is correct, after MODIFY T1 gets executed, > > topology would be applied in conjunction thereof. > > Further after that, MODIFY T2 will get executed. > > > > Thanking you in advance > > Shobhit > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > DISCLAIMER: This message is proprietary to Hughes Software Systems > Limited (HSS) and is intended solely for the use of the individual > to whom it is addressed. It may contain privileged or confidential > information and should not be circulated or used for any purpose other > than for what it is intended. If you have received this message in error, > please notify the originator immediately. If you are not the intended > recipient, you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. HSS accepts > no responsibility for loss or damage arising from the use of the information > transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Mar 7 19:52: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 TAA21095 for ; Fri, 7 Mar 2003 19:52: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 h2812DO01664; Fri, 7 Mar 2003 20:02:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h280xbO01386 for ; Fri, 7 Mar 2003 19:59:37 -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 TAA20626 for ; Fri, 7 Mar 2003 19:47:19 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h270fUwv015392; Fri, 7 Mar 2003 01:41:31 +0100 (MET) Received: from brsf10.epa.ericsson.se ([146.11.8.4]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4JNH1G; Fri, 7 Mar 2003 01:41:23 +0100 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 h270fJL01427; Fri, 7 Mar 2003 11:41:20 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.243]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DZ36QVSL; Fri, 7 Mar 2003 11:41:16 +1100 Message-ID: <3E67EAA6.F834A0B5@ericsson.com.au> Date: Fri, 07 Mar 2003 11:41:10 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: anarora@hss.hns.com CC: megaco@ietf.org, samittal@hss.hns.com, prjain@hss.hns.com, shbansal@hss.hns.com Subject: Re: [Megaco] Rollback Support in Topology Descriptor References: <65256CDF.0017CA1A.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 Anjana, I don't think this is a valid example. The commands would be executed: > 1. Topology (T1, T2, assoc) > 2. Modify = T3 > 3. Modify T1 > 4. Modify T2 If Modify T1 and T2 fails, the MG won't roll back Topology as it already has executed the descriptor. Its up to the MGC to clean this up if it wants to. Regards, Christian anarora@hss.hns.com wrote: > > Hi > > I have a query regarding rollback of topology if one of the commands in the > action fails... > > Consider the following e.g. > T1, T2 and T3 are already present in the context: > > MEGACO/1 [111.111.111.4]:222 > Transaction = 23{ > Context = 1 { > Topology { T1. T2, assoc} > Modify = T3 {Media...., Event..., Signal}, > Modify = T1 {Media...., Event..., Signal}, > Modify = T2 {Media...., Event..., Signal} > } > } > > If the commands in the action are executed in the following order > 1. Modify = T3 > 2. Topology (T1, T2, assoc) > 3. Modify T1 > 4. Modify T2 > > then if Modify T1 or Modify T2 fails, should Topology should be rollbacked to > previous value? > > thanks and regards > Anjana Arora > Hughes Software Systems > > DISCLAIMER: This message is proprietary to Hughes Software Systems > Limited (HSS) and is intended solely for the use of the individual > to whom it is addressed. It may contain privileged or confidential > information and should not be circulated or used for any purpose other > than for what it is intended. If you have received this message in error, > please notify the originator immediately. If you are not the intended > recipient, you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. HSS accepts > no responsibility for loss or damage arising from the use of the information > transmitted by this email including damage from virus. > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Mar 7 19:53: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 TAA21205 for ; Fri, 7 Mar 2003 19:53:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2815RW01948 for megaco-archive@odin.ietf.org; Fri, 7 Mar 2003 20:05: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 h2815RO01945 for ; Fri, 7 Mar 2003 20:05: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 TAA21171 for ; Fri, 7 Mar 2003 19:53: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 h2812DO01664; Fri, 7 Mar 2003 20:02:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h280xbO01386 for ; Fri, 7 Mar 2003 19:59:37 -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 TAA20626 for ; Fri, 7 Mar 2003 19:47:19 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h270fUwv015392; Fri, 7 Mar 2003 01:41:31 +0100 (MET) Received: from brsf10.epa.ericsson.se ([146.11.8.4]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4JNH1G; Fri, 7 Mar 2003 01:41:23 +0100 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 h270fJL01427; Fri, 7 Mar 2003 11:41:20 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.243]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DZ36QVSL; Fri, 7 Mar 2003 11:41:16 +1100 Message-ID: <3E67EAA6.F834A0B5@ericsson.com.au> Date: Fri, 07 Mar 2003 11:41:10 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: anarora@hss.hns.com CC: megaco@ietf.org, samittal@hss.hns.com, prjain@hss.hns.com, shbansal@hss.hns.com Subject: Re: [Megaco] Rollback Support in Topology Descriptor References: <65256CDF.0017CA1A.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 Anjana, I don't think this is a valid example. The commands would be executed: > 1. Topology (T1, T2, assoc) > 2. Modify = T3 > 3. Modify T1 > 4. Modify T2 If Modify T1 and T2 fails, the MG won't roll back Topology as it already has executed the descriptor. Its up to the MGC to clean this up if it wants to. Regards, Christian anarora@hss.hns.com wrote: > > Hi > > I have a query regarding rollback of topology if one of the commands in the > action fails... > > Consider the following e.g. > T1, T2 and T3 are already present in the context: > > MEGACO/1 [111.111.111.4]:222 > Transaction = 23{ > Context = 1 { > Topology { T1. T2, assoc} > Modify = T3 {Media...., Event..., Signal}, > Modify = T1 {Media...., Event..., Signal}, > Modify = T2 {Media...., Event..., Signal} > } > } > > If the commands in the action are executed in the following order > 1. Modify = T3 > 2. Topology (T1, T2, assoc) > 3. Modify T1 > 4. Modify T2 > > then if Modify T1 or Modify T2 fails, should Topology should be rollbacked to > previous value? > > thanks and regards > Anjana Arora > 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 Mon Mar 10 16: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 QAA15357 for ; Mon, 10 Mar 2003 16: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 h2ALkxO21633; Mon, 10 Mar 2003 16:47: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 h2ALiGO21539 for ; Mon, 10 Mar 2003 16:44:16 -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 QAA15226 for ; Mon, 10 Mar 2003 16:30:36 -0500 (EST) Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Mar 2003 16:28:08 -0500 Message-ID: From: Carl Rutter To: "'megaco@ietf.org'" Date: Mon, 10 Mar 2003 16:27:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Megaco] SDP Reply 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: , Anyone care to comment on the follwoing question? Thx, Carl Question on what SDP reply information is required by MEGACO Say someone specifies in a Local or Remote Descriptor a fully qualified attribute ie) a=ptime:30 for the Transaction Request In the Reply that goes back should the descriptor contain the attribute a=ptime:30 ie) Page 171-172 of MEGACO V1 with Corrections does not. Also fully qualified Remote Descriptors are not replied back. Isn't the intent to reply with ONLY SDP information that was altered/chosen by the MG? Is it optional to reply with the specified information? Could you point me to the section dealing with this in either RFC 2327 or 3015? 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 Mon Mar 10 16:37: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 QAA15485 for ; Mon, 10 Mar 2003 16:37:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ALoLe21854 for megaco-archive@odin.ietf.org; Mon, 10 Mar 2003 16:50: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 h2ALoLO21851 for ; Mon, 10 Mar 2003 16:50: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 QAA15456 for ; Mon, 10 Mar 2003 16:36: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 h2ALkxO21633; Mon, 10 Mar 2003 16:47: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 h2ALiGO21539 for ; Mon, 10 Mar 2003 16:44:16 -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 QAA15226 for ; Mon, 10 Mar 2003 16:30:36 -0500 (EST) Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Mar 2003 16:28:08 -0500 Message-ID: From: Carl Rutter To: "'megaco@ietf.org'" Date: Mon, 10 Mar 2003 16:27:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Megaco] SDP Reply 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: , Anyone care to comment on the follwoing question? Thx, Carl Question on what SDP reply information is required by MEGACO Say someone specifies in a Local or Remote Descriptor a fully qualified attribute ie) a=ptime:30 for the Transaction Request In the Reply that goes back should the descriptor contain the attribute a=ptime:30 ie) Page 171-172 of MEGACO V1 with Corrections does not. Also fully qualified Remote Descriptors are not replied back. Isn't the intent to reply with ONLY SDP information that was altered/chosen by the MG? Is it optional to reply with the specified information? Could you point me to the section dealing with this in either RFC 2327 or 3015? 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 Wed Mar 12 22:45: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 WAA06244 for ; Wed, 12 Mar 2003 22:45: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 h2D3wbO10048; Wed, 12 Mar 2003 22:58: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 h2D3sYO09900 for ; Wed, 12 Mar 2003 22:54:34 -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 WAA06101 for ; Wed, 12 Mar 2003 22:39:46 -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 h2D3eBs04584 for ; Thu, 13 Mar 2003 09:10:11 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2D3eA204580 for ; Thu, 13 Mar 2003 09:10:10 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2D3gti29161 for ; Thu, 13 Mar 2003 09:12:55 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CE8.00131E94 ; Thu, 13 Mar 2003 08:58:50 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CE8.00131D8B.00@dlfmail1.hss.hns.com> Date: Thu, 13 Mar 2003 09:07:04 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Service change Restart Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 query regarding the processing of Service Change Restart. consider the following scenario: Termination is in state InService. Command recieved from MGC to Restart the termination (with or wothout delay). what MG could possibly do in this case? Thanks 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 Wed Mar 12 22:46: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 WAA06278 for ; Wed, 12 Mar 2003 22:46:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2D40fG10155 for megaco-archive@odin.ietf.org; Wed, 12 Mar 2003 23:00: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 h2D40fO10152 for ; Wed, 12 Mar 2003 23:00: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 WAA06273 for ; Wed, 12 Mar 2003 22: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 h2D3wbO10048; Wed, 12 Mar 2003 22:58: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 h2D3sYO09900 for ; Wed, 12 Mar 2003 22:54:34 -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 WAA06101 for ; Wed, 12 Mar 2003 22:39:46 -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 h2D3eBs04584 for ; Thu, 13 Mar 2003 09:10:11 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2D3eA204580 for ; Thu, 13 Mar 2003 09:10:10 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2D3gti29161 for ; Thu, 13 Mar 2003 09:12:55 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CE8.00131E94 ; Thu, 13 Mar 2003 08:58:50 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CE8.00131D8B.00@dlfmail1.hss.hns.com> Date: Thu, 13 Mar 2003 09:07:04 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Service change Restart Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 query regarding the processing of Service Change Restart. consider the following scenario: Termination is in state InService. Command recieved from MGC to Restart the termination (with or wothout delay). what MG could possibly do in this case? Thanks 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 Thu Mar 13 02:59:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23320 for ; Thu, 13 Mar 2003 02:59: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 h2D8DJO04293; Thu, 13 Mar 2003 03:13: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 h2D8BCO04227 for ; Thu, 13 Mar 2003 03:11:12 -0500 Received: from auds952.usa.alcatel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23282 for ; Thu, 13 Mar 2003 02:56:21 -0500 (EST) Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.8/8.12.8) with ESMTP id h2D7wTtt012046; Thu, 13 Mar 2003 01:58:30 -0600 (CST) Received: from axws59 ([10.255.5.109]) by ssd.usa.alcatel.com (8.11.1/8.11.1) with SMTP id h2D7w6F13131; Thu, 13 Mar 2003 01:58:07 -0600 (CST) Message-ID: <00c401c2e938$5d014580$6d05ff0a@axws59> From: "Selvam.V" To: "Carl Rutter" , References: Subject: [Megaco] SDP Question Date: Thu, 13 Mar 2003 13:42:57 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 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, Does a Modify with New Remote Descriptor will release the old resources and also allocate new resources. Will the new Remote Descriptor completely replaces the old one. Thanks & Regards, selva. ----- Original Message ----- From: Carl Rutter To: Sent: Tuesday, March 11, 2003 2:57 AM Subject: [Megaco] SDP Reply Question > Anyone care to comment on the follwoing question? > > Thx, > Carl > > Question on what SDP reply information is required by MEGACO > > Say someone specifies in a Local or Remote Descriptor a fully qualified > attribute > ie) a=ptime:30 for the Transaction Request > In the Reply that goes back should the descriptor contain the attribute > a=ptime:30 > ie) Page 171-172 of MEGACO V1 with Corrections does not. > Also fully qualified Remote Descriptors are not replied back. > > Isn't the intent to reply with ONLY SDP information that was altered/chosen > by the MG? > > Is it optional to reply with the specified information? > > Could you point me to the section dealing with this in either RFC 2327 or > 3015? > > > 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 Thu Mar 13 03:01: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 DAA23365 for ; Thu, 13 Mar 2003 03:01:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2D8FXL04381 for megaco-archive@odin.ietf.org; Thu, 13 Mar 2003 03:15: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 h2D8FWO04378 for ; Thu, 13 Mar 2003 03:15: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 DAA23352 for ; Thu, 13 Mar 2003 03:00: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 h2D8DJO04293; Thu, 13 Mar 2003 03:13: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 h2D8BCO04227 for ; Thu, 13 Mar 2003 03:11:12 -0500 Received: from auds952.usa.alcatel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23282 for ; Thu, 13 Mar 2003 02:56:21 -0500 (EST) Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.8/8.12.8) with ESMTP id h2D7wTtt012046; Thu, 13 Mar 2003 01:58:30 -0600 (CST) Received: from axws59 ([10.255.5.109]) by ssd.usa.alcatel.com (8.11.1/8.11.1) with SMTP id h2D7w6F13131; Thu, 13 Mar 2003 01:58:07 -0600 (CST) Message-ID: <00c401c2e938$5d014580$6d05ff0a@axws59> From: "Selvam.V" To: "Carl Rutter" , References: Subject: [Megaco] SDP Question Date: Thu, 13 Mar 2003 13:42:57 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 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, Does a Modify with New Remote Descriptor will release the old resources and also allocate new resources. Will the new Remote Descriptor completely replaces the old one. Thanks & Regards, selva. ----- Original Message ----- From: Carl Rutter To: Sent: Tuesday, March 11, 2003 2:57 AM Subject: [Megaco] SDP Reply Question > Anyone care to comment on the follwoing question? > > Thx, > Carl > > Question on what SDP reply information is required by MEGACO > > Say someone specifies in a Local or Remote Descriptor a fully qualified > attribute > ie) a=ptime:30 for the Transaction Request > In the Reply that goes back should the descriptor contain the attribute > a=ptime:30 > ie) Page 171-172 of MEGACO V1 with Corrections does not. > Also fully qualified Remote Descriptors are not replied back. > > Isn't the intent to reply with ONLY SDP information that was altered/chosen > by the MG? > > Is it optional to reply with the specified information? > > Could you point me to the section dealing with this in either RFC 2327 or > 3015? > > > 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 Thu Mar 13 09:30: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 JAA01774 for ; Thu, 13 Mar 2003 09:30: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 h2DEivO32281; Thu, 13 Mar 2003 09:44: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 h2DEhvO32218 for ; Thu, 13 Mar 2003 09:43: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 JAA01667 for ; Thu, 13 Mar 2003 09:28:45 -0500 (EST) Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Mar 2003 09:26:14 -0500 Message-ID: From: Carl Rutter To: "'Selvam.V'" , megaco@ietf.org Subject: RE: [Megaco] SDP Question Date: Thu, 13 Mar 2003 09:26:13 -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: , Hi Selva, Thanks for the response. Not sure if you were asking another question relating to mine or was this an answer? If a question Section 7.1.8 addresses this: A new setting of a Local or Remote Descriptor completely replaces the previous setting of that descriptor in the MG. Thus to retain information from the previous setting the MGC must include that information in the new setting. If the MGC wishes to delete some information from the existing descriptor, it merely resends the descriptor (in a Modify command) with the unwanted information stripped out. Thx, Carl -----Original Message----- From: Selvam.V [mailto:sveeragh@ssd.usa.alcatel.com] Sent: Thursday, March 13, 2003 3:13 AM To: Carl Rutter; megaco@ietf.org Subject: [Megaco] SDP Question Hi Carl, Does a Modify with New Remote Descriptor will release the old resources and also allocate new resources. Will the new Remote Descriptor completely replaces the old one. Thanks & Regards, selva. ----- Original Message ----- From: Carl Rutter To: Sent: Tuesday, March 11, 2003 2:57 AM Subject: [Megaco] SDP Reply Question > Anyone care to comment on the follwoing question? > > Thx, > Carl > > Question on what SDP reply information is required by MEGACO > > Say someone specifies in a Local or Remote Descriptor a fully qualified > attribute > ie) a=ptime:30 for the Transaction Request > In the Reply that goes back should the descriptor contain the attribute > a=ptime:30 > ie) Page 171-172 of MEGACO V1 with Corrections does not. > Also fully qualified Remote Descriptors are not replied back. > > Isn't the intent to reply with ONLY SDP information that was altered/chosen > by the MG? > > Is it optional to reply with the specified information? > > Could you point me to the section dealing with this in either RFC 2327 or > 3015? > > > 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 Thu Mar 13 09:32: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 JAA01842 for ; Thu, 13 Mar 2003 09:32:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DEkVR32448 for megaco-archive@odin.ietf.org; Thu, 13 Mar 2003 09:46: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 h2DEkUO32445 for ; Thu, 13 Mar 2003 09:46: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 JAA01823 for ; Thu, 13 Mar 2003 09:31: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 h2DEivO32281; Thu, 13 Mar 2003 09:44: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 h2DEhvO32218 for ; Thu, 13 Mar 2003 09:43: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 JAA01667 for ; Thu, 13 Mar 2003 09:28:45 -0500 (EST) Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Mar 2003 09:26:14 -0500 Message-ID: From: Carl Rutter To: "'Selvam.V'" , megaco@ietf.org Subject: RE: [Megaco] SDP Question Date: Thu, 13 Mar 2003 09:26:13 -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: , Hi Selva, Thanks for the response. Not sure if you were asking another question relating to mine or was this an answer? If a question Section 7.1.8 addresses this: A new setting of a Local or Remote Descriptor completely replaces the previous setting of that descriptor in the MG. Thus to retain information from the previous setting the MGC must include that information in the new setting. If the MGC wishes to delete some information from the existing descriptor, it merely resends the descriptor (in a Modify command) with the unwanted information stripped out. Thx, Carl -----Original Message----- From: Selvam.V [mailto:sveeragh@ssd.usa.alcatel.com] Sent: Thursday, March 13, 2003 3:13 AM To: Carl Rutter; megaco@ietf.org Subject: [Megaco] SDP Question Hi Carl, Does a Modify with New Remote Descriptor will release the old resources and also allocate new resources. Will the new Remote Descriptor completely replaces the old one. Thanks & Regards, selva. ----- Original Message ----- From: Carl Rutter To: Sent: Tuesday, March 11, 2003 2:57 AM Subject: [Megaco] SDP Reply Question > Anyone care to comment on the follwoing question? > > Thx, > Carl > > Question on what SDP reply information is required by MEGACO > > Say someone specifies in a Local or Remote Descriptor a fully qualified > attribute > ie) a=ptime:30 for the Transaction Request > In the Reply that goes back should the descriptor contain the attribute > a=ptime:30 > ie) Page 171-172 of MEGACO V1 with Corrections does not. > Also fully qualified Remote Descriptors are not replied back. > > Isn't the intent to reply with ONLY SDP information that was altered/chosen > by the MG? > > Is it optional to reply with the specified information? > > Could you point me to the section dealing with this in either RFC 2327 or > 3015? > > > 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 Thu Mar 13 09:40: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 JAA02145 for ; Thu, 13 Mar 2003 09:40: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 h2DEs7O00537; Thu, 13 Mar 2003 09:54: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 h2DErOO00493 for ; Thu, 13 Mar 2003 09:53:24 -0500 Received: from auds952.usa.alcatel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02100 for ; Thu, 13 Mar 2003 09:38:24 -0500 (EST) Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.8/8.12.8) with ESMTP id h2DEeUtv004150; Thu, 13 Mar 2003 08:40:33 -0600 (CST) Received: from axws59 ([10.255.5.109]) by ssd.usa.alcatel.com (8.11.1/8.11.1) with SMTP id h2DEdiF13594; Thu, 13 Mar 2003 08:39:44 -0600 (CST) Message-ID: <01ac01c2e970$79f1e4a0$6d05ff0a@axws59> From: "Selvam.V" To: "Carl Rutter" , References: Subject: Re: [Megaco] SDP Question Date: Thu, 13 Mar 2003 20:24:38 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 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, I have asked another question. Thanks for your response. Thanks & Regards, selva. ----- Original Message ----- From: Carl Rutter To: 'Selvam.V' ; Sent: Thursday, March 13, 2003 7:56 PM Subject: RE: [Megaco] SDP Question > Hi Selva, > > Thanks for the response. > Not sure if you were asking another > question relating to mine or was this an answer? > If a question Section 7.1.8 addresses this: > A new setting of a Local or Remote Descriptor completely replaces the > previous setting of that descriptor in the MG. Thus to retain > information from the previous setting the MGC must include that > information in the new setting. If the MGC wishes to delete some > information from the existing descriptor, it merely resends the > descriptor (in a Modify command) with the unwanted information > stripped out. > > Thx, > Carl > > -----Original Message----- > From: Selvam.V [mailto:sveeragh@ssd.usa.alcatel.com] > Sent: Thursday, March 13, 2003 3:13 AM > To: Carl Rutter; megaco@ietf.org > Subject: [Megaco] SDP Question > > > Hi Carl, > > Does a Modify with New Remote Descriptor will release the > old resources and also allocate new resources. > Will the new Remote Descriptor completely replaces the old > one. > > > Thanks & Regards, > > selva. > > > > ----- Original Message ----- > From: Carl Rutter > To: > Sent: Tuesday, March 11, 2003 2:57 AM > Subject: [Megaco] SDP Reply Question > > > > Anyone care to comment on the follwoing question? > > > > Thx, > > Carl > > > > Question on what SDP reply information is required by MEGACO > > > > Say someone specifies in a Local or Remote Descriptor a fully qualified > > attribute > > ie) a=ptime:30 for the Transaction Request > > In the Reply that goes back should the descriptor contain the attribute > > a=ptime:30 > > ie) Page 171-172 of MEGACO V1 with Corrections does not. > > Also fully qualified Remote Descriptors are not replied back. > > > > Isn't the intent to reply with ONLY SDP information that was > altered/chosen > > by the MG? > > > > Is it optional to reply with the specified information? > > > > Could you point me to the section dealing with this in either RFC 2327 or > > 3015? > > > > > > 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 Thu Mar 13 09: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 JAA02171 for ; Thu, 13 Mar 2003 09:41:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DEtkD00637 for megaco-archive@odin.ietf.org; Thu, 13 Mar 2003 09: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 h2DEtkO00634 for ; Thu, 13 Mar 2003 09: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 JAA02159 for ; Thu, 13 Mar 2003 09:40: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 h2DEs7O00537; Thu, 13 Mar 2003 09:54: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 h2DErOO00493 for ; Thu, 13 Mar 2003 09:53:24 -0500 Received: from auds952.usa.alcatel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02100 for ; Thu, 13 Mar 2003 09:38:24 -0500 (EST) Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.8/8.12.8) with ESMTP id h2DEeUtv004150; Thu, 13 Mar 2003 08:40:33 -0600 (CST) Received: from axws59 ([10.255.5.109]) by ssd.usa.alcatel.com (8.11.1/8.11.1) with SMTP id h2DEdiF13594; Thu, 13 Mar 2003 08:39:44 -0600 (CST) Message-ID: <01ac01c2e970$79f1e4a0$6d05ff0a@axws59> From: "Selvam.V" To: "Carl Rutter" , References: Subject: Re: [Megaco] SDP Question Date: Thu, 13 Mar 2003 20:24:38 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 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, I have asked another question. Thanks for your response. Thanks & Regards, selva. ----- Original Message ----- From: Carl Rutter To: 'Selvam.V' ; Sent: Thursday, March 13, 2003 7:56 PM Subject: RE: [Megaco] SDP Question > Hi Selva, > > Thanks for the response. > Not sure if you were asking another > question relating to mine or was this an answer? > If a question Section 7.1.8 addresses this: > A new setting of a Local or Remote Descriptor completely replaces the > previous setting of that descriptor in the MG. Thus to retain > information from the previous setting the MGC must include that > information in the new setting. If the MGC wishes to delete some > information from the existing descriptor, it merely resends the > descriptor (in a Modify command) with the unwanted information > stripped out. > > Thx, > Carl > > -----Original Message----- > From: Selvam.V [mailto:sveeragh@ssd.usa.alcatel.com] > Sent: Thursday, March 13, 2003 3:13 AM > To: Carl Rutter; megaco@ietf.org > Subject: [Megaco] SDP Question > > > Hi Carl, > > Does a Modify with New Remote Descriptor will release the > old resources and also allocate new resources. > Will the new Remote Descriptor completely replaces the old > one. > > > Thanks & Regards, > > selva. > > > > ----- Original Message ----- > From: Carl Rutter > To: > Sent: Tuesday, March 11, 2003 2:57 AM > Subject: [Megaco] SDP Reply Question > > > > Anyone care to comment on the follwoing question? > > > > Thx, > > Carl > > > > Question on what SDP reply information is required by MEGACO > > > > Say someone specifies in a Local or Remote Descriptor a fully qualified > > attribute > > ie) a=ptime:30 for the Transaction Request > > In the Reply that goes back should the descriptor contain the attribute > > a=ptime:30 > > ie) Page 171-172 of MEGACO V1 with Corrections does not. > > Also fully qualified Remote Descriptors are not replied back. > > > > Isn't the intent to reply with ONLY SDP information that was > altered/chosen > > by the MG? > > > > Is it optional to reply with the specified information? > > > > Could you point me to the section dealing with this in either RFC 2327 or > > 3015? > > > > > > 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 Thu Mar 13 13:57: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 NAA12782 for ; Thu, 13 Mar 2003 13:57: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 h2DJBeO21705; Thu, 13 Mar 2003 14:11: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 h2DJAiO21646 for ; Thu, 13 Mar 2003 14:10:44 -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 NAA12743 for ; Thu, 13 Mar 2003 13:55:39 -0500 (EST) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2DIvZD05189; Thu, 13 Mar 2003 13:57:36 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GDFBVR61; Thu, 13 Mar 2003 13:57:35 -0500 Received: from nortelnetworks.com (acart1e2.ca.nortel.com [47.129.129.111]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GWQ5T4Z5; Thu, 13 Mar 2003 13:57:36 -0500 Message-ID: <3E70D49F.5030106@nortelnetworks.com> Date: Thu, 13 Mar 2003 13:57:35 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: gsachin@hss.hns.com, Megaco List Subject: Re: [Megaco] Service change Restart References: <65256CE8.00131D8B.00@dlfmail1.hss.hns.com> In-Reply-To: <65256CE8.00131D8B.00@dlfmail1.hss.hns.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I agree that it's very difficult to assign any real meaning to an MGC-initiated restart of a termination. My background in switch software development tells me that a restart clears certain aspects of state. However, that makes little sense in the Megaco case, because the MGC can do that directly by subtracting the termination from any context it is in and resetting descriptors if it is not in a context. Conclusion: the only thing an MGC-initiated restart of a termination does is change its state to in-service if it is not already there. gsachin@hss.hns.com wrote: > > Hi List > I have a query regarding the processing of Service Change Restart. > consider the following scenario: > > Termination is in state InService. > Command recieved from MGC to Restart the termination (with or wothout delay). > > what MG could possibly do in this case? > > > Thanks > Sachin Gupta > [disclaimer snipped] _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Mar 13 13:58: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 NAA12830 for ; Thu, 13 Mar 2003 13:58:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DJD3t21806 for megaco-archive@odin.ietf.org; Thu, 13 Mar 2003 14:13: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 h2DJD3O21803 for ; Thu, 13 Mar 2003 14:13: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 NAA12809 for ; Thu, 13 Mar 2003 13:57: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 h2DJBeO21705; Thu, 13 Mar 2003 14:11: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 h2DJAiO21646 for ; Thu, 13 Mar 2003 14:10:44 -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 NAA12743 for ; Thu, 13 Mar 2003 13:55:39 -0500 (EST) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2DIvZD05189; Thu, 13 Mar 2003 13:57:36 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GDFBVR61; Thu, 13 Mar 2003 13:57:35 -0500 Received: from nortelnetworks.com (acart1e2.ca.nortel.com [47.129.129.111]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GWQ5T4Z5; Thu, 13 Mar 2003 13:57:36 -0500 Message-ID: <3E70D49F.5030106@nortelnetworks.com> Date: Thu, 13 Mar 2003 13:57:35 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: gsachin@hss.hns.com, Megaco List Subject: Re: [Megaco] Service change Restart References: <65256CE8.00131D8B.00@dlfmail1.hss.hns.com> In-Reply-To: <65256CE8.00131D8B.00@dlfmail1.hss.hns.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree that it's very difficult to assign any real meaning to an MGC-initiated restart of a termination. My background in switch software development tells me that a restart clears certain aspects of state. However, that makes little sense in the Megaco case, because the MGC can do that directly by subtracting the termination from any context it is in and resetting descriptors if it is not in a context. Conclusion: the only thing an MGC-initiated restart of a termination does is change its state to in-service if it is not already there. gsachin@hss.hns.com wrote: > > Hi List > I have a query regarding the processing of Service Change Restart. > consider the following scenario: > > Termination is in state InService. > Command recieved from MGC to Restart the termination (with or wothout delay). > > what MG could possibly do in this case? > > > Thanks > Sachin Gupta > [disclaimer snipped] _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Mar 14 01:26: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 BAA05485 for ; Fri, 14 Mar 2003 01:26: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 h2E6cNO05760; Fri, 14 Mar 2003 01:38: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 h2E6XqO04821 for ; Fri, 14 Mar 2003 01:33:52 -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 BAA05279 for ; Fri, 14 Mar 2003 01:18:33 -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 h2E6Ips24579 for ; Fri, 14 Mar 2003 11:48:51 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2E6In224575; Fri, 14 Mar 2003 11:48:50 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2E6LWU18001; Fri, 14 Mar 2003 11:51:32 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CE9.0021A4CA ; Fri, 14 Mar 2003 11:37:28 +0530 X-Lotus-FromDomain: HSS To: Tom Taylor cc: gsachin@hss.hns.com, Megaco List Message-ID: <65256CE9.0021A31A.00@dlfmail1.hss.hns.com> Date: Fri, 14 Mar 2003 11:47:37 +0530 Subject: Re: [Megaco] Service change Restart 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: , How about ServiceChange Restart on ROOT from MGC?Does the protocol inhibit it? (It can be an easier means for the MGC to inform MG to delete all contexts rather than 'Subtract'ing each of them, when MGC is taken gracefully out-of-service) Tom Taylor on 03/14/2003 12:27:35 AM To: Sachin Gupta-PNGN/HSS@HSS, Megaco List cc: (bcc: Kushanava Laha/HSS) Subject: Re: [Megaco] Service change Restart I agree that it's very difficult to assign any real meaning to an MGC-initiated restart of a termination. My background in switch software development tells me that a restart clears certain aspects of state. However, that makes little sense in the Megaco case, because the MGC can do that directly by subtracting the termination from any context it is in and resetting descriptors if it is not in a context. Conclusion: the only thing an MGC-initiated restart of a termination does is change its state to in-service if it is not already there. gsachin@hss.hns.com wrote: > > Hi List > I have a query regarding the processing of Service Change Restart. > consider the following scenario: > > Termination is in state InService. > Command recieved from MGC to Restart the termination (with or wothout delay). > > what MG could possibly do in this case? > > > Thanks > Sachin Gupta > [disclaimer snipped] _______________________________________________ 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 Mar 14 01:27: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 BAA05574 for ; Fri, 14 Mar 2003 01:27:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E6g7s05946 for megaco-archive@odin.ietf.org; Fri, 14 Mar 2003 01:42: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 h2E6g7O05943 for ; Fri, 14 Mar 2003 01:42: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 BAA05549 for ; Fri, 14 Mar 2003 01:26: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 h2E6cNO05760; Fri, 14 Mar 2003 01:38: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 h2E6XqO04821 for ; Fri, 14 Mar 2003 01:33:52 -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 BAA05279 for ; Fri, 14 Mar 2003 01:18:33 -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 h2E6Ips24579 for ; Fri, 14 Mar 2003 11:48:51 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2E6In224575; Fri, 14 Mar 2003 11:48:50 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2E6LWU18001; Fri, 14 Mar 2003 11:51:32 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CE9.0021A4CA ; Fri, 14 Mar 2003 11:37:28 +0530 X-Lotus-FromDomain: HSS To: Tom Taylor cc: gsachin@hss.hns.com, Megaco List Message-ID: <65256CE9.0021A31A.00@dlfmail1.hss.hns.com> Date: Fri, 14 Mar 2003 11:47:37 +0530 Subject: Re: [Megaco] Service change Restart 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: , How about ServiceChange Restart on ROOT from MGC?Does the protocol inhibit it? (It can be an easier means for the MGC to inform MG to delete all contexts rather than 'Subtract'ing each of them, when MGC is taken gracefully out-of-service) Tom Taylor on 03/14/2003 12:27:35 AM To: Sachin Gupta-PNGN/HSS@HSS, Megaco List cc: (bcc: Kushanava Laha/HSS) Subject: Re: [Megaco] Service change Restart I agree that it's very difficult to assign any real meaning to an MGC-initiated restart of a termination. My background in switch software development tells me that a restart clears certain aspects of state. However, that makes little sense in the Megaco case, because the MGC can do that directly by subtracting the termination from any context it is in and resetting descriptors if it is not in a context. Conclusion: the only thing an MGC-initiated restart of a termination does is change its state to in-service if it is not already there. gsachin@hss.hns.com wrote: > > Hi List > I have a query regarding the processing of Service Change Restart. > consider the following scenario: > > Termination is in state InService. > Command recieved from MGC to Restart the termination (with or wothout delay). > > what MG could possibly do in this case? > > > Thanks > Sachin Gupta > [disclaimer snipped] _______________________________________________ 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 Mar 14 08:10: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 IAA24350 for ; Fri, 14 Mar 2003 08:10: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 h2EDMsO09497; Fri, 14 Mar 2003 08:22: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 h2EAgaO32214 for ; Fri, 14 Mar 2003 05:42:36 -0500 Received: from hfclrnd (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21149 for ; Fri, 14 Mar 2003 05:27:09 -0500 (EST) Received: (from root@localhost) by hfclrnd (8.11.6/8.11.2) id h2E9cep23264; Fri, 14 Mar 2003 15:08:40 +0530 Received: from abhishek ([132.147.166.26]) by hfclrnd (8.11.6/8.11.2) with SMTP id h2E9cdN23256; Fri, 14 Mar 2003 15:08:39 +0530 Message-ID: <001b01c2ea15$21d31690$1aa69384@abhishek> From: "Abhi" To: Cc: Date: Fri, 14 Mar 2003 16:03:20 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C2EA43.3B75CEC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Xmilter: rnd.hfcl.com X-Virus-Scanned: by AMaViS perl-11 Subject: [Megaco] query regarding the use of SDP Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_0018_01C2EA43.3B75CEC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, As we know SDP is used to ecode and decode local and remote descriptor. = I have certain doubts about some SDP paramters. They are as follows:- 1. Do we reqire "o=3D" line in megaco? if present then a. Can we set username to hypen ("-")? b. Can NTP timestamp be used for session id and=20 version? 2.Do we need sesion name? If present can we use hyphen for that? 3..Do we need sesion and media information "i=3D" line ? 4..Do we need URI ? 5. How to use bandwidth "b=3D" line? 6. How to use "t=3D" line? If present, can we have a permanent session? NOTE :- RFC-3435(MGCP ) says * The start time may be set to zero. * The stop time should be set to zero. 7. .Do we need attributes a) a=3Dcat: b) a=3Dkeywds: c) a=3Dtool:? 8. Aren't "recvonly", "senrecv", "sendonlly" are redundant in=20 Megaco? 9. How to use "a=3Dtype:" in Megaco? 10 How to use attributes "a=3Dsdplang" & "a=3Dlang" in Megaco? Thanks and regards Abhishek Bansal ------=_NextPart_000_0018_01C2EA43.3B75CEC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
As we know SDP is used to ecode and = decode local=20 and remote descriptor. I have certain doubts about some SDP paramters.=20 They  are as follows:-
1. Do we reqire "o=3D" line in = megaco?
    if present = then
    a. Can we set = username to hypen=20 ("-")?
    b. Can NTP timestamp = be used for session id and 
      =20  version?
 2.Do we need sesion = name?
    If present can we = use hyphen for=20 that?
3..Do we need sesion and media = information "i=3D"=20 line ?
4..Do we need URI ?
5. How to use bandwidth "b=3D" = line?
6. How to use "t=3D" line?
    If present, can we = have a=20 permanent session?
 NOTE :- RFC-3435(MGCP )=20  says
    * The = start time=20 may be set to zero.
   * The stop time should be set to=20 zero.

7. .Do we need attributes
       =20     a) a=3Dcat:<category>
       =20     b) a=3Dkeywds:<keywords>
       =20     c) a=3Dtool:<name & version of = tool>?
8. Aren't "recvonly", "senrecv", = "sendonlly" are=20 redundant in
    Megaco?
9. How to use "a=3Dtype:<conference = type>" in=20 Megaco?
10 How to use attributes "a=3Dsdplang" = & "a=3Dlang"=20 in Megaco?
 
Thanks and regards
Abhishek = Bansal
------=_NextPart_000_0018_01C2EA43.3B75CEC0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Mar 14 08:11: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 IAA24426 for ; Fri, 14 Mar 2003 08:11:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EDQAM09678 for megaco-archive@odin.ietf.org; Fri, 14 Mar 2003 08:26: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 h2EDQAO09675 for ; Fri, 14 Mar 2003 08:26: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 IAA24405 for ; Fri, 14 Mar 2003 08:10: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 h2EDMsO09497; Fri, 14 Mar 2003 08:22: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 h2EAgaO32214 for ; Fri, 14 Mar 2003 05:42:36 -0500 Received: from hfclrnd (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21149 for ; Fri, 14 Mar 2003 05:27:09 -0500 (EST) Received: (from root@localhost) by hfclrnd (8.11.6/8.11.2) id h2E9cep23264; Fri, 14 Mar 2003 15:08:40 +0530 Received: from abhishek ([132.147.166.26]) by hfclrnd (8.11.6/8.11.2) with SMTP id h2E9cdN23256; Fri, 14 Mar 2003 15:08:39 +0530 Message-ID: <001b01c2ea15$21d31690$1aa69384@abhishek> From: "Abhi" To: Cc: Date: Fri, 14 Mar 2003 16:03:20 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C2EA43.3B75CEC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Xmilter: rnd.hfcl.com X-Virus-Scanned: by AMaViS perl-11 Subject: [Megaco] query regarding the use of SDP Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_0018_01C2EA43.3B75CEC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, As we know SDP is used to ecode and decode local and remote descriptor. = I have certain doubts about some SDP paramters. They are as follows:- 1. Do we reqire "o=3D" line in megaco? if present then a. Can we set username to hypen ("-")? b. Can NTP timestamp be used for session id and=20 version? 2.Do we need sesion name? If present can we use hyphen for that? 3..Do we need sesion and media information "i=3D" line ? 4..Do we need URI ? 5. How to use bandwidth "b=3D" line? 6. How to use "t=3D" line? If present, can we have a permanent session? NOTE :- RFC-3435(MGCP ) says * The start time may be set to zero. * The stop time should be set to zero. 7. .Do we need attributes a) a=3Dcat: b) a=3Dkeywds: c) a=3Dtool:? 8. Aren't "recvonly", "senrecv", "sendonlly" are redundant in=20 Megaco? 9. How to use "a=3Dtype:" in Megaco? 10 How to use attributes "a=3Dsdplang" & "a=3Dlang" in Megaco? Thanks and regards Abhishek Bansal ------=_NextPart_000_0018_01C2EA43.3B75CEC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
As we know SDP is used to ecode and = decode local=20 and remote descriptor. I have certain doubts about some SDP paramters.=20 They  are as follows:-
1. Do we reqire "o=3D" line in = megaco?
    if present = then
    a. Can we set = username to hypen=20 ("-")?
    b. Can NTP timestamp = be used for session id and 
      =20  version?
 2.Do we need sesion = name?
    If present can we = use hyphen for=20 that?
3..Do we need sesion and media = information "i=3D"=20 line ?
4..Do we need URI ?
5. How to use bandwidth "b=3D" = line?
6. How to use "t=3D" line?
    If present, can we = have a=20 permanent session?
 NOTE :- RFC-3435(MGCP )=20  says
    * The = start time=20 may be set to zero.
   * The stop time should be set to=20 zero.

7. .Do we need attributes
       =20     a) a=3Dcat:<category>
       =20     b) a=3Dkeywds:<keywords>
       =20     c) a=3Dtool:<name & version of = tool>?
8. Aren't "recvonly", "senrecv", = "sendonlly" are=20 redundant in
    Megaco?
9. How to use "a=3Dtype:<conference = type>" in=20 Megaco?
10 How to use attributes "a=3Dsdplang" = & "a=3Dlang"=20 in Megaco?
 
Thanks and regards
Abhishek = Bansal
------=_NextPart_000_0018_01C2EA43.3B75CEC0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Mar 14 08:31: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 IAA24825 for ; Fri, 14 Mar 2003 08:31: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 h2EDk9O11143; Fri, 14 Mar 2003 08:46: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 h2EDjZO11118 for ; Fri, 14 Mar 2003 08:45:35 -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 IAA24757 for ; Fri, 14 Mar 2003 08:30:07 -0500 (EST) Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Mar 2003 08:27:37 -0500 Message-ID: From: Carl Rutter To: "'Abhi'" , megaco@ietf.org Cc: milton@hfcl.com Subject: RE: [Megaco] query regarding the use of SDP Date: Fri, 14 Mar 2003 08:27:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EA2D.77FDC886" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2EA2D.77FDC886 Content-Type: text/plain; charset="iso-8859-1" I'll take a stab at a few of these: FYI, In general per RFC2327 "Some lines in each description are required and some are optional but all must appear in exactly the order given here (the fixed order greatly enhances error detection and allows for a simple parser). Optional items are marked with a `*'." So the ones with the * are optional ie) i=* (media title) Also ignore what you don't understand: * "SDP parsers must completely ignore any announcement that contains a `type' letter that it does not understand." * "A session directory must ignore any attribute it doesn't understand." 1) Per section 7.1.8 RFC3015 * the "s=", "t=" and "o=" lines are optional, 2) * the "s=", "t=" and "o=" lines are optional, 3) Can be omitted, seems to be encouraged, never used it. 5) RFC2327 page 12 Carl -----Original Message----- From: Abhi [mailto:abhishek@hfcl.com] Sent: Friday, March 14, 2003 5:33 AM To: megaco@ietf.org Cc: milton@hfcl.com Subject: [Megaco] query regarding the use of SDP Hi, As we know SDP is used to ecode and decode local and remote descriptor. I have certain doubts about some SDP paramters. They are as follows:- 1. Do we reqire "o=" line in megaco? if present then a. Can we set username to hypen ("-")? b. Can NTP timestamp be used for session id and version? 2.Do we need sesion name? If present can we use hyphen for that? 3..Do we need sesion and media information "i=" line ? 4..Do we need URI ? 5. How to use bandwidth "b=" line? 6. How to use "t=" line? If present, can we have a permanent session? NOTE :- RFC-3435(MGCP ) says * The start time may be set to zero. * The stop time should be set to zero. 7. .Do we need attributes a) a=cat: b) a=keywds: c) a=tool:? 8. Aren't "recvonly", "senrecv", "sendonlly" are redundant in Megaco? 9. How to use "a=type:" in Megaco? 10 How to use attributes "a=sdplang" & "a=lang" in Megaco? Thanks and regards Abhishek Bansal ------_=_NextPart_001_01C2EA2D.77FDC886 Content-Type: text/html; charset="iso-8859-1"
I'll take a stab at a few of these:
 
FYI, In general per RFC2327
"Some lines in each description are required and some
   are optional but all must appear in exactly the order given here (the
   fixed order greatly enhances error detection and allows for a simple
   parser). Optional items are marked with a `*'."
   So the ones with the * are optional
ie) i=* (media title)
Also ignore what you don't understand:
* "SDP parsers must completely ignore any announcement
   that contains a `type' letter that it does not understand."
* "A session directory must ignore any
   attribute it doesn't understand."
 
 
1) Per section 7.1.8 RFC3015
   *  the "s=", "t=" and "o=" lines are optional,
2)
   *  the "s=", "t=" and "o=" lines are optional,
3) Can be omitted, seems to be encouraged, never used it.
5) RFC2327 page 12
 
 
Carl
 
-----Original Message-----
From: Abhi [mailto:abhishek@hfcl.com]
Sent: Friday, March 14, 2003 5:33 AM
To: megaco@ietf.org
Cc: milton@hfcl.com
Subject: [Megaco] query regarding the use of SDP

Hi,
As we know SDP is used to ecode and decode local and remote descriptor. I have certain doubts about some SDP paramters. They  are as follows:-
1. Do we reqire "o=" line in megaco?
    if present then
    a. Can we set username to hypen ("-")?
    b. Can NTP timestamp be used for session id and 
        version?
 2.Do we need sesion name?
    If present can we use hyphen for that?
3..Do we need sesion and media information "i=" line ?
4..Do we need URI ?
5. How to use bandwidth "b=" line?
6. How to use "t=" line?
    If present, can we have a permanent session?
 NOTE :- RFC-3435(MGCP )  says
    * The start time may be set to zero.
   * The stop time should be set to zero.

7. .Do we need attributes
            a) a=cat:<category>
            b) a=keywds:<keywords>
            c) a=tool:<name & version of tool>?
8. Aren't "recvonly", "senrecv", "sendonlly" are redundant in
    Megaco?
9. How to use "a=type:<conference type>" in Megaco?
10 How to use attributes "a=sdplang" & "a=lang" in Megaco?
 
Thanks and regards
Abhishek Bansal
------_=_NextPart_001_01C2EA2D.77FDC886-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Mar 14 08:32: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 IAA24906 for ; Fri, 14 Mar 2003 08:32:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EDlsc11294 for megaco-archive@odin.ietf.org; Fri, 14 Mar 2003 08:47: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 h2EDlsO11291 for ; Fri, 14 Mar 2003 08:47:54 -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 IAA24875 for ; Fri, 14 Mar 2003 08:32: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 h2EDk9O11143; Fri, 14 Mar 2003 08:46: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 h2EDjZO11118 for ; Fri, 14 Mar 2003 08:45:35 -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 IAA24757 for ; Fri, 14 Mar 2003 08:30:07 -0500 (EST) Received: by wench.telica.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Mar 2003 08:27:37 -0500 Message-ID: From: Carl Rutter To: "'Abhi'" , megaco@ietf.org Cc: milton@hfcl.com Subject: RE: [Megaco] query regarding the use of SDP Date: Fri, 14 Mar 2003 08:27:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EA2D.77FDC886" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2EA2D.77FDC886 Content-Type: text/plain; charset="iso-8859-1" I'll take a stab at a few of these: FYI, In general per RFC2327 "Some lines in each description are required and some are optional but all must appear in exactly the order given here (the fixed order greatly enhances error detection and allows for a simple parser). Optional items are marked with a `*'." So the ones with the * are optional ie) i=* (media title) Also ignore what you don't understand: * "SDP parsers must completely ignore any announcement that contains a `type' letter that it does not understand." * "A session directory must ignore any attribute it doesn't understand." 1) Per section 7.1.8 RFC3015 * the "s=", "t=" and "o=" lines are optional, 2) * the "s=", "t=" and "o=" lines are optional, 3) Can be omitted, seems to be encouraged, never used it. 5) RFC2327 page 12 Carl -----Original Message----- From: Abhi [mailto:abhishek@hfcl.com] Sent: Friday, March 14, 2003 5:33 AM To: megaco@ietf.org Cc: milton@hfcl.com Subject: [Megaco] query regarding the use of SDP Hi, As we know SDP is used to ecode and decode local and remote descriptor. I have certain doubts about some SDP paramters. They are as follows:- 1. Do we reqire "o=" line in megaco? if present then a. Can we set username to hypen ("-")? b. Can NTP timestamp be used for session id and version? 2.Do we need sesion name? If present can we use hyphen for that? 3..Do we need sesion and media information "i=" line ? 4..Do we need URI ? 5. How to use bandwidth "b=" line? 6. How to use "t=" line? If present, can we have a permanent session? NOTE :- RFC-3435(MGCP ) says * The start time may be set to zero. * The stop time should be set to zero. 7. .Do we need attributes a) a=cat: b) a=keywds: c) a=tool:? 8. Aren't "recvonly", "senrecv", "sendonlly" are redundant in Megaco? 9. How to use "a=type:" in Megaco? 10 How to use attributes "a=sdplang" & "a=lang" in Megaco? Thanks and regards Abhishek Bansal ------_=_NextPart_001_01C2EA2D.77FDC886 Content-Type: text/html; charset="iso-8859-1"
I'll take a stab at a few of these:
 
FYI, In general per RFC2327
"Some lines in each description are required and some
   are optional but all must appear in exactly the order given here (the
   fixed order greatly enhances error detection and allows for a simple
   parser). Optional items are marked with a `*'."
   So the ones with the * are optional
ie) i=* (media title)
Also ignore what you don't understand:
* "SDP parsers must completely ignore any announcement
   that contains a `type' letter that it does not understand."
* "A session directory must ignore any
   attribute it doesn't understand."
 
 
1) Per section 7.1.8 RFC3015
   *  the "s=", "t=" and "o=" lines are optional,
2)
   *  the "s=", "t=" and "o=" lines are optional,
3) Can be omitted, seems to be encouraged, never used it.
5) RFC2327 page 12
 
 
Carl
 
-----Original Message-----
From: Abhi [mailto:abhishek@hfcl.com]
Sent: Friday, March 14, 2003 5:33 AM
To: megaco@ietf.org
Cc: milton@hfcl.com
Subject: [Megaco] query regarding the use of SDP

Hi,
As we know SDP is used to ecode and decode local and remote descriptor. I have certain doubts about some SDP paramters. They  are as follows:-
1. Do we reqire "o=" line in megaco?
    if present then
    a. Can we set username to hypen ("-")?
    b. Can NTP timestamp be used for session id and 
        version?
 2.Do we need sesion name?
    If present can we use hyphen for that?
3..Do we need sesion and media information "i=" line ?
4..Do we need URI ?
5. How to use bandwidth "b=" line?
6. How to use "t=" line?
    If present, can we have a permanent session?
 NOTE :- RFC-3435(MGCP )  says
    * The start time may be set to zero.
   * The stop time should be set to zero.

7. .Do we need attributes
            a) a=cat:<category>
            b) a=keywds:<keywords>
            c) a=tool:<name & version of tool>?
8. Aren't "recvonly", "senrecv", "sendonlly" are redundant in
    Megaco?
9. How to use "a=type:<conference type>" in Megaco?
10 How to use attributes "a=sdplang" & "a=lang" in Megaco?
 
Thanks and regards
Abhishek Bansal
------_=_NextPart_001_01C2EA2D.77FDC886-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Mar 14 09:31: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 JAA26142 for ; Fri, 14 Mar 2003 09:31: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 h2EEjgO14544; Fri, 14 Mar 2003 09:45: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 h2EEhpO14447 for ; Fri, 14 Mar 2003 09:43:51 -0500 Received: from zcars0m9.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26010 for ; Fri, 14 Mar 2003 09:28:22 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2EEUJV00674; Fri, 14 Mar 2003 09:30:19 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GDF4XD17; Fri, 14 Mar 2003 09:30:19 -0500 Received: from nortelnetworks.com (acart1fn.ca.nortel.com [47.129.129.163]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G7ZYWFL5; Fri, 14 Mar 2003 09:30:19 -0500 Message-ID: <3E71E77A.1080700@nortelnetworks.com> Date: Fri, 14 Mar 2003 09:30:18 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: klaha@hss.hns.com CC: gsachin@hss.hns.com, Megaco List Subject: Re: [Megaco] Service change Restart References: <65256CE9.0021A31A.00@dlfmail1.hss.hns.com> In-Reply-To: <65256CE9.0021A31A.00@dlfmail1.hss.hns.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This is where the RFC is completely inadequate as it stands. I wouldn't mind seeing it rewritten to specify separately what happens for ServiceChange on ROOT vs. ServiceChange on individual terminations. With regard to the latter, there is also something else I'd like to see ironed out: the service state is a writable property in TerminationState, yet it is manipulated by ServiceChange. One or the other of these should go. I am quite prepared to submit a proposal for new text for section 7.2.8 in particular. Would there be interest in reviewing such a proposal? We could submit it as a contribution into SG 16's May meeting if that is workable. klaha@hss.hns.com wrote: > > How about ServiceChange Restart on ROOT from MGC?Does the protocol inhibit it? > (It can be an easier means for the MGC to inform MG to delete all contexts > rather than 'Subtract'ing each of them, when MGC is taken gracefully > out-of-service) > > > > > > Tom Taylor on 03/14/2003 12:27:35 AM > > To: Sachin Gupta-PNGN/HSS@HSS, Megaco List > cc: (bcc: Kushanava Laha/HSS) > > Subject: Re: [Megaco] Service change Restart > > > > I agree that it's very difficult to assign any real meaning to an MGC-initiated > restart of a termination. My background in switch software development tells me > that a restart clears certain aspects of state. However, that makes little > sense in > the Megaco case, because the MGC can do that directly by subtracting the > termination > from any context it is in and resetting descriptors if it is not in a context. > > Conclusion: the only thing an MGC-initiated restart of a termination does is > change > its state to in-service if it is not already there. > > gsachin@hss.hns.com wrote: > >>Hi List >>I have a query regarding the processing of Service Change Restart. >>consider the following scenario: >> >>Termination is in state InService. >>Command recieved from MGC to Restart the termination (with or wothout delay). >> >>what MG could possibly do in this case? >> >> >>Thanks >>Sachin Gupta >> > > [disclaimer snipped] > > _______________________________________________ > 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 Mar 14 09:32: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 JAA26172 for ; Fri, 14 Mar 2003 09:32:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EElgA14633 for megaco-archive@odin.ietf.org; Fri, 14 Mar 2003 09:47: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 h2EElgO14630 for ; Fri, 14 Mar 2003 09:47: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 JAA26168 for ; Fri, 14 Mar 2003 09:32: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 h2EEjgO14544; Fri, 14 Mar 2003 09:45: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 h2EEhpO14447 for ; Fri, 14 Mar 2003 09:43:51 -0500 Received: from zcars0m9.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26010 for ; Fri, 14 Mar 2003 09:28:22 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2EEUJV00674; Fri, 14 Mar 2003 09:30:19 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GDF4XD17; Fri, 14 Mar 2003 09:30:19 -0500 Received: from nortelnetworks.com (acart1fn.ca.nortel.com [47.129.129.163]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G7ZYWFL5; Fri, 14 Mar 2003 09:30:19 -0500 Message-ID: <3E71E77A.1080700@nortelnetworks.com> Date: Fri, 14 Mar 2003 09:30:18 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: klaha@hss.hns.com CC: gsachin@hss.hns.com, Megaco List Subject: Re: [Megaco] Service change Restart References: <65256CE9.0021A31A.00@dlfmail1.hss.hns.com> In-Reply-To: <65256CE9.0021A31A.00@dlfmail1.hss.hns.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is where the RFC is completely inadequate as it stands. I wouldn't mind seeing it rewritten to specify separately what happens for ServiceChange on ROOT vs. ServiceChange on individual terminations. With regard to the latter, there is also something else I'd like to see ironed out: the service state is a writable property in TerminationState, yet it is manipulated by ServiceChange. One or the other of these should go. I am quite prepared to submit a proposal for new text for section 7.2.8 in particular. Would there be interest in reviewing such a proposal? We could submit it as a contribution into SG 16's May meeting if that is workable. klaha@hss.hns.com wrote: > > How about ServiceChange Restart on ROOT from MGC?Does the protocol inhibit it? > (It can be an easier means for the MGC to inform MG to delete all contexts > rather than 'Subtract'ing each of them, when MGC is taken gracefully > out-of-service) > > > > > > Tom Taylor on 03/14/2003 12:27:35 AM > > To: Sachin Gupta-PNGN/HSS@HSS, Megaco List > cc: (bcc: Kushanava Laha/HSS) > > Subject: Re: [Megaco] Service change Restart > > > > I agree that it's very difficult to assign any real meaning to an MGC-initiated > restart of a termination. My background in switch software development tells me > that a restart clears certain aspects of state. However, that makes little > sense in > the Megaco case, because the MGC can do that directly by subtracting the > termination > from any context it is in and resetting descriptors if it is not in a context. > > Conclusion: the only thing an MGC-initiated restart of a termination does is > change > its state to in-service if it is not already there. > > gsachin@hss.hns.com wrote: > >>Hi List >>I have a query regarding the processing of Service Change Restart. >>consider the following scenario: >> >>Termination is in state InService. >>Command recieved from MGC to Restart the termination (with or wothout delay). >> >>what MG could possibly do in this case? >> >> >>Thanks >>Sachin Gupta >> > > [disclaimer snipped] > > _______________________________________________ > 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 Mar 14 09:35: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 JAA26262 for ; Fri, 14 Mar 2003 09:35:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EEo4O14773; Fri, 14 Mar 2003 09:50: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 h2EEnJO14720 for ; Fri, 14 Mar 2003 09:49:19 -0500 Received: from bos-exch01.winphoria.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26226 for ; Fri, 14 Mar 2003 09:33:50 -0500 (EST) Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 14 Mar 2003 09:35:58 -0500 Message-Id: <5.2.0.9.0.20030314092840.026c3140@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 14 Mar 2003 09:34:49 -0500 To: Carl Rutter , "'Abhi'" , megaco@ietf.org From: Aleksandr Ryabin Subject: RE: [Megaco] query regarding the use of SDP Cc: milton@hfcl.com In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_309019196==.ALT" X-OriginalArrivalTime: 14 Mar 2003 14:35:59.0137 (UTC) FILETIME=[07991910:01C2EA37] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --=====================_309019196==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Regarding 1 and 2. Per section 7.1.8 RFC3015 "s=", "t=" and "o=" are optional ONLY when SDP "sent from the MGC to the MG" which implies that in other direction (from MG to MGC) it must follow SDP as defined by RFC 2327, which defines them as mandatory. Thanks Aleks At 08:27 AM 3/14/2003, Carl Rutter wrote: >I'll take a stab at a few of these: > >FYI, In general per RFC2327 >"Some lines in each description are required and some > are optional but all must appear in exactly the order given here (the > fixed order greatly enhances error detection and allows for a simple > parser). Optional items are marked with a `*'." > So the ones with the * are optional >ie) i=* (media title) >Also ignore what you don't understand: >* "SDP parsers must completely ignore any announcement > that contains a `type' letter that it does not understand." >* "A session directory must ignore any > attribute it doesn't understand." > > >1) Per section 7.1.8 RFC3015 > * the "s=", "t=" and "o=" lines are optional, >2) > * the "s=", "t=" and "o=" lines are optional, >3) Can be omitted, seems to be encouraged, never used it. >5) RFC2327 page 12 > > >Carl > >-----Original Message----- >From: Abhi [mailto:abhishek@hfcl.com] >Sent: Friday, March 14, 2003 5:33 AM >To: megaco@ietf.org >Cc: milton@hfcl.com >Subject: [Megaco] query regarding the use of SDP > >Hi, >As we know SDP is used to ecode and decode local and remote descriptor. I >have certain doubts about some SDP paramters. They are as follows:- >1. Do we reqire "o=" line in megaco? > if present then > a. Can we set username to hypen ("-")? > b. Can NTP timestamp be used for session id and > version? > 2.Do we need sesion name? > If present can we use hyphen for that? >3..Do we need sesion and media information "i=" line ? >4..Do we need URI ? >5. How to use bandwidth "b=" line? >6. How to use "t=" line? > If present, can we have a permanent session? > NOTE :- RFC-3435(MGCP ) says > * The start time may be set to zero. > * The stop time should be set to zero. > >7. .Do we need attributes > a) a=cat: > b) a=keywds: > c) a=tool:? >8. Aren't "recvonly", "senrecv", "sendonlly" are redundant in > Megaco? >9. How to use "a=type:" in Megaco? >10 How to use attributes "a=sdplang" & "a=lang" in Megaco? > >Thanks and regards >Abhishek Bansal --=====================_309019196==.ALT Content-Type: text/html; charset="us-ascii" Regarding 1 and 2.

Per section 7.1.8 RFC3015 "s=",  "t=" and "o=" are optional
ONLY when SDP "sent from the MGC to the MG" which implies
that in other direction (from MG to MGC) it must follow SDP
as defined by RFC 2327, which defines them as mandatory.

Thanks
        Aleks

At 08:27 AM 3/14/2003, Carl Rutter wrote:
I'll take a stab at a few of these:
 
FYI, In general per RFC2327
"Some lines in each description are required and some
   are optional but all must appear in exactly the order given here (the
   fixed order greatly enhances error detection and allows for a simple
   parser). Optional items are marked with a `*'."
   So the ones with the * are optional
ie) i=* (media title)
Also ignore what you don't understand:
* "SDP parsers must completely ignore any announcement
   that contains a `type' letter that it does not understand."
* "A session directory must ignore any
   attribute it doesn't understand."
 
 
1) Per section 7.1.8 RFC3015
   *  the "s=", "t=" and "o=" lines are optional,
2)
   *  the "s=", "t=" and "o=" lines are optional,
3) Can be omitted, seems to be encouraged, never used it.
5) RFC2327 page 12
 
 
Carl
 
-----Original Message-----
From: Abhi [mailto:abhishek@hfcl.com]
Sent: Friday, March 14, 2003 5:33 AM
To: megaco@ietf.org
Cc: milton@hfcl.com
Subject: [Megaco] query regarding the use of SDP

Hi,
As we know SDP is used to ecode and decode local and remote descriptor. I have certain doubts about some SDP paramters. They  are as follows:-
1. Do we reqire "o=" line in megaco?
    if present then
    a. Can we set username to hypen ("-")?
    b. Can NTP timestamp be used for session id and
        version?
 2.Do we need sesion name?
    If present can we use hyphen for that?
3..Do we need sesion and media information "i=" line ?
4..Do we need URI ?
5. How to use bandwidth "b=" line?
6. How to use "t=" line?
    If present, can we have a permanent session?
 NOTE :- RFC-3435(MGCP )  says
    * The start time may be set to zero.
   * The stop time should be set to zero.

7. .Do we need attributes
            a) a=cat:<category>
            b) a=keywds:<keywords>
            c) a=tool:<name & version of tool>?
8. Aren't "recvonly", "senrecv", "sendonlly" are redundant in
    Megaco?
9. How to use "a=type:<conference type>" in Megaco?
10 How to use attributes "a=sdplang" & "a=lang" in Megaco?
 
Thanks and regards
Abhishek Bansal
--=====================_309019196==.ALT-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Mar 14 09:36: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 JAA26335 for ; Fri, 14 Mar 2003 09:36:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EEpmg14914 for megaco-archive@odin.ietf.org; Fri, 14 Mar 2003 09:51: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 h2EEpmO14911 for ; Fri, 14 Mar 2003 09:51: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 JAA26299 for ; Fri, 14 Mar 2003 09:36: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 h2EEo4O14773; Fri, 14 Mar 2003 09:50: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 h2EEnJO14720 for ; Fri, 14 Mar 2003 09:49:19 -0500 Received: from bos-exch01.winphoria.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26226 for ; Fri, 14 Mar 2003 09:33:50 -0500 (EST) Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 14 Mar 2003 09:35:58 -0500 Message-Id: <5.2.0.9.0.20030314092840.026c3140@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 14 Mar 2003 09:34:49 -0500 To: Carl Rutter , "'Abhi'" , megaco@ietf.org From: Aleksandr Ryabin Subject: RE: [Megaco] query regarding the use of SDP Cc: milton@hfcl.com In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_309019196==.ALT" X-OriginalArrivalTime: 14 Mar 2003 14:35:59.0137 (UTC) FILETIME=[07991910:01C2EA37] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --=====================_309019196==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Regarding 1 and 2. Per section 7.1.8 RFC3015 "s=", "t=" and "o=" are optional ONLY when SDP "sent from the MGC to the MG" which implies that in other direction (from MG to MGC) it must follow SDP as defined by RFC 2327, which defines them as mandatory. Thanks Aleks At 08:27 AM 3/14/2003, Carl Rutter wrote: >I'll take a stab at a few of these: > >FYI, In general per RFC2327 >"Some lines in each description are required and some > are optional but all must appear in exactly the order given here (the > fixed order greatly enhances error detection and allows for a simple > parser). Optional items are marked with a `*'." > So the ones with the * are optional >ie) i=* (media title) >Also ignore what you don't understand: >* "SDP parsers must completely ignore any announcement > that contains a `type' letter that it does not understand." >* "A session directory must ignore any > attribute it doesn't understand." > > >1) Per section 7.1.8 RFC3015 > * the "s=", "t=" and "o=" lines are optional, >2) > * the "s=", "t=" and "o=" lines are optional, >3) Can be omitted, seems to be encouraged, never used it. >5) RFC2327 page 12 > > >Carl > >-----Original Message----- >From: Abhi [mailto:abhishek@hfcl.com] >Sent: Friday, March 14, 2003 5:33 AM >To: megaco@ietf.org >Cc: milton@hfcl.com >Subject: [Megaco] query regarding the use of SDP > >Hi, >As we know SDP is used to ecode and decode local and remote descriptor. I >have certain doubts about some SDP paramters. They are as follows:- >1. Do we reqire "o=" line in megaco? > if present then > a. Can we set username to hypen ("-")? > b. Can NTP timestamp be used for session id and > version? > 2.Do we need sesion name? > If present can we use hyphen for that? >3..Do we need sesion and media information "i=" line ? >4..Do we need URI ? >5. How to use bandwidth "b=" line? >6. How to use "t=" line? > If present, can we have a permanent session? > NOTE :- RFC-3435(MGCP ) says > * The start time may be set to zero. > * The stop time should be set to zero. > >7. .Do we need attributes > a) a=cat: > b) a=keywds: > c) a=tool:? >8. Aren't "recvonly", "senrecv", "sendonlly" are redundant in > Megaco? >9. How to use "a=type:" in Megaco? >10 How to use attributes "a=sdplang" & "a=lang" in Megaco? > >Thanks and regards >Abhishek Bansal --=====================_309019196==.ALT Content-Type: text/html; charset="us-ascii" Regarding 1 and 2.

Per section 7.1.8 RFC3015 "s=",  "t=" and "o=" are optional
ONLY when SDP "sent from the MGC to the MG" which implies
that in other direction (from MG to MGC) it must follow SDP
as defined by RFC 2327, which defines them as mandatory.

Thanks
        Aleks

At 08:27 AM 3/14/2003, Carl Rutter wrote:
I'll take a stab at a few of these:
 
FYI, In general per RFC2327
"Some lines in each description are required and some
   are optional but all must appear in exactly the order given here (the
   fixed order greatly enhances error detection and allows for a simple
   parser). Optional items are marked with a `*'."
   So the ones with the * are optional
ie) i=* (media title)
Also ignore what you don't understand:
* "SDP parsers must completely ignore any announcement
   that contains a `type' letter that it does not understand."
* "A session directory must ignore any
   attribute it doesn't understand."
 
 
1) Per section 7.1.8 RFC3015
   *  the "s=", "t=" and "o=" lines are optional,
2)
   *  the "s=", "t=" and "o=" lines are optional,
3) Can be omitted, seems to be encouraged, never used it.
5) RFC2327 page 12
 
 
Carl
 
-----Original Message-----
From: Abhi [mailto:abhishek@hfcl.com]
Sent: Friday, March 14, 2003 5:33 AM
To: megaco@ietf.org
Cc: milton@hfcl.com
Subject: [Megaco] query regarding the use of SDP

Hi,
As we know SDP is used to ecode and decode local and remote descriptor. I have certain doubts about some SDP paramters. They  are as follows:-
1. Do we reqire "o=" line in megaco?
    if present then
    a. Can we set username to hypen ("-")?
    b. Can NTP timestamp be used for session id and
        version?
 2.Do we need sesion name?
    If present can we use hyphen for that?
3..Do we need sesion and media information "i=" line ?
4..Do we need URI ?
5. How to use bandwidth "b=" line?
6. How to use "t=" line?
    If present, can we have a permanent session?
 NOTE :- RFC-3435(MGCP )  says
    * The start time may be set to zero.
   * The stop time should be set to zero.

7. .Do we need attributes
            a) a=cat:<category>
            b) a=keywds:<keywords>
            c) a=tool:<name & version of tool>?
8. Aren't "recvonly", "senrecv", "sendonlly" are redundant in
    Megaco?
9. How to use "a=type:<conference type>" in Megaco?
10 How to use attributes "a=sdplang" & "a=lang" in Megaco?
 
Thanks and regards
Abhishek Bansal
--=====================_309019196==.ALT-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Mar 14 09: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 JAA26663 for ; Fri, 14 Mar 2003 09: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 h2EF1EO15281; Fri, 14 Mar 2003 10:01: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 h2EF0XO15248 for ; Fri, 14 Mar 2003 10:00:33 -0500 Received: from bos-exch01.winphoria.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26634 for ; Fri, 14 Mar 2003 09:45:04 -0500 (EST) Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 14 Mar 2003 09:47:14 -0500 Message-Id: <5.2.0.9.0.20030314093456.026b01b8@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 14 Mar 2003 09:47:40 -0500 To: klaha@hss.hns.com, Megaco List From: Aleksandr Ryabin Subject: Re: [Megaco] Service change Restart Cc: Tom Taylor , gsachin@hss.hns.com In-Reply-To: <65256CE9.0021A31A.00@dlfmail1.hss.hns.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 14 Mar 2003 14:47:14.0659 (UTC) FILETIME=[9A3D9330:01C2EA38] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, SC only changes the service state. Taking out of service MGC does not imply MG is taken out of service as well. You can send wildcarded W-Subtract * on Context * which will kill all the active contexts. Cheers. Aleks At 01:17 AM 3/14/2003, klaha@hss.hns.com wrote: >How about ServiceChange Restart on ROOT from MGC?Does the protocol inhibit it? >(It can be an easier means for the MGC to inform MG to delete all contexts >rather than 'Subtract'ing each of them, when MGC is taken gracefully >out-of-service) > > > > > >Tom Taylor on 03/14/2003 12:27:35 AM > >To: Sachin Gupta-PNGN/HSS@HSS, Megaco List >cc: (bcc: Kushanava Laha/HSS) > >Subject: Re: [Megaco] Service change Restart > > > >I agree that it's very difficult to assign any real meaning to an >MGC-initiated >restart of a termination. My background in switch software development >tells me >that a restart clears certain aspects of state. However, that makes little >sense in >the Megaco case, because the MGC can do that directly by subtracting the >termination >from any context it is in and resetting descriptors if it is not in a context. > >Conclusion: the only thing an MGC-initiated restart of a termination does is >change >its state to in-service if it is not already there. > >gsachin@hss.hns.com wrote: > > > > Hi List > > I have a query regarding the processing of Service Change Restart. > > consider the following scenario: > > > > Termination is in state InService. > > Command recieved from MGC to Restart the termination (with or wothout > delay). > > > > what MG could possibly do in this case? > > > > > > Thanks > > Sachin Gupta > > >[disclaimer snipped] > >_______________________________________________ >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 Mar 14 09: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 JAA26689 for ; Fri, 14 Mar 2003 09:48:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EF38t15357 for megaco-archive@odin.ietf.org; Fri, 14 Mar 2003 10:03: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 h2EF38O15354 for ; Fri, 14 Mar 2003 10:03:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26679 for ; Fri, 14 Mar 2003 09:47: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 h2EF1EO15281; Fri, 14 Mar 2003 10:01: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 h2EF0XO15248 for ; Fri, 14 Mar 2003 10:00:33 -0500 Received: from bos-exch01.winphoria.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26634 for ; Fri, 14 Mar 2003 09:45:04 -0500 (EST) Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 14 Mar 2003 09:47:14 -0500 Message-Id: <5.2.0.9.0.20030314093456.026b01b8@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 14 Mar 2003 09:47:40 -0500 To: klaha@hss.hns.com, Megaco List From: Aleksandr Ryabin Subject: Re: [Megaco] Service change Restart Cc: Tom Taylor , gsachin@hss.hns.com In-Reply-To: <65256CE9.0021A31A.00@dlfmail1.hss.hns.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 14 Mar 2003 14:47:14.0659 (UTC) FILETIME=[9A3D9330:01C2EA38] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, SC only changes the service state. Taking out of service MGC does not imply MG is taken out of service as well. You can send wildcarded W-Subtract * on Context * which will kill all the active contexts. Cheers. Aleks At 01:17 AM 3/14/2003, klaha@hss.hns.com wrote: >How about ServiceChange Restart on ROOT from MGC?Does the protocol inhibit it? >(It can be an easier means for the MGC to inform MG to delete all contexts >rather than 'Subtract'ing each of them, when MGC is taken gracefully >out-of-service) > > > > > >Tom Taylor on 03/14/2003 12:27:35 AM > >To: Sachin Gupta-PNGN/HSS@HSS, Megaco List >cc: (bcc: Kushanava Laha/HSS) > >Subject: Re: [Megaco] Service change Restart > > > >I agree that it's very difficult to assign any real meaning to an >MGC-initiated >restart of a termination. My background in switch software development >tells me >that a restart clears certain aspects of state. However, that makes little >sense in >the Megaco case, because the MGC can do that directly by subtracting the >termination >from any context it is in and resetting descriptors if it is not in a context. > >Conclusion: the only thing an MGC-initiated restart of a termination does is >change >its state to in-service if it is not already there. > >gsachin@hss.hns.com wrote: > > > > Hi List > > I have a query regarding the processing of Service Change Restart. > > consider the following scenario: > > > > Termination is in state InService. > > Command recieved from MGC to Restart the termination (with or wothout > delay). > > > > what MG could possibly do in this case? > > > > > > Thanks > > Sachin Gupta > > >[disclaimer snipped] > >_______________________________________________ >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 Mar 14 10:02: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 KAA27046 for ; Fri, 14 Mar 2003 10:02: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 h2EFHIO16631; Fri, 14 Mar 2003 10:17: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 h2EFGiO16577 for ; Fri, 14 Mar 2003 10:16:44 -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 KAA27025 for ; Fri, 14 Mar 2003 10:01:15 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2EF3Ob19678 for ; Fri, 14 Mar 2003 10:03:24 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Mar 2003 10:03:25 -0500 Message-ID: From: "Kevin Boyle" To: "Tom-PT Taylor" , klaha@hss.hns.com Cc: gsachin@hss.hns.com, Megaco List Subject: RE: [Megaco] Service change Restart Date: Fri, 14 Mar 2003 10:03:23 -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 work is ongoing in SG16 as future Annex F. Both of these items are intended to be clarified by the new work. The input documents to the San Jose Rapporteurs' Meeting can be found as AVD-2310, AVD-2311, and AVD-2298 at ftp://standard.pictel.com/avc-site/0302_San/. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Friday, March 14, 2003 9:30 AM To: klaha@hss.hns.com Cc: gsachin@hss.hns.com; Megaco List Subject: Re: [Megaco] Service change Restart This is where the RFC is completely inadequate as it stands. I wouldn't mind seeing it rewritten to specify separately what happens for ServiceChange on ROOT vs. ServiceChange on individual terminations. With regard to the latter, there is also something else I'd like to see ironed out: the service state is a writable property in TerminationState, yet it is manipulated by ServiceChange. One or the other of these should go. I am quite prepared to submit a proposal for new text for section 7.2.8 in particular. Would there be interest in reviewing such a proposal? We could submit it as a contribution into SG 16's May meeting if that is workable. klaha@hss.hns.com wrote: > > How about ServiceChange Restart on ROOT from MGC?Does the protocol > inhibit it? (It can be an easier means for the MGC to inform MG to > delete all contexts rather than 'Subtract'ing each of them, when MGC > is taken gracefully > out-of-service) > > > > > > Tom Taylor on 03/14/2003 12:27:35 AM > > To: Sachin Gupta-PNGN/HSS@HSS, Megaco List > cc: (bcc: Kushanava Laha/HSS) > > Subject: Re: [Megaco] Service change Restart > > > > I agree that it's very difficult to assign any real meaning to an > MGC-initiated restart of a termination. My background in switch > software development tells me that a restart clears certain aspects of > state. However, that makes little sense in the Megaco case, because > the MGC can do that directly by subtracting the termination > from any context it is in and resetting descriptors if it is not in a context. > > Conclusion: the only thing an MGC-initiated restart of a termination > does is change its state to in-service if it is not already there. > > gsachin@hss.hns.com wrote: > >>Hi List >>I have a query regarding the processing of Service Change Restart. >>consider the following scenario: >> >>Termination is in state InService. >>Command recieved from MGC to Restart the termination (with or wothout >>delay). >> >>what MG could possibly do in this case? >> >> >>Thanks >>Sachin Gupta >> > > [disclaimer snipped] > > _______________________________________________ > 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 Mar 14 10:04: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 KAA27155 for ; Fri, 14 Mar 2003 10:04:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EFJ1d16702 for megaco-archive@odin.ietf.org; Fri, 14 Mar 2003 10:19: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 h2EFJ1O16699 for ; Fri, 14 Mar 2003 10:19: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 KAA27101 for ; Fri, 14 Mar 2003 10:03: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 h2EFHIO16631; Fri, 14 Mar 2003 10:17: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 h2EFGiO16577 for ; Fri, 14 Mar 2003 10:16:44 -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 KAA27025 for ; Fri, 14 Mar 2003 10:01:15 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2EF3Ob19678 for ; Fri, 14 Mar 2003 10:03:24 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Mar 2003 10:03:25 -0500 Message-ID: From: "Kevin Boyle" To: "Tom-PT Taylor" , klaha@hss.hns.com Cc: gsachin@hss.hns.com, Megaco List Subject: RE: [Megaco] Service change Restart Date: Fri, 14 Mar 2003 10:03:23 -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 work is ongoing in SG16 as future Annex F. Both of these items are intended to be clarified by the new work. The input documents to the San Jose Rapporteurs' Meeting can be found as AVD-2310, AVD-2311, and AVD-2298 at ftp://standard.pictel.com/avc-site/0302_San/. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Friday, March 14, 2003 9:30 AM To: klaha@hss.hns.com Cc: gsachin@hss.hns.com; Megaco List Subject: Re: [Megaco] Service change Restart This is where the RFC is completely inadequate as it stands. I wouldn't mind seeing it rewritten to specify separately what happens for ServiceChange on ROOT vs. ServiceChange on individual terminations. With regard to the latter, there is also something else I'd like to see ironed out: the service state is a writable property in TerminationState, yet it is manipulated by ServiceChange. One or the other of these should go. I am quite prepared to submit a proposal for new text for section 7.2.8 in particular. Would there be interest in reviewing such a proposal? We could submit it as a contribution into SG 16's May meeting if that is workable. klaha@hss.hns.com wrote: > > How about ServiceChange Restart on ROOT from MGC?Does the protocol > inhibit it? (It can be an easier means for the MGC to inform MG to > delete all contexts rather than 'Subtract'ing each of them, when MGC > is taken gracefully > out-of-service) > > > > > > Tom Taylor on 03/14/2003 12:27:35 AM > > To: Sachin Gupta-PNGN/HSS@HSS, Megaco List > cc: (bcc: Kushanava Laha/HSS) > > Subject: Re: [Megaco] Service change Restart > > > > I agree that it's very difficult to assign any real meaning to an > MGC-initiated restart of a termination. My background in switch > software development tells me that a restart clears certain aspects of > state. However, that makes little sense in the Megaco case, because > the MGC can do that directly by subtracting the termination > from any context it is in and resetting descriptors if it is not in a context. > > Conclusion: the only thing an MGC-initiated restart of a termination > does is change its state to in-service if it is not already there. > > gsachin@hss.hns.com wrote: > >>Hi List >>I have a query regarding the processing of Service Change Restart. >>consider the following scenario: >> >>Termination is in state InService. >>Command recieved from MGC to Restart the termination (with or wothout >>delay). >> >>what MG could possibly do in this case? >> >> >>Thanks >>Sachin Gupta >> > > [disclaimer snipped] > > _______________________________________________ > 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 Mar 14 23:34: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 XAA28323 for ; Fri, 14 Mar 2003 23:34: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 h2F4n8O04588; Fri, 14 Mar 2003 23:49: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 h2F4ldO04551 for ; Fri, 14 Mar 2003 23:47:39 -0500 Received: from hfclrnd (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28267 for ; Fri, 14 Mar 2003 23:31:48 -0500 (EST) Received: (from root@localhost) by hfclrnd (8.11.6/8.11.2) id h2F4Xt616429; Sat, 15 Mar 2003 10:03:55 +0530 Received: from abhishek ([132.147.166.26]) by hfclrnd (8.11.6/8.11.2) with SMTP id h2F4Xsg16421; Sat, 15 Mar 2003 10:03:54 +0530 Message-ID: <002701c2eaac$be0f3f60$1aa69384@abhishek> From: "Abhi" To: "Carl Rutter" , Subject: RE: [Megaco] query regarding the use of SDP Date: Sat, 15 Mar 2003 10:08:36 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01C2EADA.D7B94A90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Xmilter: rnd.hfcl.com X-Virus-Scanned: by AMaViS perl-11 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_0024_01C2EADA.D7B94A90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable regarding 2 and 3 if this is the case then how to use these parameters "s=3D", "t=3D", = "o=3D" in megaco. what are the possible values of different fields thanks and regards Abhishek ------=_NextPart_000_0024_01C2EADA.D7B94A90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
regarding 2 and 3
if this is the case then how to use = these=20 parameters "s=3D", "t=3D", "o=3D" in megaco.
what are the possible values of = different=20 fields
thanks and regards
Abhishek
------=_NextPart_000_0024_01C2EADA.D7B94A90-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Mar 14 23:35: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 XAA28368 for ; Fri, 14 Mar 2003 23:35:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2F4of304686 for megaco-archive@odin.ietf.org; Fri, 14 Mar 2003 23:50: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 h2F4oeO04683 for ; Fri, 14 Mar 2003 23:50: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 XAA28343 for ; Fri, 14 Mar 2003 23:34: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 h2F4n8O04588; Fri, 14 Mar 2003 23:49: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 h2F4ldO04551 for ; Fri, 14 Mar 2003 23:47:39 -0500 Received: from hfclrnd (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28267 for ; Fri, 14 Mar 2003 23:31:48 -0500 (EST) Received: (from root@localhost) by hfclrnd (8.11.6/8.11.2) id h2F4Xt616429; Sat, 15 Mar 2003 10:03:55 +0530 Received: from abhishek ([132.147.166.26]) by hfclrnd (8.11.6/8.11.2) with SMTP id h2F4Xsg16421; Sat, 15 Mar 2003 10:03:54 +0530 Message-ID: <002701c2eaac$be0f3f60$1aa69384@abhishek> From: "Abhi" To: "Carl Rutter" , Subject: RE: [Megaco] query regarding the use of SDP Date: Sat, 15 Mar 2003 10:08:36 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01C2EADA.D7B94A90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Xmilter: rnd.hfcl.com X-Virus-Scanned: by AMaViS perl-11 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_0024_01C2EADA.D7B94A90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable regarding 2 and 3 if this is the case then how to use these parameters "s=3D", "t=3D", = "o=3D" in megaco. what are the possible values of different fields thanks and regards Abhishek ------=_NextPart_000_0024_01C2EADA.D7B94A90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
regarding 2 and 3
if this is the case then how to use = these=20 parameters "s=3D", "t=3D", "o=3D" in megaco.
what are the possible values of = different=20 fields
thanks and regards
Abhishek
------=_NextPart_000_0024_01C2EADA.D7B94A90-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Mar 14 23:39: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 XAA28417 for ; Fri, 14 Mar 2003 23:39: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 h2F4s5O04815; Fri, 14 Mar 2003 23:54: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 h2F4rlO04792 for ; Fri, 14 Mar 2003 23:53:47 -0500 Received: from hfclrnd (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28407 for ; Fri, 14 Mar 2003 23:37:51 -0500 (EST) Received: (from root@localhost) by hfclrnd (8.11.6/8.11.2) id h2F4dEC17027; Sat, 15 Mar 2003 10:09:14 +0530 Received: from abhishek ([132.147.166.26]) by hfclrnd (8.11.6/8.11.2) with SMTP id h2F4dDg17019; Sat, 15 Mar 2003 10:09:13 +0530 Message-ID: <003701c2eaad$7c4120c0$1aa69384@abhishek> From: "Abhi" To: "Aleksandr Ryabin" , "Carl Rutter" , References: <5.2.0.9.0.20030314092840.026c3140@imap.winphoria.com> Subject: Re: [Megaco] query regarding the use of SDP Date: Sat, 15 Mar 2003 10:13:55 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01C2EADB.95EFE6E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Xmilter: rnd.hfcl.com X-Virus-Scanned: by AMaViS perl-11 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_0034_01C2EADB.95EFE6E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: Aleksandr Ryabin=20 To: Carl Rutter ; 'Abhi' ; megaco@ietf.org=20 Cc: milton@hfcl.com=20 Sent: Friday, March 14, 2003 8:04 PM Subject: RE: [Megaco] query regarding the use of SDP Regarding 1 and 2. Per section 7.1.8 RFC3015 "s=3D", "t=3D" and "o=3D" are optional=20 ONLY when SDP "sent from the MGC to the MG" which implies=20 that in other direction (from MG to MGC) it must follow SDP as defined by RFC 2327, which defines them as mandatory.=20 Thanks Aleks At 08:27 AM 3/14/2003, Carl Rutter wrote: I'll take a stab at a few of these: =20 FYI, In general per RFC2327 "Some lines in each description are required and some are optional but all must appear in exactly the order given here = (the fixed order greatly enhances error detection and allows for a = simple parser). Optional items are marked with a `*'." So the ones with the * are optional ie) i=3D* (media title) Also ignore what you don't understand: * "SDP parsers must completely ignore any announcement that contains a `type' letter that it does not understand." * "A session directory must ignore any attribute it doesn't understand." =20 =20 1) Per section 7.1.8 RFC3015 * the "s=3D", "t=3D" and "o=3D" lines are optional, 2)=20 * the "s=3D", "t=3D" and "o=3D" lines are optional, 3) Can be omitted, seems to be encouraged, never used it. 5) RFC2327 page 12 =20 =20 Carl =20 -----Original Message----- From: Abhi [mailto:abhishek@hfcl.com] Sent: Friday, March 14, 2003 5:33 AM To: megaco@ietf.org Cc: milton@hfcl.com Subject: [Megaco] query regarding the use of SDP Hi, As we know SDP is used to ecode and decode local and remote = descriptor. I have certain doubts about some SDP paramters. They are as = follows:- 1. Do we reqire "o=3D" line in megaco? if present then a. Can we set username to hypen ("-")? b. Can NTP timestamp be used for session id and=20 version? 2.Do we need sesion name? If present can we use hyphen for that? 3..Do we need sesion and media information "i=3D" line ? 4..Do we need URI ? 5. How to use bandwidth "b=3D" line? 6. How to use "t=3D" line? If present, can we have a permanent session? NOTE :- RFC-3435(MGCP ) says * The start time may be set to zero. * The stop time should be set to zero. 7. .Do we need attributes a) a=3Dcat: b) a=3Dkeywds: c) a=3Dtool:? 8. Aren't "recvonly", "senrecv", "sendonlly" are redundant in=20 Megaco? 9. How to use "a=3Dtype:" in Megaco? 10 How to use attributes "a=3Dsdplang" & "a=3Dlang" in Megaco? =20 Thanks and regards Abhishek Bansal ------=_NextPart_000_0034_01C2EADB.95EFE6E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
----- Original Message -----
From:=20 Aleksandr=20 Ryabin
Sent: Friday, March 14, 2003 = 8:04=20 PM
Subject: RE: [Megaco] query = regarding the=20 use of SDP

Regarding 1 and 2.

Per section 7.1.8 RFC3015 = "s=3D", =20 "t=3D" and "o=3D" are optional
ONLY when SDP "sent from the MGC to = the MG"=20 which implies
that in other direction (from MG to MGC) it must = follow=20 SDP
as defined by RFC 2327, which defines them as mandatory.=20 =

Thanks
        = Aleks

At=20 08:27 AM 3/14/2003, Carl Rutter wrote:
I'll take a stab at a few of = these:
 
FYI, In general per = RFC2327
"Some lines in each = description are required=20 and some
   are optional but all must appear in exactly = the=20 order given here (the
   fixed order greatly enhances = error=20 detection and allows for a simple
   parser). Optional = items=20 are marked with a `*'."
   So the ones with the * are = optional
ie) i=3D* (media = title)
Also ignore what you don't=20 understand:
* = "SDP parsers=20 must completely ignore any announcement
   that = contains a=20 `type' letter that it does not understand."
* "A session directory must ignore = any
  =20 attribute it doesn't = understand."
 
 
1) Per section 7.1.8 = RFC3015
  =20 *  the "s=3D", "t=3D" and "o=3D" lines are = optional,
2)
   *  = the "s=3D", "t=3D"=20 and "o=3D" lines are optional,
3) Can be omitted, seems to be encouraged, never used=20 it.
5) RFC2327 = page=20 12
 
 
Carl
 
-----Original=20 Message-----
From: Abhi [mailto:abhishek@hfcl.com]
Sent: = Friday, March=20 14, 2003 5:33 AM
To: megaco@ietf.org
Cc:=20 milton@hfcl.com
Subject: [Megaco] query regarding the use = of=20 SDP

Hi,
As we know SDP is used to ecode and decode local and remote = descriptor. I have certain doubts about some SDP paramters. = They  are=20 as follows:-
1. Do we reqire = "o=3D" line in=20 megaco?
    if = present=20 then
    a. Can = we set=20 username to hypen ("-")?
    b. Can NTP timestamp be used for session = id and=20
        = version?
 2.Do we need sesion = name?
    If present can we use hyphen for=20 that?
3..Do we need sesion and = media=20 information "i=3D" line ?
4..Do we need URI=20 ?
5. How to use bandwidth = "b=3D"=20 line?
6. How to use "t=3D"=20 line?
    If = present, can=20 we have a permanent session?
 NOTE :-=20 RFC-3435(MGCP )  says
    * The start = time may be=20 set to zero.
   * The stop time should be set to=20 zero.

7. .Do we need=20 attributes
          &nbs= p; a)=20 a=3Dcat:<category>
          &nbs= p; b)=20 a=3Dkeywds:<keywords>
          &nbs= p; c)=20 a=3Dtool:<name & version of tool>?
8. Aren't "recvonly", "senrecv", "sendonlly" are redundant = in=20
   =20 Megaco?
9. How to use=20 "a=3Dtype:<conference type>" in Megaco?
10 How to use attributes "a=3Dsdplang" & "a=3Dlang" in=20 Megaco?
 
Thanks and=20 regards
Abhishek=20 Bansal
------=_NextPart_000_0034_01C2EADB.95EFE6E0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Mar 14 23:40: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 XAA28442 for ; Fri, 14 Mar 2003 23:40:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2F4te904870 for megaco-archive@odin.ietf.org; Fri, 14 Mar 2003 23: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 h2F4teO04867 for ; Fri, 14 Mar 2003 23: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 XAA28437 for ; Fri, 14 Mar 2003 23:39: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 h2F4s5O04815; Fri, 14 Mar 2003 23:54: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 h2F4rlO04792 for ; Fri, 14 Mar 2003 23:53:47 -0500 Received: from hfclrnd (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28407 for ; Fri, 14 Mar 2003 23:37:51 -0500 (EST) Received: (from root@localhost) by hfclrnd (8.11.6/8.11.2) id h2F4dEC17027; Sat, 15 Mar 2003 10:09:14 +0530 Received: from abhishek ([132.147.166.26]) by hfclrnd (8.11.6/8.11.2) with SMTP id h2F4dDg17019; Sat, 15 Mar 2003 10:09:13 +0530 Message-ID: <003701c2eaad$7c4120c0$1aa69384@abhishek> From: "Abhi" To: "Aleksandr Ryabin" , "Carl Rutter" , References: <5.2.0.9.0.20030314092840.026c3140@imap.winphoria.com> Subject: Re: [Megaco] query regarding the use of SDP Date: Sat, 15 Mar 2003 10:13:55 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01C2EADB.95EFE6E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Xmilter: rnd.hfcl.com X-Virus-Scanned: by AMaViS perl-11 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_0034_01C2EADB.95EFE6E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: Aleksandr Ryabin=20 To: Carl Rutter ; 'Abhi' ; megaco@ietf.org=20 Cc: milton@hfcl.com=20 Sent: Friday, March 14, 2003 8:04 PM Subject: RE: [Megaco] query regarding the use of SDP Regarding 1 and 2. Per section 7.1.8 RFC3015 "s=3D", "t=3D" and "o=3D" are optional=20 ONLY when SDP "sent from the MGC to the MG" which implies=20 that in other direction (from MG to MGC) it must follow SDP as defined by RFC 2327, which defines them as mandatory.=20 Thanks Aleks At 08:27 AM 3/14/2003, Carl Rutter wrote: I'll take a stab at a few of these: =20 FYI, In general per RFC2327 "Some lines in each description are required and some are optional but all must appear in exactly the order given here = (the fixed order greatly enhances error detection and allows for a = simple parser). Optional items are marked with a `*'." So the ones with the * are optional ie) i=3D* (media title) Also ignore what you don't understand: * "SDP parsers must completely ignore any announcement that contains a `type' letter that it does not understand." * "A session directory must ignore any attribute it doesn't understand." =20 =20 1) Per section 7.1.8 RFC3015 * the "s=3D", "t=3D" and "o=3D" lines are optional, 2)=20 * the "s=3D", "t=3D" and "o=3D" lines are optional, 3) Can be omitted, seems to be encouraged, never used it. 5) RFC2327 page 12 =20 =20 Carl =20 -----Original Message----- From: Abhi [mailto:abhishek@hfcl.com] Sent: Friday, March 14, 2003 5:33 AM To: megaco@ietf.org Cc: milton@hfcl.com Subject: [Megaco] query regarding the use of SDP Hi, As we know SDP is used to ecode and decode local and remote = descriptor. I have certain doubts about some SDP paramters. They are as = follows:- 1. Do we reqire "o=3D" line in megaco? if present then a. Can we set username to hypen ("-")? b. Can NTP timestamp be used for session id and=20 version? 2.Do we need sesion name? If present can we use hyphen for that? 3..Do we need sesion and media information "i=3D" line ? 4..Do we need URI ? 5. How to use bandwidth "b=3D" line? 6. How to use "t=3D" line? If present, can we have a permanent session? NOTE :- RFC-3435(MGCP ) says * The start time may be set to zero. * The stop time should be set to zero. 7. .Do we need attributes a) a=3Dcat: b) a=3Dkeywds: c) a=3Dtool:? 8. Aren't "recvonly", "senrecv", "sendonlly" are redundant in=20 Megaco? 9. How to use "a=3Dtype:" in Megaco? 10 How to use attributes "a=3Dsdplang" & "a=3Dlang" in Megaco? =20 Thanks and regards Abhishek Bansal ------=_NextPart_000_0034_01C2EADB.95EFE6E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
----- Original Message -----
From:=20 Aleksandr=20 Ryabin
Sent: Friday, March 14, 2003 = 8:04=20 PM
Subject: RE: [Megaco] query = regarding the=20 use of SDP

Regarding 1 and 2.

Per section 7.1.8 RFC3015 = "s=3D", =20 "t=3D" and "o=3D" are optional
ONLY when SDP "sent from the MGC to = the MG"=20 which implies
that in other direction (from MG to MGC) it must = follow=20 SDP
as defined by RFC 2327, which defines them as mandatory.=20 =

Thanks
        = Aleks

At=20 08:27 AM 3/14/2003, Carl Rutter wrote:
I'll take a stab at a few of = these:
 
FYI, In general per = RFC2327
"Some lines in each = description are required=20 and some
   are optional but all must appear in exactly = the=20 order given here (the
   fixed order greatly enhances = error=20 detection and allows for a simple
   parser). Optional = items=20 are marked with a `*'."
   So the ones with the * are = optional
ie) i=3D* (media = title)
Also ignore what you don't=20 understand:
* = "SDP parsers=20 must completely ignore any announcement
   that = contains a=20 `type' letter that it does not understand."
* "A session directory must ignore = any
  =20 attribute it doesn't = understand."
 
 
1) Per section 7.1.8 = RFC3015
  =20 *  the "s=3D", "t=3D" and "o=3D" lines are = optional,
2)
   *  = the "s=3D", "t=3D"=20 and "o=3D" lines are optional,
3) Can be omitted, seems to be encouraged, never used=20 it.
5) RFC2327 = page=20 12
 
 
Carl
 
-----Original=20 Message-----
From: Abhi [mailto:abhishek@hfcl.com]
Sent: = Friday, March=20 14, 2003 5:33 AM
To: megaco@ietf.org
Cc:=20 milton@hfcl.com
Subject: [Megaco] query regarding the use = of=20 SDP

Hi,
As we know SDP is used to ecode and decode local and remote = descriptor. I have certain doubts about some SDP paramters. = They  are=20 as follows:-
1. Do we reqire = "o=3D" line in=20 megaco?
    if = present=20 then
    a. Can = we set=20 username to hypen ("-")?
    b. Can NTP timestamp be used for session = id and=20
        = version?
 2.Do we need sesion = name?
    If present can we use hyphen for=20 that?
3..Do we need sesion and = media=20 information "i=3D" line ?
4..Do we need URI=20 ?
5. How to use bandwidth = "b=3D"=20 line?
6. How to use "t=3D"=20 line?
    If = present, can=20 we have a permanent session?
 NOTE :-=20 RFC-3435(MGCP )  says
    * The start = time may be=20 set to zero.
   * The stop time should be set to=20 zero.

7. .Do we need=20 attributes
          &nbs= p; a)=20 a=3Dcat:<category>
          &nbs= p; b)=20 a=3Dkeywds:<keywords>
          &nbs= p; c)=20 a=3Dtool:<name & version of tool>?
8. Aren't "recvonly", "senrecv", "sendonlly" are redundant = in=20
   =20 Megaco?
9. How to use=20 "a=3Dtype:<conference type>" in Megaco?
10 How to use attributes "a=3Dsdplang" & "a=3Dlang" in=20 Megaco?
 
Thanks and=20 regards
Abhishek=20 Bansal
------=_NextPart_000_0034_01C2EADB.95EFE6E0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Mar 14 23:47:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28593 for ; Fri, 14 Mar 2003 23:47:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F4x4O04953; Fri, 14 Mar 2003 23:59: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 h2F4w3O04919 for ; Fri, 14 Mar 2003 23:58:03 -0500 Received: from hfclrnd (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28485 for ; Fri, 14 Mar 2003 23:42:01 -0500 (EST) Received: (from root@localhost) by hfclrnd (8.11.6/8.11.2) id h2F4hAr17624; Sat, 15 Mar 2003 10:13:10 +0530 Received: from abhishek ([132.147.166.26]) by hfclrnd (8.11.6/8.11.2) with SMTP id h2F4h9g17616; Sat, 15 Mar 2003 10:13:09 +0530 Message-ID: <004f01c2eaae$08bc4340$1aa69384@abhishek> From: "Abhi" To: "Aleksandr Ryabin" , "Carl Rutter" , References: <5.2.0.9.0.20030314092840.026c3140@imap.winphoria.com> Subject: Re: [Megaco] query regarding the use of SDP Date: Sat, 15 Mar 2003 10:17:51 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01C2EADC.22689860" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Xmilter: rnd.hfcl.com X-Virus-Scanned: by AMaViS perl-11 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_004C_01C2EADC.22689860 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable regarding 2 and 3 if this is the case then how to use these parameters "s=3D", "t=3D", = "o=3D" in megaco. what are the possible values of different fields thanks and regards Abhishek ----- Original Message -----=20 From: Aleksandr Ryabin=20 To: Carl Rutter ; 'Abhi' ; megaco@ietf.org=20 Cc: milton@hfcl.com=20 Sent: Friday, March 14, 2003 8:04 PM Subject: RE: [Megaco] query regarding the use of SDP Regarding 1 and 2. Per section 7.1.8 RFC3015 "s=3D", "t=3D" and "o=3D" are optional=20 ONLY when SDP "sent from the MGC to the MG" which implies=20 that in other direction (from MG to MGC) it must follow SDP as defined by RFC 2327, which defines them as mandatory.=20 Thanks Aleks At 08:27 AM 3/14/2003, Carl Rutter wrote: I'll take a stab at a few of these: =20 FYI, In general per RFC2327 "Some lines in each description are required and some are optional but all must appear in exactly the order given here = (the fixed order greatly enhances error detection and allows for a = simple parser). Optional items are marked with a `*'." So the ones with the * are optional ie) i=3D* (media title) Also ignore what you don't understand: * "SDP parsers must completely ignore any announcement that contains a `type' letter that it does not understand." * "A session directory must ignore any attribute it doesn't understand." =20 =20 1) Per section 7.1.8 RFC3015 * the "s=3D", "t=3D" and "o=3D" lines are optional, 2)=20 * the "s=3D", "t=3D" and "o=3D" lines are optional, 3) Can be omitted, seems to be encouraged, never used it. 5) RFC2327 page 12 =20 =20 Carl =20 -----Original Message----- From: Abhi [mailto:abhishek@hfcl.com] Sent: Friday, March 14, 2003 5:33 AM To: megaco@ietf.org Cc: milton@hfcl.com Subject: [Megaco] query regarding the use of SDP Hi, As we know SDP is used to ecode and decode local and remote = descriptor. I have certain doubts about some SDP paramters. They are as = follows:- 1. Do we reqire "o=3D" line in megaco? if present then a. Can we set username to hypen ("-")? b. Can NTP timestamp be used for session id and=20 version? 2.Do we need sesion name? If present can we use hyphen for that? 3..Do we need sesion and media information "i=3D" line ? 4..Do we need URI ? 5. How to use bandwidth "b=3D" line? 6. How to use "t=3D" line? If present, can we have a permanent session? NOTE :- RFC-3435(MGCP ) says * The start time may be set to zero. * The stop time should be set to zero. 7. .Do we need attributes a) a=3Dcat: b) a=3Dkeywds: c) a=3Dtool:? 8. Aren't "recvonly", "senrecv", "sendonlly" are redundant in=20 Megaco? 9. How to use "a=3Dtype:" in Megaco? 10 How to use attributes "a=3Dsdplang" & "a=3Dlang" in Megaco? =20 Thanks and regards Abhishek Bansal ------=_NextPart_000_004C_01C2EADC.22689860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
regarding 2 and 3
if this is the case then how to use = these=20 parameters "s=3D", "t=3D", "o=3D" in megaco.
what are the possible values of = different=20 fields
thanks and regards
Abhishek
----- Original Message -----
From:=20 Aleksandr=20 Ryabin
Sent: Friday, March 14, 2003 = 8:04=20 PM
Subject: RE: [Megaco] query = regarding the=20 use of SDP

Regarding 1 and 2.

Per section 7.1.8 RFC3015 = "s=3D", =20 "t=3D" and "o=3D" are optional
ONLY when SDP "sent from the MGC to = the MG"=20 which implies
that in other direction (from MG to MGC) it must = follow=20 SDP
as defined by RFC 2327, which defines them as mandatory.=20 =

Thanks
        = Aleks

At=20 08:27 AM 3/14/2003, Carl Rutter wrote:
I'll take a stab at a few of = these:
 
FYI, In general per = RFC2327
"Some lines in each = description are required=20 and some
   are optional but all must appear in exactly = the=20 order given here (the
   fixed order greatly enhances = error=20 detection and allows for a simple
   parser). Optional = items=20 are marked with a `*'."
   So the ones with the * are = optional
ie) i=3D* (media = title)
Also ignore what you don't=20 understand:
* = "SDP parsers=20 must completely ignore any announcement
   that = contains a=20 `type' letter that it does not understand."
* "A session directory must ignore = any
  =20 attribute it doesn't = understand."
 
 
1) Per section 7.1.8 = RFC3015
  =20 *  the "s=3D", "t=3D" and "o=3D" lines are = optional,
2)
   *  = the "s=3D", "t=3D"=20 and "o=3D" lines are optional,
3) Can be omitted, seems to be encouraged, never used=20 it.
5) RFC2327 = page=20 12
 
 
Carl
 
-----Original=20 Message-----
From: Abhi [mailto:abhishek@hfcl.com]
Sent: = Friday, March=20 14, 2003 5:33 AM
To: megaco@ietf.org
Cc:=20 milton@hfcl.com
Subject: [Megaco] query regarding the use = of=20 SDP

Hi,
As we know SDP is used to ecode and decode local and remote = descriptor. I have certain doubts about some SDP paramters. = They  are=20 as follows:-
1. Do we reqire = "o=3D" line in=20 megaco?
    if = present=20 then
    a. Can = we set=20 username to hypen ("-")?
    b. Can NTP timestamp be used for session = id and=20
        = version?
 2.Do we need sesion = name?
    If present can we use hyphen for=20 that?
3..Do we need sesion and = media=20 information "i=3D" line ?
4..Do we need URI=20 ?
5. How to use bandwidth = "b=3D"=20 line?
6. How to use "t=3D"=20 line?
    If = present, can=20 we have a permanent session?
 NOTE :-=20 RFC-3435(MGCP )  says
    * The start = time may be=20 set to zero.
   * The stop time should be set to=20 zero.

7. .Do we need=20 attributes
          &nbs= p; a)=20 a=3Dcat:<category>
          &nbs= p; b)=20 a=3Dkeywds:<keywords>
          &nbs= p; c)=20 a=3Dtool:<name & version of tool>?
8. Aren't "recvonly", "senrecv", "sendonlly" are redundant = in=20
   =20 Megaco?
9. How to use=20 "a=3Dtype:<conference type>" in Megaco?
10 How to use attributes "a=3Dsdplang" & "a=3Dlang" in=20 Megaco?
 
Thanks and=20 regards
Abhishek=20 Bansal
------=_NextPart_000_004C_01C2EADC.22689860-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Mar 14 23:48: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 XAA28617 for ; Fri, 14 Mar 2003 23:48:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2F53mi05090 for megaco-archive@odin.ietf.org; Sat, 15 Mar 2003 00:03: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 h2F53mO05087 for ; Sat, 15 Mar 2003 00:03: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 XAA28609 for ; Fri, 14 Mar 2003 23:48: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 h2F4x4O04953; Fri, 14 Mar 2003 23:59: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 h2F4w3O04919 for ; Fri, 14 Mar 2003 23:58:03 -0500 Received: from hfclrnd (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28485 for ; Fri, 14 Mar 2003 23:42:01 -0500 (EST) Received: (from root@localhost) by hfclrnd (8.11.6/8.11.2) id h2F4hAr17624; Sat, 15 Mar 2003 10:13:10 +0530 Received: from abhishek ([132.147.166.26]) by hfclrnd (8.11.6/8.11.2) with SMTP id h2F4h9g17616; Sat, 15 Mar 2003 10:13:09 +0530 Message-ID: <004f01c2eaae$08bc4340$1aa69384@abhishek> From: "Abhi" To: "Aleksandr Ryabin" , "Carl Rutter" , References: <5.2.0.9.0.20030314092840.026c3140@imap.winphoria.com> Subject: Re: [Megaco] query regarding the use of SDP Date: Sat, 15 Mar 2003 10:17:51 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01C2EADC.22689860" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Xmilter: rnd.hfcl.com X-Virus-Scanned: by AMaViS perl-11 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_004C_01C2EADC.22689860 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable regarding 2 and 3 if this is the case then how to use these parameters "s=3D", "t=3D", = "o=3D" in megaco. what are the possible values of different fields thanks and regards Abhishek ----- Original Message -----=20 From: Aleksandr Ryabin=20 To: Carl Rutter ; 'Abhi' ; megaco@ietf.org=20 Cc: milton@hfcl.com=20 Sent: Friday, March 14, 2003 8:04 PM Subject: RE: [Megaco] query regarding the use of SDP Regarding 1 and 2. Per section 7.1.8 RFC3015 "s=3D", "t=3D" and "o=3D" are optional=20 ONLY when SDP "sent from the MGC to the MG" which implies=20 that in other direction (from MG to MGC) it must follow SDP as defined by RFC 2327, which defines them as mandatory.=20 Thanks Aleks At 08:27 AM 3/14/2003, Carl Rutter wrote: I'll take a stab at a few of these: =20 FYI, In general per RFC2327 "Some lines in each description are required and some are optional but all must appear in exactly the order given here = (the fixed order greatly enhances error detection and allows for a = simple parser). Optional items are marked with a `*'." So the ones with the * are optional ie) i=3D* (media title) Also ignore what you don't understand: * "SDP parsers must completely ignore any announcement that contains a `type' letter that it does not understand." * "A session directory must ignore any attribute it doesn't understand." =20 =20 1) Per section 7.1.8 RFC3015 * the "s=3D", "t=3D" and "o=3D" lines are optional, 2)=20 * the "s=3D", "t=3D" and "o=3D" lines are optional, 3) Can be omitted, seems to be encouraged, never used it. 5) RFC2327 page 12 =20 =20 Carl =20 -----Original Message----- From: Abhi [mailto:abhishek@hfcl.com] Sent: Friday, March 14, 2003 5:33 AM To: megaco@ietf.org Cc: milton@hfcl.com Subject: [Megaco] query regarding the use of SDP Hi, As we know SDP is used to ecode and decode local and remote = descriptor. I have certain doubts about some SDP paramters. They are as = follows:- 1. Do we reqire "o=3D" line in megaco? if present then a. Can we set username to hypen ("-")? b. Can NTP timestamp be used for session id and=20 version? 2.Do we need sesion name? If present can we use hyphen for that? 3..Do we need sesion and media information "i=3D" line ? 4..Do we need URI ? 5. How to use bandwidth "b=3D" line? 6. How to use "t=3D" line? If present, can we have a permanent session? NOTE :- RFC-3435(MGCP ) says * The start time may be set to zero. * The stop time should be set to zero. 7. .Do we need attributes a) a=3Dcat: b) a=3Dkeywds: c) a=3Dtool:? 8. Aren't "recvonly", "senrecv", "sendonlly" are redundant in=20 Megaco? 9. How to use "a=3Dtype:" in Megaco? 10 How to use attributes "a=3Dsdplang" & "a=3Dlang" in Megaco? =20 Thanks and regards Abhishek Bansal ------=_NextPart_000_004C_01C2EADC.22689860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
regarding 2 and 3
if this is the case then how to use = these=20 parameters "s=3D", "t=3D", "o=3D" in megaco.
what are the possible values of = different=20 fields
thanks and regards
Abhishek
----- Original Message -----
From:=20 Aleksandr=20 Ryabin
Sent: Friday, March 14, 2003 = 8:04=20 PM
Subject: RE: [Megaco] query = regarding the=20 use of SDP

Regarding 1 and 2.

Per section 7.1.8 RFC3015 = "s=3D", =20 "t=3D" and "o=3D" are optional
ONLY when SDP "sent from the MGC to = the MG"=20 which implies
that in other direction (from MG to MGC) it must = follow=20 SDP
as defined by RFC 2327, which defines them as mandatory.=20 =

Thanks
        = Aleks

At=20 08:27 AM 3/14/2003, Carl Rutter wrote:
I'll take a stab at a few of = these:
 
FYI, In general per = RFC2327
"Some lines in each = description are required=20 and some
   are optional but all must appear in exactly = the=20 order given here (the
   fixed order greatly enhances = error=20 detection and allows for a simple
   parser). Optional = items=20 are marked with a `*'."
   So the ones with the * are = optional
ie) i=3D* (media = title)
Also ignore what you don't=20 understand:
* = "SDP parsers=20 must completely ignore any announcement
   that = contains a=20 `type' letter that it does not understand."
* "A session directory must ignore = any
  =20 attribute it doesn't = understand."
 
 
1) Per section 7.1.8 = RFC3015
  =20 *  the "s=3D", "t=3D" and "o=3D" lines are = optional,
2)
   *  = the "s=3D", "t=3D"=20 and "o=3D" lines are optional,
3) Can be omitted, seems to be encouraged, never used=20 it.
5) RFC2327 = page=20 12
 
 
Carl
 
-----Original=20 Message-----
From: Abhi [mailto:abhishek@hfcl.com]
Sent: = Friday, March=20 14, 2003 5:33 AM
To: megaco@ietf.org
Cc:=20 milton@hfcl.com
Subject: [Megaco] query regarding the use = of=20 SDP

Hi,
As we know SDP is used to ecode and decode local and remote = descriptor. I have certain doubts about some SDP paramters. = They  are=20 as follows:-
1. Do we reqire = "o=3D" line in=20 megaco?
    if = present=20 then
    a. Can = we set=20 username to hypen ("-")?
    b. Can NTP timestamp be used for session = id and=20
        = version?
 2.Do we need sesion = name?
    If present can we use hyphen for=20 that?
3..Do we need sesion and = media=20 information "i=3D" line ?
4..Do we need URI=20 ?
5. How to use bandwidth = "b=3D"=20 line?
6. How to use "t=3D"=20 line?
    If = present, can=20 we have a permanent session?
 NOTE :-=20 RFC-3435(MGCP )  says
    * The start = time may be=20 set to zero.
   * The stop time should be set to=20 zero.

7. .Do we need=20 attributes
          &nbs= p; a)=20 a=3Dcat:<category>
          &nbs= p; b)=20 a=3Dkeywds:<keywords>
          &nbs= p; c)=20 a=3Dtool:<name & version of tool>?
8. Aren't "recvonly", "senrecv", "sendonlly" are redundant = in=20
   =20 Megaco?
9. How to use=20 "a=3Dtype:<conference type>" in Megaco?
10 How to use attributes "a=3Dsdplang" & "a=3Dlang" in=20 Megaco?
 
Thanks and=20 regards
Abhishek=20 Bansal
------=_NextPart_000_004C_01C2EADC.22689860-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Mar 17 01:03: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 BAA22073 for ; Mon, 17 Mar 2003 01:03: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 h2H6JVO26298; Mon, 17 Mar 2003 01:19: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 h2H6EtO26098 for ; Mon, 17 Mar 2003 01:14: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 AAA21889 for ; Mon, 17 Mar 2003 00:58:08 -0500 (EST) From: bvswamy@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 h2H5wYs20813 for ; Mon, 17 Mar 2003 11:28:34 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2H5wX220805; Mon, 17 Mar 2003 11:28:33 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2H61HG03974; Mon, 17 Mar 2003 11:31:17 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CEC.001FC2F8 ; Mon, 17 Mar 2003 11:16:55 +0530 X-Lotus-FromDomain: HSS To: mailman-owner@www1.ietf.org cc: megaco@ietf.org Message-ID: <65256CEC.001FC1D7.00@dlfmail1.hss.hns.com> Date: Mon, 17 Mar 2003 11:32:18 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Megaco Mailing List subscription Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi I have registered with the megaco mailing list but due to long leave I have temporarily disabled the account. I now need to enable the megaco mailing list subscrition. So kindly provide me details of how to enable it. login:bvswamy@hss.hns.com list: megaco@ietf.org Regards Venkat 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 Mar 17 01:05: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 BAA22090 for ; Mon, 17 Mar 2003 01:05:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2H6LMU26474 for megaco-archive@odin.ietf.org; Mon, 17 Mar 2003 01:21: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 h2H6LMO26471 for ; Mon, 17 Mar 2003 01:21: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 BAA22087 for ; Mon, 17 Mar 2003 01:04: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 h2H6JVO26298; Mon, 17 Mar 2003 01:19: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 h2H6EtO26098 for ; Mon, 17 Mar 2003 01:14: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 AAA21889 for ; Mon, 17 Mar 2003 00:58:08 -0500 (EST) From: bvswamy@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 h2H5wYs20813 for ; Mon, 17 Mar 2003 11:28:34 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2H5wX220805; Mon, 17 Mar 2003 11:28:33 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2H61HG03974; Mon, 17 Mar 2003 11:31:17 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CEC.001FC2F8 ; Mon, 17 Mar 2003 11:16:55 +0530 X-Lotus-FromDomain: HSS To: mailman-owner@www1.ietf.org cc: megaco@ietf.org Message-ID: <65256CEC.001FC1D7.00@dlfmail1.hss.hns.com> Date: Mon, 17 Mar 2003 11:32:18 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Megaco] Megaco Mailing List subscription Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi I have registered with the megaco mailing list but due to long leave I have temporarily disabled the account. I now need to enable the megaco mailing list subscrition. So kindly provide me details of how to enable it. login:bvswamy@hss.hns.com list: megaco@ietf.org Regards Venkat 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 Mar 17 01:43: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 BAA22868 for ; Mon, 17 Mar 2003 01: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 h2H6xiO28577; Mon, 17 Mar 2003 01:59: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 h2H6uhO28453 for ; Mon, 17 Mar 2003 01:56:43 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22776 for ; Mon, 17 Mar 2003 01:39:54 -0500 (EST) From: bvswamy@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 h2H6eLs00231 for ; Mon, 17 Mar 2003 12:10:21 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2H6eK200227 for ; Mon, 17 Mar 2003 12:10:20 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2H6h5w07763 for ; Mon, 17 Mar 2003 12:13:05 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CEC.00239941 ; Mon, 17 Mar 2003 11:58:49 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CEC.00239924.00@dlfmail1.hss.hns.com> Date: Mon, 17 Mar 2003 12:14:15 +0530 Subject: Re: [Megaco] Service change Restart 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 Related to Service change restart I have few queries: 1) What should MG do when it receives Service Change Restart on a already inservice termination which is in Non-Null context Should it give a error response or whether MG should clear the call and remove the termination from the context ? 2) If ServiceChange Restart with delay is recd. for an already Inservice termination which may or may not be in call then what should be MG behaviour. Should it mark the termination as Out-Of-Service till the delay timer expires and remove the termination from the context or give a error response ? In both of the above cases if MG were to give a error response then there is no error-code defined which specifies that MG is already in the state which MGC has requested. 3) What should be the MGC behaviour in the following scenario: 1) MGC recevies a Service Change graceful with NonNull delay for a termination in context. 2) Now MG want to cancel the graceful timer. The only way do currently is by sending a service Change Restart. Now what should be MGC behaviour. Should it only stop the timer and continue the call or end the call and the mark the termination as Inservice. Pls Comment. Regards Venkat Tom Taylor on 03/13/2003 06:57:35 PM To: Sachin Gupta-PNGN/HSS@HSS, Megaco List cc: Subject: Re: [Megaco] Service change Restart I agree that it's very difficult to assign any real meaning to an MGC-initiated restart of a termination. My background in switch software development tells me that a restart clears certain aspects of state. However, that makes little sense in the Megaco case, because the MGC can do that directly by subtracting the termination from any context it is in and resetting descriptors if it is not in a context. Conclusion: the only thing an MGC-initiated restart of a termination does is change its state to in-service if it is not already there. gsachin@hss.hns.com wrote: > > Hi List > I have a query regarding the processing of Service Change Restart. > consider the following scenario: > > Termination is in state InService. > Command recieved from MGC to Restart the termination (with or wothout delay). > > what MG could possibly do in this case? > > > Thanks > Sachin Gupta > [disclaimer snipped] _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Mar 17 01:45: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 BAA22915 for ; Mon, 17 Mar 2003 01:45:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2H71KA28721 for megaco-archive@odin.ietf.org; Mon, 17 Mar 2003 02:01: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 h2H71JO28718 for ; Mon, 17 Mar 2003 02:01: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 BAA22907 for ; Mon, 17 Mar 2003 01:44: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 h2H6xiO28577; Mon, 17 Mar 2003 01:59: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 h2H6uhO28453 for ; Mon, 17 Mar 2003 01:56:43 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22776 for ; Mon, 17 Mar 2003 01:39:54 -0500 (EST) From: bvswamy@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 h2H6eLs00231 for ; Mon, 17 Mar 2003 12:10:21 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2H6eK200227 for ; Mon, 17 Mar 2003 12:10:20 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2H6h5w07763 for ; Mon, 17 Mar 2003 12:13:05 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CEC.00239941 ; Mon, 17 Mar 2003 11:58:49 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CEC.00239924.00@dlfmail1.hss.hns.com> Date: Mon, 17 Mar 2003 12:14:15 +0530 Subject: Re: [Megaco] Service change Restart 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 Related to Service change restart I have few queries: 1) What should MG do when it receives Service Change Restart on a already inservice termination which is in Non-Null context Should it give a error response or whether MG should clear the call and remove the termination from the context ? 2) If ServiceChange Restart with delay is recd. for an already Inservice termination which may or may not be in call then what should be MG behaviour. Should it mark the termination as Out-Of-Service till the delay timer expires and remove the termination from the context or give a error response ? In both of the above cases if MG were to give a error response then there is no error-code defined which specifies that MG is already in the state which MGC has requested. 3) What should be the MGC behaviour in the following scenario: 1) MGC recevies a Service Change graceful with NonNull delay for a termination in context. 2) Now MG want to cancel the graceful timer. The only way do currently is by sending a service Change Restart. Now what should be MGC behaviour. Should it only stop the timer and continue the call or end the call and the mark the termination as Inservice. Pls Comment. Regards Venkat Tom Taylor on 03/13/2003 06:57:35 PM To: Sachin Gupta-PNGN/HSS@HSS, Megaco List cc: Subject: Re: [Megaco] Service change Restart I agree that it's very difficult to assign any real meaning to an MGC-initiated restart of a termination. My background in switch software development tells me that a restart clears certain aspects of state. However, that makes little sense in the Megaco case, because the MGC can do that directly by subtracting the termination from any context it is in and resetting descriptors if it is not in a context. Conclusion: the only thing an MGC-initiated restart of a termination does is change its state to in-service if it is not already there. gsachin@hss.hns.com wrote: > > Hi List > I have a query regarding the processing of Service Change Restart. > consider the following scenario: > > Termination is in state InService. > Command recieved from MGC to Restart the termination (with or wothout delay). > > what MG could possibly do in this case? > > > Thanks > Sachin Gupta > [disclaimer snipped] _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Mar 17 09:26: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 JAA14004 for ; Mon, 17 Mar 2003 09: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 h2HEfnO04638; Mon, 17 Mar 2003 09:41: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 h2HEdSO04512 for ; Mon, 17 Mar 2003 09:39:28 -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 JAA13938 for ; Mon, 17 Mar 2003 09:22:30 -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 h2HEMus08020 for ; Mon, 17 Mar 2003 19:52:56 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2HEMs208005; Mon, 17 Mar 2003 19:52:55 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2HEPd117989; Mon, 17 Mar 2003 19:55:39 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CEC.004DF31A ; Mon, 17 Mar 2003 19:41:25 +0530 X-Lotus-FromDomain: HSS To: Tom Taylor cc: gsachin@hss.hns.com, Megaco List Message-ID: <65256CEC.004DF263.00@dlfmail1.hss.hns.com> Date: Mon, 17 Mar 2003 19:51:40 +0530 Subject: Re: [Megaco] Service change Restart 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: , I would surely appreciate a symmetry (if not completely) in the ServiceChange method. regards, Kushanava Tom Taylor on 03/14/2003 08:00:18 PM To: Kushanava Laha/HSS@HSS cc: Sachin Gupta-PNGN/HSS@HSS, Megaco List Subject: Re: [Megaco] Service change Restart This is where the RFC is completely inadequate as it stands. I wouldn't mind seeing it rewritten to specify separately what happens for ServiceChange on ROOT vs. ServiceChange on individual terminations. With regard to the latter, there is also something else I'd like to see ironed out: the service state is a writable property in TerminationState, yet it is manipulated by ServiceChange. One or the other of these should go. I am quite prepared to submit a proposal for new text for section 7.2.8 in particular. Would there be interest in reviewing such a proposal? We could submit it as a contribution into SG 16's May meeting if that is workable. klaha@hss.hns.com wrote: > > How about ServiceChange Restart on ROOT from MGC?Does the protocol inhibit it? > (It can be an easier means for the MGC to inform MG to delete all contexts > rather than 'Subtract'ing each of them, when MGC is taken gracefully > out-of-service) > > > > > > Tom Taylor on 03/14/2003 12:27:35 AM > > To: Sachin Gupta-PNGN/HSS@HSS, Megaco List > cc: (bcc: Kushanava Laha/HSS) > > Subject: Re: [Megaco] Service change Restart > > > > I agree that it's very difficult to assign any real meaning to an MGC-initiated > restart of a termination. My background in switch software development tells me > that a restart clears certain aspects of state. However, that makes little > sense in > the Megaco case, because the MGC can do that directly by subtracting the > termination > from any context it is in and resetting descriptors if it is not in a context. > > Conclusion: the only thing an MGC-initiated restart of a termination does is > change > its state to in-service if it is not already there. > > gsachin@hss.hns.com wrote: > >>Hi List >>I have a query regarding the processing of Service Change Restart. >>consider the following scenario: >> >>Termination is in state InService. >>Command recieved from MGC to Restart the termination (with or wothout delay). >> >>what MG could possibly do in this case? >> >> >>Thanks >>Sachin Gupta >> > > [disclaimer snipped] > > _______________________________________________ > 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 Mar 17 09:27: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 JAA14036 for ; Mon, 17 Mar 2003 09:27:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HEhdc04692 for megaco-archive@odin.ietf.org; Mon, 17 Mar 2003 09:43: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 h2HEhdO04689 for ; Mon, 17 Mar 2003 09:43: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 JAA14027 for ; Mon, 17 Mar 2003 09:26: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 h2HEfnO04638; Mon, 17 Mar 2003 09:41: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 h2HEdSO04512 for ; Mon, 17 Mar 2003 09:39:28 -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 JAA13938 for ; Mon, 17 Mar 2003 09:22:30 -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 h2HEMus08020 for ; Mon, 17 Mar 2003 19:52:56 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2HEMs208005; Mon, 17 Mar 2003 19:52:55 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2HEPd117989; Mon, 17 Mar 2003 19:55:39 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CEC.004DF31A ; Mon, 17 Mar 2003 19:41:25 +0530 X-Lotus-FromDomain: HSS To: Tom Taylor cc: gsachin@hss.hns.com, Megaco List Message-ID: <65256CEC.004DF263.00@dlfmail1.hss.hns.com> Date: Mon, 17 Mar 2003 19:51:40 +0530 Subject: Re: [Megaco] Service change Restart 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: , I would surely appreciate a symmetry (if not completely) in the ServiceChange method. regards, Kushanava Tom Taylor on 03/14/2003 08:00:18 PM To: Kushanava Laha/HSS@HSS cc: Sachin Gupta-PNGN/HSS@HSS, Megaco List Subject: Re: [Megaco] Service change Restart This is where the RFC is completely inadequate as it stands. I wouldn't mind seeing it rewritten to specify separately what happens for ServiceChange on ROOT vs. ServiceChange on individual terminations. With regard to the latter, there is also something else I'd like to see ironed out: the service state is a writable property in TerminationState, yet it is manipulated by ServiceChange. One or the other of these should go. I am quite prepared to submit a proposal for new text for section 7.2.8 in particular. Would there be interest in reviewing such a proposal? We could submit it as a contribution into SG 16's May meeting if that is workable. klaha@hss.hns.com wrote: > > How about ServiceChange Restart on ROOT from MGC?Does the protocol inhibit it? > (It can be an easier means for the MGC to inform MG to delete all contexts > rather than 'Subtract'ing each of them, when MGC is taken gracefully > out-of-service) > > > > > > Tom Taylor on 03/14/2003 12:27:35 AM > > To: Sachin Gupta-PNGN/HSS@HSS, Megaco List > cc: (bcc: Kushanava Laha/HSS) > > Subject: Re: [Megaco] Service change Restart > > > > I agree that it's very difficult to assign any real meaning to an MGC-initiated > restart of a termination. My background in switch software development tells me > that a restart clears certain aspects of state. However, that makes little > sense in > the Megaco case, because the MGC can do that directly by subtracting the > termination > from any context it is in and resetting descriptors if it is not in a context. > > Conclusion: the only thing an MGC-initiated restart of a termination does is > change > its state to in-service if it is not already there. > > gsachin@hss.hns.com wrote: > >>Hi List >>I have a query regarding the processing of Service Change Restart. >>consider the following scenario: >> >>Termination is in state InService. >>Command recieved from MGC to Restart the termination (with or wothout delay). >> >>what MG could possibly do in this case? >> >> >>Thanks >>Sachin Gupta >> > > [disclaimer snipped] > > _______________________________________________ > 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 Mar 17 10:17: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 KAA16649 for ; Mon, 17 Mar 2003 10:17: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 h2HFXDO07491; Mon, 17 Mar 2003 10:33:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HFWfO07456 for ; Mon, 17 Mar 2003 10:32:41 -0500 Received: from ipgen-india.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16487 for ; Mon, 17 Mar 2003 10:15:42 -0500 (EST) Received: from mohan [192.168.1.244] by ipgen-india.com [192.168.1.15] with SMTP (MDaemon.PRO.v5.0.7.T) for ; Mon, 17 Mar 2003 20:48:03 +0530 Message-ID: <014701c2ed0a$53083d60$f401a8c0@mohan> From: "Mohan Hadimani" To: Cc: "keshav" , "Harikrishna C Warrier" , "Adiga" Date: Mon, 17 Mar 2003 20:53:31 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0144_01C2ECC7.44BA1CD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MDRemoteIP: 192.168.1.244 X-Return-Path: mohan@ipgen-india.com X-MDaemon-Deliver-To: megaco@ietf.org Subject: [Megaco] Megaco Media format related Queries!! Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_0144_01C2ECC7.44BA1CD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I would like to know the answer for following 2 queries. 1). Its required to send multiple media formats in ADD command. Among the following, in which way I can send the ADD request to MG? v=3D0 c=3DIN IP4 $ m=3Daudio $ RTP/AVP fmt1 fmt2 fmt3 fmt4 or v=3D0 c=3DIN IP4 $ m=3Daudio $ RTP/AVP fmt1 v=3D0 c=3DIN IP4 $ m=3Daudio $ RTP/AVP fmt2 v=3D0 c=3DIN IP4 $ m=3Daudio $ RTP/AVP fmt3 v=3D0 c=3DIN IP4 $ m=3Daudio $ RTP/AVP fmt4 2). In which case MG will report multiple media formats in ADD reply? Because I tried by sending multiple formats in the above 2 methods, but MG is always reporting only the first format(default - = according to 2327) in ADD reply. Thanx & Regards Mohan ------=_NextPart_000_0144_01C2ECC7.44BA1CD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
I would like to know the answer for following 2 = queries.
 
1). Its required to send multiple media formats in = ADD=20 command.
     Among the following, in = which way I=20 can send the ADD request to MG?
 
      v=3D0
      c=3DIN IP4 $
      m=3Daudio $ RTP/AVP = fmt1 fmt2=20 fmt3 fmt4
 
     =20 or
 
      v=3D0
      c=3DIN IP4 $
      m=3Daudio $ RTP/AVP=20 fmt1
 
      v=3D0
      c=3DIN IP4 $
      m=3Daudio $ RTP/AVP=20 fmt2
 
      v=3D0
      c=3DIN IP4 $
      m=3Daudio $ RTP/AVP=20 fmt3
 
      v=3D0
      c=3DIN IP4 $
      m=3Daudio $ RTP/AVP=20 fmt4
 
2). In which case MG will report multiple media formats in ADD = reply?
     Because I tried by sending multiple = formats in the=20 above 2 methods,
     but MG is always reporting only the first=20 format(default - according to 2327)
     in ADD reply.
 
Thanx & Regards
Mohan
 
------=_NextPart_000_0144_01C2ECC7.44BA1CD0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Mar 17 10:18: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 KAA16759 for ; Mon, 17 Mar 2003 10:18:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HFYk807661 for megaco-archive@odin.ietf.org; Mon, 17 Mar 2003 10:34: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 h2HFYkO07658 for ; Mon, 17 Mar 2003 10:34: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 KAA16716 for ; Mon, 17 Mar 2003 10:17: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 h2HFXDO07491; Mon, 17 Mar 2003 10:33:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HFWfO07456 for ; Mon, 17 Mar 2003 10:32:41 -0500 Received: from ipgen-india.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16487 for ; Mon, 17 Mar 2003 10:15:42 -0500 (EST) Received: from mohan [192.168.1.244] by ipgen-india.com [192.168.1.15] with SMTP (MDaemon.PRO.v5.0.7.T) for ; Mon, 17 Mar 2003 20:48:03 +0530 Message-ID: <014701c2ed0a$53083d60$f401a8c0@mohan> From: "Mohan Hadimani" To: Cc: "keshav" , "Harikrishna C Warrier" , "Adiga" Date: Mon, 17 Mar 2003 20:53:31 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0144_01C2ECC7.44BA1CD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MDRemoteIP: 192.168.1.244 X-Return-Path: mohan@ipgen-india.com X-MDaemon-Deliver-To: megaco@ietf.org Subject: [Megaco] Megaco Media format related Queries!! Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_0144_01C2ECC7.44BA1CD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I would like to know the answer for following 2 queries. 1). Its required to send multiple media formats in ADD command. Among the following, in which way I can send the ADD request to MG? v=3D0 c=3DIN IP4 $ m=3Daudio $ RTP/AVP fmt1 fmt2 fmt3 fmt4 or v=3D0 c=3DIN IP4 $ m=3Daudio $ RTP/AVP fmt1 v=3D0 c=3DIN IP4 $ m=3Daudio $ RTP/AVP fmt2 v=3D0 c=3DIN IP4 $ m=3Daudio $ RTP/AVP fmt3 v=3D0 c=3DIN IP4 $ m=3Daudio $ RTP/AVP fmt4 2). In which case MG will report multiple media formats in ADD reply? Because I tried by sending multiple formats in the above 2 methods, but MG is always reporting only the first format(default - = according to 2327) in ADD reply. Thanx & Regards Mohan ------=_NextPart_000_0144_01C2ECC7.44BA1CD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
I would like to know the answer for following 2 = queries.
 
1). Its required to send multiple media formats in = ADD=20 command.
     Among the following, in = which way I=20 can send the ADD request to MG?
 
      v=3D0
      c=3DIN IP4 $
      m=3Daudio $ RTP/AVP = fmt1 fmt2=20 fmt3 fmt4
 
     =20 or
 
      v=3D0
      c=3DIN IP4 $
      m=3Daudio $ RTP/AVP=20 fmt1
 
      v=3D0
      c=3DIN IP4 $
      m=3Daudio $ RTP/AVP=20 fmt2
 
      v=3D0
      c=3DIN IP4 $
      m=3Daudio $ RTP/AVP=20 fmt3
 
      v=3D0
      c=3DIN IP4 $
      m=3Daudio $ RTP/AVP=20 fmt4
 
2). In which case MG will report multiple media formats in ADD = reply?
     Because I tried by sending multiple = formats in the=20 above 2 methods,
     but MG is always reporting only the first=20 format(default - according to 2327)
     in ADD reply.
 
Thanx & Regards
Mohan
 
------=_NextPart_000_0144_01C2ECC7.44BA1CD0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Mar 17 10:44: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 KAA17613 for ; Mon, 17 Mar 2003 10: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 h2HFxiO09575; Mon, 17 Mar 2003 10:59: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 h2HFwgO09515 for ; Mon, 17 Mar 2003 10:58:42 -0500 Received: from bos-exch01.winphoria.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17579 for ; Mon, 17 Mar 2003 10:41:44 -0500 (EST) Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Mar 2003 10:43:53 -0500 Message-Id: <5.2.0.9.0.20030317103426.01cf8ba8@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 17 Mar 2003 10:43:36 -0500 To: "Abhi" , From: Aleksandr Ryabin Subject: Re: [Megaco] query regarding the use of SDP Cc: "Carl Rutter" In-Reply-To: <004f01c2eaae$08bc4340$1aa69384@abhishek> References: <5.2.0.9.0.20030314092840.026c3140@imap.winphoria.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_562880599==.ALT" X-OriginalArrivalTime: 17 Mar 2003 15:43:54.0007 (UTC) FILETIME=[03A62A70:01C2EC9C] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --=====================_562880599==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Follow SDP RFC 2327, it also gives examples of SDP parameter values. For some of the parameters SDP RFC defines usage of "-" in place of parameter fields, which means "ignore". I've seen as a common practice to extend it to use in any SDP parameter field and not only for ones SDP RFC defines it as valid as in many cases some parameters are unused for a specific application. For example, if MG does not implement conference then "t=" most likely to be ignored anyway, thus using "t=- -" could be quite reasonable. Cheers. Aleks At 11:47 PM 3/14/2003, Abhi wrote: >regarding 2 and 3 >if this is the case then how to use these parameters "s=", "t=", "o=" in >megaco. >what are the possible values of different fields >thanks and regards >Abhishek >----- Original Message ----- >From: Aleksandr Ryabin >To: Carl Rutter ; >'Abhi' ; megaco@ietf.org >Cc: milton@hfcl.com >Sent: Friday, March 14, 2003 8:04 PM >Subject: RE: [Megaco] query regarding the use of SDP > >Regarding 1 and 2. > >Per section 7.1.8 RFC3015 "s=", "t=" and "o=" are optional >ONLY when SDP "sent from the MGC to the MG" which implies >that in other direction (from MG to MGC) it must follow SDP >as defined by RFC 2327, which defines them as mandatory. > >Thanks > Aleks > >At 08:27 AM 3/14/2003, Carl Rutter wrote: >>I'll take a stab at a few of these: >> >>FYI, In general per RFC2327 >>"Some lines in each description are required and some >> are optional but all must appear in exactly the order given here (the >> fixed order greatly enhances error detection and allows for a simple >> parser). Optional items are marked with a `*'." >> So the ones with the * are optional >>ie) i=* (media title) >>Also ignore what you don't understand: >>* "SDP parsers must completely ignore any announcement >> that contains a `type' letter that it does not understand." >>* "A session directory must ignore any >> attribute it doesn't understand." >> >> >>1) Per section 7.1.8 RFC3015 >> * the "s=", "t=" and "o=" lines are optional, >>2) >> * the "s=", "t=" and "o=" lines are optional, >>3) Can be omitted, seems to be encouraged, never used it. >>5) RFC2327 page 12 >> >> >>Carl >> >>-----Original Message----- >>From: Abhi [mailto:abhishek@hfcl.com] >>Sent: Friday, March 14, 2003 5:33 AM >>To: megaco@ietf.org >>Cc: milton@hfcl.com >>Subject: [Megaco] query regarding the use of SDP >> >>Hi, >>As we know SDP is used to ecode and decode local and remote descriptor. I >>have certain doubts about some SDP paramters. They are as follows:- >>1. Do we reqire "o=" line in megaco? >> if present then >> a. Can we set username to hypen ("-")? >> b. Can NTP timestamp be used for session id and >> version? >> 2.Do we need sesion name? >> If present can we use hyphen for that? >>3..Do we need sesion and media information "i=" line ? >>4..Do we need URI ? >>5. How to use bandwidth "b=" line? >>6. How to use "t=" line? >> If present, can we have a permanent session? >> NOTE :- RFC-3435(MGCP ) says >> * The start time may be set to zero. >> * The stop time should be set to zero. >> >>7. .Do we need attributes >> a) a=cat: >> b) a=keywds: >> c) a=tool:? >>8. Aren't "recvonly", "senrecv", "sendonlly" are redundant in >> Megaco? >>9. How to use "a=type:" in Megaco? >>10 How to use attributes "a=sdplang" & "a=lang" in Megaco? >> >>Thanks and regards >>Abhishek Bansal --=====================_562880599==.ALT Content-Type: text/html; charset="us-ascii" Follow SDP RFC 2327, it also gives examples of SDP parameter values.

For some of the parameters SDP RFC defines usage of "-" in place of parameter
fields, which means "ignore". I've seen as a common practice to extend it to use in any
SDP parameter field and not only for ones SDP RFC defines it as valid as in many
cases some parameters are unused for a specific application.

For example, if MG does not implement conference then "t=" most likely to be
ignored anyway, thus using "t=- -" could be quite reasonable.

Cheers.
        Aleks

At 11:47 PM 3/14/2003, Abhi wrote:
regarding 2 and 3
if this is the case then how to use these parameters "s=", "t=", "o=" in megaco.
what are the possible values of different fields
thanks and regards
Abhishek
----- Original Message -----
From: Aleksandr Ryabin
To: Carl Rutter ; 'Abhi' ; megaco@ietf.org
Cc: milton@hfcl.com
Sent: Friday, March 14, 2003 8:04 PM
Subject: RE: [Megaco] query regarding the use of SDP

Regarding 1 and 2.

Per section 7.1.8 RFC3015 "s=",  "t=" and "o=" are optional
ONLY when SDP "sent from the MGC to the MG" which implies
that in other direction (from MG to MGC) it must follow SDP
as defined by RFC 2327, which defines them as mandatory.

Thanks
        Aleks

At 08:27 AM 3/14/2003, Carl Rutter wrote:
I'll take a stab at a few of these:
 
FYI, In general per RFC2327
"Some lines in each description are required and some
   are optional but all must appear in exactly the order given here (the
   fixed order greatly enhances error detection and allows for a simple
   parser). Optional items are marked with a `*'."
   So the ones with the * are optional
ie) i=* (media title)
Also ignore what you don't understand:
* "SDP parsers must completely ignore any announcement
   that contains a `type' letter that it does not understand."
* "A session directory must ignore any
   attribute it doesn't understand."
 
 
1) Per section 7.1.8 RFC3015
   *  the "s=", "t=" and "o=" lines are optional,
2)
   *  the "s=", "t=" and "o=" lines are optional,
3) Can be omitted, seems to be encouraged, never used it.
5) RFC2327 page 12
 
 
Carl
 
-----Original Message-----
From: Abhi [mailto:abhishek@hfcl.com]
Sent: Friday, March 14, 2003 5:33 AM
To: megaco@ietf.org
Cc: milton@hfcl.com
Subject: [Megaco] query regarding the use of SDP
Hi,
As we know SDP is used to ecode and decode local and remote descriptor. I have certain doubts about some SDP paramters. They  are as follows:-
1. Do we reqire "o=" line in megaco?
    if present then
    a. Can we set username to hypen ("-")?
    b. Can NTP timestamp be used for session id and
        version?
 2.Do we need sesion name?
    If present can we use hyphen for that?
3..Do we need sesion and media information "i=" line ?
4..Do we need URI ?
5. How to use bandwidth "b=" line?
6. How to use "t=" line?
    If present, can we have a permanent session?
 NOTE :- RFC-3435(MGCP )  says
    * The start time may be set to zero.
   * The stop time should be set to zero.
7. .Do we need attributes
            a) a=cat:<category>
            b) a=keywds:<keywords>
            c) a=tool:<name & version of tool>?
8. Aren't "recvonly", "senrecv", "sendonlly" are redundant in
    Megaco?
9. How to use "a=type:<conference type>" in Megaco?
10 How to use attributes "a=sdplang" & "a=lang" in Megaco?
 
Thanks and regards
Abhishek Bansal
--=====================_562880599==.ALT-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Mar 17 10:45: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 KAA17680 for ; Mon, 17 Mar 2003 10:45:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HG1X409706 for megaco-archive@odin.ietf.org; Mon, 17 Mar 2003 11: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 h2HG1XO09703 for ; Mon, 17 Mar 2003 11:01: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 KAA17669 for ; Mon, 17 Mar 2003 10:44: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 h2HFxiO09575; Mon, 17 Mar 2003 10:59: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 h2HFwgO09515 for ; Mon, 17 Mar 2003 10:58:42 -0500 Received: from bos-exch01.winphoria.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17579 for ; Mon, 17 Mar 2003 10:41:44 -0500 (EST) Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Mar 2003 10:43:53 -0500 Message-Id: <5.2.0.9.0.20030317103426.01cf8ba8@imap.winphoria.com> X-Sender: kengr@imap.winphoria.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 17 Mar 2003 10:43:36 -0500 To: "Abhi" , From: Aleksandr Ryabin Subject: Re: [Megaco] query regarding the use of SDP Cc: "Carl Rutter" In-Reply-To: <004f01c2eaae$08bc4340$1aa69384@abhishek> References: <5.2.0.9.0.20030314092840.026c3140@imap.winphoria.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_562880599==.ALT" X-OriginalArrivalTime: 17 Mar 2003 15:43:54.0007 (UTC) FILETIME=[03A62A70:01C2EC9C] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --=====================_562880599==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Follow SDP RFC 2327, it also gives examples of SDP parameter values. For some of the parameters SDP RFC defines usage of "-" in place of parameter fields, which means "ignore". I've seen as a common practice to extend it to use in any SDP parameter field and not only for ones SDP RFC defines it as valid as in many cases some parameters are unused for a specific application. For example, if MG does not implement conference then "t=" most likely to be ignored anyway, thus using "t=- -" could be quite reasonable. Cheers. Aleks At 11:47 PM 3/14/2003, Abhi wrote: >regarding 2 and 3 >if this is the case then how to use these parameters "s=", "t=", "o=" in >megaco. >what are the possible values of different fields >thanks and regards >Abhishek >----- Original Message ----- >From: Aleksandr Ryabin >To: Carl Rutter ; >'Abhi' ; megaco@ietf.org >Cc: milton@hfcl.com >Sent: Friday, March 14, 2003 8:04 PM >Subject: RE: [Megaco] query regarding the use of SDP > >Regarding 1 and 2. > >Per section 7.1.8 RFC3015 "s=", "t=" and "o=" are optional >ONLY when SDP "sent from the MGC to the MG" which implies >that in other direction (from MG to MGC) it must follow SDP >as defined by RFC 2327, which defines them as mandatory. > >Thanks > Aleks > >At 08:27 AM 3/14/2003, Carl Rutter wrote: >>I'll take a stab at a few of these: >> >>FYI, In general per RFC2327 >>"Some lines in each description are required and some >> are optional but all must appear in exactly the order given here (the >> fixed order greatly enhances error detection and allows for a simple >> parser). Optional items are marked with a `*'." >> So the ones with the * are optional >>ie) i=* (media title) >>Also ignore what you don't understand: >>* "SDP parsers must completely ignore any announcement >> that contains a `type' letter that it does not understand." >>* "A session directory must ignore any >> attribute it doesn't understand." >> >> >>1) Per section 7.1.8 RFC3015 >> * the "s=", "t=" and "o=" lines are optional, >>2) >> * the "s=", "t=" and "o=" lines are optional, >>3) Can be omitted, seems to be encouraged, never used it. >>5) RFC2327 page 12 >> >> >>Carl >> >>-----Original Message----- >>From: Abhi [mailto:abhishek@hfcl.com] >>Sent: Friday, March 14, 2003 5:33 AM >>To: megaco@ietf.org >>Cc: milton@hfcl.com >>Subject: [Megaco] query regarding the use of SDP >> >>Hi, >>As we know SDP is used to ecode and decode local and remote descriptor. I >>have certain doubts about some SDP paramters. They are as follows:- >>1. Do we reqire "o=" line in megaco? >> if present then >> a. Can we set username to hypen ("-")? >> b. Can NTP timestamp be used for session id and >> version? >> 2.Do we need sesion name? >> If present can we use hyphen for that? >>3..Do we need sesion and media information "i=" line ? >>4..Do we need URI ? >>5. How to use bandwidth "b=" line? >>6. How to use "t=" line? >> If present, can we have a permanent session? >> NOTE :- RFC-3435(MGCP ) says >> * The start time may be set to zero. >> * The stop time should be set to zero. >> >>7. .Do we need attributes >> a) a=cat: >> b) a=keywds: >> c) a=tool:? >>8. Aren't "recvonly", "senrecv", "sendonlly" are redundant in >> Megaco? >>9. How to use "a=type:" in Megaco? >>10 How to use attributes "a=sdplang" & "a=lang" in Megaco? >> >>Thanks and regards >>Abhishek Bansal --=====================_562880599==.ALT Content-Type: text/html; charset="us-ascii" Follow SDP RFC 2327, it also gives examples of SDP parameter values.

For some of the parameters SDP RFC defines usage of "-" in place of parameter
fields, which means "ignore". I've seen as a common practice to extend it to use in any
SDP parameter field and not only for ones SDP RFC defines it as valid as in many
cases some parameters are unused for a specific application.

For example, if MG does not implement conference then "t=" most likely to be
ignored anyway, thus using "t=- -" could be quite reasonable.

Cheers.
        Aleks

At 11:47 PM 3/14/2003, Abhi wrote:
regarding 2 and 3
if this is the case then how to use these parameters "s=", "t=", "o=" in megaco.
what are the possible values of different fields
thanks and regards
Abhishek
----- Original Message -----
From: Aleksandr Ryabin
To: Carl Rutter ; 'Abhi' ; megaco@ietf.org
Cc: milton@hfcl.com
Sent: Friday, March 14, 2003 8:04 PM
Subject: RE: [Megaco] query regarding the use of SDP

Regarding 1 and 2.

Per section 7.1.8 RFC3015 "s=",  "t=" and "o=" are optional
ONLY when SDP "sent from the MGC to the MG" which implies
that in other direction (from MG to MGC) it must follow SDP
as defined by RFC 2327, which defines them as mandatory.

Thanks
        Aleks

At 08:27 AM 3/14/2003, Carl Rutter wrote:
I'll take a stab at a few of these:
 
FYI, In general per RFC2327
"Some lines in each description are required and some
   are optional but all must appear in exactly the order given here (the
   fixed order greatly enhances error detection and allows for a simple
   parser). Optional items are marked with a `*'."
   So the ones with the * are optional
ie) i=* (media title)
Also ignore what you don't understand:
* "SDP parsers must completely ignore any announcement
   that contains a `type' letter that it does not understand."
* "A session directory must ignore any
   attribute it doesn't understand."
 
 
1) Per section 7.1.8 RFC3015
   *  the "s=", "t=" and "o=" lines are optional,
2)
   *  the "s=", "t=" and "o=" lines are optional,
3) Can be omitted, seems to be encouraged, never used it.
5) RFC2327 page 12
 
 
Carl
 
-----Original Message-----
From: Abhi [mailto:abhishek@hfcl.com]
Sent: Friday, March 14, 2003 5:33 AM
To: megaco@ietf.org
Cc: milton@hfcl.com
Subject: [Megaco] query regarding the use of SDP
Hi,
As we know SDP is used to ecode and decode local and remote descriptor. I have certain doubts about some SDP paramters. They  are as follows:-
1. Do we reqire "o=" line in megaco?
    if present then
    a. Can we set username to hypen ("-")?
    b. Can NTP timestamp be used for session id and
        version?
 2.Do we need sesion name?
    If present can we use hyphen for that?
3..Do we need sesion and media information "i=" line ?
4..Do we need URI ?
5. How to use bandwidth "b=" line?
6. How to use "t=" line?
    If present, can we have a permanent session?
 NOTE :- RFC-3435(MGCP )  says
    * The start time may be set to zero.
   * The stop time should be set to zero.
7. .Do we need attributes
            a) a=cat:<category>
            b) a=keywds:<keywords>
            c) a=tool:<name & version of tool>?
8. Aren't "recvonly", "senrecv", "sendonlly" are redundant in
    Megaco?
9. How to use "a=type:<conference type>" in Megaco?
10 How to use attributes "a=sdplang" & "a=lang" in Megaco?
 
Thanks and regards
Abhishek Bansal
--=====================_562880599==.ALT-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Mar 17 13:00: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 NAA22943 for ; Mon, 17 Mar 2003 13:00: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 h2HIGrO21300; Mon, 17 Mar 2003 13:16: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 h2HIF6O21199 for ; Mon, 17 Mar 2003 13:15:06 -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 MAA22826 for ; Mon, 17 Mar 2003 12:58:05 -0500 (EST) Received: (qmail 13364 invoked from network); 17 Mar 2003 17:52:17 -0000 Received: from unknown (HELO zzzconn03.afc.local) (10.1.4.53) by 0 with SMTP; 17 Mar 2003 17:52:17 -0000 Received: FROM xconn01.afc.local BY zzzconn03.afc.local ; Mon Mar 17 10:01:36 2003 -0800 Received: by xconn01.afc.local with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Mar 2003 09:59:10 -0800 Message-ID: From: John Stock To: "'megaco@ietf.org'" Date: Mon, 17 Mar 2003 10:00:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Megaco] Questions about auditing terminations Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, I have a few questions about auditing terminations. The case I'm concerned about is where an MGC wishes to audit individual terminations in the MG. The MGC may or may not know the state of the termination in a call, i.e. whether or not it's involved in a context or not. This may arise out of these conditions I can think of: 1. The MGC resets and loses its connection database, and wants to query the MG to rebuild it. 2. The MG performs a switchover and loses a connection which it has Replied to the MGC. The MGC now has the context/term relationship but the MG does not. The MGC may wish to audit the terminations which had recent activity, based on receipt of ServiceChange with method Disconnected. 3. Other bad stuff like message loss, software bug, etc. My questions are: - In version 2, there's a new mechanism to retrieve a ContextID for a termination, using AuditValue with a specific TerminationId and a ContextId of ALL. However per the spec this applies only to non-NULL contexts. Why? The MGC may not know whether or not the termination is involved in a context, thus it seems inappropriate for the MG to fail the command if the termination is in the NULL context. It seems like it would be appropriate to just return a null ContextId if the termination is not in a call. - Relating to the previous question, it seems like it would be appropriate for the MGC to use a value of CHOOSE in this case instead of ALL. ALL implies that multiple values may be returned, however since a termination can only be involved in one context at a time this isn't valid. I know the MG isn't creating a new Context here, but it seems like in the AuditValue case the CHOOSE ContextId could be defined to query an existing ID instead of creating a new one. - The spec seems to be quite ambiguous regarding wildcard values, especially for ContextID. The text ABNF lists (UNIT32 / "*" / "-" / "$") as valid values for ContextId, however nowhere in the ABNF, or even elsewhere in the spec (that I can see - maybe I'm missing it), does it explicitly say what each of these parameters means, nor does it state in the referenced RFC2234. The only mention that "$" is used for CHOOSE is in the last sentence in B.1: "The CHOOSE TerminationID '$' may be used to signal to the MG that it has to create an ephemeral Termination...", however this seems to be merely a descriptive paragraph and not a specification, and doesn't even reference ContextID; it's discussing TerminationID. I'm actually more concerned about "*" vs. "-" -- which one of these is ALL? I'm sure it's the former, but it doesn't seem to be specified anywhere. Thanks. John Stock Systems Engineering Advanced Fibre Communications john.stock@afc.com 707-792-6249 And now for the standard disclaimer (don't lawyers just make life fun?): This message (including any attachments) is intended only for the use of the named addressee(s), and may contain information that is legally privileged, confidential or exempt from disclosure under applicable law. If you are not a named addressee, you are hereby notified that any use, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the original sender immediately by telephone or by return E-mail and delete this message, along with any attachments, from your computer. Thank you. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Mar 17 13:01: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 NAA22978 for ; Mon, 17 Mar 2003 13:01:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HIIN421390 for megaco-archive@odin.ietf.org; Mon, 17 Mar 2003 13:18: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 h2HIINO21387 for ; Mon, 17 Mar 2003 13:18: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 NAA22974 for ; Mon, 17 Mar 2003 13: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 h2HIGrO21300; Mon, 17 Mar 2003 13:16: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 h2HIF6O21199 for ; Mon, 17 Mar 2003 13:15:06 -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 MAA22826 for ; Mon, 17 Mar 2003 12:58:05 -0500 (EST) Received: (qmail 13364 invoked from network); 17 Mar 2003 17:52:17 -0000 Received: from unknown (HELO zzzconn03.afc.local) (10.1.4.53) by 0 with SMTP; 17 Mar 2003 17:52:17 -0000 Received: FROM xconn01.afc.local BY zzzconn03.afc.local ; Mon Mar 17 10:01:36 2003 -0800 Received: by xconn01.afc.local with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Mar 2003 09:59:10 -0800 Message-ID: From: John Stock To: "'megaco@ietf.org'" Date: Mon, 17 Mar 2003 10:00:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Megaco] Questions about auditing terminations Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, I have a few questions about auditing terminations. The case I'm concerned about is where an MGC wishes to audit individual terminations in the MG. The MGC may or may not know the state of the termination in a call, i.e. whether or not it's involved in a context or not. This may arise out of these conditions I can think of: 1. The MGC resets and loses its connection database, and wants to query the MG to rebuild it. 2. The MG performs a switchover and loses a connection which it has Replied to the MGC. The MGC now has the context/term relationship but the MG does not. The MGC may wish to audit the terminations which had recent activity, based on receipt of ServiceChange with method Disconnected. 3. Other bad stuff like message loss, software bug, etc. My questions are: - In version 2, there's a new mechanism to retrieve a ContextID for a termination, using AuditValue with a specific TerminationId and a ContextId of ALL. However per the spec this applies only to non-NULL contexts. Why? The MGC may not know whether or not the termination is involved in a context, thus it seems inappropriate for the MG to fail the command if the termination is in the NULL context. It seems like it would be appropriate to just return a null ContextId if the termination is not in a call. - Relating to the previous question, it seems like it would be appropriate for the MGC to use a value of CHOOSE in this case instead of ALL. ALL implies that multiple values may be returned, however since a termination can only be involved in one context at a time this isn't valid. I know the MG isn't creating a new Context here, but it seems like in the AuditValue case the CHOOSE ContextId could be defined to query an existing ID instead of creating a new one. - The spec seems to be quite ambiguous regarding wildcard values, especially for ContextID. The text ABNF lists (UNIT32 / "*" / "-" / "$") as valid values for ContextId, however nowhere in the ABNF, or even elsewhere in the spec (that I can see - maybe I'm missing it), does it explicitly say what each of these parameters means, nor does it state in the referenced RFC2234. The only mention that "$" is used for CHOOSE is in the last sentence in B.1: "The CHOOSE TerminationID '$' may be used to signal to the MG that it has to create an ephemeral Termination...", however this seems to be merely a descriptive paragraph and not a specification, and doesn't even reference ContextID; it's discussing TerminationID. I'm actually more concerned about "*" vs. "-" -- which one of these is ALL? I'm sure it's the former, but it doesn't seem to be specified anywhere. Thanks. John Stock Systems Engineering Advanced Fibre Communications john.stock@afc.com 707-792-6249 And now for the standard disclaimer (don't lawyers just make life fun?): This message (including any attachments) is intended only for the use of the named addressee(s), and may contain information that is legally privileged, confidential or exempt from disclosure under applicable law. If you are not a named addressee, you are hereby notified that any use, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the original sender immediately by telephone or by return E-mail and delete this message, along with any attachments, from your computer. Thank you. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Mar 17 15:41: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 PAA00422 for ; Mon, 17 Mar 2003 15:41: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 h2HKvYO00675; Mon, 17 Mar 2003 15:57: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 h2HKueO00634 for ; Mon, 17 Mar 2003 15:56:40 -0500 Received: from zcars0m9.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00369 for ; Mon, 17 Mar 2003 15:39:36 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2HKfeK04058; Mon, 17 Mar 2003 15:41:40 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GDF4YGLC; Mon, 17 Mar 2003 15:41:40 -0500 Received: from nortelnetworks.com (acart41r.ca.nortel.com [47.129.49.161]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G7ZYWGJM; Mon, 17 Mar 2003 15:41:39 -0500 Message-ID: <3E7632FF.2090309@nortelnetworks.com> Date: Mon, 17 Mar 2003 15:41:35 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Abhi CC: Carl Rutter , Megaco List Subject: Re: [Megaco] query regarding the use of SDP References: <002701c2eaac$be0f3f60$1aa69384@abhishek> In-Reply-To: <002701c2eaac$be0f3f60$1aa69384@abhishek> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit They are as specified in RFC 2327. You cvan also check RFC 3426, if call signalling at the MGC level uses SIP. In other words, Megaco itself does not specify any special use of these lines. Abhi wrote: > regarding 2 and 3 > if this is the case then how to use these parameters "s=", "t=", "o=" in > megaco. > what are the possible values of different fields > thanks and regards > Abhishek _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Mar 17 15:42: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 PAA00451 for ; Mon, 17 Mar 2003 15:42:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HKxVZ00789 for megaco-archive@odin.ietf.org; Mon, 17 Mar 2003 15:59: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 h2HKxVO00786 for ; Mon, 17 Mar 2003 15:59: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 PAA00447 for ; Mon, 17 Mar 2003 15:42: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 h2HKvYO00675; Mon, 17 Mar 2003 15:57: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 h2HKueO00634 for ; Mon, 17 Mar 2003 15:56:40 -0500 Received: from zcars0m9.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00369 for ; Mon, 17 Mar 2003 15:39:36 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2HKfeK04058; Mon, 17 Mar 2003 15:41:40 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GDF4YGLC; Mon, 17 Mar 2003 15:41:40 -0500 Received: from nortelnetworks.com (acart41r.ca.nortel.com [47.129.49.161]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G7ZYWGJM; Mon, 17 Mar 2003 15:41:39 -0500 Message-ID: <3E7632FF.2090309@nortelnetworks.com> Date: Mon, 17 Mar 2003 15:41:35 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Abhi CC: Carl Rutter , Megaco List Subject: Re: [Megaco] query regarding the use of SDP References: <002701c2eaac$be0f3f60$1aa69384@abhishek> In-Reply-To: <002701c2eaac$be0f3f60$1aa69384@abhishek> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit They are as specified in RFC 2327. You cvan also check RFC 3426, if call signalling at the MGC level uses SIP. In other words, Megaco itself does not specify any special use of these lines. Abhi wrote: > regarding 2 and 3 > if this is the case then how to use these parameters "s=", "t=", "o=" in > megaco. > what are the possible values of different fields > thanks and regards > Abhishek _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Mar 17 15:54: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 PAA00806 for ; Mon, 17 Mar 2003 15:54: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 h2HLA7O02207; Mon, 17 Mar 2003 16:10: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 h2HL9nO02175 for ; Mon, 17 Mar 2003 16:09:49 -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 PAA00790 for ; Mon, 17 Mar 2003 15:52:44 -0500 (EST) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2HKson07258; Mon, 17 Mar 2003 15:54:50 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GDFB77QZ; Mon, 17 Mar 2003 15:54:50 -0500 Received: from nortelnetworks.com (acart41r.ca.nortel.com [47.129.49.161]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G7ZYWGJV; Mon, 17 Mar 2003 15:54:50 -0500 Message-ID: <3E763616.9090004@nortelnetworks.com> Date: Mon, 17 Mar 2003 15:54:46 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Abhi , Megaco List CC: milton@hfcl.com Subject: Re: [Megaco] query regarding the use of SDP References: <001b01c2ea15$21d31690$1aa69384@abhishek> In-Reply-To: <001b01c2ea15$21d31690$1aa69384@abhishek> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Some new answers below. Abhi wrote: > Hi, > As we know SDP is used to ecode and decode local and remote descriptor. > I have certain doubts about some SDP paramters. They are as follows:- > 1. Do we reqire "o=" line in megaco? > if present then > a. Can we set username to hypen ("-")? > b. Can NTP timestamp be used for session id and > version? > 2.Do we need sesion name? > If present can we use hyphen for that? > 3..Do we need sesion and media information "i=" line ? > 4..Do we need URI ? No special use in Megaco. I suspect this is most useful in the original use of SDP for session announcements, rather than interative session negotiation. > 5. How to use bandwidth "b=" line? > 6. How to use "t=" line? > If present, can we have a permanent session? > NOTE :- RFC-3435(MGCP ) says > * The start time may be set to zero. > * The stop time should be set to zero. No special Megaco instructions. Basically should take your cue from SIP. > > 7. .Do we need attributes > a) a=cat: > b) a=keywds: > c) a=tool:? Very application dependent. a) and b) would only be useful in a system where the MG can display the information conveyed by these attributes to an user. c) might be useful to a specialized MG which supports the tool concerned. > 8. Aren't "recvonly", "senrecv", "sendonlly" are redundant in > Megaco? Yes. They must not be used. > 9. How to use "a=type:" in Megaco? Similarly application-dependent. I suspect the information conveyed by this attribute is only meaningful at the MGC level. > 10 How to use attributes "a=sdplang" & "a=lang" in Megaco? Once more: these relate to information that may be displayed to an user. This is a querstion of MG and user terminal design and the interface between them. > > Thanks and regards > Abhishek Bansal _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Mar 17 15: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 PAA00830 for ; Mon, 17 Mar 2003 15:55:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HLBdu02276 for megaco-archive@odin.ietf.org; Mon, 17 Mar 2003 16:11: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 h2HLBcO02273 for ; Mon, 17 Mar 2003 16:11: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 PAA00825 for ; Mon, 17 Mar 2003 15:54: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 h2HLA7O02207; Mon, 17 Mar 2003 16:10: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 h2HL9nO02175 for ; Mon, 17 Mar 2003 16:09:49 -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 PAA00790 for ; Mon, 17 Mar 2003 15:52:44 -0500 (EST) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2HKson07258; Mon, 17 Mar 2003 15:54:50 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GDFB77QZ; Mon, 17 Mar 2003 15:54:50 -0500 Received: from nortelnetworks.com (acart41r.ca.nortel.com [47.129.49.161]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G7ZYWGJV; Mon, 17 Mar 2003 15:54:50 -0500 Message-ID: <3E763616.9090004@nortelnetworks.com> Date: Mon, 17 Mar 2003 15:54:46 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Abhi , Megaco List CC: milton@hfcl.com Subject: Re: [Megaco] query regarding the use of SDP References: <001b01c2ea15$21d31690$1aa69384@abhishek> In-Reply-To: <001b01c2ea15$21d31690$1aa69384@abhishek> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Some new answers below. Abhi wrote: > Hi, > As we know SDP is used to ecode and decode local and remote descriptor. > I have certain doubts about some SDP paramters. They are as follows:- > 1. Do we reqire "o=" line in megaco? > if present then > a. Can we set username to hypen ("-")? > b. Can NTP timestamp be used for session id and > version? > 2.Do we need sesion name? > If present can we use hyphen for that? > 3..Do we need sesion and media information "i=" line ? > 4..Do we need URI ? No special use in Megaco. I suspect this is most useful in the original use of SDP for session announcements, rather than interative session negotiation. > 5. How to use bandwidth "b=" line? > 6. How to use "t=" line? > If present, can we have a permanent session? > NOTE :- RFC-3435(MGCP ) says > * The start time may be set to zero. > * The stop time should be set to zero. No special Megaco instructions. Basically should take your cue from SIP. > > 7. .Do we need attributes > a) a=cat: > b) a=keywds: > c) a=tool:? Very application dependent. a) and b) would only be useful in a system where the MG can display the information conveyed by these attributes to an user. c) might be useful to a specialized MG which supports the tool concerned. > 8. Aren't "recvonly", "senrecv", "sendonlly" are redundant in > Megaco? Yes. They must not be used. > 9. How to use "a=type:" in Megaco? Similarly application-dependent. I suspect the information conveyed by this attribute is only meaningful at the MGC level. > 10 How to use attributes "a=sdplang" & "a=lang" in Megaco? Once more: these relate to information that may be displayed to an user. This is a querstion of MG and user terminal design and the interface between them. > > Thanks and regards > Abhishek Bansal _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Mar 17 16:15: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 QAA01546 for ; Mon, 17 Mar 2003 16:15: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 h2HLVKO03332; Mon, 17 Mar 2003 16:31: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 h2HCHiO27810 for ; Mon, 17 Mar 2003 07:17:44 -0500 Received: from ipgen-india.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11173 for ; Mon, 17 Mar 2003 07:00:49 -0500 (EST) Received: from mohan [192.168.1.244] by ipgen-india.com [192.168.1.15] with SMTP (MDaemon.PRO.v5.0.7.T) for ; Mon, 17 Mar 2003 17:33:07 +0530 Message-ID: <012601c2ecef$168bba30$f401a8c0@mohan> From: "Mohan Hadimani" To: Cc: "keshav" , "Harikrishna C Warrier" , "Adiga" Date: Mon, 17 Mar 2003 17:38:33 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0123_01C2ECAC.08425490" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MDRemoteIP: 192.168.1.244 X-Return-Path: mohan@ipgen-india.com X-MDaemon-Deliver-To: megaco@ietf.org Subject: [Megaco] Media format related queries!! Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_0123_01C2ECAC.08425490 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I would like to know the answer for following 2 queries. 1). Its required to send multiple media formats in ADD command. Among the following, in which way I can send the ADD request to MG? m=3Daudio $ RTP/AVP fmt1 fmt2 fmt3 fmt4 or m=3Daudio $ RTP/AVP fmt1 m=3Daudio $ RTP/AVP fmt2 m=3Daudio $ RTP/AVP fmt3 m=3Daudio $ RTP/AVP fmt4 2). In which case MG will report multiple media formats in ADD reply? Because I tried by sending multiple formats in the above 2 methods, but MG is always reporting only the first format(default - = according to 2327) in ADD reply. Thanx & Regards Mohan ------=_NextPart_000_0123_01C2ECAC.08425490 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
I would like to know the answer for following 2 = queries.
 
1). Its required to send multiple media formats in = ADD=20 command.
     Among the following, in = which way I=20 can send the ADD request to MG?
 
      m=3Daudio $ RTP/AVP = fmt1 fmt2=20 fmt3 fmt4
      or
      m=3Daudio $ RTP/AVP=20 fmt1
      m=3Daudio $ RTP/AVP=20 fmt2
      m=3Daudio $ RTP/AVP=20 fmt3
      m=3Daudio $ RTP/AVP=20 fmt4
 
2). In which case MG will report multiple media formats in ADD = reply?
     Because I tried by sending multiple = formats in the=20 above 2 methods,
     but MG is always reporting only the first=20 format(default - according to 2327)
     in ADD reply.
 
Thanx & Regards
Mohan
 
------=_NextPart_000_0123_01C2ECAC.08425490-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Mar 17 16:16: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 QAA01586 for ; Mon, 17 Mar 2003 16:16:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HLWnb03411 for megaco-archive@odin.ietf.org; Mon, 17 Mar 2003 16:32: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 h2HLWnO03408 for ; Mon, 17 Mar 2003 16:32:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01566 for ; Mon, 17 Mar 2003 16:15: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 h2HLVKO03332; Mon, 17 Mar 2003 16:31: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 h2HCHiO27810 for ; Mon, 17 Mar 2003 07:17:44 -0500 Received: from ipgen-india.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11173 for ; Mon, 17 Mar 2003 07:00:49 -0500 (EST) Received: from mohan [192.168.1.244] by ipgen-india.com [192.168.1.15] with SMTP (MDaemon.PRO.v5.0.7.T) for ; Mon, 17 Mar 2003 17:33:07 +0530 Message-ID: <012601c2ecef$168bba30$f401a8c0@mohan> From: "Mohan Hadimani" To: Cc: "keshav" , "Harikrishna C Warrier" , "Adiga" Date: Mon, 17 Mar 2003 17:38:33 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0123_01C2ECAC.08425490" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MDRemoteIP: 192.168.1.244 X-Return-Path: mohan@ipgen-india.com X-MDaemon-Deliver-To: megaco@ietf.org Subject: [Megaco] Media format related queries!! Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_0123_01C2ECAC.08425490 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I would like to know the answer for following 2 queries. 1). Its required to send multiple media formats in ADD command. Among the following, in which way I can send the ADD request to MG? m=3Daudio $ RTP/AVP fmt1 fmt2 fmt3 fmt4 or m=3Daudio $ RTP/AVP fmt1 m=3Daudio $ RTP/AVP fmt2 m=3Daudio $ RTP/AVP fmt3 m=3Daudio $ RTP/AVP fmt4 2). In which case MG will report multiple media formats in ADD reply? Because I tried by sending multiple formats in the above 2 methods, but MG is always reporting only the first format(default - = according to 2327) in ADD reply. Thanx & Regards Mohan ------=_NextPart_000_0123_01C2ECAC.08425490 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
I would like to know the answer for following 2 = queries.
 
1). Its required to send multiple media formats in = ADD=20 command.
     Among the following, in = which way I=20 can send the ADD request to MG?
 
      m=3Daudio $ RTP/AVP = fmt1 fmt2=20 fmt3 fmt4
      or
      m=3Daudio $ RTP/AVP=20 fmt1
      m=3Daudio $ RTP/AVP=20 fmt2
      m=3Daudio $ RTP/AVP=20 fmt3
      m=3Daudio $ RTP/AVP=20 fmt4
 
2). In which case MG will report multiple media formats in ADD = reply?
     Because I tried by sending multiple = formats in the=20 above 2 methods,
     but MG is always reporting only the first=20 format(default - according to 2327)
     in ADD reply.
 
Thanx & Regards
Mohan
 
------=_NextPart_000_0123_01C2ECAC.08425490-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Mar 17 18:01: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 SAA05890 for ; Mon, 17 Mar 2003 18:01: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 h2HNHMO12729; Mon, 17 Mar 2003 18:17: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 h2HNGlO12667 for ; Mon, 17 Mar 2003 18:16:47 -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 RAA05798 for ; Mon, 17 Mar 2003 17:59:40 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2HN1gwv011492; Tue, 18 Mar 2003 00:01:47 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVPGWYX; Tue, 18 Mar 2003 00:01:41 +0100 Received: from lmf.ericsson.se (vrrch1-177057.am.ericsson.se [138.85.177.57]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h2HN1e6B026954; Tue, 18 Mar 2003 01:01:41 +0200 (EET) Message-ID: <3E765420.22402CC4@lmf.ericsson.se> Date: Tue, 18 Mar 2003 01:02:57 +0200 X-Sybari-Trust: dbc42e02 9ffcebbb a5ee123c 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mohan Hadimani CC: megaco@ietf.org, keshav , Harikrishna C Warrier , Adiga Subject: Re: [Megaco] Megaco Media format related Queries!! References: <014701c2ed0a$53083d60$f401a8c0@mohan> 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, > 1). Its required to send multiple media formats in ADD command. > Among the following, in which way I can send the ADD request to > MG? v=0 c=IN IP4 $ m=audio $ RTP/AVP fmt1 fmt2 fmt3 > fmt4 or v=0 c=IN IP4 $ m=audio $ RTP/AVP > fmt1 v=0 c=IN IP4 $ m=audio $ RTP/AVP fmt2 > v=0 c=IN IP4 $ m=audio $ RTP/AVP fmt3 v=0 c=IN > IP4 $ m=audio $ RTP/AVP fmt4 > > [CHH] I guess you can use either alternative, and for your specific > example I would go for the first alternative. H.248 DOES allow you to > send multiple media formats (codecs) in a single m= line (H.248 allows > only a single m= line per SDP, but that's another issue...) > 2). In which case MG will report multiple media formats in ADD reply? > > [CHH] The MG can report multiple media formats in EITHER case, > depending on the values you give to ReserveValue and ReserveGroup. > Because I tried by sending multiple formats in the above 2 methods, > but MG is always reporting only the first format(default - according > to 2327) in ADD reply. > > [CHH] Again, it depends on the ReserveGroup and ReserveValue property > values (and also on the capabilities of your MG, I guess). But, like I > said earlier, I would use the first alternative, unless there is some > specific reason you can't do so. > > Regards, > > Christer Holmberg > Ericsson Finland _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Mar 17 18:02: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 SAA05913 for ; Mon, 17 Mar 2003 18:02:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HNJ2r12794 for megaco-archive@odin.ietf.org; Mon, 17 Mar 2003 18:19: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 h2HNJ2O12791 for ; Mon, 17 Mar 2003 18:19: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 SAA05908 for ; Mon, 17 Mar 2003 18:01: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 h2HNHMO12729; Mon, 17 Mar 2003 18:17: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 h2HNGlO12667 for ; Mon, 17 Mar 2003 18:16:47 -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 RAA05798 for ; Mon, 17 Mar 2003 17:59:40 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2HN1gwv011492; Tue, 18 Mar 2003 00:01:47 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVPGWYX; Tue, 18 Mar 2003 00:01:41 +0100 Received: from lmf.ericsson.se (vrrch1-177057.am.ericsson.se [138.85.177.57]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h2HN1e6B026954; Tue, 18 Mar 2003 01:01:41 +0200 (EET) Message-ID: <3E765420.22402CC4@lmf.ericsson.se> Date: Tue, 18 Mar 2003 01:02:57 +0200 X-Sybari-Trust: dbc42e02 9ffcebbb a5ee123c 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mohan Hadimani CC: megaco@ietf.org, keshav , Harikrishna C Warrier , Adiga Subject: Re: [Megaco] Megaco Media format related Queries!! References: <014701c2ed0a$53083d60$f401a8c0@mohan> 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, > 1). Its required to send multiple media formats in ADD command. > Among the following, in which way I can send the ADD request to > MG? v=0 c=IN IP4 $ m=audio $ RTP/AVP fmt1 fmt2 fmt3 > fmt4 or v=0 c=IN IP4 $ m=audio $ RTP/AVP > fmt1 v=0 c=IN IP4 $ m=audio $ RTP/AVP fmt2 > v=0 c=IN IP4 $ m=audio $ RTP/AVP fmt3 v=0 c=IN > IP4 $ m=audio $ RTP/AVP fmt4 > > [CHH] I guess you can use either alternative, and for your specific > example I would go for the first alternative. H.248 DOES allow you to > send multiple media formats (codecs) in a single m= line (H.248 allows > only a single m= line per SDP, but that's another issue...) > 2). In which case MG will report multiple media formats in ADD reply? > > [CHH] The MG can report multiple media formats in EITHER case, > depending on the values you give to ReserveValue and ReserveGroup. > Because I tried by sending multiple formats in the above 2 methods, > but MG is always reporting only the first format(default - according > to 2327) in ADD reply. > > [CHH] Again, it depends on the ReserveGroup and ReserveValue property > values (and also on the capabilities of your MG, I guess). But, like I > said earlier, I would use the first alternative, unless there is some > specific reason you can't do so. > > Regards, > > Christer Holmberg > Ericsson Finland _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Mar 17 22:58: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 WAA15963 for ; Mon, 17 Mar 2003 22:58: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 h2I4EuO01400; Mon, 17 Mar 2003 23:14: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 h2I4DCO01342 for ; Mon, 17 Mar 2003 23:13:12 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15752 for ; Mon, 17 Mar 2003 22:55:53 -0500 (EST) From: knayar@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2I3uIs14575 for ; Tue, 18 Mar 2003 09:26:18 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2I3uH214570; Tue, 18 Mar 2003 09:26:17 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2I3x1V01383; Tue, 18 Mar 2003 09:29:02 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CED.0014942D ; Tue, 18 Mar 2003 09:14:46 +0530 X-Lotus-FromDomain: HSS To: "Kevin Boyle" cc: "Tom-PT Taylor" , klaha@hss.hns.com, gsachin@hss.hns.com, Megaco List Message-ID: <65256CED.0014941C.00@dlfmail1.hss.hns.com> Date: Tue, 18 Mar 2003 09:25:04 +0530 Subject: RE: [Megaco] Service change Restart 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 Kevin Thanks for the useful pointer... I did like to know if the Annex-F is intended to be part of H.248v2 only or will also be applicable to H.248v1. Any information about the time lines by when it would be finalised/ freezed. regards, -kapil nayar http://www.hssworld.com "Kevin Boyle" on 03/14/2003 08:33:23 PM To: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS cc: Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: Kapil Nayar/HSS) Subject: RE: [Megaco] Service change Restart This work is ongoing in SG16 as future Annex F. Both of these items are intended to be clarified by the new work. The input documents to the San Jose Rapporteurs' Meeting can be found as AVD-2310, AVD-2311, and AVD-2298 at ftp://standard.pictel.com/avc-site/0302_San/. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Friday, March 14, 2003 9:30 AM To: klaha@hss.hns.com Cc: gsachin@hss.hns.com; Megaco List Subject: Re: [Megaco] Service change Restart This is where the RFC is completely inadequate as it stands. I wouldn't mind seeing it rewritten to specify separately what happens for ServiceChange on ROOT vs. ServiceChange on individual terminations. With regard to the latter, there is also something else I'd like to see ironed out: the service state is a writable property in TerminationState, yet it is manipulated by ServiceChange. One or the other of these should go. I am quite prepared to submit a proposal for new text for section 7.2.8 in particular. Would there be interest in reviewing such a proposal? We could submit it as a contribution into SG 16's May meeting if that is workable. klaha@hss.hns.com wrote: > > How about ServiceChange Restart on ROOT from MGC?Does the protocol > inhibit it? (It can be an easier means for the MGC to inform MG to > delete all contexts rather than 'Subtract'ing each of them, when MGC > is taken gracefully > out-of-service) > > > > > > Tom Taylor on 03/14/2003 12:27:35 AM > > To: Sachin Gupta-PNGN/HSS@HSS, Megaco List > cc: (bcc: Kushanava Laha/HSS) > > Subject: Re: [Megaco] Service change Restart > > > > I agree that it's very difficult to assign any real meaning to an > MGC-initiated restart of a termination. My background in switch > software development tells me that a restart clears certain aspects of > state. However, that makes little sense in the Megaco case, because > the MGC can do that directly by subtracting the termination > from any context it is in and resetting descriptors if it is not in a context. > > Conclusion: the only thing an MGC-initiated restart of a termination > does is change its state to in-service if it is not already there. > > gsachin@hss.hns.com wrote: > >>Hi List >>I have a query regarding the processing of Service Change Restart. >>consider the following scenario: >> >>Termination is in state InService. >>Command recieved from MGC to Restart the termination (with or wothout >>delay). >> >>what MG could possibly do in this case? >> >> >>Thanks >>Sachin Gupta >> > > [disclaimer snipped] > > _______________________________________________ > 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 Mon Mar 17 22:59: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 WAA16000 for ; Mon, 17 Mar 2003 22:59:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2I4GZb01534 for megaco-archive@odin.ietf.org; Mon, 17 Mar 2003 23:16: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 h2I4GZO01531 for ; Mon, 17 Mar 2003 23:16: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 WAA15984 for ; Mon, 17 Mar 2003 22:59: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 h2I4EuO01400; Mon, 17 Mar 2003 23:14: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 h2I4DCO01342 for ; Mon, 17 Mar 2003 23:13:12 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15752 for ; Mon, 17 Mar 2003 22:55:53 -0500 (EST) From: knayar@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2I3uIs14575 for ; Tue, 18 Mar 2003 09:26:18 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2I3uH214570; Tue, 18 Mar 2003 09:26:17 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2I3x1V01383; Tue, 18 Mar 2003 09:29:02 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CED.0014942D ; Tue, 18 Mar 2003 09:14:46 +0530 X-Lotus-FromDomain: HSS To: "Kevin Boyle" cc: "Tom-PT Taylor" , klaha@hss.hns.com, gsachin@hss.hns.com, Megaco List Message-ID: <65256CED.0014941C.00@dlfmail1.hss.hns.com> Date: Tue, 18 Mar 2003 09:25:04 +0530 Subject: RE: [Megaco] Service change Restart 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 Kevin Thanks for the useful pointer... I did like to know if the Annex-F is intended to be part of H.248v2 only or will also be applicable to H.248v1. Any information about the time lines by when it would be finalised/ freezed. regards, -kapil nayar http://www.hssworld.com "Kevin Boyle" on 03/14/2003 08:33:23 PM To: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS cc: Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: Kapil Nayar/HSS) Subject: RE: [Megaco] Service change Restart This work is ongoing in SG16 as future Annex F. Both of these items are intended to be clarified by the new work. The input documents to the San Jose Rapporteurs' Meeting can be found as AVD-2310, AVD-2311, and AVD-2298 at ftp://standard.pictel.com/avc-site/0302_San/. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Friday, March 14, 2003 9:30 AM To: klaha@hss.hns.com Cc: gsachin@hss.hns.com; Megaco List Subject: Re: [Megaco] Service change Restart This is where the RFC is completely inadequate as it stands. I wouldn't mind seeing it rewritten to specify separately what happens for ServiceChange on ROOT vs. ServiceChange on individual terminations. With regard to the latter, there is also something else I'd like to see ironed out: the service state is a writable property in TerminationState, yet it is manipulated by ServiceChange. One or the other of these should go. I am quite prepared to submit a proposal for new text for section 7.2.8 in particular. Would there be interest in reviewing such a proposal? We could submit it as a contribution into SG 16's May meeting if that is workable. klaha@hss.hns.com wrote: > > How about ServiceChange Restart on ROOT from MGC?Does the protocol > inhibit it? (It can be an easier means for the MGC to inform MG to > delete all contexts rather than 'Subtract'ing each of them, when MGC > is taken gracefully > out-of-service) > > > > > > Tom Taylor on 03/14/2003 12:27:35 AM > > To: Sachin Gupta-PNGN/HSS@HSS, Megaco List > cc: (bcc: Kushanava Laha/HSS) > > Subject: Re: [Megaco] Service change Restart > > > > I agree that it's very difficult to assign any real meaning to an > MGC-initiated restart of a termination. My background in switch > software development tells me that a restart clears certain aspects of > state. However, that makes little sense in the Megaco case, because > the MGC can do that directly by subtracting the termination > from any context it is in and resetting descriptors if it is not in a context. > > Conclusion: the only thing an MGC-initiated restart of a termination > does is change its state to in-service if it is not already there. > > gsachin@hss.hns.com wrote: > >>Hi List >>I have a query regarding the processing of Service Change Restart. >>consider the following scenario: >> >>Termination is in state InService. >>Command recieved from MGC to Restart the termination (with or wothout >>delay). >> >>what MG could possibly do in this case? >> >> >>Thanks >>Sachin Gupta >> > > [disclaimer snipped] > > _______________________________________________ > 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 Tue Mar 18 03:41: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 DAA04358 for ; Tue, 18 Mar 2003 03:40: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 h2I8tCO29510; Tue, 18 Mar 2003 03:55: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 h2I8qVO29414 for ; Tue, 18 Mar 2003 03:52:31 -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 DAA04257 for ; Tue, 18 Mar 2003 03:35:09 -0500 (EST) From: bvswamy@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 h2I8ZXs19911 for ; Tue, 18 Mar 2003 14:05:33 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2I8ZW219901; Tue, 18 Mar 2003 14:05:32 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2I8cGT26955; Tue, 18 Mar 2003 14:08:16 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CED.002E2300 ; Tue, 18 Mar 2003 13:53:56 +0530 X-Lotus-FromDomain: HSS To: knayar@hss.hns.com cc: "Kevin Boyle" , "Tom-PT Taylor" , Megaco List Message-ID: <65256CED.002E211D.00@dlfmail1.hss.hns.com> Date: Tue, 18 Mar 2003 14:09:19 +0530 Subject: RE: [Megaco] Service change Restart 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 Related to Service change restart I have few queries: 1) What should MG do when it receives Service Change Restart on a already inservice termination which is in Non-Null context Should it give a error response or whether MG should clear the call and remove the termination from the context ? 2) If ServiceChange Restart with delay is recd by MG for an already Inservice termination which may or may not be in call then what should be MG behaviour. Should it mark the termination as Out-Of-Service till the delay timer expires and remove the termination from the context or give a error response ? 3) If Service Change Graceful with delay is received by MG for an already out of service termination then how should MG behave? Should it mark the termination in-service right now and after timer expiry mark it out-of-service or should it give an error? In all of the above cases if MG were to give a error response then there is no error-code defined which specifies that MG is already in the state which MGC has requested , however there is an error-code "Not-Ready" defined as "The command directed to a termination was not executed because of the service state of the termination" which can be used in these situations for conveying MGC that requested operation is not done. 3) What should be the MGC behaviour in the following scenario: 1) MGC recevies a Service Change graceful with NonNull delay for a termination in context. 2) Now MG want to cancel the graceful timer. The only way do currently is by sending a service Change Restart. Now what should be MGC behaviour. Should it only stop the timer and continue the call or end the call and the mark the termination as Inservice. I Hope all these issues are addressed in the SG16 Annex F. Regards Venkat knayar@hss.hns.com on 03/18/2003 09:25:04 AM To: "Kevin Boyle" cc: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS, Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: B Venkat S.R Swamy/HSS) Subject: RE: [Megaco] Service change Restart Hi Kevin Thanks for the useful pointer... I did like to know if the Annex-F is intended to be part of H.248v2 only or will also be applicable to H.248v1. Any information about the time lines by when it would be finalised/ freezed. regards, -kapil nayar http://www.hssworld.com "Kevin Boyle" on 03/14/2003 08:33:23 PM To: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS cc: Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: Kapil Nayar/HSS) Subject: RE: [Megaco] Service change Restart This work is ongoing in SG16 as future Annex F. Both of these items are intended to be clarified by the new work. The input documents to the San Jose Rapporteurs' Meeting can be found as AVD-2310, AVD-2311, and AVD-2298 at ftp://standard.pictel.com/avc-site/0302_San/. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Friday, March 14, 2003 9:30 AM To: klaha@hss.hns.com Cc: gsachin@hss.hns.com; Megaco List Subject: Re: [Megaco] Service change Restart This is where the RFC is completely inadequate as it stands. I wouldn't mind seeing it rewritten to specify separately what happens for ServiceChange on ROOT vs. ServiceChange on individual terminations. With regard to the latter, there is also something else I'd like to see ironed out: the service state is a writable property in TerminationState, yet it is manipulated by ServiceChange. One or the other of these should go. I am quite prepared to submit a proposal for new text for section 7.2.8 in particular. Would there be interest in reviewing such a proposal? We could submit it as a contribution into SG 16's May meeting if that is workable. klaha@hss.hns.com wrote: > > How about ServiceChange Restart on ROOT from MGC?Does the protocol > inhibit it? (It can be an easier means for the MGC to inform MG to > delete all contexts rather than 'Subtract'ing each of them, when MGC > is taken gracefully > out-of-service) > > > > > > Tom Taylor on 03/14/2003 12:27:35 AM > > To: Sachin Gupta-PNGN/HSS@HSS, Megaco List > cc: (bcc: Kushanava Laha/HSS) > > Subject: Re: [Megaco] Service change Restart > > > > I agree that it's very difficult to assign any real meaning to an > MGC-initiated restart of a termination. My background in switch > software development tells me that a restart clears certain aspects of > state. However, that makes little sense in the Megaco case, because > the MGC can do that directly by subtracting the termination > from any context it is in and resetting descriptors if it is not in a context. > > Conclusion: the only thing an MGC-initiated restart of a termination > does is change its state to in-service if it is not already there. > > gsachin@hss.hns.com wrote: > >>Hi List >>I have a query regarding the processing of Service Change Restart. >>consider the following scenario: >> >>Termination is in state InService. >>Command recieved from MGC to Restart the termination (with or wothout >>delay). >> >>what MG could possibly do in this case? >> >> >>Thanks >>Sachin Gupta >> > > [disclaimer snipped] > > _______________________________________________ > 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 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Mar 18 03:42: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 DAA04381 for ; Tue, 18 Mar 2003 03:42:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2I8wwW29635 for megaco-archive@odin.ietf.org; Tue, 18 Mar 2003 03:58: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 h2I8wwO29632 for ; Tue, 18 Mar 2003 03:58: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 DAA04376 for ; Tue, 18 Mar 2003 03:41: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 h2I8tCO29510; Tue, 18 Mar 2003 03:55: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 h2I8qVO29414 for ; Tue, 18 Mar 2003 03:52:31 -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 DAA04257 for ; Tue, 18 Mar 2003 03:35:09 -0500 (EST) From: bvswamy@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 h2I8ZXs19911 for ; Tue, 18 Mar 2003 14:05:33 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2I8ZW219901; Tue, 18 Mar 2003 14:05:32 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2I8cGT26955; Tue, 18 Mar 2003 14:08:16 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CED.002E2300 ; Tue, 18 Mar 2003 13:53:56 +0530 X-Lotus-FromDomain: HSS To: knayar@hss.hns.com cc: "Kevin Boyle" , "Tom-PT Taylor" , Megaco List Message-ID: <65256CED.002E211D.00@dlfmail1.hss.hns.com> Date: Tue, 18 Mar 2003 14:09:19 +0530 Subject: RE: [Megaco] Service change Restart 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 Related to Service change restart I have few queries: 1) What should MG do when it receives Service Change Restart on a already inservice termination which is in Non-Null context Should it give a error response or whether MG should clear the call and remove the termination from the context ? 2) If ServiceChange Restart with delay is recd by MG for an already Inservice termination which may or may not be in call then what should be MG behaviour. Should it mark the termination as Out-Of-Service till the delay timer expires and remove the termination from the context or give a error response ? 3) If Service Change Graceful with delay is received by MG for an already out of service termination then how should MG behave? Should it mark the termination in-service right now and after timer expiry mark it out-of-service or should it give an error? In all of the above cases if MG were to give a error response then there is no error-code defined which specifies that MG is already in the state which MGC has requested , however there is an error-code "Not-Ready" defined as "The command directed to a termination was not executed because of the service state of the termination" which can be used in these situations for conveying MGC that requested operation is not done. 3) What should be the MGC behaviour in the following scenario: 1) MGC recevies a Service Change graceful with NonNull delay for a termination in context. 2) Now MG want to cancel the graceful timer. The only way do currently is by sending a service Change Restart. Now what should be MGC behaviour. Should it only stop the timer and continue the call or end the call and the mark the termination as Inservice. I Hope all these issues are addressed in the SG16 Annex F. Regards Venkat knayar@hss.hns.com on 03/18/2003 09:25:04 AM To: "Kevin Boyle" cc: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS, Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: B Venkat S.R Swamy/HSS) Subject: RE: [Megaco] Service change Restart Hi Kevin Thanks for the useful pointer... I did like to know if the Annex-F is intended to be part of H.248v2 only or will also be applicable to H.248v1. Any information about the time lines by when it would be finalised/ freezed. regards, -kapil nayar http://www.hssworld.com "Kevin Boyle" on 03/14/2003 08:33:23 PM To: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS cc: Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: Kapil Nayar/HSS) Subject: RE: [Megaco] Service change Restart This work is ongoing in SG16 as future Annex F. Both of these items are intended to be clarified by the new work. The input documents to the San Jose Rapporteurs' Meeting can be found as AVD-2310, AVD-2311, and AVD-2298 at ftp://standard.pictel.com/avc-site/0302_San/. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Friday, March 14, 2003 9:30 AM To: klaha@hss.hns.com Cc: gsachin@hss.hns.com; Megaco List Subject: Re: [Megaco] Service change Restart This is where the RFC is completely inadequate as it stands. I wouldn't mind seeing it rewritten to specify separately what happens for ServiceChange on ROOT vs. ServiceChange on individual terminations. With regard to the latter, there is also something else I'd like to see ironed out: the service state is a writable property in TerminationState, yet it is manipulated by ServiceChange. One or the other of these should go. I am quite prepared to submit a proposal for new text for section 7.2.8 in particular. Would there be interest in reviewing such a proposal? We could submit it as a contribution into SG 16's May meeting if that is workable. klaha@hss.hns.com wrote: > > How about ServiceChange Restart on ROOT from MGC?Does the protocol > inhibit it? (It can be an easier means for the MGC to inform MG to > delete all contexts rather than 'Subtract'ing each of them, when MGC > is taken gracefully > out-of-service) > > > > > > Tom Taylor on 03/14/2003 12:27:35 AM > > To: Sachin Gupta-PNGN/HSS@HSS, Megaco List > cc: (bcc: Kushanava Laha/HSS) > > Subject: Re: [Megaco] Service change Restart > > > > I agree that it's very difficult to assign any real meaning to an > MGC-initiated restart of a termination. My background in switch > software development tells me that a restart clears certain aspects of > state. However, that makes little sense in the Megaco case, because > the MGC can do that directly by subtracting the termination > from any context it is in and resetting descriptors if it is not in a context. > > Conclusion: the only thing an MGC-initiated restart of a termination > does is change its state to in-service if it is not already there. > > gsachin@hss.hns.com wrote: > >>Hi List >>I have a query regarding the processing of Service Change Restart. >>consider the following scenario: >> >>Termination is in state InService. >>Command recieved from MGC to Restart the termination (with or wothout >>delay). >> >>what MG could possibly do in this case? >> >> >>Thanks >>Sachin Gupta >> > > [disclaimer snipped] > > _______________________________________________ > 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 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Mar 18 11:07: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 LAA15237 for ; Tue, 18 Mar 2003 11:07: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 h2IGNuO24491; Tue, 18 Mar 2003 11:23: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 h2I3abO30908 for ; Mon, 17 Mar 2003 22:36:37 -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 WAA14904 for ; Mon, 17 Mar 2003 22:19:24 -0500 (EST) Received: from thinkpadi1492 ([141.157.27.143]) by out003.verizon.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030318032138.UZNB3697.out003.verizon.net@thinkpadi1492> for ; Mon, 17 Mar 2003 21:21:38 -0600 From: "David Kao" To: Date: Mon, 17 Mar 2003 22:21:36 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C2ECD3.929220E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Authentication-Info: Submitted using SMTP AUTH at out003.verizon.net from [141.157.27.143] at Mon, 17 Mar 2003 21:21:38 -0600 Subject: [Megaco] Processing Order of Context Properties and Termination Properties Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_0005_01C2ECD3.929220E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please accept my apology if the same questions were asked and discussed before. The spec says, "Transactions guarantee ordered Command processing. That is, Commands within a Transaction are executed sequentially." I have two relevant questions based on this statement. 1. How about the processing order of context properties? Are they supposed to be processed in the same same sequential order like the commands? For instance, based on previously posted emails from Christian Grove, topology descriptor should be processed before commands in an action, since "The Topology descriptor occurs before the commands in an action." In fact, all contextRequests come before the commands. If this is the case, is the following generalization correct? "In a transaction, actions are executed sequentially. In an action, context requests (including context property modifications and context property audits) and commands are executed sequentially." 2. How about the processing order of termination properties? Without a well-defined order, different MG implementations can respond differently to the same command. For instance, if Signals descriptor is processed before Events descriptor can produce different results than the case when Events descriptor is processed first. Regards, David Kao ------=_NextPart_000_0005_01C2ECD3.929220E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Please accept my apology if the same questions were asked and = discussed=20 before.

 

The spec=20 says, "Transactions=20 guarantee ordered Command processing. That is, Commands within a = Transaction are=20 executed sequentially." I have two relevant questions based on this=20 statement.

 

1. How about the processing order of context properties? Are = they=20 supposed to be processed in the same same sequential order like the=20 commands?

 

For instance, based on previously posted emails from Christian = Grove,=20 topology descriptor should be processed before commands in an action, = since "The=20 Topology descriptor occurs before the commands in an action." In fact, = all=20 contextRequests come before the commands. If this is the case, is the = following=20 generalization correct?

 

"In a transaction, actions are executed sequentially. In an = action,=20 context requests (including context property modifications and context = property=20 audits) and commands are executed = sequentially."

 

2. How about the processing order of termination properties? = Without a=20 well-defined order, different MG implementations can respond differently = to the=20 same command. For instance, if Signals descriptor is processed before = Events=20 descriptor can produce different results than the case when Events = descriptor is=20 processed first.

 

Regards,

 

David = Kao

 

------=_NextPart_000_0005_01C2ECD3.929220E0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Mar 18 11:08: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 LAA15300 for ; Tue, 18 Mar 2003 11:08:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IGPqC24640 for megaco-archive@odin.ietf.org; Tue, 18 Mar 2003 11:25: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 h2IGPqO24637 for ; Tue, 18 Mar 2003 11:25: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 LAA15287 for ; Tue, 18 Mar 2003 11:08: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 h2IGNuO24491; Tue, 18 Mar 2003 11:23: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 h2I3abO30908 for ; Mon, 17 Mar 2003 22:36:37 -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 WAA14904 for ; Mon, 17 Mar 2003 22:19:24 -0500 (EST) Received: from thinkpadi1492 ([141.157.27.143]) by out003.verizon.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030318032138.UZNB3697.out003.verizon.net@thinkpadi1492> for ; Mon, 17 Mar 2003 21:21:38 -0600 From: "David Kao" To: Date: Mon, 17 Mar 2003 22:21:36 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C2ECD3.929220E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Authentication-Info: Submitted using SMTP AUTH at out003.verizon.net from [141.157.27.143] at Mon, 17 Mar 2003 21:21:38 -0600 Subject: [Megaco] Processing Order of Context Properties and Termination Properties Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_0005_01C2ECD3.929220E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please accept my apology if the same questions were asked and discussed before. The spec says, "Transactions guarantee ordered Command processing. That is, Commands within a Transaction are executed sequentially." I have two relevant questions based on this statement. 1. How about the processing order of context properties? Are they supposed to be processed in the same same sequential order like the commands? For instance, based on previously posted emails from Christian Grove, topology descriptor should be processed before commands in an action, since "The Topology descriptor occurs before the commands in an action." In fact, all contextRequests come before the commands. If this is the case, is the following generalization correct? "In a transaction, actions are executed sequentially. In an action, context requests (including context property modifications and context property audits) and commands are executed sequentially." 2. How about the processing order of termination properties? Without a well-defined order, different MG implementations can respond differently to the same command. For instance, if Signals descriptor is processed before Events descriptor can produce different results than the case when Events descriptor is processed first. Regards, David Kao ------=_NextPart_000_0005_01C2ECD3.929220E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Please accept my apology if the same questions were asked and = discussed=20 before.

 

The spec=20 says, "Transactions=20 guarantee ordered Command processing. That is, Commands within a = Transaction are=20 executed sequentially." I have two relevant questions based on this=20 statement.

 

1. How about the processing order of context properties? Are = they=20 supposed to be processed in the same same sequential order like the=20 commands?

 

For instance, based on previously posted emails from Christian = Grove,=20 topology descriptor should be processed before commands in an action, = since "The=20 Topology descriptor occurs before the commands in an action." In fact, = all=20 contextRequests come before the commands. If this is the case, is the = following=20 generalization correct?

 

"In a transaction, actions are executed sequentially. In an = action,=20 context requests (including context property modifications and context = property=20 audits) and commands are executed = sequentially."

 

2. How about the processing order of termination properties? = Without a=20 well-defined order, different MG implementations can respond differently = to the=20 same command. For instance, if Signals descriptor is processed before = Events=20 descriptor can produce different results than the case when Events = descriptor is=20 processed first.

 

Regards,

 

David = Kao

 

------=_NextPart_000_0005_01C2ECD3.929220E0-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Mar 18 13:59: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 NAA24111 for ; Tue, 18 Mar 2003 13:59: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 h2IJFaO08701; Tue, 18 Mar 2003 14:15: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 h2IJD7O08487 for ; Tue, 18 Mar 2003 14:13:07 -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 NAA23841 for ; Tue, 18 Mar 2003 13:55:36 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2IIvnI01726 for ; Tue, 18 Mar 2003 13:57:49 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Mar 2003 13:57:49 -0500 Message-ID: From: "Kevin Boyle" To: knayar@hss.hns.com Cc: "Tom-PT Taylor" , klaha@hss.hns.com, gsachin@hss.hns.com, Megaco List Subject: RE: [Megaco] Service change Restart Date: Tue, 18 Mar 2003 13:57:46 -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 current plan is to incorporate it back into both V1 and V2 (since the new Annex doesn't change the existing spec, it only makes clarifications). The current timeline is May, however, I wouldn't be surprised if the Annex will be held until February 2004. Kevin -----Original Message----- From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] Sent: Monday, March 17, 2003 10:55 PM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; klaha@hss.hns.com; gsachin@hss.hns.com; Megaco List Subject: RE: [Megaco] Service change Restart Hi Kevin Thanks for the useful pointer... I did like to know if the Annex-F is intended to be part of H.248v2 only or will also be applicable to H.248v1. Any information about the time lines by when it would be finalised/ freezed. regards, -kapil nayar http://www.hssworld.com "Kevin Boyle" on 03/14/2003 08:33:23 PM To: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS cc: Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: Kapil Nayar/HSS) Subject: RE: [Megaco] Service change Restart This work is ongoing in SG16 as future Annex F. Both of these items are intended to be clarified by the new work. The input documents to the San Jose Rapporteurs' Meeting can be found as AVD-2310, AVD-2311, and AVD-2298 at ftp://standard.pictel.com/avc-site/0302_San/. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Friday, March 14, 2003 9:30 AM To: klaha@hss.hns.com Cc: gsachin@hss.hns.com; Megaco List Subject: Re: [Megaco] Service change Restart This is where the RFC is completely inadequate as it stands. I wouldn't mind seeing it rewritten to specify separately what happens for ServiceChange on ROOT vs. ServiceChange on individual terminations. With regard to the latter, there is also something else I'd like to see ironed out: the service state is a writable property in TerminationState, yet it is manipulated by ServiceChange. One or the other of these should go. I am quite prepared to submit a proposal for new text for section 7.2.8 in particular. Would there be interest in reviewing such a proposal? We could submit it as a contribution into SG 16's May meeting if that is workable. klaha@hss.hns.com wrote: > > How about ServiceChange Restart on ROOT from MGC?Does the protocol > inhibit it? (It can be an easier means for the MGC to inform MG to > delete all contexts rather than 'Subtract'ing each of them, when MGC > is taken gracefully > out-of-service) > > > > > > Tom Taylor on 03/14/2003 12:27:35 AM > > To: Sachin Gupta-PNGN/HSS@HSS, Megaco List > cc: (bcc: Kushanava Laha/HSS) > > Subject: Re: [Megaco] Service change Restart > > > > I agree that it's very difficult to assign any real meaning to an > MGC-initiated restart of a termination. My background in switch > software development tells me that a restart clears certain aspects of > state. However, that makes little sense in the Megaco case, because > the MGC can do that directly by subtracting the termination from any > context it is in and resetting descriptors if it is not in a context. > > Conclusion: the only thing an MGC-initiated restart of a termination > does is change its state to in-service if it is not already there. > > gsachin@hss.hns.com wrote: > >>Hi List >>I have a query regarding the processing of Service Change Restart. >>consider the following scenario: >> >>Termination is in state InService. >>Command recieved from MGC to Restart the termination (with or wothout >>delay). >> >>what MG could possibly do in this case? >> >> >>Thanks >>Sachin Gupta >> > > [disclaimer snipped] > > _______________________________________________ > 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 Tue Mar 18 13:59: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 NAA24167 for ; Tue, 18 Mar 2003 13:59: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 h2IJGCO08825; Tue, 18 Mar 2003 14: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 h2IJFpO08754 for ; Tue, 18 Mar 2003 14:15:51 -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 NAA24021 for ; Tue, 18 Mar 2003 13:58:20 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2IJ0XI05624 for ; Tue, 18 Mar 2003 14:00:33 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Mar 2003 14:00:33 -0500 Message-ID: From: "Kevin Boyle" To: David Kao , megaco@ietf.org Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties Date: Tue, 18 Mar 2003 14:00:27 -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: David Kao [mailto:david.kao@verizon.net] Sent: Monday, March 17, 2003 10:22 PM To: megaco@ietf.org Subject: [Megaco] Processing Order of Context Properties and Termination Properties Please accept my apology if the same questions were asked and discussed before. The spec says, "Transactions guarantee ordered Command processing. That is, Commands within a Transaction are executed sequentially." I have two relevant questions based on this statement. 1. How about the processing order of context properties? Are they supposed to be processed in the same same sequential order like the commands? For instance, based on previously posted emails from Christian Grove, topology descriptor should be processed before commands in an action, since "The Topology descriptor occurs before the commands in an action." In fact, all contextRequests come before the commands. If this is the case, is the following generalization correct? "In a transaction, actions are executed sequentially. In an action, context requests (including context property modifications and context property audits) and commands are executed sequentially." [KJBII] Yes. H.248 is, essentially, a left to right protocol. 2. How about the processing order of termination properties? Without a well-defined order, different MG implementations can respond differently to the same command. For instance, if Signals descriptor is processed before Events descriptor can produce different results than the case when Events descriptor is processed first. [KJBII] See above comment. Regards, David Kao _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Mar 18 14:00:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24226 for ; Tue, 18 Mar 2003 14:00:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IJHFT08912 for megaco-archive@odin.ietf.org; Tue, 18 Mar 2003 14:17: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 h2IJHEO08909 for ; Tue, 18 Mar 2003 14:17:14 -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 NAA24194 for ; Tue, 18 Mar 2003 13:59: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 h2IJFaO08701; Tue, 18 Mar 2003 14:15: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 h2IJD7O08487 for ; Tue, 18 Mar 2003 14:13:07 -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 NAA23841 for ; Tue, 18 Mar 2003 13:55:36 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2IIvnI01726 for ; Tue, 18 Mar 2003 13:57:49 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Mar 2003 13:57:49 -0500 Message-ID: From: "Kevin Boyle" To: knayar@hss.hns.com Cc: "Tom-PT Taylor" , klaha@hss.hns.com, gsachin@hss.hns.com, Megaco List Subject: RE: [Megaco] Service change Restart Date: Tue, 18 Mar 2003 13:57:46 -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 current plan is to incorporate it back into both V1 and V2 (since the new Annex doesn't change the existing spec, it only makes clarifications). The current timeline is May, however, I wouldn't be surprised if the Annex will be held until February 2004. Kevin -----Original Message----- From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] Sent: Monday, March 17, 2003 10:55 PM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; klaha@hss.hns.com; gsachin@hss.hns.com; Megaco List Subject: RE: [Megaco] Service change Restart Hi Kevin Thanks for the useful pointer... I did like to know if the Annex-F is intended to be part of H.248v2 only or will also be applicable to H.248v1. Any information about the time lines by when it would be finalised/ freezed. regards, -kapil nayar http://www.hssworld.com "Kevin Boyle" on 03/14/2003 08:33:23 PM To: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS cc: Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: Kapil Nayar/HSS) Subject: RE: [Megaco] Service change Restart This work is ongoing in SG16 as future Annex F. Both of these items are intended to be clarified by the new work. The input documents to the San Jose Rapporteurs' Meeting can be found as AVD-2310, AVD-2311, and AVD-2298 at ftp://standard.pictel.com/avc-site/0302_San/. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Friday, March 14, 2003 9:30 AM To: klaha@hss.hns.com Cc: gsachin@hss.hns.com; Megaco List Subject: Re: [Megaco] Service change Restart This is where the RFC is completely inadequate as it stands. I wouldn't mind seeing it rewritten to specify separately what happens for ServiceChange on ROOT vs. ServiceChange on individual terminations. With regard to the latter, there is also something else I'd like to see ironed out: the service state is a writable property in TerminationState, yet it is manipulated by ServiceChange. One or the other of these should go. I am quite prepared to submit a proposal for new text for section 7.2.8 in particular. Would there be interest in reviewing such a proposal? We could submit it as a contribution into SG 16's May meeting if that is workable. klaha@hss.hns.com wrote: > > How about ServiceChange Restart on ROOT from MGC?Does the protocol > inhibit it? (It can be an easier means for the MGC to inform MG to > delete all contexts rather than 'Subtract'ing each of them, when MGC > is taken gracefully > out-of-service) > > > > > > Tom Taylor on 03/14/2003 12:27:35 AM > > To: Sachin Gupta-PNGN/HSS@HSS, Megaco List > cc: (bcc: Kushanava Laha/HSS) > > Subject: Re: [Megaco] Service change Restart > > > > I agree that it's very difficult to assign any real meaning to an > MGC-initiated restart of a termination. My background in switch > software development tells me that a restart clears certain aspects of > state. However, that makes little sense in the Megaco case, because > the MGC can do that directly by subtracting the termination from any > context it is in and resetting descriptors if it is not in a context. > > Conclusion: the only thing an MGC-initiated restart of a termination > does is change its state to in-service if it is not already there. > > gsachin@hss.hns.com wrote: > >>Hi List >>I have a query regarding the processing of Service Change Restart. >>consider the following scenario: >> >>Termination is in state InService. >>Command recieved from MGC to Restart the termination (with or wothout >>delay). >> >>what MG could possibly do in this case? >> >> >>Thanks >>Sachin Gupta >> > > [disclaimer snipped] > > _______________________________________________ > 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 Tue Mar 18 14:00: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 OAA24245 for ; Tue, 18 Mar 2003 14:00:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IJHa108935 for megaco-archive@odin.ietf.org; Tue, 18 Mar 2003 14:17: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 h2IJHaO08932 for ; Tue, 18 Mar 2003 14:17: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 OAA24216 for ; Tue, 18 Mar 2003 14:00: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 h2IJGCO08825; Tue, 18 Mar 2003 14: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 h2IJFpO08754 for ; Tue, 18 Mar 2003 14:15:51 -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 NAA24021 for ; Tue, 18 Mar 2003 13:58:20 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2IJ0XI05624 for ; Tue, 18 Mar 2003 14:00:33 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Mar 2003 14:00:33 -0500 Message-ID: From: "Kevin Boyle" To: David Kao , megaco@ietf.org Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties Date: Tue, 18 Mar 2003 14:00:27 -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: David Kao [mailto:david.kao@verizon.net] Sent: Monday, March 17, 2003 10:22 PM To: megaco@ietf.org Subject: [Megaco] Processing Order of Context Properties and Termination Properties Please accept my apology if the same questions were asked and discussed before. The spec says, "Transactions guarantee ordered Command processing. That is, Commands within a Transaction are executed sequentially." I have two relevant questions based on this statement. 1. How about the processing order of context properties? Are they supposed to be processed in the same same sequential order like the commands? For instance, based on previously posted emails from Christian Grove, topology descriptor should be processed before commands in an action, since "The Topology descriptor occurs before the commands in an action." In fact, all contextRequests come before the commands. If this is the case, is the following generalization correct? "In a transaction, actions are executed sequentially. In an action, context requests (including context property modifications and context property audits) and commands are executed sequentially." [KJBII] Yes. H.248 is, essentially, a left to right protocol. 2. How about the processing order of termination properties? Without a well-defined order, different MG implementations can respond differently to the same command. For instance, if Signals descriptor is processed before Events descriptor can produce different results than the case when Events descriptor is processed first. [KJBII] See above comment. Regards, David Kao _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Mar 19 19:05: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 TAA16888 for ; Wed, 19 Mar 2003 19:05: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 h2K0MtO21835; Wed, 19 Mar 2003 19:22: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 h2K0KWO21697 for ; Wed, 19 Mar 2003 19:20:32 -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 TAA16761 for ; Wed, 19 Mar 2003 19:02:22 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2K04UHQ017926; Thu, 20 Mar 2003 01:04:30 +0100 (MET) Received: from brsf10.epa.ericsson.se ([146.11.8.4]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id HH7GJHDJ; Thu, 20 Mar 2003 01:04:29 +0100 Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h2K04PL25420; Thu, 20 Mar 2003 11:04:25 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.197]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HFD4KL4Z; Thu, 20 Mar 2003 11:04:22 +1100 Message-ID: <3E79057F.FB9FA3D1@ericsson.com.au> Date: Thu, 20 Mar 2003 11:04:15 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Boyle CC: knayar@hss.hns.com, Tom-PT Taylor , klaha@hss.hns.com, gsachin@hss.hns.com, Megaco List Subject: Re: [Megaco] Service change Restart 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, I don't think it has been decided to incorporate it back into both v1 and v2. >From discussion at SanJose I thought we would take the decision on what to do with the work ie. annex, appendix or merging when it came nearer to the time to approve the work. Regards, Christian Kevin Boyle wrote: > > The current plan is to incorporate it back into both V1 and V2 (since the > new Annex doesn't change the existing spec, it only makes clarifications). > The current timeline is May, however, I wouldn't be surprised if the Annex > will be held until February 2004. > > Kevin > > -----Original Message----- > From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] > Sent: Monday, March 17, 2003 10:55 PM > To: Boyle, Kevin [NCRTP:3Z40:EXCH] > Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; klaha@hss.hns.com; gsachin@hss.hns.com; > Megaco List > Subject: RE: [Megaco] Service change Restart > > Hi Kevin > > Thanks for the useful pointer... > I did like to know if the Annex-F is intended to be part of H.248v2 only or > will also be applicable to H.248v1. Any information about the time lines by > when it would be finalised/ freezed. > > regards, > -kapil nayar > http://www.hssworld.com > > "Kevin Boyle" on 03/14/2003 08:33:23 PM > > To: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS > cc: Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: Kapil > Nayar/HSS) > > Subject: RE: [Megaco] Service change Restart > > This work is ongoing in SG16 as future Annex F. Both of these items are > intended to be clarified by the new work. > > The input documents to the San Jose Rapporteurs' Meeting can be found as > AVD-2310, AVD-2311, and AVD-2298 at > ftp://standard.pictel.com/avc-site/0302_San/. > > Kevin > > -----Original Message----- > From: Taylor, Tom-PT [CAR:5N00:EXCH] > Sent: Friday, March 14, 2003 9:30 AM > To: klaha@hss.hns.com > Cc: gsachin@hss.hns.com; Megaco List > Subject: Re: [Megaco] Service change Restart > > This is where the RFC is completely inadequate as it stands. I wouldn't > mind seeing it rewritten to specify separately what happens for > ServiceChange on ROOT vs. ServiceChange on individual terminations. With > regard to the latter, there is also something else I'd like to see ironed > out: the service state is a writable property in TerminationState, yet it is > manipulated by ServiceChange. One or the other of these should go. > > I am quite prepared to submit a proposal for new text for section 7.2.8 in > particular. Would there be interest in reviewing such a proposal? We could > submit it as a contribution into SG 16's May meeting if that is workable. > > klaha@hss.hns.com wrote: > > > > How about ServiceChange Restart on ROOT from MGC?Does the protocol > > inhibit it? (It can be an easier means for the MGC to inform MG to > > delete all contexts rather than 'Subtract'ing each of them, when MGC > > is taken gracefully > > out-of-service) > > > > > > > > > > > > Tom Taylor on 03/14/2003 12:27:35 AM > > > > To: Sachin Gupta-PNGN/HSS@HSS, Megaco List > > cc: (bcc: Kushanava Laha/HSS) > > > > Subject: Re: [Megaco] Service change Restart > > > > > > > > I agree that it's very difficult to assign any real meaning to an > > MGC-initiated restart of a termination. My background in switch > > software development tells me that a restart clears certain aspects of > > state. However, that makes little sense in the Megaco case, because > > the MGC can do that directly by subtracting the termination from any > > context it is in and resetting descriptors if it is not in a > context. > > > > Conclusion: the only thing an MGC-initiated restart of a termination > > does is change its state to in-service if it is not already there. > > > > gsachin@hss.hns.com wrote: > > > >>Hi List > >>I have a query regarding the processing of Service Change Restart. > >>consider the following scenario: > >> > >>Termination is in state InService. > >>Command recieved from MGC to Restart the termination (with or wothout > >>delay). > >> > >>what MG could possibly do in this case? > >> > >> > >>Thanks > >>Sachin Gupta > >> > > > > [disclaimer snipped] > > > > _______________________________________________ > > 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 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Mar 19 19:07: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 TAA16992 for ; Wed, 19 Mar 2003 19:07:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K0Ofu21902 for megaco-archive@odin.ietf.org; Wed, 19 Mar 2003 19:24: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 h2K0OfO21899 for ; Wed, 19 Mar 2003 19:24: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 TAA16912 for ; Wed, 19 Mar 2003 19:06: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 h2K0MtO21835; Wed, 19 Mar 2003 19:22: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 h2K0KWO21697 for ; Wed, 19 Mar 2003 19:20:32 -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 TAA16761 for ; Wed, 19 Mar 2003 19:02:22 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2K04UHQ017926; Thu, 20 Mar 2003 01:04:30 +0100 (MET) Received: from brsf10.epa.ericsson.se ([146.11.8.4]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id HH7GJHDJ; Thu, 20 Mar 2003 01:04:29 +0100 Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h2K04PL25420; Thu, 20 Mar 2003 11:04:25 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.197]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HFD4KL4Z; Thu, 20 Mar 2003 11:04:22 +1100 Message-ID: <3E79057F.FB9FA3D1@ericsson.com.au> Date: Thu, 20 Mar 2003 11:04:15 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Boyle CC: knayar@hss.hns.com, Tom-PT Taylor , klaha@hss.hns.com, gsachin@hss.hns.com, Megaco List Subject: Re: [Megaco] Service change Restart 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, I don't think it has been decided to incorporate it back into both v1 and v2. >From discussion at SanJose I thought we would take the decision on what to do with the work ie. annex, appendix or merging when it came nearer to the time to approve the work. Regards, Christian Kevin Boyle wrote: > > The current plan is to incorporate it back into both V1 and V2 (since the > new Annex doesn't change the existing spec, it only makes clarifications). > The current timeline is May, however, I wouldn't be surprised if the Annex > will be held until February 2004. > > Kevin > > -----Original Message----- > From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] > Sent: Monday, March 17, 2003 10:55 PM > To: Boyle, Kevin [NCRTP:3Z40:EXCH] > Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; klaha@hss.hns.com; gsachin@hss.hns.com; > Megaco List > Subject: RE: [Megaco] Service change Restart > > Hi Kevin > > Thanks for the useful pointer... > I did like to know if the Annex-F is intended to be part of H.248v2 only or > will also be applicable to H.248v1. Any information about the time lines by > when it would be finalised/ freezed. > > regards, > -kapil nayar > http://www.hssworld.com > > "Kevin Boyle" on 03/14/2003 08:33:23 PM > > To: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS > cc: Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: Kapil > Nayar/HSS) > > Subject: RE: [Megaco] Service change Restart > > This work is ongoing in SG16 as future Annex F. Both of these items are > intended to be clarified by the new work. > > The input documents to the San Jose Rapporteurs' Meeting can be found as > AVD-2310, AVD-2311, and AVD-2298 at > ftp://standard.pictel.com/avc-site/0302_San/. > > Kevin > > -----Original Message----- > From: Taylor, Tom-PT [CAR:5N00:EXCH] > Sent: Friday, March 14, 2003 9:30 AM > To: klaha@hss.hns.com > Cc: gsachin@hss.hns.com; Megaco List > Subject: Re: [Megaco] Service change Restart > > This is where the RFC is completely inadequate as it stands. I wouldn't > mind seeing it rewritten to specify separately what happens for > ServiceChange on ROOT vs. ServiceChange on individual terminations. With > regard to the latter, there is also something else I'd like to see ironed > out: the service state is a writable property in TerminationState, yet it is > manipulated by ServiceChange. One or the other of these should go. > > I am quite prepared to submit a proposal for new text for section 7.2.8 in > particular. Would there be interest in reviewing such a proposal? We could > submit it as a contribution into SG 16's May meeting if that is workable. > > klaha@hss.hns.com wrote: > > > > How about ServiceChange Restart on ROOT from MGC?Does the protocol > > inhibit it? (It can be an easier means for the MGC to inform MG to > > delete all contexts rather than 'Subtract'ing each of them, when MGC > > is taken gracefully > > out-of-service) > > > > > > > > > > > > Tom Taylor on 03/14/2003 12:27:35 AM > > > > To: Sachin Gupta-PNGN/HSS@HSS, Megaco List > > cc: (bcc: Kushanava Laha/HSS) > > > > Subject: Re: [Megaco] Service change Restart > > > > > > > > I agree that it's very difficult to assign any real meaning to an > > MGC-initiated restart of a termination. My background in switch > > software development tells me that a restart clears certain aspects of > > state. However, that makes little sense in the Megaco case, because > > the MGC can do that directly by subtracting the termination from any > > context it is in and resetting descriptors if it is not in a > context. > > > > Conclusion: the only thing an MGC-initiated restart of a termination > > does is change its state to in-service if it is not already there. > > > > gsachin@hss.hns.com wrote: > > > >>Hi List > >>I have a query regarding the processing of Service Change Restart. > >>consider the following scenario: > >> > >>Termination is in state InService. > >>Command recieved from MGC to Restart the termination (with or wothout > >>delay). > >> > >>what MG could possibly do in this case? > >> > >> > >>Thanks > >>Sachin Gupta > >> > > > > [disclaimer snipped] > > > > _______________________________________________ > > 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 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Mar 19 23: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 XAA23841 for ; Wed, 19 Mar 2003 23: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 h2K4gOO07557; Wed, 19 Mar 2003 23:42: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 h2K4ewO07480 for ; Wed, 19 Mar 2003 23:40:58 -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 XAA23724 for ; Wed, 19 Mar 2003 23:22:43 -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 h2K4NBs17879 for ; Thu, 20 Mar 2003 09:53:11 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2K4N5217860; Thu, 20 Mar 2003 09:53:05 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2K4PeK22867; Thu, 20 Mar 2003 09:55:45 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CEF.0017013B ; Thu, 20 Mar 2003 09:41:16 +0530 X-Lotus-FromDomain: HSS To: David Kao cc: megaco@ietf.org Message-ID: <65256CEF.001700F5.00@dlfmail1.hss.hns.com> Date: Thu, 20 Mar 2003 09:56:50 +0530 Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties 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, A small addition to what Kevin has already mentioned: - Attempt is made to apply the Topology descriptor before any commands for that action. However, if due to some reason this is not possible then the Topology Descriptor is applied as soon as all the information to apply it is known to the MG. e.g. ... Context = 1{Topology{idstr1,$,Bothway } ,Add=$ {... In this case Topology will be applied once the "Add=$" command has been executed successfully. Regards, Chintan... "Kevin Boyle" on 03/19/2003 12:30:27 AM To: David Kao , megaco@ietf.org cc: (bcc: Chintan Kaushik/HSS) Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties Comments inline. [KJBII] Kevin -----Original Message----- From: David Kao [mailto:david.kao@verizon.net] Sent: Monday, March 17, 2003 10:22 PM To: megaco@ietf.org Subject: [Megaco] Processing Order of Context Properties and Termination Properties Please accept my apology if the same questions were asked and discussed before. The spec says, "Transactions guarantee ordered Command processing. That is, Commands within a Transaction are executed sequentially." I have two relevant questions based on this statement. 1. How about the processing order of context properties? Are they supposed to be processed in the same same sequential order like the commands? For instance, based on previously posted emails from Christian Grove, topology descriptor should be processed before commands in an action, since "The Topology descriptor occurs before the commands in an action." In fact, all contextRequests come before the commands. If this is the case, is the following generalization correct? "In a transaction, actions are executed sequentially. In an action, context requests (including context property modifications and context property audits) and commands are executed sequentially." [KJBII] Yes. H.248 is, essentially, a left to right protocol. 2. How about the processing order of termination properties? Without a well-defined order, different MG implementations can respond differently to the same command. For instance, if Signals descriptor is processed before Events descriptor can produce different results than the case when Events descriptor is processed first. [KJBII] See above comment. Regards, David Kao _______________________________________________ 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 Mar 19 23:26: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 XAA23887 for ; Wed, 19 Mar 2003 23:26:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K4hq607618 for megaco-archive@odin.ietf.org; Wed, 19 Mar 2003 23:43: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 h2K4hqO07615 for ; Wed, 19 Mar 2003 23:43: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 XAA23855 for ; Wed, 19 Mar 2003 23:25: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 h2K4gOO07557; Wed, 19 Mar 2003 23:42: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 h2K4ewO07480 for ; Wed, 19 Mar 2003 23:40:58 -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 XAA23724 for ; Wed, 19 Mar 2003 23:22:43 -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 h2K4NBs17879 for ; Thu, 20 Mar 2003 09:53:11 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2K4N5217860; Thu, 20 Mar 2003 09:53:05 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2K4PeK22867; Thu, 20 Mar 2003 09:55:45 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CEF.0017013B ; Thu, 20 Mar 2003 09:41:16 +0530 X-Lotus-FromDomain: HSS To: David Kao cc: megaco@ietf.org Message-ID: <65256CEF.001700F5.00@dlfmail1.hss.hns.com> Date: Thu, 20 Mar 2003 09:56:50 +0530 Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties 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, A small addition to what Kevin has already mentioned: - Attempt is made to apply the Topology descriptor before any commands for that action. However, if due to some reason this is not possible then the Topology Descriptor is applied as soon as all the information to apply it is known to the MG. e.g. ... Context = 1{Topology{idstr1,$,Bothway } ,Add=$ {... In this case Topology will be applied once the "Add=$" command has been executed successfully. Regards, Chintan... "Kevin Boyle" on 03/19/2003 12:30:27 AM To: David Kao , megaco@ietf.org cc: (bcc: Chintan Kaushik/HSS) Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties Comments inline. [KJBII] Kevin -----Original Message----- From: David Kao [mailto:david.kao@verizon.net] Sent: Monday, March 17, 2003 10:22 PM To: megaco@ietf.org Subject: [Megaco] Processing Order of Context Properties and Termination Properties Please accept my apology if the same questions were asked and discussed before. The spec says, "Transactions guarantee ordered Command processing. That is, Commands within a Transaction are executed sequentially." I have two relevant questions based on this statement. 1. How about the processing order of context properties? Are they supposed to be processed in the same same sequential order like the commands? For instance, based on previously posted emails from Christian Grove, topology descriptor should be processed before commands in an action, since "The Topology descriptor occurs before the commands in an action." In fact, all contextRequests come before the commands. If this is the case, is the following generalization correct? "In a transaction, actions are executed sequentially. In an action, context requests (including context property modifications and context property audits) and commands are executed sequentially." [KJBII] Yes. H.248 is, essentially, a left to right protocol. 2. How about the processing order of termination properties? Without a well-defined order, different MG implementations can respond differently to the same command. For instance, if Signals descriptor is processed before Events descriptor can produce different results than the case when Events descriptor is processed first. [KJBII] See above comment. Regards, David Kao _______________________________________________ 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 Mar 20 01: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 BAA28071 for ; Thu, 20 Mar 2003 01:44: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 h2K71oO16970; Thu, 20 Mar 2003 02:01: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 h2K70TO16799 for ; Thu, 20 Mar 2003 02:00:29 -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 BAA28046 for ; Thu, 20 Mar 2003 01:41:55 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2K6i8603555 for ; Thu, 20 Mar 2003 01:44:08 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Mar 2003 01:44:09 -0500 Message-ID: From: "Kevin Boyle" To: ckaushik@hss.hns.com, David Kao Cc: megaco@ietf.org Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties Date: Thu, 20 Mar 2003 01:44:08 -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 not correct. As has been repeatedly covered, the Topology descriptor is executed before any commands, regardless of the information available. The difference between this statement, and what you have expressed is this: C=1{TP{$,*,IS},A=${...} Topology first: The new term is added already isolated from all other terms in the context. Topology once "enough information" is present: The new term is added bothway to all terms, and then topology is altered to isolate the term from all other terms in the context. As you can see there is a significant difference between these two scenarios. If the command fails, then it is up to the MGC to clean up any potential mess that results from having executed the TP descriptor. Kevin -----Original Message----- From: ckaushik@hss.hns.com [mailto:ckaushik@hss.hns.com] Sent: Wednesday, March 19, 2003 11:27 PM To: David Kao Cc: megaco@ietf.org Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties Hi, A small addition to what Kevin has already mentioned: - Attempt is made to apply the Topology descriptor before any commands for that action. However, if due to some reason this is not possible then the Topology Descriptor is applied as soon as all the information to apply it is known to the MG. e.g. ... Context = 1{Topology{idstr1,$,Bothway } ,Add=$ {... In this case Topology will be applied once the "Add=$" command has been executed successfully. Regards, Chintan... "Kevin Boyle" on 03/19/2003 12:30:27 AM To: David Kao , megaco@ietf.org cc: (bcc: Chintan Kaushik/HSS) Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties Comments inline. [KJBII] Kevin -----Original Message----- From: David Kao [mailto:david.kao@verizon.net] Sent: Monday, March 17, 2003 10:22 PM To: megaco@ietf.org Subject: [Megaco] Processing Order of Context Properties and Termination Properties Please accept my apology if the same questions were asked and discussed before. The spec says, "Transactions guarantee ordered Command processing. That is, Commands within a Transaction are executed sequentially." I have two relevant questions based on this statement. 1. How about the processing order of context properties? Are they supposed to be processed in the same same sequential order like the commands? For instance, based on previously posted emails from Christian Grove, topology descriptor should be processed before commands in an action, since "The Topology descriptor occurs before the commands in an action." In fact, all contextRequests come before the commands. If this is the case, is the following generalization correct? "In a transaction, actions are executed sequentially. In an action, context requests (including context property modifications and context property audits) and commands are executed sequentially." [KJBII] Yes. H.248 is, essentially, a left to right protocol. 2. How about the processing order of termination properties? Without a well-defined order, different MG implementations can respond differently to the same command. For instance, if Signals descriptor is processed before Events descriptor can produce different results than the case when Events descriptor is processed first. [KJBII] See above comment. Regards, David Kao _______________________________________________ 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 Mar 20 01: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 BAA28109 for ; Thu, 20 Mar 2003 01:47:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K74jH17330 for megaco-archive@odin.ietf.org; Thu, 20 Mar 2003 02:04: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 h2K74TO17283 for ; Thu, 20 Mar 2003 02:04: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 BAA28078 for ; Thu, 20 Mar 2003 01:45: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 h2K71oO16970; Thu, 20 Mar 2003 02:01: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 h2K70TO16799 for ; Thu, 20 Mar 2003 02:00:29 -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 BAA28046 for ; Thu, 20 Mar 2003 01:41:55 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2K6i8603555 for ; Thu, 20 Mar 2003 01:44:08 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Mar 2003 01:44:09 -0500 Message-ID: From: "Kevin Boyle" To: ckaushik@hss.hns.com, David Kao Cc: megaco@ietf.org Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties Date: Thu, 20 Mar 2003 01:44:08 -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 not correct. As has been repeatedly covered, the Topology descriptor is executed before any commands, regardless of the information available. The difference between this statement, and what you have expressed is this: C=1{TP{$,*,IS},A=${...} Topology first: The new term is added already isolated from all other terms in the context. Topology once "enough information" is present: The new term is added bothway to all terms, and then topology is altered to isolate the term from all other terms in the context. As you can see there is a significant difference between these two scenarios. If the command fails, then it is up to the MGC to clean up any potential mess that results from having executed the TP descriptor. Kevin -----Original Message----- From: ckaushik@hss.hns.com [mailto:ckaushik@hss.hns.com] Sent: Wednesday, March 19, 2003 11:27 PM To: David Kao Cc: megaco@ietf.org Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties Hi, A small addition to what Kevin has already mentioned: - Attempt is made to apply the Topology descriptor before any commands for that action. However, if due to some reason this is not possible then the Topology Descriptor is applied as soon as all the information to apply it is known to the MG. e.g. ... Context = 1{Topology{idstr1,$,Bothway } ,Add=$ {... In this case Topology will be applied once the "Add=$" command has been executed successfully. Regards, Chintan... "Kevin Boyle" on 03/19/2003 12:30:27 AM To: David Kao , megaco@ietf.org cc: (bcc: Chintan Kaushik/HSS) Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties Comments inline. [KJBII] Kevin -----Original Message----- From: David Kao [mailto:david.kao@verizon.net] Sent: Monday, March 17, 2003 10:22 PM To: megaco@ietf.org Subject: [Megaco] Processing Order of Context Properties and Termination Properties Please accept my apology if the same questions were asked and discussed before. The spec says, "Transactions guarantee ordered Command processing. That is, Commands within a Transaction are executed sequentially." I have two relevant questions based on this statement. 1. How about the processing order of context properties? Are they supposed to be processed in the same same sequential order like the commands? For instance, based on previously posted emails from Christian Grove, topology descriptor should be processed before commands in an action, since "The Topology descriptor occurs before the commands in an action." In fact, all contextRequests come before the commands. If this is the case, is the following generalization correct? "In a transaction, actions are executed sequentially. In an action, context requests (including context property modifications and context property audits) and commands are executed sequentially." [KJBII] Yes. H.248 is, essentially, a left to right protocol. 2. How about the processing order of termination properties? Without a well-defined order, different MG implementations can respond differently to the same command. For instance, if Signals descriptor is processed before Events descriptor can produce different results than the case when Events descriptor is processed first. [KJBII] See above comment. Regards, David Kao _______________________________________________ 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 Mar 20 02:40: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 CAA10827 for ; Thu, 20 Mar 2003 02:40: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 h2K7vUO31284; Thu, 20 Mar 2003 02:57: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 h2K7usO31258 for ; Thu, 20 Mar 2003 02:56:54 -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 CAA10790 for ; Thu, 20 Mar 2003 02:38:16 -0500 (EST) From: bvswamy@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 h2K7ces01957 for ; Thu, 20 Mar 2003 13:08:40 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2K7cc201943 for ; Thu, 20 Mar 2003 13:08:38 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2K7fNP21873 for ; Thu, 20 Mar 2003 13:11:23 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CEF.0028ED37 ; Thu, 20 Mar 2003 12:57:01 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CEF.0028EB87.00@dlfmail1.hss.hns.com> Date: Thu, 20 Mar 2003 13:12:30 +0530 Subject: RE: [Megaco] Service change Restart 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 Kevin Few clarifications needed on the service change procedures: 1) What should MG do when it receives Service Change Restart on a already inservice termination which is in Non-Null context Should it give a error response or whether MG should clear the call and remove the termination from the context ? 2) If ServiceChange Restart with delay is recd by MG for an already Inservice termination which may or may not be in call then what should be MG behaviour. Should it mark the termination as Out-Of-Service till the delay timer expires and remove the termination from the context or give a error response ? 3) If Service Change Graceful with delay is received by MG for an already out of service termination then how should MG behave? Should it mark the termination in-service right now and after timer expiry mark it out-of-service or should it give an error? In all of the above cases if MG were to give a error response then there is no error-code defined which specifies that MG is already in the state which MGC has requested , however there is an error-code "Not-Ready" defined as "The command directed to a termination was not executed because of the service state of the termination" which can be used in these situations for conveying MGC that requested operation is not done. 4) What should be the MGC behaviour in the following scenario: 1) MGC recevies a Service Change graceful with NonNull delay for a termination in context. 2) Now MG want to cancel the graceful timer. The only way do currently is by sending a service Change Restart. Now what should be MGC behaviour. Should it only stop the timer and continue the call or end the call and the mark the termination as Inservice. I hope SG16 Annex F will also clarify doubts over the above items. Regards Venkat knayar@hss.hns.com on 03/18/2003 09:25:04 AM To: "Kevin Boyle" cc: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS, Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: B Venkat S.R Swamy/HSS) Subject: RE: [Megaco] Service change Restart Hi Kevin Thanks for the useful pointer... I did like to know if the Annex-F is intended to be part of H.248v2 only or will also be applicable to H.248v1. Any information about the time lines by when it would be finalised/ freezed. regards, -kapil nayar http://www.hssworld.com "Kevin Boyle" on 03/14/2003 08:33:23 PM To: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS cc: Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: Kapil Nayar/HSS) Subject: RE: [Megaco] Service change Restart This work is ongoing in SG16 as future Annex F. Both of these items are intended to be clarified by the new work. The input documents to the San Jose Rapporteurs' Meeting can be found as AVD-2310, AVD-2311, and AVD-2298 at ftp://standard.pictel.com/avc-site/0302_San/. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Friday, March 14, 2003 9:30 AM To: klaha@hss.hns.com Cc: gsachin@hss.hns.com; Megaco List Subject: Re: [Megaco] Service change Restart This is where the RFC is completely inadequate as it stands. I wouldn't mind seeing it rewritten to specify separately what happens for ServiceChange on ROOT vs. ServiceChange on individual terminations. With regard to the latter, there is also something else I'd like to see ironed out: the service state is a writable property in TerminationState, yet it is manipulated by ServiceChange. One or the other of these should go. I am quite prepared to submit a proposal for new text for section 7.2.8 in particular. Would there be interest in reviewing such a proposal? We could submit it as a contribution into SG 16's May meeting if that is workable. klaha@hss.hns.com wrote: > > How about ServiceChange Restart on ROOT from MGC?Does the protocol > inhibit it? (It can be an easier means for the MGC to inform MG to > delete all contexts rather than 'Subtract'ing each of them, when MGC > is taken gracefully > out-of-service) > > > > > > Tom Taylor on 03/14/2003 12:27:35 AM > > To: Sachin Gupta-PNGN/HSS@HSS, Megaco List > cc: (bcc: Kushanava Laha/HSS) > > Subject: Re: [Megaco] Service change Restart > > > > I agree that it's very difficult to assign any real meaning to an > MGC-initiated restart of a termination. My background in switch > software development tells me that a restart clears certain aspects of > state. However, that makes little sense in the Megaco case, because > the MGC can do that directly by subtracting the termination > from any context it is in and resetting descriptors if it is not in a context. > > Conclusion: the only thing an MGC-initiated restart of a termination > does is change its state to in-service if it is not already there. > > gsachin@hss.hns.com wrote: > >>Hi List >>I have a query regarding the processing of Service Change Restart. >>consider the following scenario: >> >>Termination is in state InService. >>Command recieved from MGC to Restart the termination (with or wothout >>delay). >> >>what MG could possibly do in this case? >> >> >>Thanks >>Sachin Gupta >> > > [disclaimer snipped] > > _______________________________________________ > 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 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Mar 20 02:42: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 CAA10889 for ; Thu, 20 Mar 2003 02:42:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K7xw131373 for megaco-archive@odin.ietf.org; Thu, 20 Mar 2003 02:59: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 h2K7xqO31362 for ; Thu, 20 Mar 2003 02:59: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 CAA10838 for ; Thu, 20 Mar 2003 02:40: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 h2K7vUO31284; Thu, 20 Mar 2003 02:57: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 h2K7usO31258 for ; Thu, 20 Mar 2003 02:56:54 -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 CAA10790 for ; Thu, 20 Mar 2003 02:38:16 -0500 (EST) From: bvswamy@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 h2K7ces01957 for ; Thu, 20 Mar 2003 13:08:40 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2K7cc201943 for ; Thu, 20 Mar 2003 13:08:38 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2K7fNP21873 for ; Thu, 20 Mar 2003 13:11:23 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CEF.0028ED37 ; Thu, 20 Mar 2003 12:57:01 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CEF.0028EB87.00@dlfmail1.hss.hns.com> Date: Thu, 20 Mar 2003 13:12:30 +0530 Subject: RE: [Megaco] Service change Restart 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 Kevin Few clarifications needed on the service change procedures: 1) What should MG do when it receives Service Change Restart on a already inservice termination which is in Non-Null context Should it give a error response or whether MG should clear the call and remove the termination from the context ? 2) If ServiceChange Restart with delay is recd by MG for an already Inservice termination which may or may not be in call then what should be MG behaviour. Should it mark the termination as Out-Of-Service till the delay timer expires and remove the termination from the context or give a error response ? 3) If Service Change Graceful with delay is received by MG for an already out of service termination then how should MG behave? Should it mark the termination in-service right now and after timer expiry mark it out-of-service or should it give an error? In all of the above cases if MG were to give a error response then there is no error-code defined which specifies that MG is already in the state which MGC has requested , however there is an error-code "Not-Ready" defined as "The command directed to a termination was not executed because of the service state of the termination" which can be used in these situations for conveying MGC that requested operation is not done. 4) What should be the MGC behaviour in the following scenario: 1) MGC recevies a Service Change graceful with NonNull delay for a termination in context. 2) Now MG want to cancel the graceful timer. The only way do currently is by sending a service Change Restart. Now what should be MGC behaviour. Should it only stop the timer and continue the call or end the call and the mark the termination as Inservice. I hope SG16 Annex F will also clarify doubts over the above items. Regards Venkat knayar@hss.hns.com on 03/18/2003 09:25:04 AM To: "Kevin Boyle" cc: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS, Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: B Venkat S.R Swamy/HSS) Subject: RE: [Megaco] Service change Restart Hi Kevin Thanks for the useful pointer... I did like to know if the Annex-F is intended to be part of H.248v2 only or will also be applicable to H.248v1. Any information about the time lines by when it would be finalised/ freezed. regards, -kapil nayar http://www.hssworld.com "Kevin Boyle" on 03/14/2003 08:33:23 PM To: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS cc: Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: Kapil Nayar/HSS) Subject: RE: [Megaco] Service change Restart This work is ongoing in SG16 as future Annex F. Both of these items are intended to be clarified by the new work. The input documents to the San Jose Rapporteurs' Meeting can be found as AVD-2310, AVD-2311, and AVD-2298 at ftp://standard.pictel.com/avc-site/0302_San/. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Friday, March 14, 2003 9:30 AM To: klaha@hss.hns.com Cc: gsachin@hss.hns.com; Megaco List Subject: Re: [Megaco] Service change Restart This is where the RFC is completely inadequate as it stands. I wouldn't mind seeing it rewritten to specify separately what happens for ServiceChange on ROOT vs. ServiceChange on individual terminations. With regard to the latter, there is also something else I'd like to see ironed out: the service state is a writable property in TerminationState, yet it is manipulated by ServiceChange. One or the other of these should go. I am quite prepared to submit a proposal for new text for section 7.2.8 in particular. Would there be interest in reviewing such a proposal? We could submit it as a contribution into SG 16's May meeting if that is workable. klaha@hss.hns.com wrote: > > How about ServiceChange Restart on ROOT from MGC?Does the protocol > inhibit it? (It can be an easier means for the MGC to inform MG to > delete all contexts rather than 'Subtract'ing each of them, when MGC > is taken gracefully > out-of-service) > > > > > > Tom Taylor on 03/14/2003 12:27:35 AM > > To: Sachin Gupta-PNGN/HSS@HSS, Megaco List > cc: (bcc: Kushanava Laha/HSS) > > Subject: Re: [Megaco] Service change Restart > > > > I agree that it's very difficult to assign any real meaning to an > MGC-initiated restart of a termination. My background in switch > software development tells me that a restart clears certain aspects of > state. However, that makes little sense in the Megaco case, because > the MGC can do that directly by subtracting the termination > from any context it is in and resetting descriptors if it is not in a context. > > Conclusion: the only thing an MGC-initiated restart of a termination > does is change its state to in-service if it is not already there. > > gsachin@hss.hns.com wrote: > >>Hi List >>I have a query regarding the processing of Service Change Restart. >>consider the following scenario: >> >>Termination is in state InService. >>Command recieved from MGC to Restart the termination (with or wothout >>delay). >> >>what MG could possibly do in this case? >> >> >>Thanks >>Sachin Gupta >> > > [disclaimer snipped] > > _______________________________________________ > 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 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Mar 20 12:04: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 MAA24880 for ; Thu, 20 Mar 2003 12:04: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 h2KHM3O06499; Thu, 20 Mar 2003 12:22: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 h2KAC6O08006 for ; Thu, 20 Mar 2003 05:12:06 -0500 Received: from beamer.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13191 for ; Thu, 20 Mar 2003 04:53:27 -0500 (EST) Received: from moody.mchh.siemens.de ([139.21.205.85]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA04040 for ; Thu, 20 Mar 2003 10:55:42 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id KAA18391 for ; Thu, 20 Mar 2003 10:55:41 +0100 (MET) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Thu, 20 Mar 2003 10:55:25 +0100 Message-ID: <2F0349FB836CD411AB1D00508B95270306DE7298@mchh268e.mchh.siemens.de> From: Tegeler Juergen To: megaco@ietf.org Date: Thu, 20 Mar 2003 10:55:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Megaco] (no subject) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, I have a question about the MEGACO packages Basic QoS (Package ID: bqos) and DIFF SERV (Package ID: diffserv). I found these packages specified in draft-madhubabu-megaco-qospackage-00.txt. However, that package expired in January 2002 and I did not find any newer document referencing these packages. What is the current status of these packages? Best regards and many thanks, Juergen Tegeler _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Mar 20 12:05: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 MAA24917 for ; Thu, 20 Mar 2003 12:05:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KHNju06630 for megaco-archive@odin.ietf.org; Thu, 20 Mar 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 h2KHNiO06627 for ; Thu, 20 Mar 2003 12:23: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 MAA24896 for ; Thu, 20 Mar 2003 12:05: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 h2KHM3O06499; Thu, 20 Mar 2003 12:22: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 h2KAC6O08006 for ; Thu, 20 Mar 2003 05:12:06 -0500 Received: from beamer.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13191 for ; Thu, 20 Mar 2003 04:53:27 -0500 (EST) Received: from moody.mchh.siemens.de ([139.21.205.85]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA04040 for ; Thu, 20 Mar 2003 10:55:42 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id KAA18391 for ; Thu, 20 Mar 2003 10:55:41 +0100 (MET) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Thu, 20 Mar 2003 10:55:25 +0100 Message-ID: <2F0349FB836CD411AB1D00508B95270306DE7298@mchh268e.mchh.siemens.de> From: Tegeler Juergen To: megaco@ietf.org Date: Thu, 20 Mar 2003 10:55:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Megaco] (no subject) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, I have a question about the MEGACO packages Basic QoS (Package ID: bqos) and DIFF SERV (Package ID: diffserv). I found these packages specified in draft-madhubabu-megaco-qospackage-00.txt. However, that package expired in January 2002 and I did not find any newer document referencing these packages. What is the current status of these packages? Best regards and many thanks, Juergen Tegeler _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Mar 21 01:32: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 BAA23722 for ; Fri, 21 Mar 2003 01:32: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 h2L6mnO01722; Fri, 21 Mar 2003 01:48: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 h2L6kAO01604 for ; Fri, 21 Mar 2003 01:46:10 -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 BAA23613 for ; Fri, 21 Mar 2003 01:27:23 -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 h2L6Ros22905 for ; Fri, 21 Mar 2003 11:57:50 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2L6Rm222890; Fri, 21 Mar 2003 11:57:49 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2L6UUa17198; Fri, 21 Mar 2003 12:00:34 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CF0.00226B1B ; Fri, 21 Mar 2003 11:45:56 +0530 X-Lotus-FromDomain: HSS To: kboyle@nortelnetworks.com cc: megaco@ietf.org Message-ID: <65256CF0.00226972.00@dlfmail1.hss.hns.com> Date: Fri, 21 Mar 2003 11:54:27 +0530 Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Kevin During discussions on this thread for cancelling a graceful service change active on a termination, following alternatives were suggested. I didn't see a final decision on the discussion. Do we now have a final resolution on which alternative will go in the standard. Option 1: Service Change Method = "Restart", Reason = "WarmBoot(902)". This mandates changes to H.248.8 to allow Reason="WarmBoot(902)" for non-ROOT terminations also. Option 2: Service Change Method = "Restart", Reason = "Service Restored(900)". This mandates changes to H.248.8 to modify the definition of Reason="Service Restored(900)" to include the cancellation of any active graceful state change on the termination. Option 3: MG sends another Service Change (method = Forced) after the graceful delay timeout. This mandates that only a Service Change (method = Forced) would finally put a termination out of service. This will need extra text to the current base protocol description. Regards Sachin Gupta ---------------------- Forwarded by Sachin Gupta-PNGN/HSS on 03/21/2003 11:49 AM --------------------------- "Kevin Boyle" on 02/04/2003 03:26:22 PM To: Kapil Nayar/HSS@HSS cc: megaco@ietf.org (bcc: megaco_maillist) Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism That's what I get for not looking it up first. Try 900. Kevin -----Original Message----- From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] Sent: Tuesday, February 04, 2003 12:22 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: megaco@ietf.org Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Hi Kevin Thanks for your reply... But, as per H.248.8 the definition of Service Change reason "WarmBoot" is: "This indicates that the entity indicated with the TerminationID is in ServiceState "In-Service", and that it has gone through a start, or recovery, action. All transactions in process may be lost, but otherwise all states are preserved on the termination." with a special comment: "This reason code only applies for TerminationID root" The protocol defines the usage of "WarmBoot" only for root termination. Alternatives? thanks, -kapil "Kevin Boyle" on 02/04/2003 12:50:20 AM To: Kapil Nayar/HSS@HSS, megaco@ietf.org cc: Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Comments inline. [KJBII] Kevin -----Original Message----- From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] Sent: Monday, February 03, 2003 7:19 AM To: megaco@ietf.org Subject: [Megaco] Cancel Service Change (method=Graceful) mechanism Hi It seems the protocol doesnot define any procedure for cancelling an earlier Service Change (method=Graceful) on a non-root termination. Taking a practical case: MG sends a Service Change (method=Graceful) on a termination with delay= 2 hours. After 1 hour, MG realizes that it doesn't want to put the termination out-of-service (after remaining 1 hour) as was earlier intended. How to inform the MGC of the new intentions - cancel graceful..? Sending Service Change (method =Restart) would mean that termination just came InService and doesnot have any active descriptors, whereas this is not the case. [KJBII] Why can't you use SC Restart? The Warm Boot SC Reason indicates that there was NO loss of state. Solution: MG sends Service Change (method = Graceful) delay =2 hours to inform MGC only about the intentions. MG sends Service Change (method = Forced) when the termination actually goes out-of-service after 2 hours. This ensures that if Service Change (method = Forced) never came, the intentions of MG never got materialised. [KJBII] Ick. So we will be required to send TWO SCs instead of one if we use SC Graceful? I really don't like that idea. Does any body have an alternative solution? Please suggest. thanks, kapil nayar www.hssworld.com DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Mar 21 01:33: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 BAA23793 for ; Fri, 21 Mar 2003 01:33:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2L6pXf01841 for megaco-archive@odin.ietf.org; Fri, 21 Mar 2003 01:51: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 h2L6pXO01838 for ; Fri, 21 Mar 2003 01:51: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 BAA23771 for ; Fri, 21 Mar 2003 01:32: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 h2L6mnO01722; Fri, 21 Mar 2003 01:48: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 h2L6kAO01604 for ; Fri, 21 Mar 2003 01:46:10 -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 BAA23613 for ; Fri, 21 Mar 2003 01:27:23 -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 h2L6Ros22905 for ; Fri, 21 Mar 2003 11:57:50 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2L6Rm222890; Fri, 21 Mar 2003 11:57:49 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2L6UUa17198; Fri, 21 Mar 2003 12:00:34 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CF0.00226B1B ; Fri, 21 Mar 2003 11:45:56 +0530 X-Lotus-FromDomain: HSS To: kboyle@nortelnetworks.com cc: megaco@ietf.org Message-ID: <65256CF0.00226972.00@dlfmail1.hss.hns.com> Date: Fri, 21 Mar 2003 11:54:27 +0530 Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Kevin During discussions on this thread for cancelling a graceful service change active on a termination, following alternatives were suggested. I didn't see a final decision on the discussion. Do we now have a final resolution on which alternative will go in the standard. Option 1: Service Change Method = "Restart", Reason = "WarmBoot(902)". This mandates changes to H.248.8 to allow Reason="WarmBoot(902)" for non-ROOT terminations also. Option 2: Service Change Method = "Restart", Reason = "Service Restored(900)". This mandates changes to H.248.8 to modify the definition of Reason="Service Restored(900)" to include the cancellation of any active graceful state change on the termination. Option 3: MG sends another Service Change (method = Forced) after the graceful delay timeout. This mandates that only a Service Change (method = Forced) would finally put a termination out of service. This will need extra text to the current base protocol description. Regards Sachin Gupta ---------------------- Forwarded by Sachin Gupta-PNGN/HSS on 03/21/2003 11:49 AM --------------------------- "Kevin Boyle" on 02/04/2003 03:26:22 PM To: Kapil Nayar/HSS@HSS cc: megaco@ietf.org (bcc: megaco_maillist) Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism That's what I get for not looking it up first. Try 900. Kevin -----Original Message----- From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] Sent: Tuesday, February 04, 2003 12:22 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: megaco@ietf.org Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Hi Kevin Thanks for your reply... But, as per H.248.8 the definition of Service Change reason "WarmBoot" is: "This indicates that the entity indicated with the TerminationID is in ServiceState "In-Service", and that it has gone through a start, or recovery, action. All transactions in process may be lost, but otherwise all states are preserved on the termination." with a special comment: "This reason code only applies for TerminationID root" The protocol defines the usage of "WarmBoot" only for root termination. Alternatives? thanks, -kapil "Kevin Boyle" on 02/04/2003 12:50:20 AM To: Kapil Nayar/HSS@HSS, megaco@ietf.org cc: Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism Comments inline. [KJBII] Kevin -----Original Message----- From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] Sent: Monday, February 03, 2003 7:19 AM To: megaco@ietf.org Subject: [Megaco] Cancel Service Change (method=Graceful) mechanism Hi It seems the protocol doesnot define any procedure for cancelling an earlier Service Change (method=Graceful) on a non-root termination. Taking a practical case: MG sends a Service Change (method=Graceful) on a termination with delay= 2 hours. After 1 hour, MG realizes that it doesn't want to put the termination out-of-service (after remaining 1 hour) as was earlier intended. How to inform the MGC of the new intentions - cancel graceful..? Sending Service Change (method =Restart) would mean that termination just came InService and doesnot have any active descriptors, whereas this is not the case. [KJBII] Why can't you use SC Restart? The Warm Boot SC Reason indicates that there was NO loss of state. Solution: MG sends Service Change (method = Graceful) delay =2 hours to inform MGC only about the intentions. MG sends Service Change (method = Forced) when the termination actually goes out-of-service after 2 hours. This ensures that if Service Change (method = Forced) never came, the intentions of MG never got materialised. [KJBII] Ick. So we will be required to send TWO SCs instead of one if we use SC Graceful? I really don't like that idea. Does any body have an alternative solution? Please suggest. thanks, kapil nayar www.hssworld.com DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Mar 21 04:38: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 EAA08635 for ; Fri, 21 Mar 2003 04:38: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 h2L9thO23750; Fri, 21 Mar 2003 04:55:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L9sNO23707 for ; Fri, 21 Mar 2003 04:54:23 -0500 Received: from hfclrnd (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08610 for ; Fri, 21 Mar 2003 04:35:32 -0500 (EST) Received: (from root@localhost) by hfclrnd (8.11.6/8.11.2) id h2L9cDN11556 for megaco@ietf.org; Fri, 21 Mar 2003 15:08:13 +0530 Received: from abhishek ([132.147.166.33]) by hfclrnd (8.11.6/8.11.2) with SMTP id h2L9cC411548 for ; Fri, 21 Mar 2003 15:08:12 +0530 Message-ID: <002201c2ef8e$38f7e5c0$21a69384@abhishek> Reply-To: "Abhishek Bansal" From: "Abhishek Bansal" To: Date: Fri, 21 Mar 2003 15:12:43 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C2EFBC.5295E300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Virus-Scanned: by AMaViS perl-11 Subject: [Megaco] how to use alf Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_001F_01C2EFBC.5295E300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi, rfc 3015 does not give any detail how to implement Alf. Can it be on th elines of rfc 1240. regards=20 abhishek ------=_NextPart_000_001F_01C2EFBC.5295E300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi,
 rfc 3015 does not give any detail = how to=20 implement Alf.
Can it be on th elines of rfc = 1240.
regards
abhishek
------=_NextPart_000_001F_01C2EFBC.5295E300-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Fri Mar 21 04:39: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 EAA08652 for ; Fri, 21 Mar 2003 04:39:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2L9vgG23803 for megaco-archive@odin.ietf.org; Fri, 21 Mar 2003 04:57: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 h2L9vgO23800 for ; Fri, 21 Mar 2003 04:57: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 EAA08649 for ; Fri, 21 Mar 2003 04:38: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 h2L9thO23750; Fri, 21 Mar 2003 04:55:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L9sNO23707 for ; Fri, 21 Mar 2003 04:54:23 -0500 Received: from hfclrnd (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08610 for ; Fri, 21 Mar 2003 04:35:32 -0500 (EST) Received: (from root@localhost) by hfclrnd (8.11.6/8.11.2) id h2L9cDN11556 for megaco@ietf.org; Fri, 21 Mar 2003 15:08:13 +0530 Received: from abhishek ([132.147.166.33]) by hfclrnd (8.11.6/8.11.2) with SMTP id h2L9cC411548 for ; Fri, 21 Mar 2003 15:08:12 +0530 Message-ID: <002201c2ef8e$38f7e5c0$21a69384@abhishek> Reply-To: "Abhishek Bansal" From: "Abhishek Bansal" To: Date: Fri, 21 Mar 2003 15:12:43 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C2EFBC.5295E300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Virus-Scanned: by AMaViS perl-11 Subject: [Megaco] how to use alf Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_001F_01C2EFBC.5295E300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi, rfc 3015 does not give any detail how to implement Alf. Can it be on th elines of rfc 1240. regards=20 abhishek ------=_NextPart_000_001F_01C2EFBC.5295E300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi,
 rfc 3015 does not give any detail = how to=20 implement Alf.
Can it be on th elines of rfc = 1240.
regards
abhishek
------=_NextPart_000_001F_01C2EFBC.5295E300-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Mar 24 00:14: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 AAA22296 for ; Mon, 24 Mar 2003 00:14: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 h2O5XQO23540; Mon, 24 Mar 2003 00:33: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 h2O5V8O23482 for ; Mon, 24 Mar 2003 00:31:08 -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 AAA22265 for ; Mon, 24 Mar 2003 00:10:55 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2O5D7bh024279; Mon, 24 Mar 2003 06:13:07 +0100 (MET) Received: from brsf10.epa.ericsson.se ([146.11.8.4]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id HK14R06M; Mon, 24 Mar 2003 06:13:06 +0100 Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h2O5D3L07580; Mon, 24 Mar 2003 16:13:03 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.201]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HFD4MTHZ; Mon, 24 Mar 2003 16:13:02 +1100 Message-ID: <3E7E7407.4C9D1470@ericsson.com.au> Date: Mon, 24 Mar 2003 13:57:11 +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: kboyle@nortelnetworks.com, megaco@ietf.org Subject: Re: [Megaco] Cancel Service Change (method=Graceful) mechanism References: <65256CF0.00226972.00@dlfmail1.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 Sanchin, I think Option 2 is the best here. Regards, Christian gsachin@hss.hns.com wrote: > > Hi Kevin > > During discussions on this thread for cancelling a graceful service change > active > on a termination, following alternatives were suggested. > I didn't see a final decision on the discussion. > Do we now have a final resolution on which alternative will go in the standard. > > Option 1: > Service Change Method = "Restart", Reason = "WarmBoot(902)". > This mandates changes to H.248.8 to allow Reason="WarmBoot(902)" for non-ROOT > terminations also. > > Option 2: > Service Change Method = "Restart", Reason = "Service Restored(900)". > This mandates changes to H.248.8 to modify the definition of Reason="Service > Restored(900)" > to include the cancellation of any active graceful state change on the > termination. > > Option 3: > MG sends another Service Change (method = Forced) after the graceful delay > timeout. > This mandates that only a Service Change (method = Forced) would finally put a > termination out of service. This will need extra text to the current base > protocol > description. > > Regards > Sachin Gupta > ---------------------- Forwarded by Sachin Gupta-PNGN/HSS on 03/21/2003 11:49 AM > --------------------------- > > "Kevin Boyle" on 02/04/2003 03:26:22 PM > > To: Kapil Nayar/HSS@HSS > cc: megaco@ietf.org (bcc: megaco_maillist) > > Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism > > That's what I get for not looking it up first. Try 900. > > Kevin > > -----Original Message----- > From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] > Sent: Tuesday, February 04, 2003 12:22 AM > To: Boyle, Kevin [NCRTP:3Z40:EXCH] > Cc: megaco@ietf.org > Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism > > Hi Kevin > > Thanks for your reply... > But, as per H.248.8 the definition of Service Change reason "WarmBoot" is: > > "This indicates that the entity indicated with the TerminationID is > in ServiceState "In-Service", and that it has gone through a start, or > recovery, action. All transactions in process may be lost, but otherwise > all states are preserved on the termination." > > with a special comment: "This reason code only applies for TerminationID > root" The protocol defines the usage of "WarmBoot" only for root > termination. > > Alternatives? > > thanks, > -kapil > > "Kevin Boyle" on 02/04/2003 12:50:20 AM > > To: Kapil Nayar/HSS@HSS, megaco@ietf.org > cc: > > Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism > > Comments inline. [KJBII] > > Kevin > > -----Original Message----- > From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] > Sent: Monday, February 03, 2003 7:19 AM > To: megaco@ietf.org > Subject: [Megaco] Cancel Service Change (method=Graceful) mechanism > > Hi > > It seems the protocol doesnot define any procedure for cancelling an earlier > Service Change (method=Graceful) on a non-root termination. > > Taking a practical case: > MG sends a Service Change (method=Graceful) on a termination with delay= 2 > hours. After 1 hour, MG realizes that it doesn't want to put the termination > out-of-service (after remaining 1 hour) as was earlier intended. How to > inform the MGC of the new intentions - cancel graceful..? Sending Service > Change (method =Restart) would mean that termination just came InService and > doesnot have any active descriptors, whereas this is not the case. > > [KJBII] Why can't you use SC Restart? The Warm Boot SC Reason indicates > that there was NO loss of state. > > Solution: > MG sends Service Change (method = Graceful) delay =2 hours to inform MGC > only about the intentions. MG sends Service Change (method = Forced) when > the termination actually goes out-of-service after 2 hours. This ensures > that if Service Change (method = Forced) never came, the intentions of MG > never got materialised. > > [KJBII] Ick. So we will be required to send TWO SCs instead of one if we > use SC Graceful? I really don't like that idea. > > Does any body have an alternative solution? Please suggest. > > thanks, > kapil nayar > www.hssworld.com > > DISCLAIMER: This message is proprietary to Hughes Software Systems Limited > (HSS) and is intended solely for the use of the individual to whom it is > addressed. It may contain privileged or confidential information and > should not be circulated or used for any purpose other than for what it is > intended. If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, you are > notified that you are strictly prohibited from using, copying, altering, or > disclosing the contents of this message. HSS accepts no responsibility for > loss or damage arising from the use of the information transmitted by this > email including damage from virus. > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > DISCLAIMER: This message is proprietary to Hughes Software Systems > Limited (HSS) and is intended solely for the use of the individual > to whom it is addressed. It may contain privileged or confidential > information and should not be circulated or used for any purpose other > than for what it is intended. If you have received this message in error, > please notify the originator immediately. If you are not the intended > recipient, you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. HSS accepts > no responsibility for loss or damage arising from the use of the information > transmitted by this email including damage from virus. > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Mar 24 00:15:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22337 for ; Mon, 24 Mar 2003 00:15:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2O5Yx723585 for megaco-archive@odin.ietf.org; Mon, 24 Mar 2003 00: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 h2O5YxO23582 for ; Mon, 24 Mar 2003 00: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 AAA22316 for ; Mon, 24 Mar 2003 00:14:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O5XQO23540; Mon, 24 Mar 2003 00:33: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 h2O5V8O23482 for ; Mon, 24 Mar 2003 00:31:08 -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 AAA22265 for ; Mon, 24 Mar 2003 00:10:55 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2O5D7bh024279; Mon, 24 Mar 2003 06:13:07 +0100 (MET) Received: from brsf10.epa.ericsson.se ([146.11.8.4]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id HK14R06M; Mon, 24 Mar 2003 06:13:06 +0100 Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h2O5D3L07580; Mon, 24 Mar 2003 16:13:03 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.201]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HFD4MTHZ; Mon, 24 Mar 2003 16:13:02 +1100 Message-ID: <3E7E7407.4C9D1470@ericsson.com.au> Date: Mon, 24 Mar 2003 13:57:11 +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: kboyle@nortelnetworks.com, megaco@ietf.org Subject: Re: [Megaco] Cancel Service Change (method=Graceful) mechanism References: <65256CF0.00226972.00@dlfmail1.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 Sanchin, I think Option 2 is the best here. Regards, Christian gsachin@hss.hns.com wrote: > > Hi Kevin > > During discussions on this thread for cancelling a graceful service change > active > on a termination, following alternatives were suggested. > I didn't see a final decision on the discussion. > Do we now have a final resolution on which alternative will go in the standard. > > Option 1: > Service Change Method = "Restart", Reason = "WarmBoot(902)". > This mandates changes to H.248.8 to allow Reason="WarmBoot(902)" for non-ROOT > terminations also. > > Option 2: > Service Change Method = "Restart", Reason = "Service Restored(900)". > This mandates changes to H.248.8 to modify the definition of Reason="Service > Restored(900)" > to include the cancellation of any active graceful state change on the > termination. > > Option 3: > MG sends another Service Change (method = Forced) after the graceful delay > timeout. > This mandates that only a Service Change (method = Forced) would finally put a > termination out of service. This will need extra text to the current base > protocol > description. > > Regards > Sachin Gupta > ---------------------- Forwarded by Sachin Gupta-PNGN/HSS on 03/21/2003 11:49 AM > --------------------------- > > "Kevin Boyle" on 02/04/2003 03:26:22 PM > > To: Kapil Nayar/HSS@HSS > cc: megaco@ietf.org (bcc: megaco_maillist) > > Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism > > That's what I get for not looking it up first. Try 900. > > Kevin > > -----Original Message----- > From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] > Sent: Tuesday, February 04, 2003 12:22 AM > To: Boyle, Kevin [NCRTP:3Z40:EXCH] > Cc: megaco@ietf.org > Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism > > Hi Kevin > > Thanks for your reply... > But, as per H.248.8 the definition of Service Change reason "WarmBoot" is: > > "This indicates that the entity indicated with the TerminationID is > in ServiceState "In-Service", and that it has gone through a start, or > recovery, action. All transactions in process may be lost, but otherwise > all states are preserved on the termination." > > with a special comment: "This reason code only applies for TerminationID > root" The protocol defines the usage of "WarmBoot" only for root > termination. > > Alternatives? > > thanks, > -kapil > > "Kevin Boyle" on 02/04/2003 12:50:20 AM > > To: Kapil Nayar/HSS@HSS, megaco@ietf.org > cc: > > Subject: RE: [Megaco] Cancel Service Change (method=Graceful) mechanism > > Comments inline. [KJBII] > > Kevin > > -----Original Message----- > From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] > Sent: Monday, February 03, 2003 7:19 AM > To: megaco@ietf.org > Subject: [Megaco] Cancel Service Change (method=Graceful) mechanism > > Hi > > It seems the protocol doesnot define any procedure for cancelling an earlier > Service Change (method=Graceful) on a non-root termination. > > Taking a practical case: > MG sends a Service Change (method=Graceful) on a termination with delay= 2 > hours. After 1 hour, MG realizes that it doesn't want to put the termination > out-of-service (after remaining 1 hour) as was earlier intended. How to > inform the MGC of the new intentions - cancel graceful..? Sending Service > Change (method =Restart) would mean that termination just came InService and > doesnot have any active descriptors, whereas this is not the case. > > [KJBII] Why can't you use SC Restart? The Warm Boot SC Reason indicates > that there was NO loss of state. > > Solution: > MG sends Service Change (method = Graceful) delay =2 hours to inform MGC > only about the intentions. MG sends Service Change (method = Forced) when > the termination actually goes out-of-service after 2 hours. This ensures > that if Service Change (method = Forced) never came, the intentions of MG > never got materialised. > > [KJBII] Ick. So we will be required to send TWO SCs instead of one if we > use SC Graceful? I really don't like that idea. > > Does any body have an alternative solution? Please suggest. > > thanks, > kapil nayar > www.hssworld.com > > DISCLAIMER: This message is proprietary to Hughes Software Systems Limited > (HSS) and is intended solely for the use of the individual to whom it is > addressed. It may contain privileged or confidential information and > should not be circulated or used for any purpose other than for what it is > intended. If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, you are > notified that you are strictly prohibited from using, copying, altering, or > disclosing the contents of this message. HSS accepts no responsibility for > loss or damage arising from the use of the information transmitted by this > email including damage from virus. > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > DISCLAIMER: This message is proprietary to Hughes Software Systems > Limited (HSS) and is intended solely for the use of the individual > to whom it is addressed. It may contain privileged or confidential > information and should not be circulated or used for any purpose other > than for what it is intended. If you have received this message in error, > please notify the originator immediately. If you are not the intended > recipient, you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. HSS accepts > no responsibility for loss or damage arising from the use of the information > transmitted by this email including damage from virus. > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Mar 24 05:06: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 FAA09250 for ; Mon, 24 Mar 2003 05:06: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 h2OAPmO20079; Mon, 24 Mar 2003 05:25: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 h2OAO4O20021 for ; Mon, 24 Mar 2003 05:24:04 -0500 Received: from smail3.alcatel.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09198 for ; Mon, 24 Mar 2003 05:03:47 -0500 (EST) From: Jean-Luc.Lecuyer@alcatel.fr Received: from frmail26.netfr.alcatel.fr (frmail26.netfr.alcatel.fr [155.132.182.156]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id h2OA65qj004045 for ; Mon, 24 Mar 2003 11:06:05 +0100 To: megaco@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Mon, 24 Mar 2003 11:06:05 +0100 X-MIMETrack: Serialize by Router on FRMAIL26/FR/ALCATEL(Release 5.0.11 |July 24, 2002) at 03/24/2003 11:06:05 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new Subject: [Megaco] CLIP function with Megaco Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 question about the "Enhanced Alerting package" (alert) and on the "Analog Display Signalling Package" (andisp) I found these packages specified in draft-boyle-megaco-alerting-03.txt. However, that package expired in March 2002 and I did not find any newer document referencing these packages. What is the current status of these packages ? Best regards and many thanks, Jean-Luc Lecuyer -------------------------------------------------------------------------------------------- Jean-Luc.Lecuyer : FND/E10VS/R&D/CCPD Lannion Full telephone number : 33 (0)2 96 04 77 09 Full fax number : 33 (0)2 96 04 72 35 Email : jean-luc.lecuyer@alcatel.fr --------------------------------------------------------------------------------------------- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Mar 24 05:07: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 FAA09302 for ; Mon, 24 Mar 2003 05:07:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OARUr20189 for megaco-archive@odin.ietf.org; Mon, 24 Mar 2003 05:27: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 h2OARUO20186 for ; Mon, 24 Mar 2003 05:27: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 FAA09277 for ; Mon, 24 Mar 2003 05:07: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 h2OAPmO20079; Mon, 24 Mar 2003 05:25: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 h2OAO4O20021 for ; Mon, 24 Mar 2003 05:24:04 -0500 Received: from smail3.alcatel.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09198 for ; Mon, 24 Mar 2003 05:03:47 -0500 (EST) From: Jean-Luc.Lecuyer@alcatel.fr Received: from frmail26.netfr.alcatel.fr (frmail26.netfr.alcatel.fr [155.132.182.156]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id h2OA65qj004045 for ; Mon, 24 Mar 2003 11:06:05 +0100 To: megaco@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Mon, 24 Mar 2003 11:06:05 +0100 X-MIMETrack: Serialize by Router on FRMAIL26/FR/ALCATEL(Release 5.0.11 |July 24, 2002) at 03/24/2003 11:06:05 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new Subject: [Megaco] CLIP function with Megaco Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 question about the "Enhanced Alerting package" (alert) and on the "Analog Display Signalling Package" (andisp) I found these packages specified in draft-boyle-megaco-alerting-03.txt. However, that package expired in March 2002 and I did not find any newer document referencing these packages. What is the current status of these packages ? Best regards and many thanks, Jean-Luc Lecuyer -------------------------------------------------------------------------------------------- Jean-Luc.Lecuyer : FND/E10VS/R&D/CCPD Lannion Full telephone number : 33 (0)2 96 04 77 09 Full fax number : 33 (0)2 96 04 72 35 Email : jean-luc.lecuyer@alcatel.fr --------------------------------------------------------------------------------------------- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Mar 24 05:43: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 FAA09842 for ; Mon, 24 Mar 2003 05:43: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 h2OB2oO22454; Mon, 24 Mar 2003 06:02: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 h2OB14O22358 for ; Mon, 24 Mar 2003 06:01:04 -0500 Received: from beamer.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09790 for ; Mon, 24 Mar 2003 05:40:45 -0500 (EST) Received: from moody.mchh.siemens.de ([139.21.205.85]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA21642 for ; Mon, 24 Mar 2003 11:43:03 +0100 (MET) Received: from mchh253e.mchh.siemens.de (mchh253e.mchh.siemens.de [139.21.200.63]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id LAA19095 for ; Mon, 24 Mar 2003 11:43:03 +0100 (MET) Received: by mchh253e.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 11:42:45 +0100 Message-ID: From: Roeser Wieland To: "'megaco@ietf.org'" Date: Mon, 24 Mar 2003 11:42:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Megaco] MEGACO support for reduction of line feeding and switching back t o normal feeding Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 a question regarding the support of MEGACO packages for the following behavior. In many countries a mechanism is used to reduce line feeding after the A subscriber is in the off hook state and the dial tone supervision is expired. Is there any signal which support such things. The second question would be how the access network come back to the normal feeding state, is there some special signal already defined ? Thank you in advance. Regards, Wieland Roeser _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Mar 24 05:44: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 FAA09874 for ; Mon, 24 Mar 2003 05:44:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OB4Ch22516 for megaco-archive@odin.ietf.org; Mon, 24 Mar 2003 06:04: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 h2OB4CO22513 for ; Mon, 24 Mar 2003 06:04: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 FAA09860 for ; Mon, 24 Mar 2003 05: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 h2OB2oO22454; Mon, 24 Mar 2003 06:02: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 h2OB14O22358 for ; Mon, 24 Mar 2003 06:01:04 -0500 Received: from beamer.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09790 for ; Mon, 24 Mar 2003 05:40:45 -0500 (EST) Received: from moody.mchh.siemens.de ([139.21.205.85]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA21642 for ; Mon, 24 Mar 2003 11:43:03 +0100 (MET) Received: from mchh253e.mchh.siemens.de (mchh253e.mchh.siemens.de [139.21.200.63]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id LAA19095 for ; Mon, 24 Mar 2003 11:43:03 +0100 (MET) Received: by mchh253e.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 11:42:45 +0100 Message-ID: From: Roeser Wieland To: "'megaco@ietf.org'" Date: Mon, 24 Mar 2003 11:42:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Megaco] MEGACO support for reduction of line feeding and switching back t o normal feeding Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 a question regarding the support of MEGACO packages for the following behavior. In many countries a mechanism is used to reduce line feeding after the A subscriber is in the off hook state and the dial tone supervision is expired. Is there any signal which support such things. The second question would be how the access network come back to the normal feeding state, is there some special signal already defined ? Thank you in advance. Regards, Wieland Roeser _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Mar 24 06:59: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 GAA11096 for ; Mon, 24 Mar 2003 06:59: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 h2OCJ2O27512; Mon, 24 Mar 2003 07:19: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 h2LMKIO11733 for ; Fri, 21 Mar 2003 17:20:18 -0500 Received: from ntserv10.tx.tekelec.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28805 for ; Fri, 21 Mar 2003 17:01:15 -0500 (EST) Received: from tekelec.com ([172.25.11.41]) by ntserv10.tx.tekelec.com (Lotus Domino Release 5.0.9a) with ESMTP id 2003032115584385:33913 ; Fri, 21 Mar 2003 15:58:43 -0600 Message-ID: <3E7B8C6E.4000803@tekelec.com> Date: Fri, 21 Mar 2003 16:04:30 -0600 From: Adrian Soncodi User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en,pdf MIME-Version: 1.0 To: megaco@ietf.org X-MIMETrack: Itemize by SMTP Server on NTServ10/Richardson/TEKELEC(Release 5.0.9a |January 7, 2002) at 03/21/2003 03:58:43 PM, Serialize by Router on NTServ10/Richardson/TEKELEC(Release 5.0.9a |January 7, 2002) at 03/21/2003 04:03:33 PM, Serialize complete at 03/21/2003 04:03:33 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Megaco] LockStep and digit collection Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 Can anybody help me with the following questions? I am trying to reliably collect several successive digit strings from an MG. These strings correspond to potentially different digit maps, and dial-ahead is allowed. 1) When sending the first DigitMap, I specify LockStep=On, so that after the first digit string is collected, subsequent digits are buffered. To get a notification for the next string, I specify "dd/ce" in the EventBufferDescriptor, do I also need to specify each individual digit in order for them to be buffered? (I am not interested in the particular digits, just the whole string.) I know that "dd/ce" implies detection of "dd/*", does it also imply buffering of "dd/*"? 2) Does this work? The behavior I expect is: after the MG reports the first string, subsequent digits are buffered. Then after I send another DigitMap+ce to the MG AND when a match is detected, the MG sends a notification for the second string. In other words, is this the correct way to avoid losing the dialed-ahead digits from the second string, in case the second DigitMap does not get to the MG fast enough? 3) I also expect any unmatched digit that terminates the first DigitMap to be buffered and to be matched against the second DigitMap, is this correct? 4) To continue like this, do I need to keep specifying EventBufferControl=LockStep with every new DigitMap, or does this default to the previous value until I turn it off? 5) Before collecting the second string, I also want to play an interruptible announcement (KeepActive=false). Therefore, along with the DigitMap, I also apply a signal. When an announcement is played, normally the first digit detected stops it. But if some digits are already present (because of dial-ahead) in the EventBuffer when the second DigitMap and signal are applied, what happens to the announcement signal? is it played at all? Obviously, on dial-ahead I would like to suppress it. Thanks, Adrian Soncodi Tekelec, Richardson, TX _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Mar 24 07:00: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 HAA11144 for ; Mon, 24 Mar 2003 07:00:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OCKaa27580 for megaco-archive@odin.ietf.org; Mon, 24 Mar 2003 07:20: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 h2OCKaO27577 for ; Mon, 24 Mar 2003 07:20: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 HAA11138 for ; Mon, 24 Mar 2003 07:00: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 h2OCJ2O27512; Mon, 24 Mar 2003 07:19: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 h2LMKIO11733 for ; Fri, 21 Mar 2003 17:20:18 -0500 Received: from ntserv10.tx.tekelec.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28805 for ; Fri, 21 Mar 2003 17:01:15 -0500 (EST) Received: from tekelec.com ([172.25.11.41]) by ntserv10.tx.tekelec.com (Lotus Domino Release 5.0.9a) with ESMTP id 2003032115584385:33913 ; Fri, 21 Mar 2003 15:58:43 -0600 Message-ID: <3E7B8C6E.4000803@tekelec.com> Date: Fri, 21 Mar 2003 16:04:30 -0600 From: Adrian Soncodi User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en,pdf MIME-Version: 1.0 To: megaco@ietf.org X-MIMETrack: Itemize by SMTP Server on NTServ10/Richardson/TEKELEC(Release 5.0.9a |January 7, 2002) at 03/21/2003 03:58:43 PM, Serialize by Router on NTServ10/Richardson/TEKELEC(Release 5.0.9a |January 7, 2002) at 03/21/2003 04:03:33 PM, Serialize complete at 03/21/2003 04:03:33 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Megaco] LockStep and digit collection Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 Can anybody help me with the following questions? I am trying to reliably collect several successive digit strings from an MG. These strings correspond to potentially different digit maps, and dial-ahead is allowed. 1) When sending the first DigitMap, I specify LockStep=On, so that after the first digit string is collected, subsequent digits are buffered. To get a notification for the next string, I specify "dd/ce" in the EventBufferDescriptor, do I also need to specify each individual digit in order for them to be buffered? (I am not interested in the particular digits, just the whole string.) I know that "dd/ce" implies detection of "dd/*", does it also imply buffering of "dd/*"? 2) Does this work? The behavior I expect is: after the MG reports the first string, subsequent digits are buffered. Then after I send another DigitMap+ce to the MG AND when a match is detected, the MG sends a notification for the second string. In other words, is this the correct way to avoid losing the dialed-ahead digits from the second string, in case the second DigitMap does not get to the MG fast enough? 3) I also expect any unmatched digit that terminates the first DigitMap to be buffered and to be matched against the second DigitMap, is this correct? 4) To continue like this, do I need to keep specifying EventBufferControl=LockStep with every new DigitMap, or does this default to the previous value until I turn it off? 5) Before collecting the second string, I also want to play an interruptible announcement (KeepActive=false). Therefore, along with the DigitMap, I also apply a signal. When an announcement is played, normally the first digit detected stops it. But if some digits are already present (because of dial-ahead) in the EventBuffer when the second DigitMap and signal are applied, what happens to the announcement signal? is it played at all? Obviously, on dial-ahead I would like to suppress it. Thanks, Adrian Soncodi Tekelec, Richardson, TX _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Mar 24 09:16: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 JAA19354 for ; Mon, 24 Mar 2003 09:16: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 h2OEZSO04643; Mon, 24 Mar 2003 09:35:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OEVfO04498 for ; Mon, 24 Mar 2003 09:31:41 -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 JAA19184 for ; Mon, 24 Mar 2003 09:11:18 -0500 (EST) From: ajhingran@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2OEBjs05146 for ; Mon, 24 Mar 2003 19:41:45 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2OEBi205142 for ; Mon, 24 Mar 2003 19:41:44 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2OEEWE17372 for ; Mon, 24 Mar 2003 19:44:32 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CF3.004CE559 ; Mon, 24 Mar 2003 19:29:54 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CF3.004CE3FE.00@dlfmail1.hss.hns.com> Date: Mon, 24 Mar 2003 19:40:24 +0530 Subject: [Megaco] Audit Descriptor and under/overspecified Descriptor 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 I have a query with respect to conflicts between the underspecified overspecified descriptor processing and audit descriptor processing. Both of these descriptors in a command request mandate the inclusion of descriptors in the command reply.Whereas there can be scenarios when multiple candidate descriptors can occur in the command reply. How is the contention resolved? I am taking an example of media descriptor. e.g. Assuming an ephemeral termination with the following current state of the descriptors: LocalControl { Mode = Inactive, nt/jit=120 } Local { v=0 c=IN IP4 132.168.200.4 m=audio 6000 RTP/AVP 4 } Now, a MODIFY command with Audit descriptor and an underspecified/ overspecified Media Desc (Local desc) is received. Modify = rtp1000 { Audit { Media }, Media { Stream = 1 { LocalControl { Mode = ReceiveOnly, nt/jit=40 }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 0 8 }}}} Assuming that during the MODIFY command processing, MG selects the following new values: IP address - 132.168.200.5 port number - 7000 payload type - 8 How should the MODIFY command reply look like: Option 1 Old media descriptor is sent. Modify = rtp1000 { Media { Stream = 1 { LocalControl { Mode = Inactive, nt/jit=120 }, Local { v=0 c=IN IP4 132.168.200.4 m=audio 6000 RTP/AVP 4 }}}} But, as per the protocol the underspecified/ overspecified Local descriptor after resolution in the MG must be returned in the response. Option 2 Old media descriptor with overwritten underspecified/ overspecified Local descriptor after resolution is sent. Modify = rtp1000 { Media { Stream = 1 { LocalControl { Mode = Inactive, nt/jit=120 }, Local { v=0 c=IN IP4 132.168.200.5 m=audio 7000 RTP/AVP 8 }}}} But, the complete Media descriptor is inconsistent, i.e., Local COntrol is old but the Local descriptor is the new one. Although, MGC would know which descriptor was underspecified/ overspecfied in the request and can relate. Option 3 New media descriptor is sent. Modify = rtp1000 { Media { Stream = 1 { LocalControl { Mode = ReceiveOnly, nt/jit=40 }, Local { v=0 c=IN IP4 132.168.200.5 m=audio 7000 RTP/AVP 8 }}}} But, as per the protocol the descriptors need to be processed in sequence of occurance and therefore, media descriptor should be the old one. I am still unclear if the protocol resolves this problem. Please comment? Rgds Ashish Jhingran _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Mar 24 09:17: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 JAA19424 for ; Mon, 24 Mar 2003 09:17:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OEbCM05103 for megaco-archive@odin.ietf.org; Mon, 24 Mar 2003 09:37: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 h2OEbCO05100 for ; Mon, 24 Mar 2003 09:37: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 JAA19400 for ; Mon, 24 Mar 2003 09:16: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 h2OEZSO04643; Mon, 24 Mar 2003 09:35:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OEVfO04498 for ; Mon, 24 Mar 2003 09:31:41 -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 JAA19184 for ; Mon, 24 Mar 2003 09:11:18 -0500 (EST) From: ajhingran@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2OEBjs05146 for ; Mon, 24 Mar 2003 19:41:45 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2OEBi205142 for ; Mon, 24 Mar 2003 19:41:44 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2OEEWE17372 for ; Mon, 24 Mar 2003 19:44:32 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CF3.004CE559 ; Mon, 24 Mar 2003 19:29:54 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CF3.004CE3FE.00@dlfmail1.hss.hns.com> Date: Mon, 24 Mar 2003 19:40:24 +0530 Subject: [Megaco] Audit Descriptor and under/overspecified Descriptor 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 I have a query with respect to conflicts between the underspecified overspecified descriptor processing and audit descriptor processing. Both of these descriptors in a command request mandate the inclusion of descriptors in the command reply.Whereas there can be scenarios when multiple candidate descriptors can occur in the command reply. How is the contention resolved? I am taking an example of media descriptor. e.g. Assuming an ephemeral termination with the following current state of the descriptors: LocalControl { Mode = Inactive, nt/jit=120 } Local { v=0 c=IN IP4 132.168.200.4 m=audio 6000 RTP/AVP 4 } Now, a MODIFY command with Audit descriptor and an underspecified/ overspecified Media Desc (Local desc) is received. Modify = rtp1000 { Audit { Media }, Media { Stream = 1 { LocalControl { Mode = ReceiveOnly, nt/jit=40 }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 0 8 }}}} Assuming that during the MODIFY command processing, MG selects the following new values: IP address - 132.168.200.5 port number - 7000 payload type - 8 How should the MODIFY command reply look like: Option 1 Old media descriptor is sent. Modify = rtp1000 { Media { Stream = 1 { LocalControl { Mode = Inactive, nt/jit=120 }, Local { v=0 c=IN IP4 132.168.200.4 m=audio 6000 RTP/AVP 4 }}}} But, as per the protocol the underspecified/ overspecified Local descriptor after resolution in the MG must be returned in the response. Option 2 Old media descriptor with overwritten underspecified/ overspecified Local descriptor after resolution is sent. Modify = rtp1000 { Media { Stream = 1 { LocalControl { Mode = Inactive, nt/jit=120 }, Local { v=0 c=IN IP4 132.168.200.5 m=audio 7000 RTP/AVP 8 }}}} But, the complete Media descriptor is inconsistent, i.e., Local COntrol is old but the Local descriptor is the new one. Although, MGC would know which descriptor was underspecified/ overspecfied in the request and can relate. Option 3 New media descriptor is sent. Modify = rtp1000 { Media { Stream = 1 { LocalControl { Mode = ReceiveOnly, nt/jit=40 }, Local { v=0 c=IN IP4 132.168.200.5 m=audio 7000 RTP/AVP 8 }}}} But, as per the protocol the descriptors need to be processed in sequence of occurance and therefore, media descriptor should be the old one. I am still unclear if the protocol resolves this problem. Please comment? Rgds Ashish Jhingran _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Mar 24 09:57: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 JAA20660 for ; Mon, 24 Mar 2003 09:57: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 h2OFHJO08166; Mon, 24 Mar 2003 10:17:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OFG8O08105 for ; Mon, 24 Mar 2003 10:16:08 -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 JAA20571 for ; Mon, 24 Mar 2003 09:55:46 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2OEw1206225; Mon, 24 Mar 2003 09:58:01 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 09:58:02 -0500 Message-ID: From: "Kevin Boyle" To: Jean-Luc.Lecuyer@alcatel.fr, megaco@ietf.org Subject: RE: [Megaco] CLIP function with Megaco Date: Mon, 24 Mar 2003 09:58:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F215.C3F76C84" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2F215.C3F76C84 Content-Type: text/plain The draft has been pulled from the IETF, and has been submitted as a work item in SG16. Given the length of time this package has existed, and the extended comment period it has been given, I expect the document will consent in May at the SG16 meeting. Kevin -----Original Message----- From: Jean-Luc.Lecuyer@alcatel.fr [mailto:Jean-Luc.Lecuyer@alcatel.fr] Sent: Monday, March 24, 2003 5:06 AM To: megaco@ietf.org Subject: [Megaco] CLIP function with Megaco I have a question about the "Enhanced Alerting package" (alert) and on the "Analog Display Signalling Package" (andisp) I found these packages specified in draft-boyle-megaco-alerting-03.txt. However, that package expired in March 2002 and I did not find any newer document referencing these packages. What is the current status of these packages ? Best regards and many thanks, Jean-Luc Lecuyer ---------------------------------------------------------------------------- ---------------- Jean-Luc.Lecuyer : FND/E10VS/R&D/CCPD Lannion Full telephone number : 33 (0)2 96 04 77 09 Full fax number : 33 (0)2 96 04 72 35 Email : jean-luc.lecuyer@alcatel.fr ---------------------------------------------------------------------------- ----------------- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C2F215.C3F76C84 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Megaco] CLIP function with Megaco

The draft has been pulled from the IETF, and has been = submitted as a work item in SG16.  Given the length of time this = package has existed, and the extended comment period it has been given, = I expect the document will consent in May at the SG16 = meeting.

Kevin

-----Original Message-----
From: Jean-Luc.Lecuyer@alcatel.fr [mailto:Jean-Luc.Lecuyer@alca= tel.fr]
Sent: Monday, March 24, 2003 5:06 AM
To: megaco@ietf.org
Subject: [Megaco] CLIP function with Megaco



I have a question about the "Enhanced Alerting = package" (alert) and on the "Analog Display Signalling = Package" (andisp)

I found these packages specified in = draft-boyle-megaco-alerting-03.txt.

However, that package expired in March 2002 and I did = not find any newer document referencing these packages.

What is the current status of these packages ?


Best regards and many thanks,
Jean-Luc Lecuyer
---------------------------------------------------------------= -----------------------------

Jean-Luc.Lecuyer = :            = ;       FND/E10VS/R&D/CCPD = Lannion
Full telephone number = :            = ;            = ;            = ;     33 (0)2 96
04 77 09
Full fax number = :            = ;            = ;            = ;            = ;        33
(0)2 96 04 72 35
Email :
jean-luc.lecuyer@alcatel.fr
---------------------------------------------------------------= ------------------------------



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

------_=_NextPart_001_01C2F215.C3F76C84-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Mar 24 09:58: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 JAA20706 for ; Mon, 24 Mar 2003 09:58:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OFInY08275 for megaco-archive@odin.ietf.org; Mon, 24 Mar 2003 10:18: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 h2OFInO08272 for ; Mon, 24 Mar 2003 10:18:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20700 for ; Mon, 24 Mar 2003 09:58: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 h2OFHJO08166; Mon, 24 Mar 2003 10:17:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OFG8O08105 for ; Mon, 24 Mar 2003 10:16:08 -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 JAA20571 for ; Mon, 24 Mar 2003 09:55:46 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2OEw1206225; Mon, 24 Mar 2003 09:58:01 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 09:58:02 -0500 Message-ID: From: "Kevin Boyle" To: Jean-Luc.Lecuyer@alcatel.fr, megaco@ietf.org Subject: RE: [Megaco] CLIP function with Megaco Date: Mon, 24 Mar 2003 09:58:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F215.C3F76C84" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2F215.C3F76C84 Content-Type: text/plain The draft has been pulled from the IETF, and has been submitted as a work item in SG16. Given the length of time this package has existed, and the extended comment period it has been given, I expect the document will consent in May at the SG16 meeting. Kevin -----Original Message----- From: Jean-Luc.Lecuyer@alcatel.fr [mailto:Jean-Luc.Lecuyer@alcatel.fr] Sent: Monday, March 24, 2003 5:06 AM To: megaco@ietf.org Subject: [Megaco] CLIP function with Megaco I have a question about the "Enhanced Alerting package" (alert) and on the "Analog Display Signalling Package" (andisp) I found these packages specified in draft-boyle-megaco-alerting-03.txt. However, that package expired in March 2002 and I did not find any newer document referencing these packages. What is the current status of these packages ? Best regards and many thanks, Jean-Luc Lecuyer ---------------------------------------------------------------------------- ---------------- Jean-Luc.Lecuyer : FND/E10VS/R&D/CCPD Lannion Full telephone number : 33 (0)2 96 04 77 09 Full fax number : 33 (0)2 96 04 72 35 Email : jean-luc.lecuyer@alcatel.fr ---------------------------------------------------------------------------- ----------------- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C2F215.C3F76C84 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Megaco] CLIP function with Megaco

The draft has been pulled from the IETF, and has been = submitted as a work item in SG16.  Given the length of time this = package has existed, and the extended comment period it has been given, = I expect the document will consent in May at the SG16 = meeting.

Kevin

-----Original Message-----
From: Jean-Luc.Lecuyer@alcatel.fr [mailto:Jean-Luc.Lecuyer@alca= tel.fr]
Sent: Monday, March 24, 2003 5:06 AM
To: megaco@ietf.org
Subject: [Megaco] CLIP function with Megaco



I have a question about the "Enhanced Alerting = package" (alert) and on the "Analog Display Signalling = Package" (andisp)

I found these packages specified in = draft-boyle-megaco-alerting-03.txt.

However, that package expired in March 2002 and I did = not find any newer document referencing these packages.

What is the current status of these packages ?


Best regards and many thanks,
Jean-Luc Lecuyer
---------------------------------------------------------------= -----------------------------

Jean-Luc.Lecuyer = :            = ;       FND/E10VS/R&D/CCPD = Lannion
Full telephone number = :            = ;            = ;            = ;     33 (0)2 96
04 77 09
Full fax number = :            = ;            = ;            = ;            = ;        33
(0)2 96 04 72 35
Email :
jean-luc.lecuyer@alcatel.fr
---------------------------------------------------------------= ------------------------------



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

------_=_NextPart_001_01C2F215.C3F76C84-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Mar 24 10:57: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 KAA23849 for ; Mon, 24 Mar 2003 10:57: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 h2OGGiO12457; Mon, 24 Mar 2003 11:16: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 h2OGFrO12413 for ; Mon, 24 Mar 2003 11:15:53 -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 KAA23813 for ; Mon, 24 Mar 2003 10:55:29 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2OFvkh27290 for ; Mon, 24 Mar 2003 10:57:46 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 10:57:47 -0500 Message-ID: From: "Kevin Boyle" To: Roeser Wieland , "'megaco@ietf.org'" Subject: RE: [Megaco] MEGACO support for reduction of line feeding and swi tching back t o normal feeding Date: Mon, 24 Mar 2003 10:57: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: , In most places, the line is placed in a "lockout" state. While there is a tone played in some localities to attempt to get the attention of the subscriber (to hang up their phone), even that has a time limit associated with its playout. There is a "Receiver Off-hook Warning" tone, commonly known as ROH, is defined in the Expanded Call Progress Tone Generator Package. It is defined in ITU-T Recommendation Q.1950, Annex A. Kevin -----Original Message----- From: Roeser Wieland [mailto:wieland.roeser@siemens.com] Sent: Monday, March 24, 2003 5:43 AM To: 'megaco@ietf.org' Subject: [Megaco] MEGACO support for reduction of line feeding and switching back t o normal feeding Hi all, I have a question regarding the support of MEGACO packages for the following behavior. In many countries a mechanism is used to reduce line feeding after the A subscriber is in the off hook state and the dial tone supervision is expired. Is there any signal which support such things. The second question would be how the access network come back to the normal feeding state, is there some special signal already defined ? Thank you in advance. Regards, Wieland Roeser _______________________________________________ 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 Mar 24 10:58: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 KAA23935 for ; Mon, 24 Mar 2003 10:58:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OGIPK12603 for megaco-archive@odin.ietf.org; Mon, 24 Mar 2003 11:18: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 h2OGIPO12600 for ; Mon, 24 Mar 2003 11:18:25 -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 KAA23883 for ; Mon, 24 Mar 2003 10:58: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 h2OGGiO12457; Mon, 24 Mar 2003 11:16: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 h2OGFrO12413 for ; Mon, 24 Mar 2003 11:15:53 -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 KAA23813 for ; Mon, 24 Mar 2003 10:55:29 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2OFvkh27290 for ; Mon, 24 Mar 2003 10:57:46 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 10:57:47 -0500 Message-ID: From: "Kevin Boyle" To: Roeser Wieland , "'megaco@ietf.org'" Subject: RE: [Megaco] MEGACO support for reduction of line feeding and swi tching back t o normal feeding Date: Mon, 24 Mar 2003 10:57: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: , In most places, the line is placed in a "lockout" state. While there is a tone played in some localities to attempt to get the attention of the subscriber (to hang up their phone), even that has a time limit associated with its playout. There is a "Receiver Off-hook Warning" tone, commonly known as ROH, is defined in the Expanded Call Progress Tone Generator Package. It is defined in ITU-T Recommendation Q.1950, Annex A. Kevin -----Original Message----- From: Roeser Wieland [mailto:wieland.roeser@siemens.com] Sent: Monday, March 24, 2003 5:43 AM To: 'megaco@ietf.org' Subject: [Megaco] MEGACO support for reduction of line feeding and switching back t o normal feeding Hi all, I have a question regarding the support of MEGACO packages for the following behavior. In many countries a mechanism is used to reduce line feeding after the A subscriber is in the off hook state and the dial tone supervision is expired. Is there any signal which support such things. The second question would be how the access network come back to the normal feeding state, is there some special signal already defined ? Thank you in advance. Regards, Wieland Roeser _______________________________________________ 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 Mar 24 10:58: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 KAA23951 for ; Mon, 24 Mar 2003 10:58: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 h2OGI7O12539; Mon, 24 Mar 2003 11:18: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 h2OGHLO12496 for ; Mon, 24 Mar 2003 11:17:21 -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 KAA23842 for ; Mon, 24 Mar 2003 10:56:57 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2OFxFh28439 for ; Mon, 24 Mar 2003 10:59:15 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 10:59:16 -0500 Message-ID: From: "Kevin Boyle" To: Christian Groves Cc: knayar@hss.hns.com, "Tom-PT Taylor" , klaha@hss.hns.com, gsachin@hss.hns.com, Megaco List Subject: RE: [Megaco] Service change Restart Date: Mon, 24 Mar 2003 10:59:15 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Well, that's why I said the "current plan". As Christian has pointed out, final decisions have yet to be made on where and how to incorporate the Annex into the Recommendation. Kevin -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] Sent: Wednesday, March 19, 2003 7:04 PM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: knayar@hss.hns.com; Taylor, Tom-PT [CAR:5N00:EXCH]; klaha@hss.hns.com; gsachin@hss.hns.com; Megaco List Subject: Re: [Megaco] Service change Restart G'Day, I don't think it has been decided to incorporate it back into both v1 and v2. >From discussion at SanJose I thought we would take the decision on what >to do with the work ie. annex, appendix or merging when it came nearer to the time to approve the work. Regards, Christian Kevin Boyle wrote: > > The current plan is to incorporate it back into both V1 and V2 (since > the new Annex doesn't change the existing spec, it only makes > clarifications). The current timeline is May, however, I wouldn't be > surprised if the Annex will be held until February 2004. > > Kevin > > -----Original Message----- > From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] > Sent: Monday, March 17, 2003 10:55 PM > To: Boyle, Kevin [NCRTP:3Z40:EXCH] > Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; klaha@hss.hns.com; > gsachin@hss.hns.com; Megaco List > Subject: RE: [Megaco] Service change Restart > > Hi Kevin > > Thanks for the useful pointer... > I did like to know if the Annex-F is intended to be part of H.248v2 > only or will also be applicable to H.248v1. Any information about the > time lines by when it would be finalised/ freezed. > > regards, > -kapil nayar > http://www.hssworld.com > > "Kevin Boyle" on 03/14/2003 08:33:23 PM > > To: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS > cc: Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: Kapil > Nayar/HSS) > > Subject: RE: [Megaco] Service change Restart > > This work is ongoing in SG16 as future Annex F. Both of these items > are intended to be clarified by the new work. > > The input documents to the San Jose Rapporteurs' Meeting can be found > as AVD-2310, AVD-2311, and AVD-2298 at > ftp://standard.pictel.com/avc-site/0302_San/. > > Kevin > > -----Original Message----- > From: Taylor, Tom-PT [CAR:5N00:EXCH] > Sent: Friday, March 14, 2003 9:30 AM > To: klaha@hss.hns.com > Cc: gsachin@hss.hns.com; Megaco List > Subject: Re: [Megaco] Service change Restart > > This is where the RFC is completely inadequate as it stands. I > wouldn't mind seeing it rewritten to specify separately what happens > for ServiceChange on ROOT vs. ServiceChange on individual > terminations. With regard to the latter, there is also something else > I'd like to see ironed > out: the service state is a writable property in TerminationState, yet it is > manipulated by ServiceChange. One or the other of these should go. > > I am quite prepared to submit a proposal for new text for section > 7.2.8 in particular. Would there be interest in reviewing such a > proposal? We could submit it as a contribution into SG 16's May > meeting if that is workable. > > klaha@hss.hns.com wrote: > > > > How about ServiceChange Restart on ROOT from MGC?Does the protocol > > inhibit it? (It can be an easier means for the MGC to inform MG to > > delete all contexts rather than 'Subtract'ing each of them, when MGC > > is taken gracefully > > out-of-service) > > > > > > > > > > > > Tom Taylor on 03/14/2003 12:27:35 AM > > > > To: Sachin Gupta-PNGN/HSS@HSS, Megaco List > > cc: (bcc: Kushanava Laha/HSS) > > > > Subject: Re: [Megaco] Service change Restart > > > > > > > > I agree that it's very difficult to assign any real meaning to an > > MGC-initiated restart of a termination. My background in switch > > software development tells me that a restart clears certain aspects > > of state. However, that makes little sense in the Megaco case, > > because the MGC can do that directly by subtracting the termination > > from any context it is in and resetting descriptors if it is not in > > a > context. > > > > Conclusion: the only thing an MGC-initiated restart of a termination > > does is change its state to in-service if it is not already there. > > > > gsachin@hss.hns.com wrote: > > > >>Hi List > >>I have a query regarding the processing of Service Change Restart. > >>consider the following scenario: > >> > >>Termination is in state InService. > >>Command recieved from MGC to Restart the termination (with or > >>wothout delay). > >> > >>what MG could possibly do in this case? > >> > >> > >>Thanks > >>Sachin Gupta > >> > > > > [disclaimer snipped] > > > > _______________________________________________ > > 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 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Mar 24 10:59: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 KAA23977 for ; Mon, 24 Mar 2003 10:59:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OGJiW12684 for megaco-archive@odin.ietf.org; Mon, 24 Mar 2003 11:19: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 h2OGJiO12681 for ; Mon, 24 Mar 2003 11:19: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 KAA23968 for ; Mon, 24 Mar 2003 10:59: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 h2OGI7O12539; Mon, 24 Mar 2003 11:18: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 h2OGHLO12496 for ; Mon, 24 Mar 2003 11:17:21 -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 KAA23842 for ; Mon, 24 Mar 2003 10:56:57 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2OFxFh28439 for ; Mon, 24 Mar 2003 10:59:15 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 10:59:16 -0500 Message-ID: From: "Kevin Boyle" To: Christian Groves Cc: knayar@hss.hns.com, "Tom-PT Taylor" , klaha@hss.hns.com, gsachin@hss.hns.com, Megaco List Subject: RE: [Megaco] Service change Restart Date: Mon, 24 Mar 2003 10:59:15 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Well, that's why I said the "current plan". As Christian has pointed out, final decisions have yet to be made on where and how to incorporate the Annex into the Recommendation. Kevin -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] Sent: Wednesday, March 19, 2003 7:04 PM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: knayar@hss.hns.com; Taylor, Tom-PT [CAR:5N00:EXCH]; klaha@hss.hns.com; gsachin@hss.hns.com; Megaco List Subject: Re: [Megaco] Service change Restart G'Day, I don't think it has been decided to incorporate it back into both v1 and v2. >From discussion at SanJose I thought we would take the decision on what >to do with the work ie. annex, appendix or merging when it came nearer to the time to approve the work. Regards, Christian Kevin Boyle wrote: > > The current plan is to incorporate it back into both V1 and V2 (since > the new Annex doesn't change the existing spec, it only makes > clarifications). The current timeline is May, however, I wouldn't be > surprised if the Annex will be held until February 2004. > > Kevin > > -----Original Message----- > From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] > Sent: Monday, March 17, 2003 10:55 PM > To: Boyle, Kevin [NCRTP:3Z40:EXCH] > Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; klaha@hss.hns.com; > gsachin@hss.hns.com; Megaco List > Subject: RE: [Megaco] Service change Restart > > Hi Kevin > > Thanks for the useful pointer... > I did like to know if the Annex-F is intended to be part of H.248v2 > only or will also be applicable to H.248v1. Any information about the > time lines by when it would be finalised/ freezed. > > regards, > -kapil nayar > http://www.hssworld.com > > "Kevin Boyle" on 03/14/2003 08:33:23 PM > > To: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS > cc: Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: Kapil > Nayar/HSS) > > Subject: RE: [Megaco] Service change Restart > > This work is ongoing in SG16 as future Annex F. Both of these items > are intended to be clarified by the new work. > > The input documents to the San Jose Rapporteurs' Meeting can be found > as AVD-2310, AVD-2311, and AVD-2298 at > ftp://standard.pictel.com/avc-site/0302_San/. > > Kevin > > -----Original Message----- > From: Taylor, Tom-PT [CAR:5N00:EXCH] > Sent: Friday, March 14, 2003 9:30 AM > To: klaha@hss.hns.com > Cc: gsachin@hss.hns.com; Megaco List > Subject: Re: [Megaco] Service change Restart > > This is where the RFC is completely inadequate as it stands. I > wouldn't mind seeing it rewritten to specify separately what happens > for ServiceChange on ROOT vs. ServiceChange on individual > terminations. With regard to the latter, there is also something else > I'd like to see ironed > out: the service state is a writable property in TerminationState, yet it is > manipulated by ServiceChange. One or the other of these should go. > > I am quite prepared to submit a proposal for new text for section > 7.2.8 in particular. Would there be interest in reviewing such a > proposal? We could submit it as a contribution into SG 16's May > meeting if that is workable. > > klaha@hss.hns.com wrote: > > > > How about ServiceChange Restart on ROOT from MGC?Does the protocol > > inhibit it? (It can be an easier means for the MGC to inform MG to > > delete all contexts rather than 'Subtract'ing each of them, when MGC > > is taken gracefully > > out-of-service) > > > > > > > > > > > > Tom Taylor on 03/14/2003 12:27:35 AM > > > > To: Sachin Gupta-PNGN/HSS@HSS, Megaco List > > cc: (bcc: Kushanava Laha/HSS) > > > > Subject: Re: [Megaco] Service change Restart > > > > > > > > I agree that it's very difficult to assign any real meaning to an > > MGC-initiated restart of a termination. My background in switch > > software development tells me that a restart clears certain aspects > > of state. However, that makes little sense in the Megaco case, > > because the MGC can do that directly by subtracting the termination > > from any context it is in and resetting descriptors if it is not in > > a > context. > > > > Conclusion: the only thing an MGC-initiated restart of a termination > > does is change its state to in-service if it is not already there. > > > > gsachin@hss.hns.com wrote: > > > >>Hi List > >>I have a query regarding the processing of Service Change Restart. > >>consider the following scenario: > >> > >>Termination is in state InService. > >>Command recieved from MGC to Restart the termination (with or > >>wothout delay). > >> > >>what MG could possibly do in this case? > >> > >> > >>Thanks > >>Sachin Gupta > >> > > > > [disclaimer snipped] > > > > _______________________________________________ > > 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 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Mar 24 11:27: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 LAA24691 for ; Mon, 24 Mar 2003 11:27: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 h2OGhGO14263; Mon, 24 Mar 2003 11: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 h2OGgtO14225 for ; Mon, 24 Mar 2003 11:42:55 -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 LAA24556 for ; Mon, 24 Mar 2003 11:22:30 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2OGOmh04916 for ; Mon, 24 Mar 2003 11:24:48 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 11:24:49 -0500 Message-ID: From: "Kevin Boyle" To: bvswamy@hss.hns.com, megaco@ietf.org Subject: RE: [Megaco] Service change Restart Date: Mon, 24 Mar 2003 11:24: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: , Comments inline. [KJBII] Before we get too bogged down into a lot of scenario by scenario details, keep in mind that the intent of this work is to define as simple a model as possible. There is no need to define an enormous state machine that has a state for every possible scenario. There are, in reality two states, and a possible third pseudo-state: In service, Out of service, and the fleeting delayed OOS brought about by things like a SC Graceful. Kevin -----Original Message----- From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] Sent: Thursday, March 20, 2003 2:43 AM To: megaco@ietf.org Subject: RE: [Megaco] Service change Restart Hi Kevin Few clarifications needed on the service change procedures: 1) What should MG do when it receives Service Change Restart on a already inservice termination which is in Non-Null context Should it give a error response or whether MG should clear the call and remove the termination from the context ? [KJBII] MGs may not remove terms from context without a Subtract command from the MGC. The MG should Restart the term, in accordance with its function and provisioning, and await cleanup commands from the MGC. If that restart means that the media stream is lost, then that is something that the MGC should take into account before requesting that the MG restart a particular termination. 2) If ServiceChange Restart with delay is recd by MG for an already Inservice termination which may or may not be in call then what should be MG behaviour. Should it mark the termination as Out-Of-Service till the delay timer expires and remove the termination from the context or give a error response ? [KJBII] If the term is inservice, and the command is to restart, why would you remove it from service? The delay is just that -- a delay. Don't do anything with the term until the delay expires, and then Restart it upon the expiry of the delay. 3) If Service Change Graceful with delay is received by MG for an already out of service termination then how should MG behave? Should it mark the termination in-service right now and after timer expiry mark it out-of-service or should it give an error? [KJBII] So, an out of service termination receives a command to take it out of service. I say acknowledge the command, and leave the termination as it is -- delay or not. Since it is already out of service, this is, effectively, a no-op. Now, the implications to think about are: What if the MG took the term OOS, and then, later, the MGC sends a Forced or Graceful? This has the implication that the MG, by itself, cannot bring the termination back into service. It implies, to me, that BOTH the MG and MGC must take action on that term in order to have it return to service. In all of the above cases if MG were to give a error response then there is no error-code defined which specifies that MG is already in the state which MGC has requested , however there is an error-code "Not-Ready" defined as "The command directed to a termination was not executed because of the service state of the termination" which can be used in these situations for conveying MGC that requested operation is not done. 4) What should be the MGC behaviour in the following scenario: 1) MGC recevies a Service Change graceful with NonNull delay for a termination in context. 2) Now MG want to cancel the graceful timer. The only way do currently is by sending a service Change Restart. Now what should be MGC behaviour. Should it only stop the timer and continue the call or end the call and the mark the termination as Inservice. [KJBII] I believe that any SC command received while there is one still awaiting its SCDelay expiry effectively overrides the existing command. For example, if a SC Graceful with a long delay is in progress, and a SC Forced with comes during the delay timing, then the Graceful is cancelled, and the Forced is executed as signaled. I hope SG16 Annex F will also clarify doubts over the above items. Regards Venkat knayar@hss.hns.com on 03/18/2003 09:25:04 AM To: "Kevin Boyle" cc: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS, Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: B Venkat S.R Swamy/HSS) Subject: RE: [Megaco] Service change Restart Hi Kevin Thanks for the useful pointer... I did like to know if the Annex-F is intended to be part of H.248v2 only or will also be applicable to H.248v1. Any information about the time lines by when it would be finalised/ freezed. regards, -kapil nayar http://www.hssworld.com "Kevin Boyle" on 03/14/2003 08:33:23 PM To: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS cc: Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: Kapil Nayar/HSS) Subject: RE: [Megaco] Service change Restart This work is ongoing in SG16 as future Annex F. Both of these items are intended to be clarified by the new work. The input documents to the San Jose Rapporteurs' Meeting can be found as AVD-2310, AVD-2311, and AVD-2298 at ftp://standard.pictel.com/avc-site/0302_San/. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Friday, March 14, 2003 9:30 AM To: klaha@hss.hns.com Cc: gsachin@hss.hns.com; Megaco List Subject: Re: [Megaco] Service change Restart This is where the RFC is completely inadequate as it stands. I wouldn't mind seeing it rewritten to specify separately what happens for ServiceChange on ROOT vs. ServiceChange on individual terminations. With regard to the latter, there is also something else I'd like to see ironed out: the service state is a writable property in TerminationState, yet it is manipulated by ServiceChange. One or the other of these should go. I am quite prepared to submit a proposal for new text for section 7.2.8 in particular. Would there be interest in reviewing such a proposal? We could submit it as a contribution into SG 16's May meeting if that is workable. klaha@hss.hns.com wrote: > > How about ServiceChange Restart on ROOT from MGC?Does the protocol > inhibit it? (It can be an easier means for the MGC to inform MG to > delete all contexts rather than 'Subtract'ing each of them, when MGC > is taken gracefully > out-of-service) > > > > > > Tom Taylor on 03/14/2003 12:27:35 AM > > To: Sachin Gupta-PNGN/HSS@HSS, Megaco List > cc: (bcc: Kushanava Laha/HSS) > > Subject: Re: [Megaco] Service change Restart > > > > I agree that it's very difficult to assign any real meaning to an > MGC-initiated restart of a termination. My background in switch > software development tells me that a restart clears certain aspects of > state. However, that makes little sense in the Megaco case, because > the MGC can do that directly by subtracting the termination from any > context it is in and resetting descriptors if it is not in a context. > > Conclusion: the only thing an MGC-initiated restart of a termination > does is change its state to in-service if it is not already there. > > gsachin@hss.hns.com wrote: > >>Hi List >>I have a query regarding the processing of Service Change Restart. >>consider the following scenario: >> >>Termination is in state InService. >>Command recieved from MGC to Restart the termination (with or wothout >>delay). >> >>what MG could possibly do in this case? >> >> >>Thanks >>Sachin Gupta >> > > [disclaimer snipped] > > _______________________________________________ > 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 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Mar 24 11:28: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 LAA24724 for ; Mon, 24 Mar 2003 11:28:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OGmII14471 for megaco-archive@odin.ietf.org; Mon, 24 Mar 2003 11:48: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 h2OGmIO14468 for ; Mon, 24 Mar 2003 11:48:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24714 for ; Mon, 24 Mar 2003 11:27: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 h2OGhGO14263; Mon, 24 Mar 2003 11: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 h2OGgtO14225 for ; Mon, 24 Mar 2003 11:42:55 -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 LAA24556 for ; Mon, 24 Mar 2003 11:22:30 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2OGOmh04916 for ; Mon, 24 Mar 2003 11:24:48 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 11:24:49 -0500 Message-ID: From: "Kevin Boyle" To: bvswamy@hss.hns.com, megaco@ietf.org Subject: RE: [Megaco] Service change Restart Date: Mon, 24 Mar 2003 11:24: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: , Comments inline. [KJBII] Before we get too bogged down into a lot of scenario by scenario details, keep in mind that the intent of this work is to define as simple a model as possible. There is no need to define an enormous state machine that has a state for every possible scenario. There are, in reality two states, and a possible third pseudo-state: In service, Out of service, and the fleeting delayed OOS brought about by things like a SC Graceful. Kevin -----Original Message----- From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] Sent: Thursday, March 20, 2003 2:43 AM To: megaco@ietf.org Subject: RE: [Megaco] Service change Restart Hi Kevin Few clarifications needed on the service change procedures: 1) What should MG do when it receives Service Change Restart on a already inservice termination which is in Non-Null context Should it give a error response or whether MG should clear the call and remove the termination from the context ? [KJBII] MGs may not remove terms from context without a Subtract command from the MGC. The MG should Restart the term, in accordance with its function and provisioning, and await cleanup commands from the MGC. If that restart means that the media stream is lost, then that is something that the MGC should take into account before requesting that the MG restart a particular termination. 2) If ServiceChange Restart with delay is recd by MG for an already Inservice termination which may or may not be in call then what should be MG behaviour. Should it mark the termination as Out-Of-Service till the delay timer expires and remove the termination from the context or give a error response ? [KJBII] If the term is inservice, and the command is to restart, why would you remove it from service? The delay is just that -- a delay. Don't do anything with the term until the delay expires, and then Restart it upon the expiry of the delay. 3) If Service Change Graceful with delay is received by MG for an already out of service termination then how should MG behave? Should it mark the termination in-service right now and after timer expiry mark it out-of-service or should it give an error? [KJBII] So, an out of service termination receives a command to take it out of service. I say acknowledge the command, and leave the termination as it is -- delay or not. Since it is already out of service, this is, effectively, a no-op. Now, the implications to think about are: What if the MG took the term OOS, and then, later, the MGC sends a Forced or Graceful? This has the implication that the MG, by itself, cannot bring the termination back into service. It implies, to me, that BOTH the MG and MGC must take action on that term in order to have it return to service. In all of the above cases if MG were to give a error response then there is no error-code defined which specifies that MG is already in the state which MGC has requested , however there is an error-code "Not-Ready" defined as "The command directed to a termination was not executed because of the service state of the termination" which can be used in these situations for conveying MGC that requested operation is not done. 4) What should be the MGC behaviour in the following scenario: 1) MGC recevies a Service Change graceful with NonNull delay for a termination in context. 2) Now MG want to cancel the graceful timer. The only way do currently is by sending a service Change Restart. Now what should be MGC behaviour. Should it only stop the timer and continue the call or end the call and the mark the termination as Inservice. [KJBII] I believe that any SC command received while there is one still awaiting its SCDelay expiry effectively overrides the existing command. For example, if a SC Graceful with a long delay is in progress, and a SC Forced with comes during the delay timing, then the Graceful is cancelled, and the Forced is executed as signaled. I hope SG16 Annex F will also clarify doubts over the above items. Regards Venkat knayar@hss.hns.com on 03/18/2003 09:25:04 AM To: "Kevin Boyle" cc: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS, Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: B Venkat S.R Swamy/HSS) Subject: RE: [Megaco] Service change Restart Hi Kevin Thanks for the useful pointer... I did like to know if the Annex-F is intended to be part of H.248v2 only or will also be applicable to H.248v1. Any information about the time lines by when it would be finalised/ freezed. regards, -kapil nayar http://www.hssworld.com "Kevin Boyle" on 03/14/2003 08:33:23 PM To: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS cc: Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: Kapil Nayar/HSS) Subject: RE: [Megaco] Service change Restart This work is ongoing in SG16 as future Annex F. Both of these items are intended to be clarified by the new work. The input documents to the San Jose Rapporteurs' Meeting can be found as AVD-2310, AVD-2311, and AVD-2298 at ftp://standard.pictel.com/avc-site/0302_San/. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Friday, March 14, 2003 9:30 AM To: klaha@hss.hns.com Cc: gsachin@hss.hns.com; Megaco List Subject: Re: [Megaco] Service change Restart This is where the RFC is completely inadequate as it stands. I wouldn't mind seeing it rewritten to specify separately what happens for ServiceChange on ROOT vs. ServiceChange on individual terminations. With regard to the latter, there is also something else I'd like to see ironed out: the service state is a writable property in TerminationState, yet it is manipulated by ServiceChange. One or the other of these should go. I am quite prepared to submit a proposal for new text for section 7.2.8 in particular. Would there be interest in reviewing such a proposal? We could submit it as a contribution into SG 16's May meeting if that is workable. klaha@hss.hns.com wrote: > > How about ServiceChange Restart on ROOT from MGC?Does the protocol > inhibit it? (It can be an easier means for the MGC to inform MG to > delete all contexts rather than 'Subtract'ing each of them, when MGC > is taken gracefully > out-of-service) > > > > > > Tom Taylor on 03/14/2003 12:27:35 AM > > To: Sachin Gupta-PNGN/HSS@HSS, Megaco List > cc: (bcc: Kushanava Laha/HSS) > > Subject: Re: [Megaco] Service change Restart > > > > I agree that it's very difficult to assign any real meaning to an > MGC-initiated restart of a termination. My background in switch > software development tells me that a restart clears certain aspects of > state. However, that makes little sense in the Megaco case, because > the MGC can do that directly by subtracting the termination from any > context it is in and resetting descriptors if it is not in a context. > > Conclusion: the only thing an MGC-initiated restart of a termination > does is change its state to in-service if it is not already there. > > gsachin@hss.hns.com wrote: > >>Hi List >>I have a query regarding the processing of Service Change Restart. >>consider the following scenario: >> >>Termination is in state InService. >>Command recieved from MGC to Restart the termination (with or wothout >>delay). >> >>what MG could possibly do in this case? >> >> >>Thanks >>Sachin Gupta >> > > [disclaimer snipped] > > _______________________________________________ > 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 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Mar 24 14:12: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 OAA29387 for ; Mon, 24 Mar 2003 14:12: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 h2OJVaO25308; Mon, 24 Mar 2003 14:31: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 h2OJU6O25244 for ; Mon, 24 Mar 2003 14:30:06 -0500 Received: from ntserv10.tx.tekelec.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29314 for ; Mon, 24 Mar 2003 14:09:40 -0500 (EST) Received: from tekelec.com ([172.25.11.41]) by ntserv10.tx.tekelec.com (Lotus Domino Release 5.0.9a) with ESMTP id 2003032413115766:1096 ; Mon, 24 Mar 2003 13:11:57 -0600 Message-ID: <3E7F59E1.9010408@tekelec.com> Date: Mon, 24 Mar 2003 13:17:53 -0600 From: Adrian Soncodi User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en,pdf MIME-Version: 1.0 To: megaco@ietf.org X-MIMETrack: Itemize by SMTP Server on NTServ10/Richardson/TEKELEC(Release 5.0.9a |January 7, 2002) at 03/24/2003 01:11:57 PM, Serialize by Router on NTServ10/Richardson/TEKELEC(Release 5.0.9a |January 7, 2002) at 03/24/2003 01:11:59 PM, Serialize complete at 03/24/2003 01:11:59 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Megaco] LockStep and digit collection Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 Can anybody help me with the following questions? I am trying to reliably collect several successive digit strings from an MG. These strings correspond to potentially different digit maps, and dial-ahead is allowed. 1) When sending the first DigitMap, I specify LockStep=On, so that after the first digit string is collected, subsequent digits are buffered. To get a notification for the next string, I specify "dd/ce" in the EventBufferDescriptor, do I also need to specify each individual digit in order for them to be buffered? (I am not interested in the particular digits, just the whole string.) I know that "dd/ce" implies detection of "dd/*", does it also imply buffering of "dd/*"? 2) Does this work? The behavior I expect is: after the MG reports the first string, subsequent digits are buffered. Then after I send another DigitMap+ce to the MG AND when a match is detected, the MG sends a notification for the second string. In other words, is this the correct way to avoid losing the dialed-ahead digits from the second string, in case the second DigitMap does not get to the MG fast enough? 3) I also expect any unmatched digit that terminates the first DigitMap to be buffered and to be matched against the second DigitMap, is this correct? 4) To continue like this, do I need to keep specifying EventBufferControl=LockStep with every new DigitMap, or does this default to the previous value until I turn it off? 5) Before collecting the second string, I also want to play an interruptible announcement (KeepActive=false). Therefore, along with the DigitMap, I also apply a signal. When an announcement is played, normally the first digit detected stops it. But if some digits are already present (because of dial-ahead) in the EventBuffer when the second DigitMap and signal are applied, what happens to the announcement signal? is it played at all? Obviously, on dial-ahead I would like to suppress it. Thanks, Adrian Soncodi Tekelec, Richardson, TX _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Mar 24 14:13: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 OAA29436 for ; Mon, 24 Mar 2003 14:13:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OJXFC25371 for megaco-archive@odin.ietf.org; Mon, 24 Mar 2003 14:33: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 h2OJXFO25368 for ; Mon, 24 Mar 2003 14:33:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29426 for ; Mon, 24 Mar 2003 14: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 h2OJVaO25308; Mon, 24 Mar 2003 14:31: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 h2OJU6O25244 for ; Mon, 24 Mar 2003 14:30:06 -0500 Received: from ntserv10.tx.tekelec.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29314 for ; Mon, 24 Mar 2003 14:09:40 -0500 (EST) Received: from tekelec.com ([172.25.11.41]) by ntserv10.tx.tekelec.com (Lotus Domino Release 5.0.9a) with ESMTP id 2003032413115766:1096 ; Mon, 24 Mar 2003 13:11:57 -0600 Message-ID: <3E7F59E1.9010408@tekelec.com> Date: Mon, 24 Mar 2003 13:17:53 -0600 From: Adrian Soncodi User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en,pdf MIME-Version: 1.0 To: megaco@ietf.org X-MIMETrack: Itemize by SMTP Server on NTServ10/Richardson/TEKELEC(Release 5.0.9a |January 7, 2002) at 03/24/2003 01:11:57 PM, Serialize by Router on NTServ10/Richardson/TEKELEC(Release 5.0.9a |January 7, 2002) at 03/24/2003 01:11:59 PM, Serialize complete at 03/24/2003 01:11:59 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Megaco] LockStep and digit collection Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 Can anybody help me with the following questions? I am trying to reliably collect several successive digit strings from an MG. These strings correspond to potentially different digit maps, and dial-ahead is allowed. 1) When sending the first DigitMap, I specify LockStep=On, so that after the first digit string is collected, subsequent digits are buffered. To get a notification for the next string, I specify "dd/ce" in the EventBufferDescriptor, do I also need to specify each individual digit in order for them to be buffered? (I am not interested in the particular digits, just the whole string.) I know that "dd/ce" implies detection of "dd/*", does it also imply buffering of "dd/*"? 2) Does this work? The behavior I expect is: after the MG reports the first string, subsequent digits are buffered. Then after I send another DigitMap+ce to the MG AND when a match is detected, the MG sends a notification for the second string. In other words, is this the correct way to avoid losing the dialed-ahead digits from the second string, in case the second DigitMap does not get to the MG fast enough? 3) I also expect any unmatched digit that terminates the first DigitMap to be buffered and to be matched against the second DigitMap, is this correct? 4) To continue like this, do I need to keep specifying EventBufferControl=LockStep with every new DigitMap, or does this default to the previous value until I turn it off? 5) Before collecting the second string, I also want to play an interruptible announcement (KeepActive=false). Therefore, along with the DigitMap, I also apply a signal. When an announcement is played, normally the first digit detected stops it. But if some digits are already present (because of dial-ahead) in the EventBuffer when the second DigitMap and signal are applied, what happens to the announcement signal? is it played at all? Obviously, on dial-ahead I would like to suppress it. Thanks, Adrian Soncodi Tekelec, Richardson, TX _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Mar 24 14:32: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 OAA29999 for ; Mon, 24 Mar 2003 14:32: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 h2OJqNO26992; Mon, 24 Mar 2003 14:52: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 h2OJpVO26931 for ; Mon, 24 Mar 2003 14:51:31 -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 OAA29954 for ; Mon, 24 Mar 2003 14:31:03 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2OJXLh05250 for ; Mon, 24 Mar 2003 14:33:21 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 14:33:21 -0500 Message-ID: From: "Kevin Boyle" To: Adrian Soncodi , megaco@ietf.org Subject: RE: [Megaco] LockStep and digit collection Date: Mon, 24 Mar 2003 14:33: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: , Comments inline. [KJBII] Kevin -----Original Message----- From: Adrian Soncodi [mailto:adrian.soncodi@tekelec.com] Sent: Monday, March 24, 2003 2:18 PM To: megaco@ietf.org Subject: [Megaco] LockStep and digit collection Can anybody help me with the following questions? I am trying to reliably collect several successive digit strings from an MG. These strings correspond to potentially different digit maps, and dial-ahead is allowed. 1) When sending the first DigitMap, I specify LockStep=On, so that after the first digit string is collected, subsequent digits are buffered. To get a notification for the next string, I specify "dd/ce" in the EventBufferDescriptor, do I also need to specify each individual digit in order for them to be buffered? (I am not interested in the particular digits, just the whole string.) I know that "dd/ce" implies detection of "dd/*", does it also imply buffering of "dd/*"? [KJBII] Actually, once a digitmap completes, the digitmap is disabled. Given the way the spec is written, there would be no further buffering of digits. H.248.16 provides a way to force the MG to buffer digits for a specified time duration. 2) Does this work? The behavior I expect is: after the MG reports the first string, subsequent digits are buffered. Then after I send another DigitMap+ce to the MG AND when a match is detected, the MG sends a notification for the second string. In other words, is this the correct way to avoid losing the dialed-ahead digits from the second string, in case the second DigitMap does not get to the MG fast enough? [KJBII] H.248.16 allows you to perform this function. 3) I also expect any unmatched digit that terminates the first DigitMap to be buffered and to be matched against the second DigitMap, is this correct? [KJBII] H.248.16 allows the MGC to specify how the terminating event is handled (discarded, reported, etc). 4) To continue like this, do I need to keep specifying EventBufferControl=LockStep with every new DigitMap, or does this default to the previous value until I turn it off? [KJBII] LockStep remains in force until the EventBufferControl parm is reset. 5) Before collecting the second string, I also want to play an interruptible announcement (KeepActive=false). Therefore, along with the DigitMap, I also apply a signal. When an announcement is played, normally the first digit detected stops it. But if some digits are already present (because of dial-ahead) in the EventBuffer when the second DigitMap and signal are applied, what happens to the announcement signal? is it played at all? Obviously, on dial-ahead I would like to suppress it. [KJBII] Generally speaking, detected events will halt signals. This would apply to buffered Events as well, as long as there is an Events descriptor to match against. Note that matching against the EB descriptor would NOT halt a signal. Thanks, Adrian Soncodi Tekelec, Richardson, TX _______________________________________________ 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 Mar 24 14:33: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 OAA00032 for ; Mon, 24 Mar 2003 14:33:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OJrlt27049 for megaco-archive@odin.ietf.org; Mon, 24 Mar 2003 14:53: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 h2OJrlO27046 for ; Mon, 24 Mar 2003 14:53: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 OAA00026 for ; Mon, 24 Mar 2003 14:33: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 h2OJqNO26992; Mon, 24 Mar 2003 14:52: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 h2OJpVO26931 for ; Mon, 24 Mar 2003 14:51:31 -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 OAA29954 for ; Mon, 24 Mar 2003 14:31:03 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2OJXLh05250 for ; Mon, 24 Mar 2003 14:33:21 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 14:33:21 -0500 Message-ID: From: "Kevin Boyle" To: Adrian Soncodi , megaco@ietf.org Subject: RE: [Megaco] LockStep and digit collection Date: Mon, 24 Mar 2003 14:33: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: , Comments inline. [KJBII] Kevin -----Original Message----- From: Adrian Soncodi [mailto:adrian.soncodi@tekelec.com] Sent: Monday, March 24, 2003 2:18 PM To: megaco@ietf.org Subject: [Megaco] LockStep and digit collection Can anybody help me with the following questions? I am trying to reliably collect several successive digit strings from an MG. These strings correspond to potentially different digit maps, and dial-ahead is allowed. 1) When sending the first DigitMap, I specify LockStep=On, so that after the first digit string is collected, subsequent digits are buffered. To get a notification for the next string, I specify "dd/ce" in the EventBufferDescriptor, do I also need to specify each individual digit in order for them to be buffered? (I am not interested in the particular digits, just the whole string.) I know that "dd/ce" implies detection of "dd/*", does it also imply buffering of "dd/*"? [KJBII] Actually, once a digitmap completes, the digitmap is disabled. Given the way the spec is written, there would be no further buffering of digits. H.248.16 provides a way to force the MG to buffer digits for a specified time duration. 2) Does this work? The behavior I expect is: after the MG reports the first string, subsequent digits are buffered. Then after I send another DigitMap+ce to the MG AND when a match is detected, the MG sends a notification for the second string. In other words, is this the correct way to avoid losing the dialed-ahead digits from the second string, in case the second DigitMap does not get to the MG fast enough? [KJBII] H.248.16 allows you to perform this function. 3) I also expect any unmatched digit that terminates the first DigitMap to be buffered and to be matched against the second DigitMap, is this correct? [KJBII] H.248.16 allows the MGC to specify how the terminating event is handled (discarded, reported, etc). 4) To continue like this, do I need to keep specifying EventBufferControl=LockStep with every new DigitMap, or does this default to the previous value until I turn it off? [KJBII] LockStep remains in force until the EventBufferControl parm is reset. 5) Before collecting the second string, I also want to play an interruptible announcement (KeepActive=false). Therefore, along with the DigitMap, I also apply a signal. When an announcement is played, normally the first digit detected stops it. But if some digits are already present (because of dial-ahead) in the EventBuffer when the second DigitMap and signal are applied, what happens to the announcement signal? is it played at all? Obviously, on dial-ahead I would like to suppress it. [KJBII] Generally speaking, detected events will halt signals. This would apply to buffered Events as well, as long as there is an Events descriptor to match against. Note that matching against the EB descriptor would NOT halt a signal. Thanks, Adrian Soncodi Tekelec, Richardson, TX _______________________________________________ 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 Mar 24 15:00: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 PAA00758 for ; Mon, 24 Mar 2003 15:00: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 h2OKKGO28867; Mon, 24 Mar 2003 15:20: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 h2OKJ6O28778 for ; Mon, 24 Mar 2003 15:19:06 -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 OAA00622 for ; Mon, 24 Mar 2003 14:58:35 -0500 (EST) Received: (qmail 29796 invoked from network); 24 Mar 2003 19:52:19 -0000 Received: from unknown (HELO zzzconn03.afc.local) (10.1.4.53) by 0 with SMTP; 24 Mar 2003 19:52:19 -0000 Received: FROM xconn01.afc.local BY zzzconn03.afc.local ; Mon Mar 24 12:02:20 2003 -0800 Received: by xconn01.afc.local with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 11:59:43 -0800 Message-ID: From: John Stock To: "'megaco@ietf.org'" Date: Mon, 24 Mar 2003 12:00: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] MID - unique for each MG on an MGC? Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, Is it required, or advisable, for the MID of MG's to be unique across an MGC? That is, will it cause problems if two MG's on an MGC have the same MID? I realize this is an implementation issue, but was trying to get a feel for what others might be seeing. Thanks. John Stock Systems Engineering Advanced Fibre Communications john.stock@afc.com 707-792-6249 And now for the standard disclaimer (don't lawyers just make life fun?): This message (including any attachments) is intended only for the use of the named addressee(s), and may contain information that is legally privileged, confidential or exempt from disclosure under applicable law. If you are not a named addressee, you are hereby notified that any use, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the original sender immediately by telephone or by return E-mail and delete this message, along with any attachments, from your computer. Thank you. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Mar 24 15: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 PAA00804 for ; Mon, 24 Mar 2003 15:01:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OKLfA28898 for megaco-archive@odin.ietf.org; Mon, 24 Mar 2003 15:21: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 h2OKLfO28895 for ; Mon, 24 Mar 2003 15:21: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 PAA00796 for ; Mon, 24 Mar 2003 15: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 h2OKKGO28867; Mon, 24 Mar 2003 15:20: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 h2OKJ6O28778 for ; Mon, 24 Mar 2003 15:19:06 -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 OAA00622 for ; Mon, 24 Mar 2003 14:58:35 -0500 (EST) Received: (qmail 29796 invoked from network); 24 Mar 2003 19:52:19 -0000 Received: from unknown (HELO zzzconn03.afc.local) (10.1.4.53) by 0 with SMTP; 24 Mar 2003 19:52:19 -0000 Received: FROM xconn01.afc.local BY zzzconn03.afc.local ; Mon Mar 24 12:02:20 2003 -0800 Received: by xconn01.afc.local with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 11:59:43 -0800 Message-ID: From: John Stock To: "'megaco@ietf.org'" Date: Mon, 24 Mar 2003 12:00: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] MID - unique for each MG on an MGC? Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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, Is it required, or advisable, for the MID of MG's to be unique across an MGC? That is, will it cause problems if two MG's on an MGC have the same MID? I realize this is an implementation issue, but was trying to get a feel for what others might be seeing. Thanks. John Stock Systems Engineering Advanced Fibre Communications john.stock@afc.com 707-792-6249 And now for the standard disclaimer (don't lawyers just make life fun?): This message (including any attachments) is intended only for the use of the named addressee(s), and may contain information that is legally privileged, confidential or exempt from disclosure under applicable law. If you are not a named addressee, you are hereby notified that any use, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the original sender immediately by telephone or by return E-mail and delete this message, along with any attachments, from your computer. Thank you. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Mar 25 04:47: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 EAA04913 for ; Tue, 25 Mar 2003 04:47: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 h2PA6lO30172; Tue, 25 Mar 2003 05:06: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 h2PA4lO30099 for ; Tue, 25 Mar 2003 05:04:47 -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 EAA04850 for ; Tue, 25 Mar 2003 04:43:57 -0500 (EST) From: bvswamy@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 h2P9iHs03605 for ; Tue, 25 Mar 2003 15:14:17 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2P9iE203597; Tue, 25 Mar 2003 15:14:14 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2P9kvQ02687; Tue, 25 Mar 2003 15:17:02 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CF4.00346355 ; Tue, 25 Mar 2003 15:02:13 +0530 X-Lotus-FromDomain: HSS To: "Kevin Boyle" cc: megaco@ietf.org Message-ID: <65256CF4.0034623F.00@dlfmail1.hss.hns.com> Date: Tue, 25 Mar 2003 15:17:57 +0530 Subject: RE: [Megaco] Service change Restart 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 Kevin Thanks for you clarifications. But the points that I have mentioned were basically not normal scenario but are scenario developing because of the inconsistancy between MG-MGC termination state machine. This can be due to any reason like switchovers or some malfunctioning at either end. So there should be some mechanism to correct this inconsistancy by providing error responses to such SC requests. I have still have some doubts on the point 2 and 4 below (comments inline [bvswamy]). Regards Venkat "Kevin Boyle" on 03/24/2003 09:54:47 PM To: B Venkat S.R Swamy/HSS@HSS, megaco@ietf.org cc: Subject: RE: [Megaco] Service change Restart Comments inline. [KJBII] Before we get too bogged down into a lot of scenario by scenario details, keep in mind that the intent of this work is to define as simple a model as possible. There is no need to define an enormous state machine that has a state for every possible scenario. There are, in reality two states, and a possible third pseudo-state: In service, Out of service, and the fleeting delayed OOS brought about by things like a SC Graceful. Kevin -----Original Message----- From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] Sent: Thursday, March 20, 2003 2:43 AM To: megaco@ietf.org Subject: RE: [Megaco] Service change Restart Hi Kevin Few clarifications needed on the service change procedures: 1) What should MG do when it receives Service Change Restart on a already inservice termination which is in Non-Null context Should it give a error response or whether MG should clear the call and remove the termination from the context ? [KJBII] MGs may not remove terms from context without a Subtract command from the MGC. The MG should Restart the term, in accordance with its function and provisioning, and await cleanup commands from the MGC. If that restart means that the media stream is lost, then that is something that the MGC should take into account before requesting that the MG restart a particular termination. 2) If ServiceChange Restart with delay is recd by MG for an already Inservice termination which may or may not be in call then what should be MG behaviour. Should it mark the termination as Out-Of-Service till the delay timer expires and remove the termination from the context or give a error response ? [KJBII] If the term is inservice, and the command is to restart, why would you remove it from service? The delay is just that -- a delay. Don't do anything with the term until the delay expires, and then Restart it upon the expiry of the delay. [bvswamy] Does this mean MG should not generate any megaco message towards MGC for these set of terminations till the delay timer expires because by sending SC Restart with delay, MGC is implicitly telling that the terminations are out-of-service at his end and is not expecting any messages for that terminations.Please correct me if I am wrong. 3) If Service Change Graceful with delay is received by MG for an already out of service termination then how should MG behave? Should it mark the termination in-service right now and after timer expiry mark it out-of-service or should it give an error? [KJBII] So, an out of service termination receives a command to take it out of service. I say acknowledge the command, and leave the termination as it is -- delay or not. Since it is already out of service, this is, effectively, a no-op. Now, the implications to think about are: What if the MG took the term OOS, and then, later, the MGC sends a Forced or Graceful? This has the implication that the MG, by itself, cannot bring the termination back into service. It implies, to me, that BOTH the MG and MGC must take action on that term in order to have it return to service. In all of the above cases if MG were to give a error response then there is no error-code defined which specifies that MG is already in the state which MGC has requested , however there is an error-code "Not-Ready" defined as "The command directed to a termination was not executed because of the service state of the termination" which can be used in these situations for conveying MGC that requested operation is not done. 4) What should be the MGC behaviour in the following scenario: 1) MGC recevies a Service Change graceful with NonNull delay for a termination in context. 2) Now MG want to cancel the graceful timer. The only way do currently is by sending a service Change Restart. Now what should be MGC behaviour. Should it only stop the timer and continue the call or end the call and the mark the termination as Inservice. [KJBII] I believe that any SC command received while there is one still awaiting its SCDelay expiry effectively overrides the existing command. For example, if a SC Graceful with a long delay is in progress, and a SC Forced with comes during the delay timing, then the Graceful is cancelled, and the Forced is executed as signaled. [bvswamy] Does this mean that any call running on the terminations will get cleared when MGC receives such overriding messages(Forced or Restart). I hope SG16 Annex F will also clarify doubts over the above items. Regards Venkat knayar@hss.hns.com on 03/18/2003 09:25:04 AM To: "Kevin Boyle" cc: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS, Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: B Venkat S.R Swamy/HSS) Subject: RE: [Megaco] Service change Restart Hi Kevin Thanks for the useful pointer... I did like to know if the Annex-F is intended to be part of H.248v2 only or will also be applicable to H.248v1. Any information about the time lines by when it would be finalised/ freezed. regards, -kapil nayar http://www.hssworld.com "Kevin Boyle" on 03/14/2003 08:33:23 PM To: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS cc: Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: Kapil Nayar/HSS) Subject: RE: [Megaco] Service change Restart This work is ongoing in SG16 as future Annex F. Both of these items are intended to be clarified by the new work. The input documents to the San Jose Rapporteurs' Meeting can be found as AVD-2310, AVD-2311, and AVD-2298 at ftp://standard.pictel.com/avc-site/0302_San/. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Friday, March 14, 2003 9:30 AM To: klaha@hss.hns.com Cc: gsachin@hss.hns.com; Megaco List Subject: Re: [Megaco] Service change Restart This is where the RFC is completely inadequate as it stands. I wouldn't mind seeing it rewritten to specify separately what happens for ServiceChange on ROOT vs. ServiceChange on individual terminations. With regard to the latter, there is also something else I'd like to see ironed out: the service state is a writable property in TerminationState, yet it is manipulated by ServiceChange. One or the other of these should go. I am quite prepared to submit a proposal for new text for section 7.2.8 in particular. Would there be interest in reviewing such a proposal? We could submit it as a contribution into SG 16's May meeting if that is workable. klaha@hss.hns.com wrote: > > How about ServiceChange Restart on ROOT from MGC?Does the protocol > inhibit it? (It can be an easier means for the MGC to inform MG to > delete all contexts rather than 'Subtract'ing each of them, when MGC > is taken gracefully > out-of-service) > > > > > > Tom Taylor on 03/14/2003 12:27:35 AM > > To: Sachin Gupta-PNGN/HSS@HSS, Megaco List > cc: (bcc: Kushanava Laha/HSS) > > Subject: Re: [Megaco] Service change Restart > > > > I agree that it's very difficult to assign any real meaning to an > MGC-initiated restart of a termination. My background in switch > software development tells me that a restart clears certain aspects of > state. However, that makes little sense in the Megaco case, because > the MGC can do that directly by subtracting the termination from any > context it is in and resetting descriptors if it is not in a context. > > Conclusion: the only thing an MGC-initiated restart of a termination > does is change its state to in-service if it is not already there. > > gsachin@hss.hns.com wrote: > >>Hi List >>I have a query regarding the processing of Service Change Restart. >>consider the following scenario: >> >>Termination is in state InService. >>Command recieved from MGC to Restart the termination (with or wothout >>delay). >> >>what MG could possibly do in this case? >> >> >>Thanks >>Sachin Gupta >> > > [disclaimer snipped] > > _______________________________________________ > 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 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ 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 Mar 25 04:48: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 EAA04958 for ; Tue, 25 Mar 2003 04:48:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PA8V530997 for megaco-archive@odin.ietf.org; Tue, 25 Mar 2003 05:08: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 h2PA8VO30993 for ; Tue, 25 Mar 2003 05:08: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 EAA04934 for ; Tue, 25 Mar 2003 04:47: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 h2PA6lO30172; Tue, 25 Mar 2003 05:06: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 h2PA4lO30099 for ; Tue, 25 Mar 2003 05:04:47 -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 EAA04850 for ; Tue, 25 Mar 2003 04:43:57 -0500 (EST) From: bvswamy@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 h2P9iHs03605 for ; Tue, 25 Mar 2003 15:14:17 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2P9iE203597; Tue, 25 Mar 2003 15:14:14 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2P9kvQ02687; Tue, 25 Mar 2003 15:17:02 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CF4.00346355 ; Tue, 25 Mar 2003 15:02:13 +0530 X-Lotus-FromDomain: HSS To: "Kevin Boyle" cc: megaco@ietf.org Message-ID: <65256CF4.0034623F.00@dlfmail1.hss.hns.com> Date: Tue, 25 Mar 2003 15:17:57 +0530 Subject: RE: [Megaco] Service change Restart 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 Kevin Thanks for you clarifications. But the points that I have mentioned were basically not normal scenario but are scenario developing because of the inconsistancy between MG-MGC termination state machine. This can be due to any reason like switchovers or some malfunctioning at either end. So there should be some mechanism to correct this inconsistancy by providing error responses to such SC requests. I have still have some doubts on the point 2 and 4 below (comments inline [bvswamy]). Regards Venkat "Kevin Boyle" on 03/24/2003 09:54:47 PM To: B Venkat S.R Swamy/HSS@HSS, megaco@ietf.org cc: Subject: RE: [Megaco] Service change Restart Comments inline. [KJBII] Before we get too bogged down into a lot of scenario by scenario details, keep in mind that the intent of this work is to define as simple a model as possible. There is no need to define an enormous state machine that has a state for every possible scenario. There are, in reality two states, and a possible third pseudo-state: In service, Out of service, and the fleeting delayed OOS brought about by things like a SC Graceful. Kevin -----Original Message----- From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] Sent: Thursday, March 20, 2003 2:43 AM To: megaco@ietf.org Subject: RE: [Megaco] Service change Restart Hi Kevin Few clarifications needed on the service change procedures: 1) What should MG do when it receives Service Change Restart on a already inservice termination which is in Non-Null context Should it give a error response or whether MG should clear the call and remove the termination from the context ? [KJBII] MGs may not remove terms from context without a Subtract command from the MGC. The MG should Restart the term, in accordance with its function and provisioning, and await cleanup commands from the MGC. If that restart means that the media stream is lost, then that is something that the MGC should take into account before requesting that the MG restart a particular termination. 2) If ServiceChange Restart with delay is recd by MG for an already Inservice termination which may or may not be in call then what should be MG behaviour. Should it mark the termination as Out-Of-Service till the delay timer expires and remove the termination from the context or give a error response ? [KJBII] If the term is inservice, and the command is to restart, why would you remove it from service? The delay is just that -- a delay. Don't do anything with the term until the delay expires, and then Restart it upon the expiry of the delay. [bvswamy] Does this mean MG should not generate any megaco message towards MGC for these set of terminations till the delay timer expires because by sending SC Restart with delay, MGC is implicitly telling that the terminations are out-of-service at his end and is not expecting any messages for that terminations.Please correct me if I am wrong. 3) If Service Change Graceful with delay is received by MG for an already out of service termination then how should MG behave? Should it mark the termination in-service right now and after timer expiry mark it out-of-service or should it give an error? [KJBII] So, an out of service termination receives a command to take it out of service. I say acknowledge the command, and leave the termination as it is -- delay or not. Since it is already out of service, this is, effectively, a no-op. Now, the implications to think about are: What if the MG took the term OOS, and then, later, the MGC sends a Forced or Graceful? This has the implication that the MG, by itself, cannot bring the termination back into service. It implies, to me, that BOTH the MG and MGC must take action on that term in order to have it return to service. In all of the above cases if MG were to give a error response then there is no error-code defined which specifies that MG is already in the state which MGC has requested , however there is an error-code "Not-Ready" defined as "The command directed to a termination was not executed because of the service state of the termination" which can be used in these situations for conveying MGC that requested operation is not done. 4) What should be the MGC behaviour in the following scenario: 1) MGC recevies a Service Change graceful with NonNull delay for a termination in context. 2) Now MG want to cancel the graceful timer. The only way do currently is by sending a service Change Restart. Now what should be MGC behaviour. Should it only stop the timer and continue the call or end the call and the mark the termination as Inservice. [KJBII] I believe that any SC command received while there is one still awaiting its SCDelay expiry effectively overrides the existing command. For example, if a SC Graceful with a long delay is in progress, and a SC Forced with comes during the delay timing, then the Graceful is cancelled, and the Forced is executed as signaled. [bvswamy] Does this mean that any call running on the terminations will get cleared when MGC receives such overriding messages(Forced or Restart). I hope SG16 Annex F will also clarify doubts over the above items. Regards Venkat knayar@hss.hns.com on 03/18/2003 09:25:04 AM To: "Kevin Boyle" cc: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS, Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: B Venkat S.R Swamy/HSS) Subject: RE: [Megaco] Service change Restart Hi Kevin Thanks for the useful pointer... I did like to know if the Annex-F is intended to be part of H.248v2 only or will also be applicable to H.248v1. Any information about the time lines by when it would be finalised/ freezed. regards, -kapil nayar http://www.hssworld.com "Kevin Boyle" on 03/14/2003 08:33:23 PM To: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS cc: Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: Kapil Nayar/HSS) Subject: RE: [Megaco] Service change Restart This work is ongoing in SG16 as future Annex F. Both of these items are intended to be clarified by the new work. The input documents to the San Jose Rapporteurs' Meeting can be found as AVD-2310, AVD-2311, and AVD-2298 at ftp://standard.pictel.com/avc-site/0302_San/. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Friday, March 14, 2003 9:30 AM To: klaha@hss.hns.com Cc: gsachin@hss.hns.com; Megaco List Subject: Re: [Megaco] Service change Restart This is where the RFC is completely inadequate as it stands. I wouldn't mind seeing it rewritten to specify separately what happens for ServiceChange on ROOT vs. ServiceChange on individual terminations. With regard to the latter, there is also something else I'd like to see ironed out: the service state is a writable property in TerminationState, yet it is manipulated by ServiceChange. One or the other of these should go. I am quite prepared to submit a proposal for new text for section 7.2.8 in particular. Would there be interest in reviewing such a proposal? We could submit it as a contribution into SG 16's May meeting if that is workable. klaha@hss.hns.com wrote: > > How about ServiceChange Restart on ROOT from MGC?Does the protocol > inhibit it? (It can be an easier means for the MGC to inform MG to > delete all contexts rather than 'Subtract'ing each of them, when MGC > is taken gracefully > out-of-service) > > > > > > Tom Taylor on 03/14/2003 12:27:35 AM > > To: Sachin Gupta-PNGN/HSS@HSS, Megaco List > cc: (bcc: Kushanava Laha/HSS) > > Subject: Re: [Megaco] Service change Restart > > > > I agree that it's very difficult to assign any real meaning to an > MGC-initiated restart of a termination. My background in switch > software development tells me that a restart clears certain aspects of > state. However, that makes little sense in the Megaco case, because > the MGC can do that directly by subtracting the termination from any > context it is in and resetting descriptors if it is not in a context. > > Conclusion: the only thing an MGC-initiated restart of a termination > does is change its state to in-service if it is not already there. > > gsachin@hss.hns.com wrote: > >>Hi List >>I have a query regarding the processing of Service Change Restart. >>consider the following scenario: >> >>Termination is in state InService. >>Command recieved from MGC to Restart the termination (with or wothout >>delay). >> >>what MG could possibly do in this case? >> >> >>Thanks >>Sachin Gupta >> > > [disclaimer snipped] > > _______________________________________________ > 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 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ 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 Mar 25 05:17: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 FAA05656 for ; Tue, 25 Mar 2003 05:17: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 h2PAbCO32659; Tue, 25 Mar 2003 05:37: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 h2PAaXO32269 for ; Tue, 25 Mar 2003 05:36:33 -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 FAA05564 for ; Tue, 25 Mar 2003 05:15:47 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2PAI1HQ019043; Tue, 25 Mar 2003 11:18:01 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id HMMSJHK7; Tue, 25 Mar 2003 11:18:02 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.31.86]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h2PAI1Eq016376; Tue, 25 Mar 2003 12:18:02 +0200 (EET) Message-ID: <3E802CDA.3DCA0D2@lmf.ericsson.se> Date: Tue, 25 Mar 2003 12:18:03 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stock CC: "'megaco@ietf.org'" Subject: Re: [Megaco] MID - unique for each MG on an MGC? 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, > Is it required, or advisable, for the MID of MG's to be unique across an > MGC? That is, will it cause problems if two MG's on an MGC have the same > MID? I realize this is an implementation issue, but was trying to get a > feel for what others might be seeing. Like you said, I think this is a pure implementation issue. I can't think of any issue how this would affect the pure protocol, since the MID isn't really used for any protocol functionalities. But, if your application for example recognises the MG using the MID, and multiple MGs use the same MID, you may of course run into problem. But, again, that is an implementation issue. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Tue Mar 25 05:18: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 FAA05696 for ; Tue, 25 Mar 2003 05:18:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PAcfM00712 for megaco-archive@odin.ietf.org; Tue, 25 Mar 2003 05:38: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 h2PAcfO00709 for ; Tue, 25 Mar 2003 05:38: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 FAA05692 for ; Tue, 25 Mar 2003 05:17: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 h2PAbCO32659; Tue, 25 Mar 2003 05:37: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 h2PAaXO32269 for ; Tue, 25 Mar 2003 05:36:33 -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 FAA05564 for ; Tue, 25 Mar 2003 05:15:47 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2PAI1HQ019043; Tue, 25 Mar 2003 11:18:01 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id HMMSJHK7; Tue, 25 Mar 2003 11:18:02 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.31.86]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h2PAI1Eq016376; Tue, 25 Mar 2003 12:18:02 +0200 (EET) Message-ID: <3E802CDA.3DCA0D2@lmf.ericsson.se> Date: Tue, 25 Mar 2003 12:18:03 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stock CC: "'megaco@ietf.org'" Subject: Re: [Megaco] MID - unique for each MG on an MGC? 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, > Is it required, or advisable, for the MID of MG's to be unique across an > MGC? That is, will it cause problems if two MG's on an MGC have the same > MID? I realize this is an implementation issue, but was trying to get a > feel for what others might be seeing. Like you said, I think this is a pure implementation issue. I can't think of any issue how this would affect the pure protocol, since the MID isn't really used for any protocol functionalities. But, if your application for example recognises the MG using the MID, and multiple MGs use the same MID, you may of course run into problem. But, again, that is an implementation issue. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Mar 26 00:42: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 AAA18786 for ; Wed, 26 Mar 2003 00:42: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 h2Q62lO18211; Wed, 26 Mar 2003 01:02: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 h2Q60wO18145 for ; Wed, 26 Mar 2003 01:00:58 -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 AAA18730 for ; Wed, 26 Mar 2003 00:39:37 -0500 (EST) From: ajhingran@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2Q5e0s01687 for ; Wed, 26 Mar 2003 11:10:00 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2Q5dx201679 for ; Wed, 26 Mar 2003 11:09:59 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2Q5gme18409 for ; Wed, 26 Mar 2003 11:12:48 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CF5.001E0B3E ; Wed, 26 Mar 2003 10:58:09 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CF5.001E0AA8.00@dlfmail1.hss.hns.com> Date: Wed, 26 Mar 2003 11:08:46 +0530 Subject: [Megaco] Audit Descriptor and under/overspecified Descriptor 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 I am repeating the mail sent earlier by me , as there was no reply. Please help in clarifying the issue. I have a query with respect to conflicts between the underspecified overspecified descriptor processing and audit descriptor processing. Both of these descriptors in a command request mandate the inclusion of descriptors in the command reply.Whereas there can be scenarios when multiple candidate descriptors can occur in the command reply. How is the contention resolved? I am taking an example of media descriptor. e.g. Assuming an ephemeral termination with the following current state of the descriptors: LocalControl { Mode = Inactive, nt/jit=120 } Local { v=0 c=IN IP4 132.168.200.4 m=audio 6000 RTP/AVP 4 } Now, a MODIFY command with Audit descriptor and an underspecified/ overspecified Media Desc (Local desc) is received. Modify = rtp1000 { Audit { Media }, Media { Stream = 1 { LocalControl { Mode = ReceiveOnly, nt/jit=40 }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 0 8 }}}} Assuming that during the MODIFY command processing, MG selects the following new values: IP address - 132.168.200.5 port number - 7000 payload type - 8 How should the MODIFY command reply look like: Option 1 Old media descriptor is sent. Modify = rtp1000 { Media { Stream = 1 { LocalControl { Mode = Inactive, nt/jit=120 }, Local { v=0 c=IN IP4 132.168.200.4 m=audio 6000 RTP/AVP 4 }}}} But, as per the protocol the underspecified/ overspecified Local descriptor after resolution in the MG must be returned in the response. Option 2 Old media descriptor with overwritten underspecified/ overspecified Local descriptor after resolution is sent. Modify = rtp1000 { Media { Stream = 1 { LocalControl { Mode = Inactive, nt/jit=120 }, Local { v=0 c=IN IP4 132.168.200.5 m=audio 7000 RTP/AVP 8 }}}} But, the complete Media descriptor is inconsistent, i.e., Local COntrol is old but the Local descriptor is the new one. Although, MGC would know which descriptor was underspecified/ overspecfied in the request and can relate. Option 3 New media descriptor is sent. Modify = rtp1000 { Media { Stream = 1 { LocalControl { Mode = ReceiveOnly, nt/jit=40 }, Local { v=0 c=IN IP4 132.168.200.5 m=audio 7000 RTP/AVP 8 }}}} But, as per the protocol the descriptors need to be processed in sequence of occurance and therefore, media descriptor should be the old one. I am still unclear if the protocol resolves this problem. Please comment? Rgds Ashish Jhingran _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Mar 26 00:43: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 AAA18808 for ; Wed, 26 Mar 2003 00:43:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2Q64Su18247 for megaco-archive@odin.ietf.org; Wed, 26 Mar 2003 01:04: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 h2Q64SO18244 for ; Wed, 26 Mar 2003 01:04: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 AAA18805 for ; Wed, 26 Mar 2003 00:43: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 h2Q62lO18211; Wed, 26 Mar 2003 01:02: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 h2Q60wO18145 for ; Wed, 26 Mar 2003 01:00:58 -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 AAA18730 for ; Wed, 26 Mar 2003 00:39:37 -0500 (EST) From: ajhingran@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2Q5e0s01687 for ; Wed, 26 Mar 2003 11:10:00 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2Q5dx201679 for ; Wed, 26 Mar 2003 11:09:59 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2Q5gme18409 for ; Wed, 26 Mar 2003 11:12:48 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CF5.001E0B3E ; Wed, 26 Mar 2003 10:58:09 +0530 X-Lotus-FromDomain: HSS To: megaco@ietf.org Message-ID: <65256CF5.001E0AA8.00@dlfmail1.hss.hns.com> Date: Wed, 26 Mar 2003 11:08:46 +0530 Subject: [Megaco] Audit Descriptor and under/overspecified Descriptor 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 I am repeating the mail sent earlier by me , as there was no reply. Please help in clarifying the issue. I have a query with respect to conflicts between the underspecified overspecified descriptor processing and audit descriptor processing. Both of these descriptors in a command request mandate the inclusion of descriptors in the command reply.Whereas there can be scenarios when multiple candidate descriptors can occur in the command reply. How is the contention resolved? I am taking an example of media descriptor. e.g. Assuming an ephemeral termination with the following current state of the descriptors: LocalControl { Mode = Inactive, nt/jit=120 } Local { v=0 c=IN IP4 132.168.200.4 m=audio 6000 RTP/AVP 4 } Now, a MODIFY command with Audit descriptor and an underspecified/ overspecified Media Desc (Local desc) is received. Modify = rtp1000 { Audit { Media }, Media { Stream = 1 { LocalControl { Mode = ReceiveOnly, nt/jit=40 }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 0 8 }}}} Assuming that during the MODIFY command processing, MG selects the following new values: IP address - 132.168.200.5 port number - 7000 payload type - 8 How should the MODIFY command reply look like: Option 1 Old media descriptor is sent. Modify = rtp1000 { Media { Stream = 1 { LocalControl { Mode = Inactive, nt/jit=120 }, Local { v=0 c=IN IP4 132.168.200.4 m=audio 6000 RTP/AVP 4 }}}} But, as per the protocol the underspecified/ overspecified Local descriptor after resolution in the MG must be returned in the response. Option 2 Old media descriptor with overwritten underspecified/ overspecified Local descriptor after resolution is sent. Modify = rtp1000 { Media { Stream = 1 { LocalControl { Mode = Inactive, nt/jit=120 }, Local { v=0 c=IN IP4 132.168.200.5 m=audio 7000 RTP/AVP 8 }}}} But, the complete Media descriptor is inconsistent, i.e., Local COntrol is old but the Local descriptor is the new one. Although, MGC would know which descriptor was underspecified/ overspecfied in the request and can relate. Option 3 New media descriptor is sent. Modify = rtp1000 { Media { Stream = 1 { LocalControl { Mode = ReceiveOnly, nt/jit=40 }, Local { v=0 c=IN IP4 132.168.200.5 m=audio 7000 RTP/AVP 8 }}}} But, as per the protocol the descriptors need to be processed in sequence of occurance and therefore, media descriptor should be the old one. I am still unclear if the protocol resolves this problem. Please comment? Rgds Ashish Jhingran _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Mar 26 13:36: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 NAA06572 for ; Wed, 26 Mar 2003 13:36: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 h2QIofO21171; Wed, 26 Mar 2003 13:50: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 h2QImDO20999 for ; Wed, 26 Mar 2003 13:48:13 -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 NAA06256 for ; Wed, 26 Mar 2003 13:26:45 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2QISr019684; Wed, 26 Mar 2003 13:28:53 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Mar 2003 13:28:54 -0500 Message-ID: From: "Kevin Boyle" To: bvswamy@hss.hns.com Cc: megaco@ietf.org Subject: RE: [Megaco] Service change Restart Date: Wed, 26 Mar 2003 13:28:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F3C5.8C4D6C0A" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2F3C5.8C4D6C0A Content-Type: text/plain More comments inline. [KJBII] You did make a good point about having a SCReason to specify that a Restart isn't really a Restart, but is rather a cancellation of a pending ServiceChange command. I think it is useful to have such a Reason code, and I will see about submitting a proposal to the next SG16 meeting to add one. Kevin -----Original Message----- From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] Sent: Tuesday, March 25, 2003 4:48 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: megaco@ietf.org Subject: RE: [Megaco] Service change Restart Hi Kevin Thanks for you clarifications. But the points that I have mentioned were basically not normal scenario but are scenario developing because of the inconsistancy between MG-MGC termination state machine. This can be due to any reason like switchovers or some malfunctioning at either end. So there should be some mechanism to correct this inconsistancy by providing error responses to such SC requests. I have still have some doubts on the point 2 and 4 below (comments inline [bvswamy]). [KJBII] If the MG cannot execute a command, then, I agree, it should return an error. Regards Venkat "Kevin Boyle" on 03/24/2003 09:54:47 PM To: B Venkat S.R Swamy/HSS@HSS, megaco@ietf.org cc: Subject: RE: [Megaco] Service change Restart Comments inline. [KJBII] Before we get too bogged down into a lot of scenario by scenario details, keep in mind that the intent of this work is to define as simple a model as possible. There is no need to define an enormous state machine that has a state for every possible scenario. There are, in reality two states, and a possible third pseudo-state: In service, Out of service, and the fleeting delayed OOS brought about by things like a SC Graceful. Kevin -----Original Message----- From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] Sent: Thursday, March 20, 2003 2:43 AM To: megaco@ietf.org Subject: RE: [Megaco] Service change Restart Hi Kevin Few clarifications needed on the service change procedures: 1) What should MG do when it receives Service Change Restart on a already inservice termination which is in Non-Null context Should it give a error response or whether MG should clear the call and remove the termination from the context ? [KJBII] MGs may not remove terms from context without a Subtract command from the MGC. The MG should Restart the term, in accordance with its function and provisioning, and await cleanup commands from the MGC. If that restart means that the media stream is lost, then that is something that the MGC should take into account before requesting that the MG restart a particular termination. 2) If ServiceChange Restart with delay is recd by MG for an already Inservice termination which may or may not be in call then what should be MG behaviour. Should it mark the termination as Out-Of-Service till the delay timer expires and remove the termination from the context or give a error response ? [KJBII] If the term is inservice, and the command is to restart, why would you remove it from service? The delay is just that -- a delay. Don't do anything with the term until the delay expires, and then Restart it upon the expiry of the delay. [bvswamy] Does this mean MG should not generate any megaco message towards MGC for these set of terminations till the delay timer expires because by sending SC Restart with delay, MGC is implicitly telling that the terminations are out-of-service at his end and is not expecting any messages for that terminations.Please correct me if I am wrong. [KJBII] I do not see why any other messaging would have to be held. The Restart will execute at the end of the delay -- that doesn't mean that no other messaging can be sent during the delay. What if the term is in context, the MGC sends a SC Restart with delay, and then subsequently sends a subtract? I think it entirely reasonable that the Subtract be executed, even though there is a pending Restart. Also, Restart does NOT mean the terms go out of service and then back in service. It means that the terms were reset to an initial state. Think of it like the difference between restarting windows and turning off the computer. In the turning off case, the computer has halted function. In the other, the computer is still functioning, but is reloading itself. Now, does a restart mean that functionality will cease to work for a short time? Probably -- but that is a matter of implementation. I can conceive of a Restart that would be fast enough that there may not be a perceptible interruption of functionality on a particular term. Keep in mind, however, that a Restart on Root will affect ALL terms on the MG, and WILL result in service disruption. This is one of the differences between Root and other terms. 3) If Service Change Graceful with delay is received by MG for an already out of service termination then how should MG behave? Should it mark the termination in-service right now and after timer expiry mark it out-of-service or should it give an error? [KJBII] So, an out of service termination receives a command to take it out of service. I say acknowledge the command, and leave the termination as it is -- delay or not. Since it is already out of service, this is, effectively, a no-op. Now, the implications to think about are: What if the MG took the term OOS, and then, later, the MGC sends a Forced or Graceful? This has the implication that the MG, by itself, cannot bring the termination back into service. It implies, to me, that BOTH the MG and MGC must take action on that term in order to have it return to service. In all of the above cases if MG were to give a error response then there is no error-code defined which specifies that MG is already in the state which MGC has requested , however there is an error-code "Not-Ready" defined as "The command directed to a termination was not executed because of the service state of the termination" which can be used in these situations for conveying MGC that requested operation is not done. 4) What should be the MGC behaviour in the following scenario: 1) MGC recevies a Service Change graceful with NonNull delay for a termination in context. 2) Now MG want to cancel the graceful timer. The only way do currently is by sending a service Change Restart. Now what should be MGC behaviour. Should it only stop the timer and continue the call or end the call and the mark the termination as Inservice. [KJBII] I believe that any SC command received while there is one still awaiting its SCDelay expiry effectively overrides the existing command. For example, if a SC Graceful with a long delay is in progress, and a SC Forced with comes during the delay timing, then the Graceful is cancelled, and the Forced is executed as signaled. [bvswamy] Does this mean that any call running on the terminations will get cleared when MGC receives such overriding messages(Forced or Restart). [KJBII] As always, it is up to the MGC to take appropriate action. Certainly, if the MGC receives a Forced to override a Graceful, then the MGC should tear down the context at that time, rather than waiting for the delay to expire. In the case of a Restart, the Graceful is certainly cancelled, and the MGC can leave the context as it is, if it so chooses. I hope SG16 Annex F will also clarify doubts over the above items. Regards Venkat knayar@hss.hns.com on 03/18/2003 09:25:04 AM To: "Kevin Boyle" cc: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS, Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: B Venkat S.R Swamy/HSS) Subject: RE: [Megaco] Service change Restart Hi Kevin Thanks for the useful pointer... I did like to know if the Annex-F is intended to be part of H.248v2 only or will also be applicable to H.248v1. Any information about the time lines by when it would be finalised/ freezed. regards, -kapil nayar http://www.hssworld.com "Kevin Boyle" on 03/14/2003 08:33:23 PM To: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS cc: Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: Kapil Nayar/HSS) Subject: RE: [Megaco] Service change Restart This work is ongoing in SG16 as future Annex F. Both of these items are intended to be clarified by the new work. The input documents to the San Jose Rapporteurs' Meeting can be found as AVD-2310, AVD-2311, and AVD-2298 at ftp://standard.pictel.com/avc-site/0302_San/. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Friday, March 14, 2003 9:30 AM To: klaha@hss.hns.com Cc: gsachin@hss.hns.com; Megaco List Subject: Re: [Megaco] Service change Restart This is where the RFC is completely inadequate as it stands. I wouldn't mind seeing it rewritten to specify separately what happens for ServiceChange on ROOT vs. ServiceChange on individual terminations. With regard to the latter, there is also something else I'd like to see ironed out: the service state is a writable property in TerminationState, yet it is manipulated by ServiceChange. One or the other of these should go. I am quite prepared to submit a proposal for new text for section 7.2.8 in particular. Would there be interest in reviewing such a proposal? We could submit it as a contribution into SG 16's May meeting if that is workable. klaha@hss.hns.com wrote: > > How about ServiceChange Restart on ROOT from MGC?Does the protocol > inhibit it? (It can be an easier means for the MGC to inform MG to > delete all contexts rather than 'Subtract'ing each of them, when MGC > is taken gracefully > out-of-service) > > > > > > Tom Taylor on 03/14/2003 12:27:35 AM > > To: Sachin Gupta-PNGN/HSS@HSS, Megaco List > cc: (bcc: Kushanava Laha/HSS) > > Subject: Re: [Megaco] Service change Restart > > > > I agree that it's very difficult to assign any real meaning to an > MGC-initiated restart of a termination. My background in switch > software development tells me that a restart clears certain aspects of > state. However, that makes little sense in the Megaco case, because > the MGC can do that directly by subtracting the termination from any > context it is in and resetting descriptors if it is not in a context. > > Conclusion: the only thing an MGC-initiated restart of a termination > does is change its state to in-service if it is not already there. > > gsachin@hss.hns.com wrote: > >>Hi List >>I have a query regarding the processing of Service Change Restart. >>consider the following scenario: >> >>Termination is in state InService. >>Command recieved from MGC to Restart the termination (with or wothout >>delay). >> >>what MG could possibly do in this case? >> >> >>Thanks >>Sachin Gupta >> > > [disclaimer snipped] > > _______________________________________________ > 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 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C2F3C5.8C4D6C0A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Megaco] Service change Restart

More comments inline. [KJBII]

You did make a good point about having a SCReason to = specify that a Restart isn't really a Restart, but is rather a = cancellation of a pending ServiceChange command.  I think it is = useful to have such a Reason code, and I will see about submitting a = proposal to the next SG16 meeting to add one.

Kevin

-----Original Message-----
From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] =
Sent: Tuesday, March 25, 2003 4:48 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: megaco@ietf.org
Subject: RE: [Megaco] Service change Restart




Hi Kevin
     Thanks for you = clarifications.
But the points that I have mentioned were basically = not normal scenario but are scenario developing because of the = inconsistancy between MG-MGC termination state machine. This can be due = to any reason like switchovers or some malfunctioning at either end. So = there should be some mechanism to correct this inconsistancy by = providing error responses to such SC requests. I have still have some = doubts on the point 2 and 4  below (comments inline = [bvswamy]).

[KJBII] If the MG cannot execute a command, then, I = agree, it should return an error.

Regards
Venkat





"Kevin Boyle" = <kboyle@nortelnetworks.com> on 03/24/2003 09:54:47 PM

To:   B Venkat S.R Swamy/HSS@HSS, = megaco@ietf.org
cc:

Subject:  RE: [Megaco] Service change = Restart



Comments inline. [KJBII]

Before we get too bogged down into a lot of scenario = by scenario details, keep in mind that the intent of this work is to = define as simple a model as possible.  There is no need to define = an enormous state machine that has a state for every possible = scenario.  There are, in reality two states, and a possible third = pseudo-state: In service, Out of service, and the fleeting delayed OOS = brought about by things like a SC Graceful.

Kevin

-----Original Message-----
From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com]
Sent: Thursday, March 20, 2003 2:43 AM
To: megaco@ietf.org
Subject: RE: [Megaco] Service change Restart




Hi Kevin
     Few clarifications needed = on the service change procedures:

1) What should MG do when it receives Service Change = Restart on a already inservice termination which is in Non-Null = context

     Should it give a error = response or whether MG should clear the call and remove the termination = from the context ?

[KJBII] MGs may not remove terms from context without = a Subtract command from the MGC.  The MG should Restart the term, = in accordance with its function and provisioning, and await cleanup = commands from the MGC.  If that restart means that the media = stream is lost, then that is something that the MGC should take into = account before requesting that the MG restart a particular = termination.

2) If ServiceChange Restart with delay is recd by = MG  for an already Inservice termination which may or may not be = in call then what should be

     MG behaviour. Should it mark = the termination as Out-Of-Service till the delay timer expires and = remove the termination from the context

    or give a error response ?

[KJBII] If the term is inservice, and the command is = to restart, why would you remove it from service?  The delay is = just that -- a delay.  Don't do anything with the term until the = delay expires, and then Restart it upon the expiry of the = delay.



[bvswamy]  Does this mean MG should not generate = any megaco message towards MGC
          for = these set of terminations till the delay timer expires because = by
          sending = SC Restart with delay, MGC is implicitly telling that the = terminations
          are = out-of-service at his end and is not expecting any messages for = that
          = terminations.Please correct me if I am wrong.

[KJBII] I do not see why any other messaging would = have to be held.  The Restart will execute at the end of the delay = -- that doesn't mean that no other messaging can be sent during the = delay.  What if the term is in context, the MGC sends a SC Restart = with delay, and then subsequently sends a subtract?  I think it = entirely reasonable that the Subtract be executed, even though there is = a pending Restart.

Also, Restart does NOT mean the terms go out of = service and then back in service.  It means that the terms were = reset to an initial state.  Think of it like the difference = between restarting windows and turning off the computer.  In the = turning off case, the computer has halted function.  In the other, = the computer is still functioning, but is reloading itself.  Now, = does a restart mean that functionality will cease to work for a short = time? Probably -- but that is a matter of implementation.  I can = conceive of a Restart that would be fast enough that there may not be a = perceptible interruption of functionality on a particular = term.

Keep in mind, however, that a Restart on Root will = affect ALL terms on the MG, and WILL result in service = disruption.  This is one of the differences between Root and other = terms.


3) If Service Change Graceful with delay = is    received by MG for an already
out
of service termination then how should MG = behave?
    Should it mark the termination = in-service right now and after timer expiry mark it out-of-service or = should it give an error?

[KJBII] So, an out of service termination receives a = command to take it out of service.  I say acknowledge the command, = and leave the termination as it is -- delay or not.  Since it is = already out of service, this is, effectively, a no-op.  Now, the = implications to think about are: What if the MG took the term OOS, and = then, later, the MGC sends a Forced or Graceful? This has the = implication that the MG, by itself, cannot bring the termination back = into service.  It implies, to me, that BOTH the MG and MGC must = take action on that term in order to have it return to = service.


In all of the above cases if MG were to give a error = response then there is no error-code defined which specifies that MG is = already in the state which MGC has requested , however there is an = error-code "Not-Ready" defined as "The command directed = to a  termination was not executed because of the service state of = the termination" which can be used in these situations for = conveying MGC that requested operation is not done.


4) What should be the MGC behaviour in the following = scenario:
     1) MGC recevies a Service = Change graceful with NonNull delay for a termination in context.
     2) Now MG want to cancel = the graceful timer. The only way do currently is by sending a
          service = Change Restart.
     Now what should be MGC = behaviour. Should it only stop the timer and continue the call or end = the call and the mark the termination

     as Inservice.

[KJBII] I believe that any SC command received while = there is one still awaiting its SCDelay expiry effectively overrides = the existing command.  For example, if a SC Graceful with a long = delay is in progress, and a SC Forced with comes during the delay = timing, then the Graceful is cancelled, and the Forced is executed as = signaled.

[bvswamy] Does this mean that any call running on the = terminations will get
           = cleared when MGC receives such overriding messages(Forced or = Restart).

[KJBII] As always, it is up to the MGC to take = appropriate action.  Certainly, if the MGC receives a Forced to = override a Graceful, then the MGC should tear down the context at that = time, rather than waiting for the delay to expire.  In the case of = a Restart, the Graceful is certainly cancelled, and the MGC can leave = the context as it is, if it so chooses.

I hope SG16 Annex F will also clarify doubts over the = above items.

Regards
Venkat




knayar@hss.hns.com on 03/18/2003 09:25:04 AM

To:   "Kevin Boyle" = <kboyle@nortelnetworks.com>
cc:   "Tom-PT Taylor" = <taylor@nortelnetworks.com>, Kushanava Laha/HSS@HSS,
      Sachin = Gupta-PNGN/HSS@HSS, Megaco List <megaco@ietf.org> (bcc: B = Venkat
      S.R Swamy/HSS)

Subject:  RE: [Megaco] Service change = Restart





Hi Kevin

Thanks for the useful pointer...
I did like to know if the Annex-F is intended to be = part of H.248v2 only or will also be applicable to H.248v1. Any = information about the time lines by when it would be finalised/ = freezed.

regards,
-kapil nayar
http://www.hssworld.com





"Kevin Boyle" = <kboyle@nortelnetworks.com> on 03/14/2003 08:33:23 PM

To:   "Tom-PT Taylor" = <taylor@nortelnetworks.com>, Kushanava Laha/HSS@HSS
cc:   Sachin Gupta-PNGN/HSS@HSS, Megaco = List <megaco@ietf.org> (bcc: Kapil
      Nayar/HSS)

Subject:  RE: [Megaco] Service change = Restart



This work is ongoing in SG16 as future Annex F.  = Both of these items are intended to be clarified by the new = work.

The input documents to the San Jose Rapporteurs' = Meeting can be found as AVD-2310, AVD-2311, and AVD-2298 at ftp://standard.pictel.com/avc-site/0302_San/.

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH]
Sent: Friday, March 14, 2003 9:30 AM
To: klaha@hss.hns.com
Cc: gsachin@hss.hns.com; Megaco List
Subject: Re: [Megaco] Service change Restart


This is where the RFC is completely inadequate as it = stands.  I wouldn't mind seeing it rewritten to specify separately = what happens for ServiceChange on ROOT vs. ServiceChange on individual = terminations.  With regard to the latter, there is also something = else I'd like to see ironed

out: the service state is a writable property in = TerminationState, yet it is manipulated by ServiceChange.  One or = the other of these should go.

I am quite prepared to submit a proposal for new text = for section 7.2.8 in particular.  Would there be interest in = reviewing such a proposal?  We could submit it as a contribution = into SG 16's May meeting if that is workable.

klaha@hss.hns.com wrote:
>
> How about ServiceChange Restart on ROOT from = MGC?Does the protocol
> inhibit it? (It can be an easier means for the = MGC to inform MG to
> delete all contexts rather than 'Subtract'ing = each of them, when MGC
> is taken gracefully
> out-of-service)
>
>
>
>
>
> Tom Taylor <taylor@nortelnetworks.com> on = 03/14/2003 12:27:35 AM
>
> To:   Sachin Gupta-PNGN/HSS@HSS, = Megaco List <megaco@ietf.org>
> cc:    (bcc: Kushanava = Laha/HSS)
>
> Subject:  Re: [Megaco] Service change = Restart
>
>
>
> I agree that it's very difficult to assign any = real meaning to an
> MGC-initiated restart of a termination.  = My background in switch
> software development tells me that a restart = clears certain aspects of
> state.  However, that makes little sense = in the Megaco case, because
> the MGC can do that directly by subtracting the = termination from any
> context it is in and resetting descriptors if = it is not in a
context.
>
> Conclusion: the only thing an MGC-initiated = restart of a termination
> does is change its state to in-service if it is = not already there.
>
> gsachin@hss.hns.com wrote:
>
>>Hi List
>>I have a query regarding the processing of = Service Change Restart.
>>consider the following scenario:
>>
>>Termination is in state InService.
>>Command recieved from MGC to Restart the = termination (with or wothout
>>delay).
>>
>>what MG could possibly do in this = case?
>>
>>
>>Thanks
>>Sachin Gupta
>>
>
> [disclaimer snipped]
>
> = _______________________________________________
> 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




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








DISCLAIMER: This message is proprietary to Hughes = Software Systems Limited
(HSS) and is intended solely for the use of the = individual to whom it is addressed. It may contain  privileged or = confidential information  and should not be circulated or used for = any purpose other than for what it is intended. If you have received = this message in error, please notify the originator immediately. If you = are not the intended recipient, you are notified that you are strictly = prohibited from using, copying, altering, or disclosing the contents of = this message. HSS accepts no responsibility for loss or damage arising = from the use of the information transmitted by this email including = damage from virus.


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




------_=_NextPart_001_01C2F3C5.8C4D6C0A-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Wed Mar 26 13:38: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 NAA06607 for ; Wed, 26 Mar 2003 13:38:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QIx1h21683 for megaco-archive@odin.ietf.org; Wed, 26 Mar 2003 13:59: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 h2QIx0O21680 for ; Wed, 26 Mar 2003 13:59: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 NAA06591 for ; Wed, 26 Mar 2003 13:37: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 h2QIofO21171; Wed, 26 Mar 2003 13:50: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 h2QImDO20999 for ; Wed, 26 Mar 2003 13:48:13 -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 NAA06256 for ; Wed, 26 Mar 2003 13:26:45 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2QISr019684; Wed, 26 Mar 2003 13:28:53 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Mar 2003 13:28:54 -0500 Message-ID: From: "Kevin Boyle" To: bvswamy@hss.hns.com Cc: megaco@ietf.org Subject: RE: [Megaco] Service change Restart Date: Wed, 26 Mar 2003 13:28:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F3C5.8C4D6C0A" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2F3C5.8C4D6C0A Content-Type: text/plain More comments inline. [KJBII] You did make a good point about having a SCReason to specify that a Restart isn't really a Restart, but is rather a cancellation of a pending ServiceChange command. I think it is useful to have such a Reason code, and I will see about submitting a proposal to the next SG16 meeting to add one. Kevin -----Original Message----- From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] Sent: Tuesday, March 25, 2003 4:48 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: megaco@ietf.org Subject: RE: [Megaco] Service change Restart Hi Kevin Thanks for you clarifications. But the points that I have mentioned were basically not normal scenario but are scenario developing because of the inconsistancy between MG-MGC termination state machine. This can be due to any reason like switchovers or some malfunctioning at either end. So there should be some mechanism to correct this inconsistancy by providing error responses to such SC requests. I have still have some doubts on the point 2 and 4 below (comments inline [bvswamy]). [KJBII] If the MG cannot execute a command, then, I agree, it should return an error. Regards Venkat "Kevin Boyle" on 03/24/2003 09:54:47 PM To: B Venkat S.R Swamy/HSS@HSS, megaco@ietf.org cc: Subject: RE: [Megaco] Service change Restart Comments inline. [KJBII] Before we get too bogged down into a lot of scenario by scenario details, keep in mind that the intent of this work is to define as simple a model as possible. There is no need to define an enormous state machine that has a state for every possible scenario. There are, in reality two states, and a possible third pseudo-state: In service, Out of service, and the fleeting delayed OOS brought about by things like a SC Graceful. Kevin -----Original Message----- From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] Sent: Thursday, March 20, 2003 2:43 AM To: megaco@ietf.org Subject: RE: [Megaco] Service change Restart Hi Kevin Few clarifications needed on the service change procedures: 1) What should MG do when it receives Service Change Restart on a already inservice termination which is in Non-Null context Should it give a error response or whether MG should clear the call and remove the termination from the context ? [KJBII] MGs may not remove terms from context without a Subtract command from the MGC. The MG should Restart the term, in accordance with its function and provisioning, and await cleanup commands from the MGC. If that restart means that the media stream is lost, then that is something that the MGC should take into account before requesting that the MG restart a particular termination. 2) If ServiceChange Restart with delay is recd by MG for an already Inservice termination which may or may not be in call then what should be MG behaviour. Should it mark the termination as Out-Of-Service till the delay timer expires and remove the termination from the context or give a error response ? [KJBII] If the term is inservice, and the command is to restart, why would you remove it from service? The delay is just that -- a delay. Don't do anything with the term until the delay expires, and then Restart it upon the expiry of the delay. [bvswamy] Does this mean MG should not generate any megaco message towards MGC for these set of terminations till the delay timer expires because by sending SC Restart with delay, MGC is implicitly telling that the terminations are out-of-service at his end and is not expecting any messages for that terminations.Please correct me if I am wrong. [KJBII] I do not see why any other messaging would have to be held. The Restart will execute at the end of the delay -- that doesn't mean that no other messaging can be sent during the delay. What if the term is in context, the MGC sends a SC Restart with delay, and then subsequently sends a subtract? I think it entirely reasonable that the Subtract be executed, even though there is a pending Restart. Also, Restart does NOT mean the terms go out of service and then back in service. It means that the terms were reset to an initial state. Think of it like the difference between restarting windows and turning off the computer. In the turning off case, the computer has halted function. In the other, the computer is still functioning, but is reloading itself. Now, does a restart mean that functionality will cease to work for a short time? Probably -- but that is a matter of implementation. I can conceive of a Restart that would be fast enough that there may not be a perceptible interruption of functionality on a particular term. Keep in mind, however, that a Restart on Root will affect ALL terms on the MG, and WILL result in service disruption. This is one of the differences between Root and other terms. 3) If Service Change Graceful with delay is received by MG for an already out of service termination then how should MG behave? Should it mark the termination in-service right now and after timer expiry mark it out-of-service or should it give an error? [KJBII] So, an out of service termination receives a command to take it out of service. I say acknowledge the command, and leave the termination as it is -- delay or not. Since it is already out of service, this is, effectively, a no-op. Now, the implications to think about are: What if the MG took the term OOS, and then, later, the MGC sends a Forced or Graceful? This has the implication that the MG, by itself, cannot bring the termination back into service. It implies, to me, that BOTH the MG and MGC must take action on that term in order to have it return to service. In all of the above cases if MG were to give a error response then there is no error-code defined which specifies that MG is already in the state which MGC has requested , however there is an error-code "Not-Ready" defined as "The command directed to a termination was not executed because of the service state of the termination" which can be used in these situations for conveying MGC that requested operation is not done. 4) What should be the MGC behaviour in the following scenario: 1) MGC recevies a Service Change graceful with NonNull delay for a termination in context. 2) Now MG want to cancel the graceful timer. The only way do currently is by sending a service Change Restart. Now what should be MGC behaviour. Should it only stop the timer and continue the call or end the call and the mark the termination as Inservice. [KJBII] I believe that any SC command received while there is one still awaiting its SCDelay expiry effectively overrides the existing command. For example, if a SC Graceful with a long delay is in progress, and a SC Forced with comes during the delay timing, then the Graceful is cancelled, and the Forced is executed as signaled. [bvswamy] Does this mean that any call running on the terminations will get cleared when MGC receives such overriding messages(Forced or Restart). [KJBII] As always, it is up to the MGC to take appropriate action. Certainly, if the MGC receives a Forced to override a Graceful, then the MGC should tear down the context at that time, rather than waiting for the delay to expire. In the case of a Restart, the Graceful is certainly cancelled, and the MGC can leave the context as it is, if it so chooses. I hope SG16 Annex F will also clarify doubts over the above items. Regards Venkat knayar@hss.hns.com on 03/18/2003 09:25:04 AM To: "Kevin Boyle" cc: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS, Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: B Venkat S.R Swamy/HSS) Subject: RE: [Megaco] Service change Restart Hi Kevin Thanks for the useful pointer... I did like to know if the Annex-F is intended to be part of H.248v2 only or will also be applicable to H.248v1. Any information about the time lines by when it would be finalised/ freezed. regards, -kapil nayar http://www.hssworld.com "Kevin Boyle" on 03/14/2003 08:33:23 PM To: "Tom-PT Taylor" , Kushanava Laha/HSS@HSS cc: Sachin Gupta-PNGN/HSS@HSS, Megaco List (bcc: Kapil Nayar/HSS) Subject: RE: [Megaco] Service change Restart This work is ongoing in SG16 as future Annex F. Both of these items are intended to be clarified by the new work. The input documents to the San Jose Rapporteurs' Meeting can be found as AVD-2310, AVD-2311, and AVD-2298 at ftp://standard.pictel.com/avc-site/0302_San/. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Friday, March 14, 2003 9:30 AM To: klaha@hss.hns.com Cc: gsachin@hss.hns.com; Megaco List Subject: Re: [Megaco] Service change Restart This is where the RFC is completely inadequate as it stands. I wouldn't mind seeing it rewritten to specify separately what happens for ServiceChange on ROOT vs. ServiceChange on individual terminations. With regard to the latter, there is also something else I'd like to see ironed out: the service state is a writable property in TerminationState, yet it is manipulated by ServiceChange. One or the other of these should go. I am quite prepared to submit a proposal for new text for section 7.2.8 in particular. Would there be interest in reviewing such a proposal? We could submit it as a contribution into SG 16's May meeting if that is workable. klaha@hss.hns.com wrote: > > How about ServiceChange Restart on ROOT from MGC?Does the protocol > inhibit it? (It can be an easier means for the MGC to inform MG to > delete all contexts rather than 'Subtract'ing each of them, when MGC > is taken gracefully > out-of-service) > > > > > > Tom Taylor on 03/14/2003 12:27:35 AM > > To: Sachin Gupta-PNGN/HSS@HSS, Megaco List > cc: (bcc: Kushanava Laha/HSS) > > Subject: Re: [Megaco] Service change Restart > > > > I agree that it's very difficult to assign any real meaning to an > MGC-initiated restart of a termination. My background in switch > software development tells me that a restart clears certain aspects of > state. However, that makes little sense in the Megaco case, because > the MGC can do that directly by subtracting the termination from any > context it is in and resetting descriptors if it is not in a context. > > Conclusion: the only thing an MGC-initiated restart of a termination > does is change its state to in-service if it is not already there. > > gsachin@hss.hns.com wrote: > >>Hi List >>I have a query regarding the processing of Service Change Restart. >>consider the following scenario: >> >>Termination is in state InService. >>Command recieved from MGC to Restart the termination (with or wothout >>delay). >> >>what MG could possibly do in this case? >> >> >>Thanks >>Sachin Gupta >> > > [disclaimer snipped] > > _______________________________________________ > 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 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C2F3C5.8C4D6C0A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Megaco] Service change Restart

More comments inline. [KJBII]

You did make a good point about having a SCReason to = specify that a Restart isn't really a Restart, but is rather a = cancellation of a pending ServiceChange command.  I think it is = useful to have such a Reason code, and I will see about submitting a = proposal to the next SG16 meeting to add one.

Kevin

-----Original Message-----
From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] =
Sent: Tuesday, March 25, 2003 4:48 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: megaco@ietf.org
Subject: RE: [Megaco] Service change Restart




Hi Kevin
     Thanks for you = clarifications.
But the points that I have mentioned were basically = not normal scenario but are scenario developing because of the = inconsistancy between MG-MGC termination state machine. This can be due = to any reason like switchovers or some malfunctioning at either end. So = there should be some mechanism to correct this inconsistancy by = providing error responses to such SC requests. I have still have some = doubts on the point 2 and 4  below (comments inline = [bvswamy]).

[KJBII] If the MG cannot execute a command, then, I = agree, it should return an error.

Regards
Venkat





"Kevin Boyle" = <kboyle@nortelnetworks.com> on 03/24/2003 09:54:47 PM

To:   B Venkat S.R Swamy/HSS@HSS, = megaco@ietf.org
cc:

Subject:  RE: [Megaco] Service change = Restart



Comments inline. [KJBII]

Before we get too bogged down into a lot of scenario = by scenario details, keep in mind that the intent of this work is to = define as simple a model as possible.  There is no need to define = an enormous state machine that has a state for every possible = scenario.  There are, in reality two states, and a possible third = pseudo-state: In service, Out of service, and the fleeting delayed OOS = brought about by things like a SC Graceful.

Kevin

-----Original Message-----
From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com]
Sent: Thursday, March 20, 2003 2:43 AM
To: megaco@ietf.org
Subject: RE: [Megaco] Service change Restart




Hi Kevin
     Few clarifications needed = on the service change procedures:

1) What should MG do when it receives Service Change = Restart on a already inservice termination which is in Non-Null = context

     Should it give a error = response or whether MG should clear the call and remove the termination = from the context ?

[KJBII] MGs may not remove terms from context without = a Subtract command from the MGC.  The MG should Restart the term, = in accordance with its function and provisioning, and await cleanup = commands from the MGC.  If that restart means that the media = stream is lost, then that is something that the MGC should take into = account before requesting that the MG restart a particular = termination.

2) If ServiceChange Restart with delay is recd by = MG  for an already Inservice termination which may or may not be = in call then what should be

     MG behaviour. Should it mark = the termination as Out-Of-Service till the delay timer expires and = remove the termination from the context

    or give a error response ?

[KJBII] If the term is inservice, and the command is = to restart, why would you remove it from service?  The delay is = just that -- a delay.  Don't do anything with the term until the = delay expires, and then Restart it upon the expiry of the = delay.



[bvswamy]  Does this mean MG should not generate = any megaco message towards MGC
          for = these set of terminations till the delay timer expires because = by
          sending = SC Restart with delay, MGC is implicitly telling that the = terminations
          are = out-of-service at his end and is not expecting any messages for = that
          = terminations.Please correct me if I am wrong.

[KJBII] I do not see why any other messaging would = have to be held.  The Restart will execute at the end of the delay = -- that doesn't mean that no other messaging can be sent during the = delay.  What if the term is in context, the MGC sends a SC Restart = with delay, and then subsequently sends a subtract?  I think it = entirely reasonable that the Subtract be executed, even though there is = a pending Restart.

Also, Restart does NOT mean the terms go out of = service and then back in service.  It means that the terms were = reset to an initial state.  Think of it like the difference = between restarting windows and turning off the computer.  In the = turning off case, the computer has halted function.  In the other, = the computer is still functioning, but is reloading itself.  Now, = does a restart mean that functionality will cease to work for a short = time? Probably -- but that is a matter of implementation.  I can = conceive of a Restart that would be fast enough that there may not be a = perceptible interruption of functionality on a particular = term.

Keep in mind, however, that a Restart on Root will = affect ALL terms on the MG, and WILL result in service = disruption.  This is one of the differences between Root and other = terms.


3) If Service Change Graceful with delay = is    received by MG for an already
out
of service termination then how should MG = behave?
    Should it mark the termination = in-service right now and after timer expiry mark it out-of-service or = should it give an error?

[KJBII] So, an out of service termination receives a = command to take it out of service.  I say acknowledge the command, = and leave the termination as it is -- delay or not.  Since it is = already out of service, this is, effectively, a no-op.  Now, the = implications to think about are: What if the MG took the term OOS, and = then, later, the MGC sends a Forced or Graceful? This has the = implication that the MG, by itself, cannot bring the termination back = into service.  It implies, to me, that BOTH the MG and MGC must = take action on that term in order to have it return to = service.


In all of the above cases if MG were to give a error = response then there is no error-code defined which specifies that MG is = already in the state which MGC has requested , however there is an = error-code "Not-Ready" defined as "The command directed = to a  termination was not executed because of the service state of = the termination" which can be used in these situations for = conveying MGC that requested operation is not done.


4) What should be the MGC behaviour in the following = scenario:
     1) MGC recevies a Service = Change graceful with NonNull delay for a termination in context.
     2) Now MG want to cancel = the graceful timer. The only way do currently is by sending a
          service = Change Restart.
     Now what should be MGC = behaviour. Should it only stop the timer and continue the call or end = the call and the mark the termination

     as Inservice.

[KJBII] I believe that any SC command received while = there is one still awaiting its SCDelay expiry effectively overrides = the existing command.  For example, if a SC Graceful with a long = delay is in progress, and a SC Forced with comes during the delay = timing, then the Graceful is cancelled, and the Forced is executed as = signaled.

[bvswamy] Does this mean that any call running on the = terminations will get
           = cleared when MGC receives such overriding messages(Forced or = Restart).

[KJBII] As always, it is up to the MGC to take = appropriate action.  Certainly, if the MGC receives a Forced to = override a Graceful, then the MGC should tear down the context at that = time, rather than waiting for the delay to expire.  In the case of = a Restart, the Graceful is certainly cancelled, and the MGC can leave = the context as it is, if it so chooses.

I hope SG16 Annex F will also clarify doubts over the = above items.

Regards
Venkat




knayar@hss.hns.com on 03/18/2003 09:25:04 AM

To:   "Kevin Boyle" = <kboyle@nortelnetworks.com>
cc:   "Tom-PT Taylor" = <taylor@nortelnetworks.com>, Kushanava Laha/HSS@HSS,
      Sachin = Gupta-PNGN/HSS@HSS, Megaco List <megaco@ietf.org> (bcc: B = Venkat
      S.R Swamy/HSS)

Subject:  RE: [Megaco] Service change = Restart





Hi Kevin

Thanks for the useful pointer...
I did like to know if the Annex-F is intended to be = part of H.248v2 only or will also be applicable to H.248v1. Any = information about the time lines by when it would be finalised/ = freezed.

regards,
-kapil nayar
http://www.hssworld.com





"Kevin Boyle" = <kboyle@nortelnetworks.com> on 03/14/2003 08:33:23 PM

To:   "Tom-PT Taylor" = <taylor@nortelnetworks.com>, Kushanava Laha/HSS@HSS
cc:   Sachin Gupta-PNGN/HSS@HSS, Megaco = List <megaco@ietf.org> (bcc: Kapil
      Nayar/HSS)

Subject:  RE: [Megaco] Service change = Restart



This work is ongoing in SG16 as future Annex F.  = Both of these items are intended to be clarified by the new = work.

The input documents to the San Jose Rapporteurs' = Meeting can be found as AVD-2310, AVD-2311, and AVD-2298 at ftp://standard.pictel.com/avc-site/0302_San/.

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH]
Sent: Friday, March 14, 2003 9:30 AM
To: klaha@hss.hns.com
Cc: gsachin@hss.hns.com; Megaco List
Subject: Re: [Megaco] Service change Restart


This is where the RFC is completely inadequate as it = stands.  I wouldn't mind seeing it rewritten to specify separately = what happens for ServiceChange on ROOT vs. ServiceChange on individual = terminations.  With regard to the latter, there is also something = else I'd like to see ironed

out: the service state is a writable property in = TerminationState, yet it is manipulated by ServiceChange.  One or = the other of these should go.

I am quite prepared to submit a proposal for new text = for section 7.2.8 in particular.  Would there be interest in = reviewing such a proposal?  We could submit it as a contribution = into SG 16's May meeting if that is workable.

klaha@hss.hns.com wrote:
>
> How about ServiceChange Restart on ROOT from = MGC?Does the protocol
> inhibit it? (It can be an easier means for the = MGC to inform MG to
> delete all contexts rather than 'Subtract'ing = each of them, when MGC
> is taken gracefully
> out-of-service)
>
>
>
>
>
> Tom Taylor <taylor@nortelnetworks.com> on = 03/14/2003 12:27:35 AM
>
> To:   Sachin Gupta-PNGN/HSS@HSS, = Megaco List <megaco@ietf.org>
> cc:    (bcc: Kushanava = Laha/HSS)
>
> Subject:  Re: [Megaco] Service change = Restart
>
>
>
> I agree that it's very difficult to assign any = real meaning to an
> MGC-initiated restart of a termination.  = My background in switch
> software development tells me that a restart = clears certain aspects of
> state.  However, that makes little sense = in the Megaco case, because
> the MGC can do that directly by subtracting the = termination from any
> context it is in and resetting descriptors if = it is not in a
context.
>
> Conclusion: the only thing an MGC-initiated = restart of a termination
> does is change its state to in-service if it is = not already there.
>
> gsachin@hss.hns.com wrote:
>
>>Hi List
>>I have a query regarding the processing of = Service Change Restart.
>>consider the following scenario:
>>
>>Termination is in state InService.
>>Command recieved from MGC to Restart the = termination (with or wothout
>>delay).
>>
>>what MG could possibly do in this = case?
>>
>>
>>Thanks
>>Sachin Gupta
>>
>
> [disclaimer snipped]
>
> = _______________________________________________
> 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




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








DISCLAIMER: This message is proprietary to Hughes = Software Systems Limited
(HSS) and is intended solely for the use of the = individual to whom it is addressed. It may contain  privileged or = confidential information  and should not be circulated or used for = any purpose other than for what it is intended. If you have received = this message in error, please notify the originator immediately. If you = are not the intended recipient, you are notified that you are strictly = prohibited from using, copying, altering, or disclosing the contents of = this message. HSS accepts no responsibility for loss or damage arising = from the use of the information transmitted by this email including = damage from virus.


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




------_=_NextPart_001_01C2F3C5.8C4D6C0A-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Mar 27 01:46: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 BAA05715 for ; Thu, 27 Mar 2003 01:46: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 h2R771O14565; Thu, 27 Mar 2003 02:07: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 h2R75dO13341 for ; Thu, 27 Mar 2003 02:05:39 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05681 for ; Thu, 27 Mar 2003 01:43:57 -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 h2R6iHs18227 for ; Thu, 27 Mar 2003 12:14:17 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2R6iG218217; Thu, 27 Mar 2003 12:14:16 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2R6l5E06352; Thu, 27 Mar 2003 12:17:05 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CF6.0023ECAD ; Thu, 27 Mar 2003 12:02:23 +0530 X-Lotus-FromDomain: HSS To: "Kevin Boyle" cc: megaco@ietf.org Message-ID: <65256CF6.0023EB8C.00@dlfmail1.hss.hns.com> Date: Thu, 27 Mar 2003 12:18:12 +0530 Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties 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 Kevin/List, Taking the discussion a bit further, please clarify if the following sequence for implementing Topology Descriptor is correct. Transaction receieved: ...Context=1{Topology{$, *, isolate}, Modify=T2{...}, Add=${...}} Processing steps: 1. Resolve the termination name i.e. select one termination conforming to the name specified in the Add command. 2. Add this termination to the Context. This step may involve using some information given in the Add command. 3. If the addition of the termination is successful proceed further. If the addition of termination to Context is not successful give a Context Level Error in the response. 4. Apply Topology for the newly added termination. 5. Process the Modify command. 6. Process the Add command. Some information present in this command will be used while adding the termination to the Context. Rest of the information is processed here. Please correct me if I am wrong. Regards, Chintan... www.hssworld.com "Kevin Boyle" on 03/20/2003 12:14:08 PM To: Chintan Kaushik/HSS@HSS, David Kao cc: megaco@ietf.org Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties This is not correct. As has been repeatedly covered, the Topology descriptor is executed before any commands, regardless of the information available. The difference between this statement, and what you have expressed is this: C=1{TP{$,*,IS},A=${...} Topology first: The new term is added already isolated from all other terms in the context. Topology once "enough information" is present: The new term is added bothway to all terms, and then topology is altered to isolate the term from all other terms in the context. As you can see there is a significant difference between these two scenarios. If the command fails, then it is up to the MGC to clean up any potential mess that results from having executed the TP descriptor. Kevin -----Original Message----- From: ckaushik@hss.hns.com [mailto:ckaushik@hss.hns.com] Sent: Wednesday, March 19, 2003 11:27 PM To: David Kao Cc: megaco@ietf.org Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties Hi, A small addition to what Kevin has already mentioned: - Attempt is made to apply the Topology descriptor before any commands for that action. However, if due to some reason this is not possible then the Topology Descriptor is applied as soon as all the information to apply it is known to the MG. e.g. ... Context = 1{Topology{idstr1,$,Bothway } ,Add=$ {... In this case Topology will be applied once the "Add=$" command has been executed successfully. Regards, Chintan... "Kevin Boyle" on 03/19/2003 12:30:27 AM To: David Kao , megaco@ietf.org cc: (bcc: Chintan Kaushik/HSS) Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties Comments inline. [KJBII] Kevin -----Original Message----- From: David Kao [mailto:david.kao@verizon.net] Sent: Monday, March 17, 2003 10:22 PM To: megaco@ietf.org Subject: [Megaco] Processing Order of Context Properties and Termination Properties Please accept my apology if the same questions were asked and discussed before. The spec says, "Transactions guarantee ordered Command processing. That is, Commands within a Transaction are executed sequentially." I have two relevant questions based on this statement. 1. How about the processing order of context properties? Are they supposed to be processed in the same same sequential order like the commands? For instance, based on previously posted emails from Christian Grove, topology descriptor should be processed before commands in an action, since "The Topology descriptor occurs before the commands in an action." In fact, all contextRequests come before the commands. If this is the case, is the following generalization correct? "In a transaction, actions are executed sequentially. In an action, context requests (including context property modifications and context property audits) and commands are executed sequentially." [KJBII] Yes. H.248 is, essentially, a left to right protocol. 2. How about the processing order of termination properties? Without a well-defined order, different MG implementations can respond differently to the same command. For instance, if Signals descriptor is processed before Events descriptor can produce different results than the case when Events descriptor is processed first. [KJBII] See above comment. Regards, David Kao _______________________________________________ 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 Thu Mar 27 01: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 BAA05752 for ; Thu, 27 Mar 2003 01:48:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R79bo16311 for megaco-archive@odin.ietf.org; Thu, 27 Mar 2003 02:09: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 h2R79aO16308 for ; Thu, 27 Mar 2003 02:09: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 BAA05744 for ; Thu, 27 Mar 2003 01:47: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 h2R771O14565; Thu, 27 Mar 2003 02:07: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 h2R75dO13341 for ; Thu, 27 Mar 2003 02:05:39 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05681 for ; Thu, 27 Mar 2003 01:43:57 -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 h2R6iHs18227 for ; Thu, 27 Mar 2003 12:14:17 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h2R6iG218217; Thu, 27 Mar 2003 12:14:16 +0530 (IST) Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h2R6l5E06352; Thu, 27 Mar 2003 12:17:05 +0530 (IST) Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256CF6.0023ECAD ; Thu, 27 Mar 2003 12:02:23 +0530 X-Lotus-FromDomain: HSS To: "Kevin Boyle" cc: megaco@ietf.org Message-ID: <65256CF6.0023EB8C.00@dlfmail1.hss.hns.com> Date: Thu, 27 Mar 2003 12:18:12 +0530 Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties 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 Kevin/List, Taking the discussion a bit further, please clarify if the following sequence for implementing Topology Descriptor is correct. Transaction receieved: ...Context=1{Topology{$, *, isolate}, Modify=T2{...}, Add=${...}} Processing steps: 1. Resolve the termination name i.e. select one termination conforming to the name specified in the Add command. 2. Add this termination to the Context. This step may involve using some information given in the Add command. 3. If the addition of the termination is successful proceed further. If the addition of termination to Context is not successful give a Context Level Error in the response. 4. Apply Topology for the newly added termination. 5. Process the Modify command. 6. Process the Add command. Some information present in this command will be used while adding the termination to the Context. Rest of the information is processed here. Please correct me if I am wrong. Regards, Chintan... www.hssworld.com "Kevin Boyle" on 03/20/2003 12:14:08 PM To: Chintan Kaushik/HSS@HSS, David Kao cc: megaco@ietf.org Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties This is not correct. As has been repeatedly covered, the Topology descriptor is executed before any commands, regardless of the information available. The difference between this statement, and what you have expressed is this: C=1{TP{$,*,IS},A=${...} Topology first: The new term is added already isolated from all other terms in the context. Topology once "enough information" is present: The new term is added bothway to all terms, and then topology is altered to isolate the term from all other terms in the context. As you can see there is a significant difference between these two scenarios. If the command fails, then it is up to the MGC to clean up any potential mess that results from having executed the TP descriptor. Kevin -----Original Message----- From: ckaushik@hss.hns.com [mailto:ckaushik@hss.hns.com] Sent: Wednesday, March 19, 2003 11:27 PM To: David Kao Cc: megaco@ietf.org Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties Hi, A small addition to what Kevin has already mentioned: - Attempt is made to apply the Topology descriptor before any commands for that action. However, if due to some reason this is not possible then the Topology Descriptor is applied as soon as all the information to apply it is known to the MG. e.g. ... Context = 1{Topology{idstr1,$,Bothway } ,Add=$ {... In this case Topology will be applied once the "Add=$" command has been executed successfully. Regards, Chintan... "Kevin Boyle" on 03/19/2003 12:30:27 AM To: David Kao , megaco@ietf.org cc: (bcc: Chintan Kaushik/HSS) Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties Comments inline. [KJBII] Kevin -----Original Message----- From: David Kao [mailto:david.kao@verizon.net] Sent: Monday, March 17, 2003 10:22 PM To: megaco@ietf.org Subject: [Megaco] Processing Order of Context Properties and Termination Properties Please accept my apology if the same questions were asked and discussed before. The spec says, "Transactions guarantee ordered Command processing. That is, Commands within a Transaction are executed sequentially." I have two relevant questions based on this statement. 1. How about the processing order of context properties? Are they supposed to be processed in the same same sequential order like the commands? For instance, based on previously posted emails from Christian Grove, topology descriptor should be processed before commands in an action, since "The Topology descriptor occurs before the commands in an action." In fact, all contextRequests come before the commands. If this is the case, is the following generalization correct? "In a transaction, actions are executed sequentially. In an action, context requests (including context property modifications and context property audits) and commands are executed sequentially." [KJBII] Yes. H.248 is, essentially, a left to right protocol. 2. How about the processing order of termination properties? Without a well-defined order, different MG implementations can respond differently to the same command. For instance, if Signals descriptor is processed before Events descriptor can produce different results than the case when Events descriptor is processed first. [KJBII] See above comment. Regards, David Kao _______________________________________________ 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 Thu Mar 27 11:22: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 LAA05609 for ; Thu, 27 Mar 2003 11:22: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 h2RGhhO30188; Thu, 27 Mar 2003 11:43: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 h2RGRdO28571 for ; Thu, 27 Mar 2003 11:27:39 -0500 Received: from eins.siemens.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05049 for ; Thu, 27 Mar 2003 11:05:47 -0500 (EST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.8/8.12.8) with ESMTP id h2RG87Mt007430 for ; Thu, 27 Mar 2003 17:08:07 +0100 Received: from vies194a.sie.siemens.at (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.8/8.12.1) with ESMTP id h2RG86aH008375 for ; Thu, 27 Mar 2003 17:08:06 +0100 (MET) Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Mar 2003 17:09:04 +0100 Message-ID: From: Kalleitner Franz To: megaco@ietf.org Date: Thu, 27 Mar 2003 17:08:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F47B.26FE7400" Subject: [Megaco] Signal status after move from specific to NULL context Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2F47B.26FE7400 Content-Type: text/plain Dear Megaco-List members, A physical termination is added into in a specifc context and a signal is connected to that phy. termination. Afterwards the physical termination is subtracted and shall be removed back to the NULL context. What is the status of the signal after the subtract command? a.) is it still active b.) deactivated because of the subtract command. yours sincerly ------_=_NextPart_001_01C2F47B.26FE7400 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PVVTLUFTQ0lJIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTMuMTIiPg0KPFRJVExFPlNpZ25hbCAg c3RhdHVzIGFmdGVyIG1vdmUgZnJvbSBzcGVjaWZpYyB0byBOVUxMIGNvbnRleHQ8L1RJVExFPg0K PC9IRUFEPg0KPEJPRFk+DQoNCjxQPjxGT05UIFNJWkU9Mj5EZWFyIE1lZ2Fjby1MaXN0IG1lbWJl cnMsPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+QSBwaHlzaWNhbCB0ZXJtaW5hdGlv biBpcyBhZGRlZCBpbnRvIGluIGEgc3BlY2lmYyBjb250ZXh0IGFuZCBhIHNpZ25hbCBpcyBjb25u ZWN0ZWQgdG8gdGhhdCBwaHkuIHRlcm1pbmF0aW9uLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ QWZ0ZXJ3YXJkcyB0aGUgcGh5c2ljYWwgdGVybWluYXRpb24gaXMgc3VidHJhY3RlZCBhbmQgc2hh bGwgYmUgcmVtb3ZlZCBiYWNrIHRvIHRoZSBOVUxMIGNvbnRleHQuPC9GT05UPg0KPC9QPg0KDQo8 UD48Rk9OVCBTSVpFPTI+V2hhdCBpcyB0aGUgc3RhdHVzIG9mIHRoZSBzaWduYWwgYWZ0ZXIgdGhl IHN1YnRyYWN0IGNvbW1hbmQ/IDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPmEuKSBp cyBpdCBzdGlsbCBhY3RpdmUgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5iLikgZGVhY3RpdmF0 ZWQgYmVjYXVzZSBvZiB0aGUgc3VidHJhY3QgY29tbWFuZC48L0ZPTlQ+DQo8L1A+DQo8QlI+DQoN CjxQPjxGT05UIFNJWkU9Mj55b3VycyBzaW5jZXJseSA8L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4N CjwvSFRNTD4= ------_=_NextPart_001_01C2F47B.26FE7400-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Mar 27 11:23: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 LAA05655 for ; Thu, 27 Mar 2003 11:23:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RGjCN30277 for megaco-archive@odin.ietf.org; Thu, 27 Mar 2003 11:45:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RGjCO30274 for ; Thu, 27 Mar 2003 11:45: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 LAA05641 for ; Thu, 27 Mar 2003 11: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 h2RGhhO30188; Thu, 27 Mar 2003 11:43: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 h2RGRdO28571 for ; Thu, 27 Mar 2003 11:27:39 -0500 Received: from eins.siemens.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05049 for ; Thu, 27 Mar 2003 11:05:47 -0500 (EST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.8/8.12.8) with ESMTP id h2RG87Mt007430 for ; Thu, 27 Mar 2003 17:08:07 +0100 Received: from vies194a.sie.siemens.at (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.8/8.12.1) with ESMTP id h2RG86aH008375 for ; Thu, 27 Mar 2003 17:08:06 +0100 (MET) Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Mar 2003 17:09:04 +0100 Message-ID: From: Kalleitner Franz To: megaco@ietf.org Date: Thu, 27 Mar 2003 17:08:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F47B.26FE7400" Subject: [Megaco] Signal status after move from specific to NULL context Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2F47B.26FE7400 Content-Type: text/plain Dear Megaco-List members, A physical termination is added into in a specifc context and a signal is connected to that phy. termination. Afterwards the physical termination is subtracted and shall be removed back to the NULL context. What is the status of the signal after the subtract command? a.) is it still active b.) deactivated because of the subtract command. yours sincerly ------_=_NextPart_001_01C2F47B.26FE7400 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PVVTLUFTQ0lJIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTMuMTIiPg0KPFRJVExFPlNpZ25hbCAg c3RhdHVzIGFmdGVyIG1vdmUgZnJvbSBzcGVjaWZpYyB0byBOVUxMIGNvbnRleHQ8L1RJVExFPg0K PC9IRUFEPg0KPEJPRFk+DQoNCjxQPjxGT05UIFNJWkU9Mj5EZWFyIE1lZ2Fjby1MaXN0IG1lbWJl cnMsPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+QSBwaHlzaWNhbCB0ZXJtaW5hdGlv biBpcyBhZGRlZCBpbnRvIGluIGEgc3BlY2lmYyBjb250ZXh0IGFuZCBhIHNpZ25hbCBpcyBjb25u ZWN0ZWQgdG8gdGhhdCBwaHkuIHRlcm1pbmF0aW9uLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ QWZ0ZXJ3YXJkcyB0aGUgcGh5c2ljYWwgdGVybWluYXRpb24gaXMgc3VidHJhY3RlZCBhbmQgc2hh bGwgYmUgcmVtb3ZlZCBiYWNrIHRvIHRoZSBOVUxMIGNvbnRleHQuPC9GT05UPg0KPC9QPg0KDQo8 UD48Rk9OVCBTSVpFPTI+V2hhdCBpcyB0aGUgc3RhdHVzIG9mIHRoZSBzaWduYWwgYWZ0ZXIgdGhl IHN1YnRyYWN0IGNvbW1hbmQ/IDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPmEuKSBp cyBpdCBzdGlsbCBhY3RpdmUgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5iLikgZGVhY3RpdmF0 ZWQgYmVjYXVzZSBvZiB0aGUgc3VidHJhY3QgY29tbWFuZC48L0ZPTlQ+DQo8L1A+DQo8QlI+DQoN CjxQPjxGT05UIFNJWkU9Mj55b3VycyBzaW5jZXJseSA8L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4N CjwvSFRNTD4= ------_=_NextPart_001_01C2F47B.26FE7400-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Mar 27 14:55: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 OAA15625 for ; Thu, 27 Mar 2003 14:55: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 h2RKGLO16092; Thu, 27 Mar 2003 15:16: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 h2RKE1O15972 for ; Thu, 27 Mar 2003 15:14:01 -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 OAA15479 for ; Thu, 27 Mar 2003 14:52:04 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2RJsOB00211 for ; Thu, 27 Mar 2003 14:54:25 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Mar 2003 14:54:25 -0500 Message-ID: From: "Kevin Boyle" To: ckaushik@hss.hns.com Cc: megaco@ietf.org Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties Date: Thu, 27 Mar 2003 14:54: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: , Clearly you cannot add the new term before modifying T2. So the steps are thus: 1. Process the TP descriptor, noting that there is a term that will be added later in the action which will be isolated from all the other existing terms in the context. 2. Process the Modify T2 command. 3. Process the Add command, and add the new term. Note that because the TP descriptor has ALREADY been processed, the term is added isolated from all other terms in the context. Kevin -----Original Message----- From: ckaushik@hss.hns.com [mailto:ckaushik@hss.hns.com] Sent: Thursday, March 27, 2003 1:48 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: megaco@ietf.org Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties Hi Kevin/List, Taking the discussion a bit further, please clarify if the following sequence for implementing Topology Descriptor is correct. Transaction receieved: ...Context=1{Topology{$, *, isolate}, Modify=T2{...}, Add=${...}} Processing steps: 1. Resolve the termination name i.e. select one termination conforming to the name specified in the Add command. 2. Add this termination to the Context. This step may involve using some information given in the Add command. 3. If the addition of the termination is successful proceed further. If the addition of termination to Context is not successful give a Context Level Error in the response. 4. Apply Topology for the newly added termination. 5. Process the Modify command. 6. Process the Add command. Some information present in this command will be used while adding the termination to the Context. Rest of the information is processed here. Please correct me if I am wrong. Regards, Chintan... www.hssworld.com "Kevin Boyle" on 03/20/2003 12:14:08 PM To: Chintan Kaushik/HSS@HSS, David Kao cc: megaco@ietf.org Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties This is not correct. As has been repeatedly covered, the Topology descriptor is executed before any commands, regardless of the information available. The difference between this statement, and what you have expressed is this: C=1{TP{$,*,IS},A=${...} Topology first: The new term is added already isolated from all other terms in the context. Topology once "enough information" is present: The new term is added bothway to all terms, and then topology is altered to isolate the term from all other terms in the context. As you can see there is a significant difference between these two scenarios. If the command fails, then it is up to the MGC to clean up any potential mess that results from having executed the TP descriptor. Kevin -----Original Message----- From: ckaushik@hss.hns.com [mailto:ckaushik@hss.hns.com] Sent: Wednesday, March 19, 2003 11:27 PM To: David Kao Cc: megaco@ietf.org Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties Hi, A small addition to what Kevin has already mentioned: - Attempt is made to apply the Topology descriptor before any commands for that action. However, if due to some reason this is not possible then the Topology Descriptor is applied as soon as all the information to apply it is known to the MG. e.g. ... Context = 1{Topology{idstr1,$,Bothway } ,Add=$ {... In this case Topology will be applied once the "Add=$" command has been executed successfully. Regards, Chintan... "Kevin Boyle" on 03/19/2003 12:30:27 AM To: David Kao , megaco@ietf.org cc: (bcc: Chintan Kaushik/HSS) Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties Comments inline. [KJBII] Kevin -----Original Message----- From: David Kao [mailto:david.kao@verizon.net] Sent: Monday, March 17, 2003 10:22 PM To: megaco@ietf.org Subject: [Megaco] Processing Order of Context Properties and Termination Properties Please accept my apology if the same questions were asked and discussed before. The spec says, "Transactions guarantee ordered Command processing. That is, Commands within a Transaction are executed sequentially." I have two relevant questions based on this statement. 1. How about the processing order of context properties? Are they supposed to be processed in the same same sequential order like the commands? For instance, based on previously posted emails from Christian Grove, topology descriptor should be processed before commands in an action, since "The Topology descriptor occurs before the commands in an action." In fact, all contextRequests come before the commands. If this is the case, is the following generalization correct? "In a transaction, actions are executed sequentially. In an action, context requests (including context property modifications and context property audits) and commands are executed sequentially." [KJBII] Yes. H.248 is, essentially, a left to right protocol. 2. How about the processing order of termination properties? Without a well-defined order, different MG implementations can respond differently to the same command. For instance, if Signals descriptor is processed before Events descriptor can produce different results than the case when Events descriptor is processed first. [KJBII] See above comment. Regards, David Kao _______________________________________________ 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 Thu Mar 27 14:56: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 OAA15684 for ; Thu, 27 Mar 2003 14:56:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RKI9i16222 for megaco-archive@odin.ietf.org; Thu, 27 Mar 2003 15:18: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 h2RKI9O16219 for ; Thu, 27 Mar 2003 15:18:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15672 for ; Thu, 27 Mar 2003 14:56: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 h2RKGLO16092; Thu, 27 Mar 2003 15:16: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 h2RKE1O15972 for ; Thu, 27 Mar 2003 15:14:01 -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 OAA15479 for ; Thu, 27 Mar 2003 14:52:04 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2RJsOB00211 for ; Thu, 27 Mar 2003 14:54:25 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Mar 2003 14:54:25 -0500 Message-ID: From: "Kevin Boyle" To: ckaushik@hss.hns.com Cc: megaco@ietf.org Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties Date: Thu, 27 Mar 2003 14:54: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: , Clearly you cannot add the new term before modifying T2. So the steps are thus: 1. Process the TP descriptor, noting that there is a term that will be added later in the action which will be isolated from all the other existing terms in the context. 2. Process the Modify T2 command. 3. Process the Add command, and add the new term. Note that because the TP descriptor has ALREADY been processed, the term is added isolated from all other terms in the context. Kevin -----Original Message----- From: ckaushik@hss.hns.com [mailto:ckaushik@hss.hns.com] Sent: Thursday, March 27, 2003 1:48 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: megaco@ietf.org Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties Hi Kevin/List, Taking the discussion a bit further, please clarify if the following sequence for implementing Topology Descriptor is correct. Transaction receieved: ...Context=1{Topology{$, *, isolate}, Modify=T2{...}, Add=${...}} Processing steps: 1. Resolve the termination name i.e. select one termination conforming to the name specified in the Add command. 2. Add this termination to the Context. This step may involve using some information given in the Add command. 3. If the addition of the termination is successful proceed further. If the addition of termination to Context is not successful give a Context Level Error in the response. 4. Apply Topology for the newly added termination. 5. Process the Modify command. 6. Process the Add command. Some information present in this command will be used while adding the termination to the Context. Rest of the information is processed here. Please correct me if I am wrong. Regards, Chintan... www.hssworld.com "Kevin Boyle" on 03/20/2003 12:14:08 PM To: Chintan Kaushik/HSS@HSS, David Kao cc: megaco@ietf.org Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties This is not correct. As has been repeatedly covered, the Topology descriptor is executed before any commands, regardless of the information available. The difference between this statement, and what you have expressed is this: C=1{TP{$,*,IS},A=${...} Topology first: The new term is added already isolated from all other terms in the context. Topology once "enough information" is present: The new term is added bothway to all terms, and then topology is altered to isolate the term from all other terms in the context. As you can see there is a significant difference between these two scenarios. If the command fails, then it is up to the MGC to clean up any potential mess that results from having executed the TP descriptor. Kevin -----Original Message----- From: ckaushik@hss.hns.com [mailto:ckaushik@hss.hns.com] Sent: Wednesday, March 19, 2003 11:27 PM To: David Kao Cc: megaco@ietf.org Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties Hi, A small addition to what Kevin has already mentioned: - Attempt is made to apply the Topology descriptor before any commands for that action. However, if due to some reason this is not possible then the Topology Descriptor is applied as soon as all the information to apply it is known to the MG. e.g. ... Context = 1{Topology{idstr1,$,Bothway } ,Add=$ {... In this case Topology will be applied once the "Add=$" command has been executed successfully. Regards, Chintan... "Kevin Boyle" on 03/19/2003 12:30:27 AM To: David Kao , megaco@ietf.org cc: (bcc: Chintan Kaushik/HSS) Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties Comments inline. [KJBII] Kevin -----Original Message----- From: David Kao [mailto:david.kao@verizon.net] Sent: Monday, March 17, 2003 10:22 PM To: megaco@ietf.org Subject: [Megaco] Processing Order of Context Properties and Termination Properties Please accept my apology if the same questions were asked and discussed before. The spec says, "Transactions guarantee ordered Command processing. That is, Commands within a Transaction are executed sequentially." I have two relevant questions based on this statement. 1. How about the processing order of context properties? Are they supposed to be processed in the same same sequential order like the commands? For instance, based on previously posted emails from Christian Grove, topology descriptor should be processed before commands in an action, since "The Topology descriptor occurs before the commands in an action." In fact, all contextRequests come before the commands. If this is the case, is the following generalization correct? "In a transaction, actions are executed sequentially. In an action, context requests (including context property modifications and context property audits) and commands are executed sequentially." [KJBII] Yes. H.248 is, essentially, a left to right protocol. 2. How about the processing order of termination properties? Without a well-defined order, different MG implementations can respond differently to the same command. For instance, if Signals descriptor is processed before Events descriptor can produce different results than the case when Events descriptor is processed first. [KJBII] See above comment. Regards, David Kao _______________________________________________ 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 Thu Mar 27 17:17: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 RAA22038 for ; Thu, 27 Mar 2003 17:17: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 h2RMbtO28297; Thu, 27 Mar 2003 17:37: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 h2RMW3O27212 for ; Thu, 27 Mar 2003 17:32:03 -0500 Received: from motgate5.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21712 for ; Thu, 27 Mar 2003 17:10:05 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h2RMBw8j022891 for ; Thu, 27 Mar 2003 15:11:58 -0700 (MST) Received: [from az33exm05.corp.mot.com (az33exm05.corp.mot.com [199.2.84.25]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id PAA12623 for ; Thu, 27 Mar 2003 15:12:12 -0700 (MST)] Received: by az33exm05.corp.mot.com with Internet Mail Service (5.5.2656.59) id <166WCPWH>; Thu, 27 Mar 2003 15:12:24 -0700 Message-ID: <7FD24C15A06DD511BF9E00D0B73E995207139411@az33exm05.corp.mot.com> From: Maschoff Mark-P53708 To: megaco@ietf.org Date: Thu, 27 Mar 2003 15:11:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F4AD.D61EB18A" Subject: [Megaco] Error Code 406 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2F4AD.D61EB18A Content-Type: text/plain; charset="iso-8859-1" Question on Error code 406 - Incorrect identifier: was this error code meant for Transaction ID errors? Also, are there any rules/preferences for where an error code should be inserted in a reply? Can more than one error code be included? Thanks, Mark ------_=_NextPart_001_01C2F4AD.D61EB18A Content-Type: text/html; charset="iso-8859-1"
Question on Error code 406 - Incorrect identifier:  was this error code meant for Transaction ID errors? 
 
Also, are there any rules/preferences for where an error code should be inserted in a reply?  Can more than one error code be included?
 
Thanks,
 
Mark
------_=_NextPart_001_01C2F4AD.D61EB18A-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Mar 27 17:18: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 RAA22074 for ; Thu, 27 Mar 2003 17:18:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RMdZg28374 for megaco-archive@odin.ietf.org; Thu, 27 Mar 2003 17:39: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 h2RMdZO28371 for ; Thu, 27 Mar 2003 17:39: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 RAA22066 for ; Thu, 27 Mar 2003 17:17: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 h2RMbtO28297; Thu, 27 Mar 2003 17:37: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 h2RMW3O27212 for ; Thu, 27 Mar 2003 17:32:03 -0500 Received: from motgate5.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21712 for ; Thu, 27 Mar 2003 17:10:05 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h2RMBw8j022891 for ; Thu, 27 Mar 2003 15:11:58 -0700 (MST) Received: [from az33exm05.corp.mot.com (az33exm05.corp.mot.com [199.2.84.25]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id PAA12623 for ; Thu, 27 Mar 2003 15:12:12 -0700 (MST)] Received: by az33exm05.corp.mot.com with Internet Mail Service (5.5.2656.59) id <166WCPWH>; Thu, 27 Mar 2003 15:12:24 -0700 Message-ID: <7FD24C15A06DD511BF9E00D0B73E995207139411@az33exm05.corp.mot.com> From: Maschoff Mark-P53708 To: megaco@ietf.org Date: Thu, 27 Mar 2003 15:11:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F4AD.D61EB18A" Subject: [Megaco] Error Code 406 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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_01C2F4AD.D61EB18A Content-Type: text/plain; charset="iso-8859-1" Question on Error code 406 - Incorrect identifier: was this error code meant for Transaction ID errors? Also, are there any rules/preferences for where an error code should be inserted in a reply? Can more than one error code be included? Thanks, Mark ------_=_NextPart_001_01C2F4AD.D61EB18A Content-Type: text/html; charset="iso-8859-1"
Question on Error code 406 - Incorrect identifier:  was this error code meant for Transaction ID errors? 
 
Also, are there any rules/preferences for where an error code should be inserted in a reply?  Can more than one error code be included?
 
Thanks,
 
Mark
------_=_NextPart_001_01C2F4AD.D61EB18A-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Mar 27 22:52: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 WAA03150 for ; Thu, 27 Mar 2003 22:52: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 h2S4DDO19896; Thu, 27 Mar 2003 23:13:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S4BLO19831 for ; Thu, 27 Mar 2003 23:11:21 -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 WAA03096 for ; Thu, 27 Mar 2003 22:49:14 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2S3pabh028361; Fri, 28 Mar 2003 04:51:36 +0100 (MET) Received: from brsf10.epa.ericsson.se ([146.11.8.4]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id HK1V4WHJ; Fri, 28 Mar 2003 04:51:36 +0100 Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h2S3pWL11109; Fri, 28 Mar 2003 14:51:32 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.201]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HFD4PQZS; Fri, 28 Mar 2003 14:51:31 +1100 Message-ID: <3E83BDB0.2C8821D1@ericsson.com.au> Date: Fri, 28 Mar 2003 14:12:48 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Maschoff Mark-P53708 CC: megaco@ietf.org Subject: Re: [Megaco] Error Code 406 References: <7FD24C15A06DD511BF9E00D0B73E995207139411@az33exm05.corp.mot.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 Mark, I think you mean error code 410. H.248.8 states: 4.2.6 Error Code #: 410 Name: Incorrect identifier Definition: The transaction request(s) has been disregarded due to a syntax error (illegal length or illegal character) having been found in a mId, transactionId, contextId, terminationId, PropertyId, EventId, SignalId, StatisticsId, ParameterId or requestID. Package: - Reference: No Error Text in the error Descriptor: The concerned ID is included in the error text in the error descriptor. Comment: If the error is detected prior to determining a valid transaction ID, no meaningful action can be taken on the receipt of the error message. Christian Maschoff Mark-P53708 wrote: > > Question on Error code 406 - Incorrect identifier: was this error code meant > for Transaction ID errors? > > Also, are there any rules/preferences for where an error code should be > inserted in a reply? Can more than one error code be included? > > Thanks, > > Mark _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Mar 27 22:52: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 WAA03178 for ; Thu, 27 Mar 2003 22:52: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 h2S4DJO19920; Thu, 27 Mar 2003 23:13: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 h2S4BUO19836 for ; Thu, 27 Mar 2003 23:11: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 WAA03099 for ; Thu, 27 Mar 2003 22:49:22 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2S3pbbh028373; Fri, 28 Mar 2003 04:51:37 +0100 (MET) Received: from brsf10.epa.ericsson.se ([146.11.8.4]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id HMMT153T; Fri, 28 Mar 2003 04:51:37 +0100 Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h2S3pXL11114; Fri, 28 Mar 2003 14:51:33 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.201]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HFD4PQZ4; Fri, 28 Mar 2003 14:51:31 +1100 Message-ID: <3E83BEC4.BAFC6C53@ericsson.com.au> Date: Fri, 28 Mar 2003 14:17:24 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ajhingran@hss.hns.com CC: megaco@ietf.org Subject: Re: [Megaco] Audit Descriptor and under/overspecified Descriptor References: <65256CF5.001E0AA8.00@dlfmail1.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 Why are you auditing and modifying in the same command? It seems like a very strange thing to do.... If you've overspecified/underspecified the modify the MG will return the selected properties in its reply. Christian ajhingran@hss.hns.com wrote: > > Hi > > I am repeating the mail sent earlier by me , as there was no reply. > Please help in clarifying the issue. > > I have a query with respect to conflicts between the underspecified > overspecified descriptor processing and audit descriptor processing. > Both of these descriptors in a command request mandate the inclusion > of descriptors in the command reply.Whereas there can be scenarios > when multiple candidate descriptors can occur in the command reply. > > How is the contention resolved? > > I am taking an example of media descriptor. > > e.g. > Assuming an ephemeral termination with the following current state of the > descriptors: > > LocalControl { Mode = Inactive, nt/jit=120 } > Local { > v=0 > c=IN IP4 132.168.200.4 > m=audio 6000 RTP/AVP 4 > } > > Now, a MODIFY command with Audit descriptor and an underspecified/ overspecified > Media > Desc (Local desc) is received. > > Modify = rtp1000 { > Audit { Media }, > Media { Stream = 1 { > LocalControl { Mode = ReceiveOnly, nt/jit=40 }, > Local { > v=0 > c=IN IP4 $ > m=audio $ RTP/AVP 0 8 > }}}} > > Assuming that during the MODIFY command processing, MG selects the following new > values: > IP address - 132.168.200.5 > port number - 7000 > payload type - 8 > > How should the MODIFY command reply look like: > > Option 1 > Old media descriptor is sent. > Modify = rtp1000 { > Media { Stream = 1 { > LocalControl { Mode = Inactive, nt/jit=120 }, > Local { > v=0 > c=IN IP4 132.168.200.4 > m=audio 6000 RTP/AVP 4 > }}}} > But, as per the protocol the underspecified/ overspecified Local descriptor > after resolution in the MG must be returned in the response. > > Option 2 > Old media descriptor with overwritten underspecified/ overspecified Local > descriptor after resolution is sent. > Modify = rtp1000 { > Media { Stream = 1 { > LocalControl { Mode = Inactive, nt/jit=120 }, > Local { > v=0 > c=IN IP4 132.168.200.5 > m=audio 7000 RTP/AVP 8 > }}}} > But, the complete Media descriptor is inconsistent, i.e., Local COntrol is old > but > the Local descriptor is the new one. Although, MGC would know which descriptor > was > underspecified/ overspecfied in the request and can relate. > > Option 3 > New media descriptor is sent. > Modify = rtp1000 { > Media { Stream = 1 { > LocalControl { Mode = ReceiveOnly, nt/jit=40 }, > Local { > v=0 > c=IN IP4 132.168.200.5 > m=audio 7000 RTP/AVP 8 > }}}} > But, as per the protocol the descriptors need to be processed in sequence of > occurance > and therefore, media descriptor should be the old one. > > I am still unclear if the protocol resolves this problem. > Please comment? > > Rgds > > Ashish Jhingran > > _______________________________________________ > 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 Mar 27 22:53: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 WAA03213 for ; Thu, 27 Mar 2003 22:53:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2S4EqE19951 for megaco-archive@odin.ietf.org; Thu, 27 Mar 2003 23:14: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 h2S4EqO19948 for ; Thu, 27 Mar 2003 23:14: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 WAA03195 for ; Thu, 27 Mar 2003 22:52: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 h2S4DDO19896; Thu, 27 Mar 2003 23:13:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S4BLO19831 for ; Thu, 27 Mar 2003 23:11:21 -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 WAA03096 for ; Thu, 27 Mar 2003 22:49:14 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2S3pabh028361; Fri, 28 Mar 2003 04:51:36 +0100 (MET) Received: from brsf10.epa.ericsson.se ([146.11.8.4]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id HK1V4WHJ; Fri, 28 Mar 2003 04:51:36 +0100 Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h2S3pWL11109; Fri, 28 Mar 2003 14:51:32 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.201]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HFD4PQZS; Fri, 28 Mar 2003 14:51:31 +1100 Message-ID: <3E83BDB0.2C8821D1@ericsson.com.au> Date: Fri, 28 Mar 2003 14:12:48 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Maschoff Mark-P53708 CC: megaco@ietf.org Subject: Re: [Megaco] Error Code 406 References: <7FD24C15A06DD511BF9E00D0B73E995207139411@az33exm05.corp.mot.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 Mark, I think you mean error code 410. H.248.8 states: 4.2.6 Error Code #: 410 Name: Incorrect identifier Definition: The transaction request(s) has been disregarded due to a syntax error (illegal length or illegal character) having been found in a mId, transactionId, contextId, terminationId, PropertyId, EventId, SignalId, StatisticsId, ParameterId or requestID. Package: - Reference: No Error Text in the error Descriptor: The concerned ID is included in the error text in the error descriptor. Comment: If the error is detected prior to determining a valid transaction ID, no meaningful action can be taken on the receipt of the error message. Christian Maschoff Mark-P53708 wrote: > > Question on Error code 406 - Incorrect identifier: was this error code meant > for Transaction ID errors? > > Also, are there any rules/preferences for where an error code should be > inserted in a reply? Can more than one error code be included? > > Thanks, > > Mark _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Thu Mar 27 22:53: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 WAA03227 for ; Thu, 27 Mar 2003 22:53:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2S4F1c19978 for megaco-archive@odin.ietf.org; Thu, 27 Mar 2003 23:15: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 h2S4F1O19975 for ; Thu, 27 Mar 2003 23:15: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 WAA03201 for ; Thu, 27 Mar 2003 22:52: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 h2S4DJO19920; Thu, 27 Mar 2003 23:13: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 h2S4BUO19836 for ; Thu, 27 Mar 2003 23:11: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 WAA03099 for ; Thu, 27 Mar 2003 22:49:22 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2S3pbbh028373; Fri, 28 Mar 2003 04:51:37 +0100 (MET) Received: from brsf10.epa.ericsson.se ([146.11.8.4]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id HMMT153T; Fri, 28 Mar 2003 04:51:37 +0100 Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h2S3pXL11114; Fri, 28 Mar 2003 14:51:33 +1100 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.233.201]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HFD4PQZ4; Fri, 28 Mar 2003 14:51:31 +1100 Message-ID: <3E83BEC4.BAFC6C53@ericsson.com.au> Date: Fri, 28 Mar 2003 14:17:24 +1100 From: Christian Groves X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ajhingran@hss.hns.com CC: megaco@ietf.org Subject: Re: [Megaco] Audit Descriptor and under/overspecified Descriptor References: <65256CF5.001E0AA8.00@dlfmail1.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 Why are you auditing and modifying in the same command? It seems like a very strange thing to do.... If you've overspecified/underspecified the modify the MG will return the selected properties in its reply. Christian ajhingran@hss.hns.com wrote: > > Hi > > I am repeating the mail sent earlier by me , as there was no reply. > Please help in clarifying the issue. > > I have a query with respect to conflicts between the underspecified > overspecified descriptor processing and audit descriptor processing. > Both of these descriptors in a command request mandate the inclusion > of descriptors in the command reply.Whereas there can be scenarios > when multiple candidate descriptors can occur in the command reply. > > How is the contention resolved? > > I am taking an example of media descriptor. > > e.g. > Assuming an ephemeral termination with the following current state of the > descriptors: > > LocalControl { Mode = Inactive, nt/jit=120 } > Local { > v=0 > c=IN IP4 132.168.200.4 > m=audio 6000 RTP/AVP 4 > } > > Now, a MODIFY command with Audit descriptor and an underspecified/ overspecified > Media > Desc (Local desc) is received. > > Modify = rtp1000 { > Audit { Media }, > Media { Stream = 1 { > LocalControl { Mode = ReceiveOnly, nt/jit=40 }, > Local { > v=0 > c=IN IP4 $ > m=audio $ RTP/AVP 0 8 > }}}} > > Assuming that during the MODIFY command processing, MG selects the following new > values: > IP address - 132.168.200.5 > port number - 7000 > payload type - 8 > > How should the MODIFY command reply look like: > > Option 1 > Old media descriptor is sent. > Modify = rtp1000 { > Media { Stream = 1 { > LocalControl { Mode = Inactive, nt/jit=120 }, > Local { > v=0 > c=IN IP4 132.168.200.4 > m=audio 6000 RTP/AVP 4 > }}}} > But, as per the protocol the underspecified/ overspecified Local descriptor > after resolution in the MG must be returned in the response. > > Option 2 > Old media descriptor with overwritten underspecified/ overspecified Local > descriptor after resolution is sent. > Modify = rtp1000 { > Media { Stream = 1 { > LocalControl { Mode = Inactive, nt/jit=120 }, > Local { > v=0 > c=IN IP4 132.168.200.5 > m=audio 7000 RTP/AVP 8 > }}}} > But, the complete Media descriptor is inconsistent, i.e., Local COntrol is old > but > the Local descriptor is the new one. Although, MGC would know which descriptor > was > underspecified/ overspecfied in the request and can relate. > > Option 3 > New media descriptor is sent. > Modify = rtp1000 { > Media { Stream = 1 { > LocalControl { Mode = ReceiveOnly, nt/jit=40 }, > Local { > v=0 > c=IN IP4 132.168.200.5 > m=audio 7000 RTP/AVP 8 > }}}} > But, as per the protocol the descriptors need to be processed in sequence of > occurance > and therefore, media descriptor should be the old one. > > I am still unclear if the protocol resolves this problem. > Please comment? > > Rgds > > Ashish Jhingran > > _______________________________________________ > 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 Mar 31 08:21: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 IAA05692 for ; Mon, 31 Mar 2003 08:21: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 h2VDiOO03336; Mon, 31 Mar 2003 08:44: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 h2VDewO03237 for ; Mon, 31 Mar 2003 08:40:58 -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 IAA05629 for ; Mon, 31 Mar 2003 08:17:01 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2VDJDG11937 for ; Mon, 31 Mar 2003 08:19:14 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Mar 2003 08:19:14 -0500 Message-ID: From: "Kevin Boyle" To: ZHAO BO Cc: megaco@ietf.org Date: Mon, 31 Mar 2003 08:19:11 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Megaco] RE: A question about CID pakage Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Instead of using a flag, it is possible to address your concerns by utilizing the signals themselves to handle V5. Because the MG and MGC will know that the subscriber is a V5 agent, it should be fairly easy to get both boxes to work together successfully. Because the MG doesn't know the line state, the data signal (andisp/data) for V5 on-hook data transmission and the dwa signal (andisp/dwa) for V5 off-hook data transmission. For andisp/data, the tas parameter specifies whether a Dual Tone Alerting Signal (DT-AS) shall be applied or not: tas=dt : send DT-AS signal tas=nt : do not send DT-AS signal Note that the dwa signal cannot differentiate. Therefore, the MG signalling would be dependent upon what the MGC sent and the MG would still not have to have knowledge of the line state. For example: andisp/data, tas=nt = line on-hook, data transmission without DT-AS signal sent andisp/data, tas=dt = line on-hook, data transmission utilizing DT-AS signal sent andisp/dwa = line off-hook, data transmission utilizing DT-AS signal is sent Does this solve your problem? Kevin -----Original Message----- From: ZHAO BO [mailto:zbo@huawei.com] Sent: Monday, March 31, 2003 4:43 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: megaco@ietf.org Subject: A question about CID pakage Hi Kevin: In andisp package, the same signal dwa is used for all the types of CID, include normal CID and call waiting ID. It's the responsibility of MGW to decide the CID type and make proper action. My question rises here: For MGW+V5 combination, the MGW may have no way to know the status of a V5 subsriber(onhook, offhook), because the user signalling is transported transparently from AN to MGC via V5UA. As a result, MGW can't dicide the CID type(normal or call waiting). Maybe a flag is still needed in this case? Best regards Zhao Bo Huawei Technologies 2003/03/31 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Mar 31 08:22: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 IAA05718 for ; Mon, 31 Mar 2003 08:22:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VDk8Q03382 for megaco-archive@odin.ietf.org; Mon, 31 Mar 2003 08:46: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 h2VDk8O03379 for ; Mon, 31 Mar 2003 08:46:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05711 for ; Mon, 31 Mar 2003 08:22: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 h2VDiOO03336; Mon, 31 Mar 2003 08:44: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 h2VDewO03237 for ; Mon, 31 Mar 2003 08:40:58 -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 IAA05629 for ; Mon, 31 Mar 2003 08:17:01 -0500 (EST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2VDJDG11937 for ; Mon, 31 Mar 2003 08:19:14 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Mar 2003 08:19:14 -0500 Message-ID: From: "Kevin Boyle" To: ZHAO BO Cc: megaco@ietf.org Date: Mon, 31 Mar 2003 08:19:11 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Megaco] RE: A question about CID pakage Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Instead of using a flag, it is possible to address your concerns by utilizing the signals themselves to handle V5. Because the MG and MGC will know that the subscriber is a V5 agent, it should be fairly easy to get both boxes to work together successfully. Because the MG doesn't know the line state, the data signal (andisp/data) for V5 on-hook data transmission and the dwa signal (andisp/dwa) for V5 off-hook data transmission. For andisp/data, the tas parameter specifies whether a Dual Tone Alerting Signal (DT-AS) shall be applied or not: tas=dt : send DT-AS signal tas=nt : do not send DT-AS signal Note that the dwa signal cannot differentiate. Therefore, the MG signalling would be dependent upon what the MGC sent and the MG would still not have to have knowledge of the line state. For example: andisp/data, tas=nt = line on-hook, data transmission without DT-AS signal sent andisp/data, tas=dt = line on-hook, data transmission utilizing DT-AS signal sent andisp/dwa = line off-hook, data transmission utilizing DT-AS signal is sent Does this solve your problem? Kevin -----Original Message----- From: ZHAO BO [mailto:zbo@huawei.com] Sent: Monday, March 31, 2003 4:43 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: megaco@ietf.org Subject: A question about CID pakage Hi Kevin: In andisp package, the same signal dwa is used for all the types of CID, include normal CID and call waiting ID. It's the responsibility of MGW to decide the CID type and make proper action. My question rises here: For MGW+V5 combination, the MGW may have no way to know the status of a V5 subsriber(onhook, offhook), because the user signalling is transported transparently from AN to MGC via V5UA. As a result, MGW can't dicide the CID type(normal or call waiting). Maybe a flag is still needed in this case? Best regards Zhao Bo Huawei Technologies 2003/03/31 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Mar 31 08:54: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 IAA06500 for ; Mon, 31 Mar 2003 08:54: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 h2VEGIO05354; Mon, 31 Mar 2003 09:16: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 h2VA8EO22643 for ; Mon, 31 Mar 2003 05:08:14 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00377 for ; Mon, 31 Mar 2003 04:44:29 -0500 (EST) Received: from zhaobo (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HCL004NWXK1AC@mta0.huawei.com> for megaco@ietf.org; Mon, 31 Mar 2003 17:40:53 +0800 (CST) Date: Mon, 31 Mar 2003 17:42:48 +0800 From: ZHAO BO To: Kevin Boyle Cc: megaco@ietf.org Message-id: <000501c2f769$e46ef960$ea486e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Megaco] A question about CID pakage Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 Kevin: In andisp package, the same signal dwa is used for all the types of CID, include normal CID and call waiting ID. It's the responsibility of MGW to decide the CID type and make proper action. My question rises here: For MGW+V5 combination, the MGW may have no way to know the status of a V5 subsriber(onhook, offhook), because the user signalling is transported transparently from AN to MGC via V5UA. As a result, MGW can't dicide the CID type(normal or call waiting). Maybe a flag is still needed in this case? Best regards Zhao Bo Huawei Technologies 2003/03/31 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailnull@www1.ietf.org Mon Mar 31 08:55: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 IAA06576 for ; Mon, 31 Mar 2003 08:55:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VEIdM05505 for megaco-archive@odin.ietf.org; Mon, 31 Mar 2003 09:18: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 h2VEIdO05502 for ; Mon, 31 Mar 2003 09:18: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 IAA06531 for ; Mon, 31 Mar 2003 08:54: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 h2VEGIO05354; Mon, 31 Mar 2003 09:16: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 h2VA8EO22643 for ; Mon, 31 Mar 2003 05:08:14 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00377 for ; Mon, 31 Mar 2003 04:44:29 -0500 (EST) Received: from zhaobo (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HCL004NWXK1AC@mta0.huawei.com> for megaco@ietf.org; Mon, 31 Mar 2003 17:40:53 +0800 (CST) Date: Mon, 31 Mar 2003 17:42:48 +0800 From: ZHAO BO To: Kevin Boyle Cc: megaco@ietf.org Message-id: <000501c2f769$e46ef960$ea486e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Megaco] A question about CID pakage Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: 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 Kevin: In andisp package, the same signal dwa is used for all the types of CID, include normal CID and call waiting ID. It's the responsibility of MGW to decide the CID type and make proper action. My question rises here: For MGW+V5 combination, the MGW may have no way to know the status of a V5 subsriber(onhook, offhook), because the user signalling is transported transparently from AN to MGC via V5UA. As a result, MGW can't dicide the CID type(normal or call waiting). Maybe a flag is still needed in this case? Best regards Zhao Bo Huawei Technologies 2003/03/31 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco