From mailman-bounces@ietf.org Fri Oct 1 09:27:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28085 for ; Fri, 1 Oct 2004 09:27:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDK5M-00035J-Mu for megaco-archive@lists.ietf.org; Fri, 01 Oct 2004 05:52:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: megaco-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:20:15 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit 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, mailman-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: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@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-bounces@ietf.org Mon Oct 4 00:28:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01079 for ; Mon, 4 Oct 2004 00:28:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEKM7-0003q4-F4; Mon, 04 Oct 2004 00:21:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEK9W-0000fN-IA for megaco@megatron.ietf.org; Mon, 04 Oct 2004 00:08:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22877 for ; Mon, 4 Oct 2004 00:08:38 -0400 (EDT) Received: from ns2.nec.com.au ([147.76.180.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEKAC-0006qu-9O for megaco@ietf.org; Mon, 04 Oct 2004 00:09:29 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by ns2.nec.com.au (Postfix) with ESMTP id 04D743776F for ; Mon, 4 Oct 2004 13:59:30 +1000 (EST) Received: from ns2.nec.com.au ([127.0.0.1]) by localhost (ns2.nec.com.au [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 00969-01-88 for ; Mon, 4 Oct 2004 13:59:29 +1000 (EST) Received: from smtp2.nec.com.au (smtp2.internal.nec.com.au [172.31.8.19]) by ns2.nec.com.au (Postfix) with ESMTP id E771537754 for ; Mon, 4 Oct 2004 13:59:29 +1000 (EST) Received: from tns.neca.nec.com.au (localhost.localdomain [127.0.0.1]) by smtp2.nec.com.au (8.12.8/8.12.8) with ESMTP id i943xTXt000582 for ; Mon, 4 Oct 2004 13:59:29 +1000 Received: from GWANGXP ([147.76.211.59]) by tns.neca.nec.com.au (8.12.8/8.12.8) with SMTP id i943xTvN030075 for ; Mon, 4 Oct 2004 13:59:29 +1000 From: "Gillian Wang" To: Date: Mon, 4 Oct 2004 13:56:59 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Subject: [Megaco] Text encoding format X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit Dear Megaco members, My questions here are regarding the information provided in Annex B and Annex C of the H.248.1 v2 standard. In H.248.1 Annex B.2, text encoding format is specified. There is another hexadicimal octet coding specified in B.3. Can you please advise where this hexadecimal octet coding should be used for the megaco message structure? Are the attributes defined in Annex C for binary encoding only? if yes, how to set these attributes for the text encoding? like Gain, jitterbuff, Silencesupp or encrptkey, etc. If not, can we use the PropertyID and values for the text encoding? Thanks for the clarification. Regards Gillian _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Oct 4 02:46:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03559 for ; Mon, 4 Oct 2004 02:46:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEMTX-0001WO-7I; Mon, 04 Oct 2004 02:37:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEMQo-00013N-QU for megaco@megatron.ietf.org; Mon, 04 Oct 2004 02:34:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02227 for ; Mon, 4 Oct 2004 02:34:44 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEMZg-0003N8-2s for megaco@ietf.org; Mon, 04 Oct 2004 02:44:06 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i946YYRU003793 for ; Mon, 4 Oct 2004 08:34:34 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 4 Oct 2004 08:34:34 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id T8W0TGNL; Mon, 4 Oct 2004 08:34:31 +0200 Received: from ericsson.com (EG2E500202DSEGL [146.11.22.10]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id TTNNJS7J; Mon, 4 Oct 2004 16:34:28 +1000 Message-ID: <4160EF86.5090909@ericsson.com> Date: Mon, 04 Oct 2004 16:36:54 +1000 X-Sybari-Trust: 4aa9efde 74898554 be1a151b 00000139 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: Gillian Wang Subject: Re: [Megaco] Text encoding format References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 04 Oct 2004 06:34:34.0557 (UTC) FILETIME=[368176D0:01C4A9DC] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by eagle.ericsson.se id i946YYRU003793 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: quoted-printable G'Day Gillian, The hexadecimal format should be used whereever Octet String encoding is=20 defined. See H.248.1 sect 12.2, "Octet String: A number of octets. See An= nex A=20 and B.3 for encoding" In H.248.1v3 we clarified the use of Annex C to be: "The referencing of Annex C properties follows the PackageID/PropertyID=20 structure; however Annex C is not in itself a package. Annex C is conside= red to=20 have PackageID 0x0000 for binary encoding and =93anxc=94 for text encodin= g. For text=20 encoding of H.248.1, Annex C shall only be used in the case that the requ= ired=20 property is not already defined by a package or represented by SDP. The n= esting=20 of one Annex C property inside another is forbidden." Regards, Christian Gillian Wang wrote: > Dear Megaco members, >=20 > My questions here are regarding the information provided in Annex B and > Annex C of the H.248.1 v2 standard. >=20 > In H.248.1 Annex B.2, text encoding format is specified. There is anoth= er > hexadicimal octet coding specified in B.3. Can you please advise where = this > hexadecimal octet coding should be used for the megaco message structur= e? >=20 > Are the attributes defined in Annex C for binary encoding only? if yes,= how > to set these attributes for the text encoding? like Gain, jitterbuff, > Silencesupp or encrptkey, etc. If not, can we use the PropertyID and va= lues > for the text encoding? >=20 > Thanks for the clarification. >=20 > Regards > Gillian >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Oct 4 04:06:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09483 for ; Mon, 4 Oct 2004 04:06:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CENfi-0003Z9-Lf; Mon, 04 Oct 2004 03:54:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CENa3-0002az-49 for megaco@megatron.ietf.org; Mon, 04 Oct 2004 03:48:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07998 for ; Mon, 4 Oct 2004 03:48:20 -0400 (EDT) Received: from ns2.nec.com.au ([147.76.180.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CENj4-0000Hz-3s for megaco@ietf.org; Mon, 04 Oct 2004 03:57:43 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by ns2.nec.com.au (Postfix) with ESMTP id D267137754; Mon, 4 Oct 2004 17:47:48 +1000 (EST) Received: from ns2.nec.com.au ([127.0.0.1]) by localhost (ns2.nec.com.au [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01408-01-26; Mon, 4 Oct 2004 17:47:48 +1000 (EST) Received: from smtp2.nec.com.au (smtp2.internal.nec.com.au [172.31.8.19]) by ns2.nec.com.au (Postfix) with ESMTP id BFA843774F; Mon, 4 Oct 2004 17:47:48 +1000 (EST) Received: from tns.neca.nec.com.au (localhost.localdomain [127.0.0.1]) by smtp2.nec.com.au (8.12.8/8.12.8) with ESMTP id i947lmKN005212; Mon, 4 Oct 2004 17:47:48 +1000 Received: from GWANGXP ([147.76.211.59]) by tns.neca.nec.com.au (8.12.8/8.12.8) with SMTP id i947llvN008009; Mon, 4 Oct 2004 17:47:47 +1000 From: "Gillian Wang" To: "Christian Groves" Date: Mon, 4 Oct 2004 17:45:18 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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.1441 Importance: Normal In-Reply-To: <4160EF86.5090909@ericsson.com> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Cc: "Megaco@Ietf. Org" Subject: [Megaco] definition on parameter and property X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Christian, thanks for the clarification. For the second question, based on my understanding of the Megaco protocol= , properties are related to the packages; parameters are grouped into descriptors. In that case, I thought that the Annex C might specify the parameters which belonged to different descriptors, although some not to existing descriptors. However, your answer provides a different implementation approach of these parameters/properties. Thanks for that! = By the way, are there any clear definitions on parameters and properties fro= m implementation's point of view? Regards Gillian -----Original Message----- From: Christian Groves [mailto:christian.groves@ericsson.com] Sent: Monday, 4 October 2004 4:37 PM To: Gillian Wang Cc: megaco@ietf.org Subject: Re: [Megaco] Text encoding format G'Day Gillian, The hexadecimal format should be used whereever Octet String encoding is defined. See H.248.1 sect 12.2, "Octet String: A number of octets. See An= nex A and B.3 for encoding" In H.248.1v3 we clarified the use of Annex C to be: "The referencing of Annex C properties follows the PackageID/PropertyID structure; however Annex C is not in itself a package. Annex C is conside= red to have PackageID 0x0000 for binary encoding and =93anxc=94 for text encodin= g. For text encoding of H.248.1, Annex C shall only be used in the case that the required property is not already defined by a package or represented by SDP. The nesting of one Annex C property inside another is forbidden." Regards, Christian Gillian Wang wrote: > Dear Megaco members, > > My questions here are regarding the information provided in Annex B and > Annex C of the H.248.1 v2 standard. > > In H.248.1 Annex B.2, text encoding format is specified. There is anoth= er > hexadicimal octet coding specified in B.3. Can you please advise where this > hexadecimal octet coding should be used for the megaco message structur= e? > > Are the attributes defined in Annex C for binary encoding only? if yes, how > to set these attributes for the text encoding? like Gain, jitterbuff, > Silencesupp or encrptkey, etc. If not, can we use the PropertyID and values > for the text encoding? > > Thanks for the clarification. > > Regards > Gillian > > > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Oct 4 10:24:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09041 for ; Mon, 4 Oct 2004 10:24:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CETi0-0000zI-1z; Mon, 04 Oct 2004 10:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CETZv-0007Ph-9E for megaco@megatron.ietf.org; Mon, 04 Oct 2004 10:12:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07684 for ; Mon, 4 Oct 2004 10:12:36 -0400 (EDT) Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CETiq-0008Do-G6 for megaco@ietf.org; Mon, 04 Oct 2004 10:22:03 -0400 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.ccpu.com (Postfix) with ESMTP id BB6463468EA for ; Mon, 4 Oct 2004 07:11:54 -0700 (PDT) Received: from smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (VaMailArmor-2.0.1.16) id 21819-217AA83F; Mon, 04 Oct 2004 07:10:33 -0700 Received: from CCIN00339 (unknown [172.25.0.53]) by smtp.ccpu.com (Postfix) with ESMTP id DF51C346904 for ; Mon, 4 Oct 2004 07:10:23 -0700 (PDT) From: "Karthikeyan S" To: Date: Mon, 4 Oct 2004 19:40:22 +0530 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSVc6lqDrNnmVAVT3mzfnt864zCAwUpviFg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20041004141025.DF51C346904@smtp.ccpu.com> X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.27.0.12; VDF: 6.27.0.85; host: smtp) X-Spam-Score: 0.2 (/) X-Scan-Signature: 8ba8529e77affe49b0f315db98a262ee Subject: [Megaco] RE: Generating error responses X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1442659371==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1442659371== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C4AA49.FFD748D0" This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C4AA49.FFD748D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit HI, Can somebody clarify on the following? If one transaction has three actions, and the application has generated response for commands in the first action but not generated response for the second action [PendingLimit crossed], how should the Megaco layer compose the transaction response? Following are the solutions I can think of: i) Compose transaction response with the commands for the first action and the rest of the transaction with action error replies. ii) Compose transaction response with the commands for the first action and the rest of the transaction with command error replies for the remaining two actions iii) Compose the transaction with error code on the transaction itself saying PendingLimit crossed. If these solutions are invalid request to kindly propose me some valid solution. I would greatly appreciate if anybody could help me on these. Thanks in advance Karthik _____ From: Karthikeyan S [mailto:karthiks@ccpu.com] Sent: Wednesday, September 08, 2004 12:46 PM To: 'megaco@ietf.org' Subject: Generating error responses HI, Can any of you could clarify the following issues: i) If the application has not generated response for one command, can the Megaco stack generate error responses for the other subsequent commands? As per section 8 it says it should not be done. ii) If there are two incoming actions in a transaction which has wild carded termination commands. If the application has not properly responded for the first action with all the responses, a. Does the first action needs to be responded with wild carded response or b. It shall contain the responses which was received previously and followed by an error response. c. Can the stack generate error response for the second action? iii) What if the first action assumed in ii) is an optional action. I would greatly appreciate if any of you replies for this query. Thanks Karthik ------=_NextPart_000_0020_01C4AA49.FFD748D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

HI,

 

Can somebody clarify on the = following?

 

If one transaction has three = actions, and the application has generated response for commands in the first action = but not generated response for the second action [PendingLimit crossed], how = should the Megaco layer compose the transaction = response?

 

Following are the solutions I can = think of:

i)           = ;          Compose transaction response with the commands for the first action and the rest = of the transaction with action error replies.

ii)           = ;        Compose transaction response with the commands for the first action and the rest = of the transaction with command error replies for the remaining two = actions

iii)           = ;       Compose the transaction with error code on the transaction itself saying = PendingLimit crossed.

 

If these solutions are invalid = request to kindly propose me some valid solution. I would greatly appreciate if = anybody could help me on these.

 

Thanks in = advance

Karthik

=

 

 

From: = Karthikeyan S [mailto:karthiks@ccpu.com]
Sent: Wednesday, = September 08, 2004 12:46 PM
To: 'megaco@ietf.org'
Subject: Generating error responses

 

HI,

 

Can any of you could clarify the following = issues:

 

i)           = ;          If the application has not = generated response for one command, can the Megaco stack generate error responses = for the other subsequent commands? As per section 8 it says it should not be = done.

ii)           = ;        If there are two incoming = actions in a transaction which has wild carded termination commands. If the = application has not properly responded for the first action with all the responses, =

a.       = Does the first action needs to be responded with wild carded response = or

b.       = It shall contain the responses which was received previously and followed by an = error response.

c.       = Can the stack generate error response for the second = action?

iii)           = ;       What if the first action = assumed in ii) is an optional action.

 

I would greatly appreciate if any of you replies for = this query.

 

Thanks

Karthik

 

 

 

------=_NextPart_000_0020_01C4AA49.FFD748D0-- --===============1442659371== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1442659371==-- From megaco-bounces@ietf.org Mon Oct 4 10:33:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09920 for ; Mon, 4 Oct 2004 10:33:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CETjs-0001Rh-EY; Mon, 04 Oct 2004 10:22:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CETfi-0000KP-MT for megaco@megatron.ietf.org; Mon, 04 Oct 2004 10:18:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08347 for ; Mon, 4 Oct 2004 10:18:36 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEToo-00012V-CW for megaco@ietf.org; Mon, 04 Oct 2004 10:28:02 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i94EI5C24399 for ; Mon, 4 Oct 2004 10:18:05 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Oct 2004 10:18:04 -0400 Message-ID: <1E7140413C19AD4E827D63B820A24D2B01E21A95@zrtphxm2> From: "Kevin Boyle" To: Gillian Wang , Christian Groves Subject: RE: [Megaco] definition on parameter and property Date: Mon, 4 Oct 2004 10:17:51 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: "Megaco@Ietf. Org" X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Some of the parameters you specifically mention (gain, jitterbuf) are handled via packages defined in H.248.1 Annex E. The others you mention (silence suppression, encryption) have SDP attributes already defined. You will have to do some research on what is defined and applicable for your implementation. Note that most packages defined for H.248 are in the H.248 subseries, with several in Q.1950. Kevin -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Gillian Wang Sent: Monday, October 04, 2004 3:45 AM To: Christian Groves Cc: Megaco@Ietf. Org Subject: [Megaco] definition on parameter and property Christian, thanks for the clarification. For the second question, based on my understanding of the Megaco protocol, properties are related to the packages; parameters are grouped into descriptors. In that case, I thought that the Annex C might specify the parameters which belonged to different descriptors, although some not to existing descriptors. However, your answer provides a different implementation approach of these parameters/properties. Thanks for that! By the way, are there any clear definitions on parameters and properties from implementation's point of view? Regards Gillian -----Original Message----- From: Christian Groves [mailto:christian.groves@ericsson.com] Sent: Monday, 4 October 2004 4:37 PM To: Gillian Wang Cc: megaco@ietf.org Subject: Re: [Megaco] Text encoding format G'Day Gillian, The hexadecimal format should be used whereever Octet String encoding is defined. See H.248.1 sect 12.2, "Octet String: A number of octets. See Annex A and B.3 for encoding" In H.248.1v3 we clarified the use of Annex C to be: "The referencing of Annex C properties follows the PackageID/PropertyID structure; however Annex C is not in itself a package. Annex C is considered to have PackageID 0x0000 for binary encoding and "anxc" for text encoding. For text encoding of H.248.1, Annex C shall only be used in the case that the required property is not already defined by a package or represented by SDP. The nesting of one Annex C property inside another is forbidden." Regards, Christian Gillian Wang wrote: > Dear Megaco members, > > My questions here are regarding the information provided in Annex B > and Annex C of the H.248.1 v2 standard. > > In H.248.1 Annex B.2, text encoding format is specified. There is > another hexadicimal octet coding specified in B.3. Can you please > advise where this > hexadecimal octet coding should be used for the megaco message structure? > > Are the attributes defined in Annex C for binary encoding only? if > yes, how > to set these attributes for the text encoding? like Gain, jitterbuff, > Silencesupp or encrptkey, etc. If not, can we use the PropertyID and values > for the text encoding? > > Thanks for the clarification. > > Regards > Gillian > > > > > > _______________________________________________ > Megaco mailing 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-bounces@ietf.org Mon Oct 4 10:56:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11784 for ; Mon, 4 Oct 2004 10:56:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEUBw-0006FR-WA; Mon, 04 Oct 2004 10:51:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEU4u-0005jf-VW for megaco@megatron.ietf.org; Mon, 04 Oct 2004 10:44:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10477 for ; Mon, 4 Oct 2004 10:44:38 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEUE0-0004jh-Q8 for megaco@ietf.org; Mon, 04 Oct 2004 10:54:05 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i94Ei7m13655 for ; Mon, 4 Oct 2004 10:44:08 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Oct 2004 10:44:07 -0400 Message-ID: <1E7140413C19AD4E827D63B820A24D2B01E21B70@zrtphxm2> From: "Kevin Boyle" To: Karthikeyan S , megaco@ietf.org Subject: RE: [Megaco] RE: Generating error responses Date: Mon, 4 Oct 2004 10:43:59 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Replies are built per command in order. So, this means that the MG should build the responses for the executed commands, and then add Error 533 at the point of failure and halt. Unless the failed commands have the Optional flag on them, there should be never be more than one error in a reply. Kevin _____ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Karthikeyan S Sent: Monday, October 04, 2004 10:10 AM To: megaco@ietf.org Subject: [Megaco] RE: Generating error responses HI, Can somebody clarify on the following? If one transaction has three actions, and the application has generated response for commands in the first action but not generated response for the second action [PendingLimit crossed], how should the Megaco layer compose the transaction response? Following are the solutions I can think of: i) Compose transaction response with the commands for the first action and the rest of the transaction with action error replies. ii) Compose transaction response with the commands for the first action and the rest of the transaction with command error replies for the remaining two actions iii) Compose the transaction with error code on the transaction itself saying PendingLimit crossed. If these solutions are invalid request to kindly propose me some valid solution. I would greatly appreciate if anybody could help me on these. Thanks in advance Karthik _____ From: Karthikeyan S [mailto:karthiks@ccpu.com] Sent: Wednesday, September 08, 2004 12:46 PM To: 'megaco@ietf.org' Subject: Generating error responses HI, Can any of you could clarify the following issues: i) If the application has not generated response for one command, can the Megaco stack generate error responses for the other subsequent commands? As per section 8 it says it should not be done. ii) If there are two incoming actions in a transaction which has wild carded termination commands. If the application has not properly responded for the first action with all the responses, a. Does the first action needs to be responded with wild carded response or b. It shall contain the responses which was received previously and followed by an error response. c. Can the stack generate error response for the second action? iii) What if the first action assumed in ii) is an optional action. I would greatly appreciate if any of you replies for this query. Thanks Karthik _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Oct 4 19:44:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08111 for ; Mon, 4 Oct 2004 19:44:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEcLr-0002H1-S2; Mon, 04 Oct 2004 19:34:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEcFo-0001XS-T6 for megaco@megatron.ietf.org; Mon, 04 Oct 2004 19:28:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07326 for ; Mon, 4 Oct 2004 19:28:25 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEcOw-0008TG-VN for megaco@ietf.org; Mon, 04 Oct 2004 19:37:58 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i94NSOWR004599 for ; Tue, 5 Oct 2004 01:28:24 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 5 Oct 2004 01:28:27 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id TPBK2XLF; Tue, 5 Oct 2004 01:28:23 +0200 Received: from ericsson.com (EG2E500202DSEGL [146.11.22.8]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id TTNNKBGG; Tue, 5 Oct 2004 09:28:08 +1000 Message-ID: <4161DD1D.2050405@ericsson.com> Date: Tue, 05 Oct 2004 09:30:37 +1000 X-Sybari-Trust: f9558121 74898554 06a6727e 00000139 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: Gillian Wang Subject: Re: [Megaco] definition on parameter and property References: <1E7140413C19AD4E827D63B820A24D2B01E21A95@zrtphxm2> In-Reply-To: <1E7140413C19AD4E827D63B820A24D2B01E21A95@zrtphxm2> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2004 23:28:27.0114 (UTC) FILETIME=[D98904A0:01C4AA69] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit Cc: "Megaco@Ietf. Org" , Kevin Boyle X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit G'Day Gillian, Properties belong to descriptors (local, remote, local control, term state) Parameters belong to signals and events. Annex C describes properties (unfortunately it uses the word 'parameter' occasionally in the text). Regards, Christian Kevin Boyle wrote: > Some of the parameters you specifically mention (gain, jitterbuf) are > handled via packages defined in H.248.1 Annex E. The others you mention > (silence suppression, encryption) have SDP attributes already defined. > > You will have to do some research on what is defined and applicable for > your implementation. Note that most packages defined for H.248 are in > the H.248 subseries, with several in Q.1950. > > Kevin > > -----Original Message----- > From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf > Of Gillian Wang > Sent: Monday, October 04, 2004 3:45 AM > To: Christian Groves > Cc: Megaco@Ietf. Org > Subject: [Megaco] definition on parameter and property > > Christian, thanks for the clarification. > > For the second question, based on my understanding of the Megaco > protocol, properties are related to the packages; parameters are grouped > into descriptors. In that case, I thought that the Annex C might specify > the parameters which belonged to different descriptors, although some > not to existing descriptors. However, your answer provides a different > implementation approach of these parameters/properties. Thanks for that! > By the way, are there any clear definitions on parameters and properties > from implementation's point of view? > > Regards > Gillian > > > > -----Original Message----- > From: Christian Groves [mailto:christian.groves@ericsson.com] > Sent: Monday, 4 October 2004 4:37 PM > To: Gillian Wang > Cc: megaco@ietf.org > Subject: Re: [Megaco] Text encoding format > > > G'Day Gillian, > > The hexadecimal format should be used whereever Octet String encoding is > defined. See H.248.1 sect 12.2, "Octet String: A number of octets. See > Annex A and B.3 for encoding" > > In H.248.1v3 we clarified the use of Annex C to be: > "The referencing of Annex C properties follows the PackageID/PropertyID > structure; however Annex C is not in itself a package. Annex C is > considered to have PackageID 0x0000 for binary encoding and "anxc" for > text encoding. For text encoding of H.248.1, Annex C shall only be used > in the case that the required property is not already defined by a > package or represented by SDP. The nesting of one Annex C property > inside another is forbidden." > > Regards, Christian > > Gillian Wang wrote: > > > Dear Megaco members, > > > > My questions here are regarding the information provided in Annex B > > and Annex C of the H.248.1 v2 standard. > > > > In H.248.1 Annex B.2, text encoding format is specified. There is > > another hexadicimal octet coding specified in B.3. Can you please > > advise where > this > > hexadecimal octet coding should be used for the megaco message > structure? > > > > Are the attributes defined in Annex C for binary encoding only? if > > yes, > how > > to set these attributes for the text encoding? like Gain, jitterbuff, > > Silencesupp or encrptkey, etc. If not, can we use the PropertyID and > values > > for the text encoding? > > > > Thanks for the clarification. > > > > Regards > > Gillian > > > > > > > > > > > > _______________________________________________ > > Megaco mailing 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-bounces@ietf.org Tue Oct 5 02:50:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24786 for ; Tue, 5 Oct 2004 02:50:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEj5O-00042L-0n; Tue, 05 Oct 2004 02:46:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEj4q-0003tp-Vk for megaco@megatron.ietf.org; Tue, 05 Oct 2004 02:45:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24320 for ; Tue, 5 Oct 2004 02:45:35 -0400 (EDT) Received: from ns2.nec.com.au ([147.76.180.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEjE4-0000CP-F2 for megaco@ietf.org; Tue, 05 Oct 2004 02:55:09 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by ns2.nec.com.au (Postfix) with ESMTP id 4F08737779; Tue, 5 Oct 2004 16:45:01 +1000 (EST) Received: from ns2.nec.com.au ([127.0.0.1]) by localhost (ns2.nec.com.au [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 04263-01-12; Tue, 5 Oct 2004 16:45:01 +1000 (EST) Received: from smtp2.nec.com.au (smtp2.internal.nec.com.au [172.31.8.19]) by ns2.nec.com.au (Postfix) with ESMTP id 30AC837778; Tue, 5 Oct 2004 16:45:01 +1000 (EST) Received: from tns.neca.nec.com.au (localhost.localdomain [127.0.0.1]) by smtp2.nec.com.au (8.12.8/8.12.8) with ESMTP id i956j0FF024920; Tue, 5 Oct 2004 16:45:00 +1000 Received: from GWANGXP ([147.76.211.59]) by tns.neca.nec.com.au (8.12.8/8.12.8) with SMTP id i956j0vN015488; Tue, 5 Oct 2004 16:45:00 +1000 From: "Gillian Wang" To: "Christian Groves" Subject: RE: [Megaco] definition on parameter and property Date: Tue, 5 Oct 2004 16:42:29 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: <4161DD1D.2050405@ericsson.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: 7bit Cc: "Megaco@Ietf. Org" , Kevin Boyle X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Christian, Do you mean that properties and parameters are same, all belonging to descriptors, depending on what kind of descriptors they belong, they are referred as different name? As in section 7.1 of H.248.1, "The parameters to a command are termed Descriptors", I got confused. Regards Gillian -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org]On Behalf Of Christian Groves Sent: Tuesday, 5 October 2004 9:31 AM To: Gillian Wang Cc: Megaco@Ietf. Org; Kevin Boyle Subject: Re: [Megaco] definition on parameter and property G'Day Gillian, Properties belong to descriptors (local, remote, local control, term state) Parameters belong to signals and events. Annex C describes properties (unfortunately it uses the word 'parameter' occasionally in the text). Regards, Christian Kevin Boyle wrote: > Some of the parameters you specifically mention (gain, jitterbuf) are > handled via packages defined in H.248.1 Annex E. The others you mention > (silence suppression, encryption) have SDP attributes already defined. > > You will have to do some research on what is defined and applicable for > your implementation. Note that most packages defined for H.248 are in > the H.248 subseries, with several in Q.1950. > > Kevin > > -----Original Message----- > From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf > Of Gillian Wang > Sent: Monday, October 04, 2004 3:45 AM > To: Christian Groves > Cc: Megaco@Ietf. Org > Subject: [Megaco] definition on parameter and property > > Christian, thanks for the clarification. > > For the second question, based on my understanding of the Megaco > protocol, properties are related to the packages; parameters are grouped > into descriptors. In that case, I thought that the Annex C might specify > the parameters which belonged to different descriptors, although some > not to existing descriptors. However, your answer provides a different > implementation approach of these parameters/properties. Thanks for that! > By the way, are there any clear definitions on parameters and properties > from implementation's point of view? > > Regards > Gillian > > > > -----Original Message----- > From: Christian Groves [mailto:christian.groves@ericsson.com] > Sent: Monday, 4 October 2004 4:37 PM > To: Gillian Wang > Cc: megaco@ietf.org > Subject: Re: [Megaco] Text encoding format > > > G'Day Gillian, > > The hexadecimal format should be used whereever Octet String encoding is > defined. See H.248.1 sect 12.2, "Octet String: A number of octets. See > Annex A and B.3 for encoding" > > In H.248.1v3 we clarified the use of Annex C to be: > "The referencing of Annex C properties follows the PackageID/PropertyID > structure; however Annex C is not in itself a package. Annex C is > considered to have PackageID 0x0000 for binary encoding and "anxc" for > text encoding. For text encoding of H.248.1, Annex C shall only be used > in the case that the required property is not already defined by a > package or represented by SDP. The nesting of one Annex C property > inside another is forbidden." > > Regards, Christian > > Gillian Wang wrote: > > > Dear Megaco members, > > > > My questions here are regarding the information provided in Annex B > > and Annex C of the H.248.1 v2 standard. > > > > In H.248.1 Annex B.2, text encoding format is specified. There is > > another hexadicimal octet coding specified in B.3. Can you please > > advise where > this > > hexadecimal octet coding should be used for the megaco message > structure? > > > > Are the attributes defined in Annex C for binary encoding only? if > > yes, > how > > to set these attributes for the text encoding? like Gain, jitterbuff, > > Silencesupp or encrptkey, etc. If not, can we use the PropertyID and > values > > for the text encoding? > > > > Thanks for the clarification. > > > > Regards > > Gillian > > > > > > > > > > > > _______________________________________________ > > Megaco mailing 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-bounces@ietf.org Tue Oct 5 03:17:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27646 for ; Tue, 5 Oct 2004 03:17:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEjRD-0007s9-40; Tue, 05 Oct 2004 03:08:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEjJq-0006aM-3Z for megaco@megatron.ietf.org; Tue, 05 Oct 2004 03:01:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25727 for ; Tue, 5 Oct 2004 03:01:04 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEjSu-0002wN-LW for megaco@ietf.org; Tue, 05 Oct 2004 03:10:39 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9570sfM011371 for ; Tue, 5 Oct 2004 09:00:54 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 5 Oct 2004 09:00:54 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id TNGNAJWV; Tue, 5 Oct 2004 09:00:53 +0200 Received: from ericsson.com (EG2E500202DSEGL [146.11.22.60]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id TTNNKKC3; Tue, 5 Oct 2004 17:00:46 +1000 Message-ID: <41624732.8090806@ericsson.com> Date: Tue, 05 Oct 2004 17:03:14 +1000 X-Sybari-Trust: 1dcfc93e 74898554 06a6727e 00000139 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: Gillian Wang Subject: Re: [Megaco] definition on parameter and property References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2004 07:00:54.0071 (UTC) FILETIME=[0E61EC70:01C4AAA9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: 7bit Cc: "Megaco@Ietf. Org" , Kevin Boyle X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello Gillian, I like to think "Properties of a termination or stream, parameters of an event or signal". Unfortunately the use of "parameter" is a little loose in the specification. This is a little bit acedemic as packages describe where the parameter or property live. Christian Gillian Wang wrote: > Hi Christian, > > Do you mean that properties and parameters are same, all belonging to > descriptors, depending on what kind of descriptors they belong, they are > referred as different name? > > As in section 7.1 of H.248.1, "The parameters to a command are termed > Descriptors", I got confused. > > Regards > Gillian > > > > -----Original Message----- > From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org]On Behalf > Of Christian Groves > Sent: Tuesday, 5 October 2004 9:31 AM > To: Gillian Wang > Cc: Megaco@Ietf. Org; Kevin Boyle > Subject: Re: [Megaco] definition on parameter and property > > > G'Day Gillian, > > Properties belong to descriptors (local, remote, local control, term state) > Parameters belong to signals and events. > > Annex C describes properties (unfortunately it uses the word 'parameter' > occasionally in the text). > > Regards, Christian > > Kevin Boyle wrote: > > >>Some of the parameters you specifically mention (gain, jitterbuf) are >>handled via packages defined in H.248.1 Annex E. The others you mention >>(silence suppression, encryption) have SDP attributes already defined. >> >>You will have to do some research on what is defined and applicable for >>your implementation. Note that most packages defined for H.248 are in >>the H.248 subseries, with several in Q.1950. >> >>Kevin >> >>-----Original Message----- >>From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf >>Of Gillian Wang >>Sent: Monday, October 04, 2004 3:45 AM >>To: Christian Groves >>Cc: Megaco@Ietf. Org >>Subject: [Megaco] definition on parameter and property >> >>Christian, thanks for the clarification. >> >>For the second question, based on my understanding of the Megaco >>protocol, properties are related to the packages; parameters are grouped >>into descriptors. In that case, I thought that the Annex C might specify >>the parameters which belonged to different descriptors, although some >>not to existing descriptors. However, your answer provides a different >>implementation approach of these parameters/properties. Thanks for that! >>By the way, are there any clear definitions on parameters and properties >>from implementation's point of view? >> >>Regards >>Gillian >> >> >> >>-----Original Message----- >>From: Christian Groves [mailto:christian.groves@ericsson.com] >>Sent: Monday, 4 October 2004 4:37 PM >>To: Gillian Wang >>Cc: megaco@ietf.org >>Subject: Re: [Megaco] Text encoding format >> >> >>G'Day Gillian, >> >>The hexadecimal format should be used whereever Octet String encoding is >>defined. See H.248.1 sect 12.2, "Octet String: A number of octets. See >>Annex A and B.3 for encoding" >> >>In H.248.1v3 we clarified the use of Annex C to be: >>"The referencing of Annex C properties follows the PackageID/PropertyID >>structure; however Annex C is not in itself a package. Annex C is >>considered to have PackageID 0x0000 for binary encoding and "anxc" for >>text encoding. For text encoding of H.248.1, Annex C shall only be used >>in the case that the required property is not already defined by a >>package or represented by SDP. The nesting of one Annex C property >>inside another is forbidden." >> >>Regards, Christian >> >>Gillian Wang wrote: >> >> > Dear Megaco members, >> > >> > My questions here are regarding the information provided in Annex B >> > and Annex C of the H.248.1 v2 standard. >> > >> > In H.248.1 Annex B.2, text encoding format is specified. There is >> > another hexadicimal octet coding specified in B.3. Can you please >> > advise where >>this >> > hexadecimal octet coding should be used for the megaco message >>structure? >> > >> > Are the attributes defined in Annex C for binary encoding only? if >> > yes, >>how >> > to set these attributes for the text encoding? like Gain, jitterbuff, >> > Silencesupp or encrptkey, etc. If not, can we use the PropertyID and >>values >> > for the text encoding? >> > >> > Thanks for the clarification. >> > >> > Regards >> > Gillian >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Megaco mailing 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-bounces@ietf.org Tue Oct 5 07:41:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17779 for ; Tue, 5 Oct 2004 07:41:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEnes-00037M-4m; Tue, 05 Oct 2004 07:39:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEnbC-0002s6-4A for megaco@megatron.ietf.org; Tue, 05 Oct 2004 07:35:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17459 for ; Tue, 5 Oct 2004 07:35:17 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEnkT-0002Xs-4m for megaco@ietf.org; Tue, 05 Oct 2004 07:44:53 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i95BYjI28496 for ; Tue, 5 Oct 2004 07:34:45 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Oct 2004 07:34:46 -0400 Message-ID: <1E7140413C19AD4E827D63B820A24D2B01EC9151@zrtphxm2> From: "Kevin Boyle" To: megaco@ietf.org Subject: RE: [Megaco] RE: Generating error responses Date: Tue, 5 Oct 2004 07:34:34 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Err... 506, not 533. 533 is message too long for MTU size. Kevin -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Boyle, Kevin [NCRTP:3Z40:EXCH] Sent: Monday, October 04, 2004 10:44 AM To: Karthikeyan S; megaco@ietf.org Subject: RE: [Megaco] RE: Generating error responses Replies are built per command in order. So, this means that the MG should build the responses for the executed commands, and then add Error 533 at the point of failure and halt. Unless the failed commands have the Optional flag on them, there should be never be more than one error in a reply. Kevin _____ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Karthikeyan S Sent: Monday, October 04, 2004 10:10 AM To: megaco@ietf.org Subject: [Megaco] RE: Generating error responses HI, Can somebody clarify on the following? If one transaction has three actions, and the application has generated response for commands in the first action but not generated response for the second action [PendingLimit crossed], how should the Megaco layer compose the transaction response? Following are the solutions I can think of: i) Compose transaction response with the commands for the first action and the rest of the transaction with action error replies. ii) Compose transaction response with the commands for the first action and the rest of the transaction with command error replies for the remaining two actions iii) Compose the transaction with error code on the transaction itself saying PendingLimit crossed. If these solutions are invalid request to kindly propose me some valid solution. I would greatly appreciate if anybody could help me on these. Thanks in advance Karthik _____ From: Karthikeyan S [mailto:karthiks@ccpu.com] Sent: Wednesday, September 08, 2004 12:46 PM To: 'megaco@ietf.org' Subject: Generating error responses HI, Can any of you could clarify the following issues: i) If the application has not generated response for one command, can the Megaco stack generate error responses for the other subsequent commands? As per section 8 it says it should not be done. ii) If there are two incoming actions in a transaction which has wild carded termination commands. If the application has not properly responded for the first action with all the responses, a. Does the first action needs to be responded with wild carded response or b. It shall contain the responses which was received previously and followed by an error response. c. Can the stack generate error response for the second action? iii) What if the first action assumed in ii) is an optional action. I would greatly appreciate if any of you replies for this query. Thanks Karthik _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Wed Oct 6 06:23:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09248 for ; Wed, 6 Oct 2004 06:23:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF8rn-0005IN-FB; Wed, 06 Oct 2004 06:17:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF8rR-000563-UX for megaco@megatron.ietf.org; Wed, 06 Oct 2004 06:17:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09061 for ; Wed, 6 Oct 2004 06:17:26 -0400 (EDT) Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF90l-0006d3-BI for megaco@ietf.org; Wed, 06 Oct 2004 06:27:17 -0400 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.ccpu.com (Postfix) with ESMTP id 713F3346906 for ; Wed, 6 Oct 2004 03:16:43 -0700 (PDT) Received: from smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (VaMailArmor-2.0.1.16) id 20205-4F09A017; Wed, 06 Oct 2004 03:15:37 -0700 Received: from ccpu00179 (unknown [172.25.0.135]) by smtp.ccpu.com (Postfix) with SMTP id 671EA34693A for ; Wed, 6 Oct 2004 03:15:36 -0700 (PDT) Message-ID: <001d01c4abf6$710da280$870019ac@ccpu00179> From: "Geetha" To: Date: Wed, 6 Oct 2004 15:47:19 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4942.400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.28.0.3; VDF: 6.28.0.4; host: smtp) X-Spam-Score: 2.4 (++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Megaco] Re: RTCP XR X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1784147932==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1784147932== Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C4ABBB.C30168A0" This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C4ABBB.C30168A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, In RTCP XR Base Package defined in H.248.30(03/2004) the statisticsID = are from 1 to 12. The IDs 4 to 8 of that coincides with the statisticsID = of the base pkg, rtp version1. Also R Factor and External R Factor have ths same strings 'ns'. Can you please clarify on this? Thanks in Advance, Geetha ------=_NextPart_000_001A_01C4ABBB.C30168A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
In RTCP XR Base Package defined in=20 H.248.30(03/2004) the statisticsID are from 1 to 12. The IDs 4 to 8 = of that=20 coincides with the statisticsID of the base pkg, rtp = version1.
Also R Factor and External R Factor = have ths same=20 strings 'ns'.
 
Can you please clarify on = this?
 
Thanks in Advance,
Geetha
 
------=_NextPart_000_001A_01C4ABBB.C30168A0-- --===============1784147932== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1784147932==-- From megaco-bounces@ietf.org Fri Oct 8 14:41:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20380 for ; Fri, 8 Oct 2004 14:41:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFzX8-0005aa-KK; Fri, 08 Oct 2004 14:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFzQq-0003VC-Nn for megaco@megatron.ietf.org; Fri, 08 Oct 2004 14:25:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18449 for ; Fri, 8 Oct 2004 14:25:33 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFzam-00058F-DA for megaco@ietf.org; Fri, 08 Oct 2004 14:35:52 -0400 Received: from ma8117exch002u.wins.lucent.com (h152-148-89-177.lucent.com [152.148.89.177]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i98IOulj008639 for ; Fri, 8 Oct 2004 13:24:57 -0500 (CDT) Received: by ma8117exch002u.inse.lucent.com with Internet Mail Service (5.5.2657.72) id <4M3GT8C0>; Fri, 8 Oct 2004 14:24:56 -0400 Message-ID: <4F9DBE266768DC46A1F17E875D3716410942209E@ma8117exch002u.inse.lucent.com> From: "Lu, Kang-Sen (Kang-Sen)" To: "'megaco@ietf.org'" Date: Fri, 8 Oct 2004 14:24:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Megaco] question about topology descriptor X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org A topology descriptor consists of a sequence of associated terminations of the form (T1, T2, association[, StreamId]). Does the MG apply the topology association to the context in the sequence they appear in the topology descriptor like a sequential program? If so, then why (T1, T2, bothway) and (T1, T2, isolate, S1) can cause undefined behavior? _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Oct 12 01:35:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04638 for ; Tue, 12 Oct 2004 01:35:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHFGF-0006AZ-JH; Tue, 12 Oct 2004 01:31:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHFCk-0004uf-Eb for megaco@megatron.ietf.org; Tue, 12 Oct 2004 01:28:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03854 for ; Tue, 12 Oct 2004 01:28:09 -0400 (EDT) Received: from ns1.nec.com.au ([147.76.180.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHFNP-0005RG-Rn for megaco@ietf.org; Tue, 12 Oct 2004 01:39:12 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by ns1.nec.com.au (Postfix) with ESMTP id B754737775 for ; Tue, 12 Oct 2004 15:27:31 +1000 (EST) Received: from ns1.nec.com.au ([127.0.0.1]) by localhost (ns1.nec.com.au [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01237-01-16 for ; Tue, 12 Oct 2004 15:27:31 +1000 (EST) Received: from smtp2.nec.com.au (smtp2.internal.nec.com.au [172.31.8.19]) by ns1.nec.com.au (Postfix) with ESMTP id 9FF6C3776D for ; Tue, 12 Oct 2004 15:27:31 +1000 (EST) Received: from tns.neca.nec.com.au (localhost.localdomain [127.0.0.1]) by smtp2.nec.com.au (8.12.8/8.12.8) with ESMTP id i9C5RVYb002350 for ; Tue, 12 Oct 2004 15:27:31 +1000 Received: from GWANGXP ([147.76.211.59]) by tns.neca.nec.com.au (8.12.8/8.12.8) with SMTP id i9C5RUvN014584 for ; Tue, 12 Oct 2004 15:27:31 +1000 From: "Gillian Wang" To: "Megaco@Ietf. Org" Date: Tue, 12 Oct 2004 15:24:58 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: <4161DD1D.2050405@ericsson.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [Megaco] Redundant payload transmission X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit Dear Megaco members, Can anybody advise that if H.248 protocol supports the indication of the redundant voice payload transmission? Regards Gillian _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Oct 12 10:52:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26813 for ; Tue, 12 Oct 2004 10:52:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHNlb-00046a-W4; Tue, 12 Oct 2004 10:36:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHNht-0001X7-Hx for megaco@megatron.ietf.org; Tue, 12 Oct 2004 10:32:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24433 for ; Tue, 12 Oct 2004 10:32:51 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHNsd-0006W4-8d for megaco@ietf.org; Tue, 12 Oct 2004 10:44:00 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9CEWDB21564; Tue, 12 Oct 2004 10:32:13 -0400 (EDT) Received: from [47.130.17.8] (acart088.ca.nortel.com [47.130.17.8]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SPNPLX20; Tue, 12 Oct 2004 10:32:13 -0400 Message-ID: <416BEAEC.6070904@nortelnetworks.com> Date: Tue, 12 Oct 2004 10:32:12 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gillian Wang Subject: Re: [Megaco] Redundant payload transmission References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: "Megaco@Ietf. Org" X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit That would be in the payload description in the SDP of the Local and Remote descriptors. Nothing really to do with the H.248 protocol itself. Gillian Wang wrote: > Dear Megaco members, > > Can anybody advise that if H.248 protocol supports the indication of the > redundant voice payload transmission? > > Regards > Gillian > > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Oct 12 13:06:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09287 for ; Tue, 12 Oct 2004 13:06:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHPsY-0006bD-S8; Tue, 12 Oct 2004 12:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHPdU-0002lU-3Q for megaco@megatron.ietf.org; Tue, 12 Oct 2004 12:36:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06920 for ; Tue, 12 Oct 2004 12:36:25 -0400 (EDT) From: Deepak.Pant@utstar.com Received: from ns3.utstar.com ([216.37.120.25] helo=rm-mail1.utstar.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHPe9-0001FK-6c for megaco@ietf.org; Tue, 12 Oct 2004 12:37:09 -0400 Received: from gypsum.mw.3com.com (gypsum.utstar.com [216.37.120.52] (may be forged)) by rm-mail1.utstar.com (8.12.11/8.12.11) with ESMTP id i9CGN2nm025652 for ; Tue, 12 Oct 2004 11:23:03 -0500 (CDT) Received: from utstarchi01.mw.3com.com (uschi001.mw.3com.com [149.112.142.9]) by gypsum.mw.3com.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i9CGPGt5022245 for ; Tue, 12 Oct 2004 11:25:17 -0500 (CDT) To: megaco@ietf.org Date: Tue, 12 Oct 2004 11:25:14 -0500 Message-ID: X-MIMETrack: Serialize by Router on UTSTARCHI01/UTStarcom(Release 5.0.12 |February 13, 2003) at 10/12/2004 11:25:17 AM MIME-Version: 1.0 X-Spam-Score: 1.6 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Megaco] ToS byte marking-followup X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0064611182==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org --===============0064611182== Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 DQpJcyB0aGVyZSBhIHN0YW5kYXJkaXplZCBtZWNoYW5pc20gdG8gc2V0IHRoZSBUT1MgYml0IG1h cmtpbmcNCg0KQW4gZWFybGllciBlLW1haWwgaGFkIHRhbGtlZCBhYm91dCB1c2luZyBhIFFvU092 ZXJyaWRlIHByb3BlcnR5Lg0KDQoNCkFub3RoZXIgZS1tYWlsIGhhZCB0YWxrZWQgYWJvdXQgdXNp bmcgIkVUU0kgR2F0ZSBDb250cm9sIHBhY2thZ2UiLiBJIGNvdWxkDQpub3QgZmluZCByZWZlcmVu Y2UgdG8gaXQgaW4gdGhlIEguMjQ4IHBhY2thZ2UgZGVmaW5pdGlvbnMuDQoNClRoZSBkcmFmdCBk cmFmdC1tYWRodWJhYnUtbWVnYWNvLXFvc3BhY2thZ2UtMDAudHh0IGlzIGV4cGlyZWQuDQoNCkNv dWxkIHNvbWVvbmUgZ3VpZGUgdXMgYXMgdG8gd2hhdCBpcyB0aGUgc3RhbmRhcmRpemVkIG1lY2hh bmlzbQ0KZm9yIFRPUyBiaXQgbWVya2luZyBpbiBNZWdhY28uDQoNClJlZ2FyZHMNCi1EZWVwYWsN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQnJhZCwNCg0KDQoNCldlIGhh dmUgZGVmaW5lZCB0aGUgoa5Rb1NPdmVycmlkZaGvIHByb3BlcnR5IGluIG91ciBNZWdhY28gcGFj a2FnZSBmb3IgZXhwbGljaXRseSBzZXR0aW5nIHRoZSBUb1MgYml0cyB3aXRoaW4gdGhlIFJUUCBt ZWRpYSBzdHJlYW0uICBJZiB0aGlzIHByb3BlcnR5IGlzDQogbm90IHNldCwgdGhlIE1HIHVzZXMg dGhlIE1lZGlhIGFuZCBDb2RlYyB0eXBlcyBzcGVjaWZpZWQgaW4gdGhlIFNEUCB0byBnZW5lcmF0 ZSB0aGUgbWFwcGluZy4gIElmIG5laXRoZXIgb2YgdGhlIGFib3ZlIGlzIGFwcGxpY2FibGUsIHRo ZSBNRyB3aWxsIHVzZQ0KYSBzdGF0aWMgbWFwcGluZyB0YWJsZSB3aGljaCBpcyBjb25maWd1cmVk IGJ5IHRoZSBvcGVyYXRvci4gIFRoZSBuZXh0IHJlbGVhc2Ugb2Ygb3VyIHByb2R1Y3Qgd2lsbCBz dXBwb3J0IHNldHRpbmcgdGhlIGZ1bGwgNiBRb1MgYml0cy4gIEhvcGUgdGhpcyBpcw0KdXNlZnVs Lg0KDQoNCg0KQ2hlZXJzLA0KDQpFZA0KDQpRb1MgT3ZlcnJpZGUNClByb3BlcnR5SWQ6IFFvU092 ZXJyaWRlKDB4MDAwNSkNCg0KRGVzY3JpcHRpb246IFRoZSBUb1MgbWFwcGluZyB0byB1c2UgZm9y IHRoaXMgdGVybWluYXRpb24uDQoNClR5cGU6IG9jdGV0IHN0cmluZy4gIEluIHRoZSB0ZXh0IGVu Y29kaW5nIG9mIE1FR0FDTy9ILjI0OCB0aGlzIGlzIHJlcHJlc2VudGVkIGFzIGEgc3RyaW5nLCB0 aGF0IGlzIHRoZSB2YWx1ZXMgYXJlIDAgdG8gNy4NCg0KUG9zc2libGUgVmFsdWVzOiBhcyBjb25m aWd1cmVkIGluIHRoZSBNR0MuDQoNCkRlZmF1bHQ6IE5vIG92ZXJyaWRlIGlzIGFwcGxpZWQuDQoN CkRlZmluZWQgaW46IExvY2FsQ29udHJvbC4NCg0KQ2hhcmFjdGVyaXN0aWNzOiByZWFkLXdyaXRl Lg0KDQo= --===============0064611182== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0064611182==-- From megaco-bounces@ietf.org Tue Oct 12 23:34:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14754 for ; Tue, 12 Oct 2004 23:34:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHZtP-0005Jy-5O; Tue, 12 Oct 2004 23:33:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHZs9-00054l-IX for megaco@megatron.ietf.org; Tue, 12 Oct 2004 23:32:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14517 for ; Tue, 12 Oct 2004 23:32:13 -0400 (EDT) Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHa2p-0002Re-Sp for megaco@ietf.org; Tue, 12 Oct 2004 23:43:30 -0400 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.ccpu.com (Postfix) with ESMTP id EC7F334688E for ; Tue, 12 Oct 2004 20:31:33 -0700 (PDT) Received: from smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (VaMailArmor-2.0.1.16) id 15071-545DFD5A; Tue, 12 Oct 2004 20:31:29 -0700 Received: from ccpu00179 (unknown [172.25.0.135]) by smtp.ccpu.com (Postfix) with SMTP id 0E6923468BB for ; Tue, 12 Oct 2004 20:31:28 -0700 (PDT) Message-ID: <001101c4b13e$2cde9590$870019ac@ccpu00179> From: "Geetha" To: Subject: [Megaco]: RTCP XR Base package Date: Wed, 13 Oct 2004 09:03:24 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4942.400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.28.0.3; VDF: 6.28.0.12; host: smtp) X-Spam-Score: 2.4 (++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1750360514==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1750360514== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C4B103.7F07C390" This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C4B103.7F07C390 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, In RTCP XR Base Package defined in H.248.30(03/2004) the statisticsID = are from 1 to 12. The IDs 4 to 8 of that coincides with the statisticsID = of the base pkg, rtp version1. Also R Factor and External R Factor have ths same strings 'ns'. Can you please clarify on this? Thanks in Advance, Geetha ------=_NextPart_000_000D_01C4B103.7F07C390 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
In RTCP XR Base Package defined in=20 H.248.30(03/2004) the statisticsID are from 1 to 12. The IDs 4 to 8 = of that=20 coincides with the statisticsID of the base pkg, rtp = version1.
Also R Factor and External R Factor = have ths same=20 strings 'ns'.
 
Can you please clarify on = this?
 
Thanks in Advance,
Geetha
------=_NextPart_000_000D_01C4B103.7F07C390-- --===============1750360514== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1750360514==-- From megaco-bounces@ietf.org Wed Oct 13 13:33:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18004 for ; Wed, 13 Oct 2004 13:33:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHmw4-0007pg-Vf; Wed, 13 Oct 2004 13:29:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHmnS-0005vI-Cg for megaco@megatron.ietf.org; Wed, 13 Oct 2004 13:20:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17101 for ; Wed, 13 Oct 2004 13:20:17 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHmyR-00012N-Ox for Megaco@ietf.org; Wed, 13 Oct 2004 13:31:40 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9DHJi511688 for ; Wed, 13 Oct 2004 13:19:44 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id <45SX848L>; Wed, 13 Oct 2004 13:19:45 -0400 Message-ID: <1E7140413C19AD4E827D63B820A24D2B0223E2E8@zrtphxm2> From: "Kevin Boyle" To: Angelo Contardi , Megaco - IETF Date: Wed, 13 Oct 2004 13:19:38 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: [Megaco] RE: Ambiguity in MEGACO textual grammar ? X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org After having another look through the grammar and the text of the spec, I see that the contextTerminationAudit construct would produce something like this: !/1 [12.34.56.78]:2944 P=123{C=1{AV=C{term1,term2,term3}}} I don't see the great advantage of that over, say: !/1 [12.34.56.78]:2944 P=123{C=1{AV=term1,AV=term2,AV=term3}} Further, the latter is better aligned with the rest of the protocol construction. I could find no reference to this particular construct anywhere but in the grammar. I do not have any particular recollection of why this would have been built this way. Does anyone remember that far back to know why this was designed in this fashion? Kevin -----Original Message----- From: Angelo Contardi [mailto:angelo.contardi@italtel.it] Sent: Wednesday, October 13, 2004 12:51 PM To: Megaco - IETF Subject: Ambiguity in MEGACO textual grammar ? Hello Megaco - IETF Team, during my study about MEGACO V2 Textual syntax (Annex B) i have probably discover TWO (similar) ambiguties in "auditReply" productions. In fact, auditReply = (AuditValueToken / AuditCapToken ) ( contextTerminationAudit / auditOther) and may be "rewritten" as: auditReply = AuditValueToken contextTerminationAudit / (1) AuditValueToken auditOther / (2) AuditCapToken contextTerminationAudit / (3) AuditCapToken auditOther (4) Let me consider the First two productions (1) and (2) (but what i will say is valid for the last couple too, (3) and (4)). auditOther = EQUAL TerminationID [LBRKT terminationAudit RBRKT] contextTerminationAudit = EQUAL CtxToken LBRKT errorDescriptor RBRKT / ... terminationAudit = auditReturnParameter *(COMMA auditReturnParameter) auditReturnParameter = ... / ... / errorDescriptor So, production (1) may genarate a "string" (sentencial form) of this kind: AuditValueToken EQUAL CtxToken LBRKT errorDescriptor RBRKT While production (2) may generate a "string" (sentencial form) of this kind: AuditValueToken EQUAL TerminationID LBRKT errorDescriptor RBRKT Well, if i choose a TerminationID in pathNAME form, that simulate the CtxToken value, "c" or "context", the two production are the same and it's not possible to distinguish between them. Changing AuditValueToken with AuditCapToken, demostrate that production (3) and (4) may generate the same sequence (are ambiguous, in some cases). I know NOBODY probably choose TerminationID value = CtxToken value, but theorically this choice is allowed. Best regards Angelo Contardi angelo.contardi@italtel.it 2004-10-13 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Wed Oct 13 13:45:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18827 for ; Wed, 13 Oct 2004 13:45:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHn6T-0001Ph-LN; Wed, 13 Oct 2004 13:39:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHm0t-0002kb-M0 for megaco@megatron.ietf.org; Wed, 13 Oct 2004 12:30:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13455 for ; Wed, 13 Oct 2004 12:30:07 -0400 (EDT) Received: from ns.italtel.it ([138.132.53.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHmBs-0008WR-7Y for Megaco@ietf.org; Wed, 13 Oct 2004 12:41:29 -0400 Received: from ns.italtel.it (localhost [127.0.0.1]) by ns.italtel.it (8.12.11/8.12.9) with ESMTP id i9DGTUTG009765 for ; Wed, 13 Oct 2004 18:29:30 +0200 (MEST) Received: from IMADS2.milano.italtel.it (imads2.milano.italtel.it [138.132.90.31]) by ns.italtel.it (8.12.11/8.12.11) with ESMTP id i9DGTUaZ009762 for ; Wed, 13 Oct 2004 18:29:30 +0200 (MEST) Message-Id: <200410131629.i9DGTUaZ009762@ns.italtel.it> X-Spam-Filter: made by ns.italtel.it Received: from IC4CW171 (ic4cw171.settimo.italtel.it [138.132.82.171]) by IMADS2.milano.italtel.it with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4XZFCDGY; Wed, 13 Oct 2004 18:29:29 +0200 Date: Wed, 13 Oct 2004 18:51:00 +0200 From: "Angelo Contardi" To: "Megaco - IETF " Organization: Italtel X-mailer: Foxmail 5.0 [it] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====001_Dragon487811433074_=====" X-Spam-Score: 0.8 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba X-Mailman-Approved-At: Wed, 13 Oct 2004 13:39:56 -0400 Subject: [Megaco] Ambiguity in MEGACO textual grammar ? X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --=====001_Dragon487811433074_===== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello Megaco - IETF Team, during my study about MEGACO V2 Textual syntax (Annex B) i have probably discover TWO (similar) ambiguties in "auditReply" productions. In fact, auditReply = (AuditValueToken / AuditCapToken ) ( contextTerminationAudit / auditOther) and may be "rewritten" as: auditReply = AuditValueToken contextTerminationAudit / (1) AuditValueToken auditOther / (2) AuditCapToken contextTerminationAudit / (3) AuditCapToken auditOther (4) Let me consider the First two productions (1) and (2) (but what i will say is valid for the last couple too, (3) and (4)). auditOther = EQUAL TerminationID [LBRKT terminationAudit RBRKT] contextTerminationAudit = EQUAL CtxToken LBRKT errorDescriptor RBRKT / ... terminationAudit = auditReturnParameter *(COMMA auditReturnParameter) auditReturnParameter = ... / ... / errorDescriptor So, production (1) may genarate a "string" (sentencial form) of this kind: AuditValueToken EQUAL CtxToken LBRKT errorDescriptor RBRKT While production (2) may generate a "string" (sentencial form) of this kind: AuditValueToken EQUAL TerminationID LBRKT errorDescriptor RBRKT Well, if i choose a TerminationID in pathNAME form, that simulate the CtxToken value, "c" or "context", the two production are the same and it's not possible to distinguish between them. Changing AuditValueToken with AuditCapToken, demostrate that production (3) and (4) may generate the same sequence (are ambiguous, in some cases). I know NOBODY probably choose TerminationID value = CtxToken value, but theorically this choice is allowed. Best regards Angelo Contardi angelo.contardi@italtel.it 2004-10-13 --=====001_Dragon487811433074_===== Content-Type: image/gif; name="fox.gif" Content-Disposition: FoxmailIcon; filename="fox.gif" Content-Transfer-Encoding: base64 R0lGODlhIwAfALMLAP///+Dg4OCgAOCAAOAAAMDA4KCgwKBgQIAAAGBggCAgIAAAAAAAAAAAAAAA AAAAACH/C05FVFNDQVBFMi4wAwHoAwAh+QQJDwALACwAAAAAIwAfAAAE+3DJSem5Na+jux3CxWWi Zx5DIgiD6Lrgan6FoYZDzuborKGDQKEAXBl1Al/lEgwUjcaeTClhBpDQ6ECypYqwzauAuOhSN8BY s6AoDBSjczW9atrcibicmQPZ229yS0AGNUEGCkIKghYiBgGQkZIKi4wHBoWSmgEGjHOXBZucnUov aJeYhUM1pD58fRifCbMJe2Atcy2qBbWlWEdfApmQvD5uMVktFyGhkr0mbllQtCjNxM8dhdJ9CZi8 l5I12BlDyTndw92rNeIUBe6RddyqCQEJfSn1Nu4Tw8TKB9TdQSFAAa19/CRYE0JkRL5aChCAoISg A6cFC4e0qqBgNlhEBLM0bNI4ToJBbwEofURQkcKjSKs2TlhJoGZNhrMQStjVTkNEmzbD8bLxLFXI DiqTKl0aAQAh+QQJDwALACwCAAAAIQAfAAAE+3DJSeW5Na+jux3CxWWi1x1DIgiD6Lrgan6FoYZD zuboXKGDQKEAXBl1At/kEgwUjcaeTMkMIKHRgUTrE12bVgFxwaUCY82CojBQjJSW86ppYyfecGYO RF+3lQY1BoN6gQZBBgpCCjOBQ48GLgYBlJWWCowZBZaUQ5GDm5yWBhqhokIigaeDpaeVqYOOnqQd pqJMcQcJuwkmm4+2UC0oB7K9HUKxjwFYTAKqnccVnryyUCIhtgHSFAE2EwmHMSu8KLYF3BMFGeJG 4YF3k5U16TUaewLvoeHAhty0GfDxQ7dtT4oE3tJ1MMivDgoBCqop9CBw1wIFCEBgQgCHL4LBYQqg YURgseMGFxFBBcA0EgHHjiJaEpg5Uwi6cBNNYKRJ09IQnDk1sBxKtGgEACH5BAkPAAsALAgAAAAb AB8AAAT7cMl56rz44H2GqBpnbVeXCMIArquHckNhnN9gp3ZHUnZQFB0XCvfaVQaBQHDI1BVFyBuz OZBURUsUMukBLq4Lg48SdG0LisJAEcKIfUfpdqZOtN0FZdkzT693EgZ5cYIGSAYKPgqAYYMgb0mR kQqLG4JwBpeSmwYkmnoHn5KZO5qPmYI/Mp2lP3oFEiAJswmMqZKwR6GqtZ6uuEcCnwW9GTcBAkkg H3mSxTxCWrQdzUnEGzbRAgmZxKG4MxhSQ9ya3KoyMs/ZTOfEAQnZA7MB4RPs5IUJQB4KtPb35JGb tUABgn4GAcmTV0GBJoMICJJYCMJftwCUICJAYGQahUYCIEH6IMbtGQmDIUPiIjbD5IWMMGPKjAAA IfkECQ8ACwAsBQAAAB4AHwAABPtwyTmPpbjmvc4Q1rGFXOYlgjCELPulpVcYKDjc6u2VlDcEhYIv RcQJeBLLLzAkEncwnjJgdD4HEmxM+VIFvh/hQiv1vZYFRWGgECGT5tSStk6431zcXM1+LwwGHT4G Mz8GCkAKfhIGLAZfkJEBCopvjYAFkpKBSJghhJoBgDyAoJ+lQUGjJZiZTHchCbIJpISuX5yCK7YF tBu8kblKAqBfvRm2mxUWILdfvhTFwROzMpHHGKA/RSIJmHaPkDPQEzddOd7F3qkz4xjmTjfrvQEJ 5gOyouRj8E7rdB4EKJhFY8O9eLMWKEDwgRICHvcirjigoNhCBLIgRgwxECPTJIcIQpZhcREBgZMn gfTytq/EQpQor/Wi0TIDpZs4c+KMAAAh+QQJDwALACwCAAAAIQAfAAAE+3DJSeW5Na+jux3CxWWi 1x1DIgiD6Lrgan6FoYZDzuboXKGDQKEAXBl1At/kEgwUjcaeTMkMIKHRgUTrE12bVgFxwaUCY82C ojBQjJSW86ppYyfecGYORF+34T9ABjVBBgpCCoAULgYBjo+QCokdBhoHBoOQmgGVGpgnF5mbn54F oJeYg0M1naWgSxcJsgkmql0ol6u0lKYzTAKiQrsVtiYiIQWawxSNvR6zKMmPBcsSos4ZCZjUl5A1 1cHYE9qi2qs138yaQ3s55tQBCe2ynMvBAVgr5nUoAgqzNohJK5BvzqwFChCAkISAl6MYWPZcUCAq IQJZGVRZ2bNDLuKBf9sCSLKIoCEzNu1STiyJgIBLl0KoaVvmpZ0LhC1fwpxGzQbNF3hGCh1KNAIA IfkECQ8ACwAsAAAAACMAHwAABPtwyUnpuTWvo7sdwsVlomceQyIIg+i64Gp+haGGQ87m6Kyhg0Ch AFwZdQJf5RIMFI3GnkwpYQaQ0OhAsqWKsM2rgLjoUjfAWLOgKAwUo3M1vWra3Im4nJkD2dtvcktA BjVBBgpCCoIWIgYBkJGSCouMBwaFkpoBBoxzlwWbnJ1KL2iXmIVDNaQ+fH0YnwmzCXtgLXMtqgW1 pVhHXwKZkLw+bjFZLRchoZK9Jm5ZULQozcTPHYXSfQmYvJeSNdgZQ8k53cPdqzXiFAXukXXcqgkB CX0p9TbuE8PEygfU3UEhQAGtffwkWBNCZES+WgoQgKCEoAOnBQuHtKqgYDZYRASzNGzSOE6CQW8B KH1EUJHCo0irNk5YSaBmTYazEErY1U5DRJs2w/Gy8SxVyA4qkypdGgEAIfkECQ8ACwAsAgAAACEA HwAABPtwyUnluTWvo7sdwsVlotcdQyIIg+i64Gp+haGGQ87m6Fyhg0ChAFwZdQLf5BIMFI3GnkzJ DCCh0YFE6xNdQTkwh0sFxs7hlpLCRKbTo/XGDA4EDIrCQKE01AyAbX4GQXhCfCZ+Q4sGLgZ2kJEB CogVBZJCNQeAl5iQBhqdnkQXfp6AoZ6QIoCcjKAdophMFhcJtwkml4uyUC0om4u5HUKtiwFYTAKm dgXDljW4igVQIiGyAc8Ud88JhDEruCiyzqEZ30befgmbkdGWsBVhAuqd3ryD2vHyOvfO2WlucVMS MB8REAqkaZsxD9cCBQgQQpQz4c0FBcwgIrhFcSWOiIScJlFCQBIBxY8lCahUmemWjY4QV65058zG QhOUcurcqTMCACH5BAkPAAsALAgAAAAbAB8AAAT7cMl56rz44H2GqBpnbVeXCMIArquHckNhnN9g p3ZHUnZQFB0XCvfaVQaBQHDI1BVFyBuzOZBURUuU66ZaXBcGHyW4HdpypLDvKBWeu+mCkuwZ0N47 iUHO3hvsCYEFCXlgfCBqSYqKCgpxawZ7i5MBBo9JiHKUkTuScweRkT8/nJ0/cwUSIIGBhXuaSalH oKOEcbCxRwKePrYZNwECmBUfuAG+PEJarB24gxtnUwmiCaCLMsheygLTntOjMtgX0UPfg8dvgZXI 5CjfM0AeCqwzGG9CrAsKCPL7efdnKijwtA9BKxL3QMwTFaBRQQQIjKx4SKBiRR+DpmXbsM8OosVr g2ZsnOCwpMmTEQAAIfkECQ8ACwAsBQAAAB4AHwAABPtwyTmPpbjmvc4Q1rGFXOYlgjCELPulpVcY KDjc6u2VlDcEhYIvRcQJeBLLLzAkEncwnjJgdD4HEmxM+VLlPquFVup7mW86ZKWcQrvD6k4ZHAgY FIWBIm4wyG8GMz93QHtxCwYsBnWMjQEKhkiJfQWOjn6SgSGBlnaYHH2cm6FBQX08lJVMIkkWCa8J qIGqdZ9KB7MFsRu5jbYeApx1uhmzl2sHILR1uxTCvhOwMo3EGJw/RSIJlAm41DQZaE4328LbpTMz zVlVOee6AQlur3brYuJO5zRCHwqw4OHwtYG1QAGCfgZ5vHljQYEwgwheKWTYsFwlSBARICBDIhkj gY8fgejaZq+EQZAgqemiUTIDxpcwY0YAACH5BAkPAAsALAIAAAAhAB8AAAT7cMlJ5bk1r6O7HcLF ZaLXHUMiCIPouuBqfoWhhkPO5uhcoYNAoQBcGXUC3+QSDBSNxp5MyQwgodGBROsTXZtWAXHBpQJj zYKiMFCMlJbzqmljJ95wZg5EX7fhP0AGNUEGCkIKgBQuBgGOj5AKiR0GGgcGg5CaAZUamCcXmZuf ngWgl5iDQzWdpaBLFwmyCSaqXSiXq7SUpjNMAqJCuxW2JiIhBZrDFI29HrMoyY8FyxKizhkJmNSX kDXVwdgT2qLaqzXfzJpDeznm1AEJ7bKcy8EBWCvmdSgCCrM2iEkrkG/OrAUKEICQhICXoxhY9lxQ ICohAlkZVFnZs0Mu4oF/2wJIsoigITM27VJOLImAgEuXQqhpW+alnQuELV/CnEbNBs0XeEYKHUo0 AgAh+QQJDwALACwAAAAAIwAfAAAE+3DJSee5NVOs9RkD1y1XcYzZZxjh5b6HYaLpUBTrBe7gJ/y0 yqcQMA1+yF8okVgIgpZBIABKWltQ4c56PZ2yEt1xGvhNlV5w+CMtKn4KIlYdbd9AN6qIzp4WFCBx enQbH36AA4IzhBZ5ZAoKfgWMEmSWl2SThAaYAZxkK1kwCwELK52hUGI7XxIrMjcGamxIPWsmTAmL QbRdOitERXsdBVVcLQcCjkW7I8VcP7kJB8GZ0ygyxyAJK9PVfgZNzgVX26cB07A3uuEUmhLVSjvc BQnobNv27RPvMpbFLujZm3ZEQa59/Pj9M/FlgDQFCApC7OBpwbdYHRT4CwARNAETDZhiiatgEBhH SAg8jnS1EEfGlARi+mFScqU6HCspQIwpkxmRBDVHvvqYEZLRo0iNRgAAIfkECQ8ACwAsAgAAACEA HwAABPtwyUnXuTVTrOsZA9dZR3GM22AY4eW+h2GiaVGsF6iDn+DTk08hYBr4jr5QIrEQAC2DQACE rLaeQV3Vejphc0ZpwCdNdrEkkLSg8CmGV7TkEyUWQLapCE1fK0Bvek8yKzgffoBDMygyNo44eWIK CmsFKENilZmbnJYZmJwBBqGjYisaoKGiK6QGI6mhAxKFj5d2kWVHLSZLCYsaRLR5VTkrmCZeFTYG vY0FSC4CuDbJFKJMEgksRj69CSWbBd+fGdtH2szgmTfYEzcaWuhS387i7BSu8FTa4gHfO0uuPQEo I4G/HgqatQMSr5cCBEYmIZAjYUcLBTKkPESwhCMijITGAkza2FEOho0EUq5ZAnLhk4cpVd7y19Il ipE4c+qMAAAh+QQJDwALACwIAAAAGwAfAAAE+3BJeeq8eNp8xtiZdhRH2BnGV63sYZDh0hUFWnm4 1wl8PAekAW/I+yQSC4FpEAh4iFBVjIKDRkslX0fYDPCaRezEABR5mgUFT1Fwgi7k8hZd8NDc2cwL OAcqPGxuUwt7N2h/A4EwU3skd10KCnSDe12Wl10FIZVxl50BKDGVQCiYoAaMj2WEKDQ1lKpyIwdH CYt6sXwnlSR5F1sCXk0rAqo0vlRCRLUJI5cFzRhVyyjNbZY1SBdP1HHNL662BtoS0zwJLwkBzTlH oOQL5gLo0Os7CrXj0jlDzAoIQiIhmJIjRwkFlf4hOBKj4Ap8rQJEUsjQxAoJCgloRHMEEyK8EP80 bgRyJ4HHjxcmqlzJMgIAIfkECQ8ACwAsBQAAAB4AHwAABPtwySmPpTjfPM8YG1cdxSFWg2GAVuse RnmiRaFaX/55Qj8vnkKgNOgZe6BEYiGYeQKBz3HK+qGk0yMIaMUVoYEeFGky/bzQgqKnEFat13Th U4uGup+04tO2w1VAT0N7A30ycAsGCSRCYAoKcogSYJSVYAVWKgaWAZtggCeajZqcoCIqdVAGE6I1 q6ExjaodJAdKCYcZsbKdtCkxaXcSsZWvgQcCqUO5rLyzC7eLzgWLGMADYWTQKtKVNksYOVoDCSpQ i7vU3+FYSOQxCQGLOkqd4BM6U+XU8jwKt4o45DNC7pYCBEUeIZihoyELBcACHESghGHDFv9QSVRI 8R4ehxcSJhIYmUZJRo8zDo4kuUxIgpMoOTyaSbMmzQgAIfkECQ8ACwAsAgAAACEAHwAABPtwyUnX uTVTrOsZA9dZR3GM22AY4eW+h2GiaVGsF6iDn+DTk08hYBr4jr5QIrEQAC2DQACErLaeQV3Vejph c0ZpwCdNdrEkkLSg8CmGV7TkEyUWQLapCE1fK0BvenJBH36AQzODc3liCgprBUAGGWKVlmKRGiua lwEGlZuamZQLK52hok8rMjaTI6xAFyZLCYmpNDkrQ0R7E7AoLgKMdl4Vn6MatAkllgXLxrvIFQkr y7uYBkwUMpjJpgHLrDa12dvNdzvUzuB0IEue2hLcYlsC6gnsRgq05dvR9QIGKFOAQB/BDvOMbNFx QcE8ggiWZGA1RcuOFvt0BXAEUSSiv4sXMUAkQHLNkozxSLTj4WIBQZIl7QxJgDIljD0cc+rcGQEA IfkECQ8ACwAsAAAAACMAHwAABPtwyUnnuadqebdfxyB23lVkn3YNxoi9l4Gm1VoYeCjuQyj8tNqh EAgUBr/kr5dILARBiy6AvCgPgt4sytkJsN8fuAfiSkdJMDaU2UZXPeWVbD7Hfwlk4kuvg3QCTQlF Cgp5bnU2RYuLJ34UQ0SLCJSNjxOMRQSbCI0BlwsGmZsEnUYGZjALATiSAZWsogWDKXA7W61FNwuz AYNOJSJJIxxDB4InCb2+wUhyWiG5RseSsxtHzs8YAgWu3cdGwBpHckmCCUOZJ8fiFQYF5TsJOOiu uhgf3c8i86K+B++6WRtHwdUSee9+6eDnocCEd4yOYJjXCx0SQ+0KTrD3DUfFgHMKEFwM6YEVr4i7 NiiAGCAkgiYbMhm5kVGCoVyFXMKk4E9XN1QqKZHS1eRmu4A/a9pEQIqATyIJjIrDYWCnypxYs2aN AAAh+QQJDwALACwCAAAAIQAfAAAE+3DJSde5p2p59z5D2HlXkXnVNRgi5l7GiVJqYdxgqA+g4M+0 QyEQKAx8SB8vkVgIgJxc4HhJHgQ8GdSiE1y9vi/Pso2KkN8rKKMFqnhJ67hshvsSx4R3Tn8LmAlE Cgp4bR4GNjcxIENEjkQmQIgFlJQxlI8Imo4FM42PmI8BBKQInAEen6IBBqKkpJAGqauiN5+brAaB qBWqtAMStrELgcUUQ5WqSVkmgAUJz0RNE0WKlQFxKsJF0I3TC5aAkwVWVaFFz97UuhMJLEd3gEKi zUzHGu9I7rrzoBjHsjR02SftwLhnGwIKDPEHUbEcIb6V2eEuWoIehCROZAgoNIECBEcGIaAzYUcW BYgEabJH8gUhYYM+ImDZJ4PMV5CYvNQI5eMrApAweXRHs2fMo0iRRgAAIfkECQ8ACwAsCAAAABsA HwAABPtwSXnqmTivqun4XLcdxdVVgwFabGWY5zEURi1/+CALvFgVgUBhwCvydInEQhD7BIgV40Gg g51wgmmWp9VtRCNQUTuVXWAG4QSlM0q9mrSQrRUkiIksPA5k25NBCgp3VnwBKEBBikElYAsGfQWJ QQiVigWOkIuKBJ0IlwEimgFynJ0EjAZgo6Sslq0JQXyTmI+jNAuxuhiQk2o/B0kJBcOxAUoSvZsl MjWJxJJByBsfAgHWh1HRjNDSHkRGwgkky8FJE1jhNeO+cyES1epy472S0xjpPAmQujcf9/ji6eN3 bMcggOhyFBGnAAERQQjA5MhxQcGohgjOdZhoYSKQswCCMGrUwEICxlOMknhEmKHhKVRCoiVYydJk yJs4cUYAACH5BAkPAAsALAUAAAAeAB8AAAT7cMkpjz00U6vzGSDXLVaBjdVnhFdrGSdKfoVhf2A+ fEIvz4VAoDDoGXu7RGIhkFlAgaLleBDsYs6coLrtcXek3yxk5FY/GOzouTtSweJxu5coJrZwMVug TAgVCnVqIzZjQUKIQiZxEjAFh0IIkogFjBKJQgSaCJQBcTYGmJqaigY/oIc2kJMBNn6eGqqQpo0G hzULfroUsom0QAd9BQnDQkuNj5CtE0+qisSHx7bKyylVj5TD0ciY1X0JB9QmfRO2UQFGYAmu4Zgm IhNa6QProQHg04/HGvJI9La6cIDYx68fHYD3eAQiWBDEEXp9FCAoAgiBDB0YrygwF0AnIgIlFzFe COQMkEeQKFxI8DjqWQKSDFFIHEVAEbaX61DKMMmzp88IACH5BAkPAAsALAIAAAAhAB8AAAT7cMlJ 17mnann3PkPYeVeRedU1GCLmXsaJUmph3GCoD6Dgz7RDIRAoDHxIHy+RWAiAnFzgeEkeBDwZ1KIT XL2+L8+yjYqQ3ysoowWqeEnruGyG+xLHhHdOfwuYCUQKCnhtZTVEiYkmdDQFQ4kIkotQBhqKRASa CIsBKDcbBpiaBJxFlh4GBR4BN5ABk62iBYEVqluuRDYLtAGBTRKqq25CB4AmCb2+E7fEK6q6xpC0 wY/EV4+LyEXAC7MzgAlCmCbG3dBFKAk34q/RI9WUGuuivgfCj90U9do7A+u9xO3Qt89dnDuqfvUg RJDZtINKwilAcGQQglSQjhzUcUE0AbqJCJhoEDali7+O9IYMAimyoL+TGUCS0sWEkAF9GGB2mEiK gK5sCWy2jPKCwsqjSJNGAAAh+QQJDwALACwAAAAAIwAfAAAE+3DJSee5NVOs9RkD1y1XcYzZZxjh 5b6HYaLpUBTrBe7gJ/y0yqcQMA1+yF8okVgIgpZBIABKWltQ4c56PZ2yEt1xGvhNlV5w+CMtKn4K IlYdbd9AN6qIzp4WFCBxenQbH36AA4IzhBZ5ZAoKfgWMEmSWl2SThAaYAZxkK1kwCwELK52hUGI7 XxIrMjcGamxIPWsmTAmLQbRdOitERXsdBVVcLQcCjkW7I8VcP7kJB8GZ0ygyxyAJK9PVfgZNzgVX 26cB07A3uuEUmhLVSjvcBQnobNv27RPvMpbFLujZm3ZEQa59/Pj9M/FlgDQFCApC7OBpwbdYHRT4 CwARNAETDZhiiatgEBhHSAg8jnS1EEfGlARi+mFScqU6HCspQIwpkxmRBDVHvvqYEZLRo0iNRgAA IfkECQ8ACwAsAgAAACEAHwAABPtwyUnXuTVTrOsZA9dZR3GM22AY4eW+h2GiaVGsF6iDn+DTk08h YBr4jr5QIrEQAC2DQACErLaeQV3Vejphc0ZpwCdNdrEkkLSg8CmGV7TkEyUWQLapCE1fK0Bvek8y KzgffoBDMygyNo44eWIKCmsFKENilZmbnJYZmJwBBqGjYisaoKGiK6QGI6mhAxKFj5d2kWVHLSZL CYsaRLR5VTkrmCZeFTYGvY0FSC4CuDbJFKJMEgksRj69CSWbBd+fGdtH2szgmTfYEzcaWuhS387i 7BSu8FTa4gHfO0uuPQEoI4G/HgqatQMSr5cCBEYmIZAjYUcLBTKkPESwhCMijITGAkza2FEOho0E Uq5ZAnLhk4cpVd7y19IlipE4c+qMAAAh+QQJDwALACwIAAAAGwAfAAAE+3BJeeq8eNp8xtiZdhRH 2BnGV63sYZDh0hUFWnm41wl8PAekAW/I+yQSC4FpEAh4iFBVjIKDRkslX0fYDPCaRezEABR5mgUF T1Fwgi7k8hZd8NDc2cwLOAcqPGxuUwt7N2h/A4EwU3skd10KCnSDe12Wl10FIZVxl50BKDGVQCiY oAaMj2WEKDQ1lKpyIwdHCYt6sXwnlSR5F1sCXk0rAqo0vlRCRLUJI5cFzRhVyyjNbZY1SBdP1HHN L662BtoS0zwJLwkBzTlHoOQL5gLo0Os7CrXj0jlDzAoIQiIhmJIjRwkFlf4hOBKj4Ap8rQJEUsjQ xAoJCgloRHMEEyK8EP80bgRyJ4HHjxcmqlzJMgIAIfkECQ8ACwAsBQAAAB4AHwAABPtwySmPpTjf PM8YG1cdxSFWg2GAVuseRnmiRaFaX/55Qj8vnkKgNOgZe6BEYiGYeQKBz3HK+qGk0yMIaMUVoYEe FGky/bzQgqKnEFat13ThU4uGup+04tO2w1VAT0N7A30ycAsGCSRCYAoKcogSYJSVYAVWKgaWAZtg gCeajZqcoCIqdVAGE6I1q6ExjaodJAdKCYcZsbKdtCkxaXcSsZWvgQcCqUO5rLyzC7eLzgWLGMAD YWTQKtKVNksYOVoDCSpQi7vU3+FYSOQxCQGLOkqd4BM6U+XU8jwKt4o45DNC7pYCBEUeIZihoyEL BcACHESghGHDFv9QSVRI8R4ehxcSJhIYmUZJRo8zDo4kuUxIgpMoOTyaSbMmzQgAIfkECQ8ACwAs AgAAACEAHwAABPtwyUnXuTVTrOsZA9dZR3GM22AY4eW+h2GiaVGsF6iDn+DTk08hYBr4jr5QIrEQ AC2DQACErLaeQV3Vejphc0ZpwCdNdrEkkLSg8CmGV7TkEyUWQLapCE1fK0BvenJBH36AQzODc3li CgprBUAGGWKVlmKRGiualwEGlZuamZQLK52hok8rMjaTI6xAFyZLCYmpNDkrQ0R7E7AoLgKMdl4V n6MatAkllgXLxrvIFQkry7uYBkwUMpjJpgHLrDa12dvNdzvUzuB0IEue2hLcYlsC6gnsRgq05dvR 9QIGKFOAQB/BDvOMbNFxQcE8ggiWZGA1RcuOFvt0BXAEUSSiv4sXMUAkQHLNkozxSLTj4WIBQZIl 7QxJgDIljD0cc+rcGQEAIfkECQ8ACwAsAAAAACMAHwAABPtwyUnpuTWvo7sdwsVlomceQyIIg+i6 4Gp+haGGQ87m6Kyhg0ChAFwZdQJf5RIMFI3GnkwpYQaQ0OhAsqWKsM2rgLjoUjfAWLOgKAwUo3M1 vWra3Im4nJkD2dtvcktABjVBBgpCCoIWIgYBkJGSCouMBwaFkpoBBoxzlwWbnJ1KL2iXmIVDNaQ+ fH0YnwmzCXtgLXMtqgW1pVhHXwKZkLw+bjFZLRchoZK9Jm5ZULQozcTPHYXSfQmYvJeSNdgZQ8k5 3cPdqzXiFAXukXXcqgkBCX0p9TbuE8PEygfU3UEhQAGtffwkWBNCZES+WgoQgKCEoAOnBQuHtKqg YDZYRASzNGzSOE6CQW8BKH1EUJHCo0irNk5YSaBmTYazEErY1U5DRJs2w/Gy8SxVyA4qkypdGgEA IfkECQ8ACwAsAgAAACEAHwAABPtwyUnluTWvo7sdwsVlotcdQyIIg+i64Gp+haGGQ87m6Fyhg0Ch AFwZdQLf5BIMFI3GnkzJDCCh0YFE6xNdm1YBccGlAmPNgqIwUIyUlvOqaWMn3nBmDkRft5UGNQaD eoEGQQYKQgozgUOPBi4GAZSVlgqMGQWWlEORg5uclgYaoaJCIoGng6WnlamDjp6kHaaiTHEHCbsJ JpuPtlAtKAeyvR1CsY8BWEwCqp3HFZ68slAiIbYB0hQBNhMJhzErvCi2BdwTBRniRuGBd5OVNek1 GnsC76HhwIbctBnw8UO3bU+KBN7SdTDIrw4KAQqqKfQgcNcCBQhAYEIAhy+CwWEKoGFEYLHjBhcR QQXANBIBx44iWhKYOVMIunATTWCkSdPSEJw5NbAcSrRoBAAh+QQJDwALACwIAAAAGwAfAAAE+3DJ eeq8+OB9hqgaZ21XlwjCAK6rh3JDYZzfYKd2R1J2UBQdFwr32lUGgUBwyNQVRcgbszmQVEVLFDLp AS6uC4OPEnRtC4rCQBHCiH1H6XamTrTdBWXZM0+vdxIGeXGCBkgGCj4KgGGDIG9JkZEKixuCcAaX kpsGJJp6B5+SmTuaj5mCPzKdpT96BRIgCbMJjKmSsEehqrWerrhHAp8FvRk3AQJJIB95ksU8Qlq0 Hc1JxBs20QIJmcShuDMYUkPcmtyqMjLP2UznxAEJ2QOzAeET7OSFCUAeCrT29+SRm7VAAYJ+BgHJ k1dBgSaDCAiSWAjCX7cAlCAiQGBkGoVGAiBB+iDG7RkJgyFD4iI2w+SFjDBjyowAACH5BAkPAAsA LAUAAAAeAB8AAAT7cMk5j6W45r3OENaxhVzmJYIwhCz7paVXGCg43OrtlZQ3BIWCL0XECXgSyy8w JBJ3MJ4yYHQ+BxJsTPlSBb4f4UIr9b2WBUVhoBAhk+bUkrZOuN9c3FzNfi8MBh0+BjM/BgpACn4S BiwGX5CRAQqKb42ABZKSgUiYIYSaAYA8gKCfpUFBoyWYmUx3IQmyCaSErl+cgiu2BbQbvJG5SgKg X70ZtpsVFiC3X74UxcETszKRxxigP0UiCZh2j5Az0BM3XTnexd6pM+MY5k43670BCeYDsqLkY/BO 63QeBCiYRWPDvXizFihA8IESAh73Iq44oKDYQgSyIEYMMRAj0ySHCEKWYXERAYGTJ4H08ravxEKU KK/1otEyA6WbOHPijAAAIfkECQ8ACwAsAgAAACEAHwAABPtwyUnluTWvo7sdwsVlotcdQyIIg+i6 4Gp+haGGQ87m6Fyhg0ChAFwZdQLf5BIMFI3GnkzJDCCh0YFE6xNdm1YBccGlAmPNgqIwUIyUlvOq aWMn3nBmDkRft+E/QAY1QQYKQgqAFC4GAY6PkAqJHQYaBwaDkJoBlRqYJxeZm5+eBaCXmINDNZ2l oEsXCbIJJqpdKJertJSmM0wCokK7FbYmIiEFmsMUjb0esyjJjwXLEqLOGQmY1JeQNdXB2BPaotqr Nd/MmkN7OebUAQntspzLwQFYK+Z1KAIKszaISSuQb86sBQoQgJCEgJejGFj2XFAgKiECWRlUWdmz Qy7igX/bAkiyiKAhMzbtUk4siYCAS5dCqGlb5qWdC4QtX8KcRs0GzRd4RgodSjQCACH+PEZJTEUg SURFTlRJVFkNCkNyZWF0ZWQgb3IgbW9kaWZpZWQgYnkNCkVEIVNPTiAnOTYgW1hmL1VDZl0NCgA7 --=====001_Dragon487811433074_===== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --=====001_Dragon487811433074_=====-- From megaco-bounces@ietf.org Wed Oct 13 22:35:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07366 for ; Wed, 13 Oct 2004 22:35:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHvLs-000735-CB; Wed, 13 Oct 2004 22:28:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHvC0-0004jZ-O4 for megaco@megatron.ietf.org; Wed, 13 Oct 2004 22:18:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06297 for ; Wed, 13 Oct 2004 22:18:12 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHvN4-00061D-OW for Megaco@ietf.org; Wed, 13 Oct 2004 22:29:39 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9E2IARU015629 for ; Thu, 14 Oct 2004 04:18:10 +0200 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 14 Oct 2004 04:18:12 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4KCAHR2L; Thu, 14 Oct 2004 04:18:10 +0200 Received: from ericsson.com (mieptest.epa.ericsson.se [146.11.22.32]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4PCZXBZ3; Thu, 14 Oct 2004 12:18:06 +1000 Message-ID: <416DDC5A.1080706@ericsson.com> Date: Thu, 14 Oct 2004 11:54:34 +1000 X-Sybari-Trust: d93d14bc 47b3073a 1a0a948c 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: Kevin Boyle Subject: Re: [Megaco] RE: Ambiguity in MEGACO textual grammar ? References: <1E7140413C19AD4E827D63B820A24D2B0223E2E8@zrtphxm2> In-Reply-To: <1E7140413C19AD4E827D63B820A24D2B0223E2E8@zrtphxm2> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Oct 2004 02:18:12.0352 (UTC) FILETIME=[0E20C000:01C4B194] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: Megaco - IETF , Angelo Contardi X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello Kevin and Angelo, contextTerminationAudit was/is a short form to be able to get back a compact list of termination IDs. This is mentioned in H.248.1v1: "Annexes A and B provide a special syntax for presenting such a list in condensed form, such that the AuditValue command tag does not have to be repeated for each TerminationID." Regards, Christian Kevin Boyle wrote: > After having another look through the grammar and the text of the spec, I > see that the contextTerminationAudit construct would produce something like > this: > > !/1 [12.34.56.78]:2944 P=123{C=1{AV=C{term1,term2,term3}}} > > I don't see the great advantage of that over, say: > > !/1 [12.34.56.78]:2944 P=123{C=1{AV=term1,AV=term2,AV=term3}} > > Further, the latter is better aligned with the rest of the protocol > construction. > > I could find no reference to this particular construct anywhere but in the > grammar. I do not have any particular recollection of why this would have > been built this way. Does anyone remember that far back to know why this > was designed in this fashion? > > Kevin > > -----Original Message----- > From: Angelo Contardi [mailto:angelo.contardi@italtel.it] > Sent: Wednesday, October 13, 2004 12:51 PM > To: Megaco - IETF > Subject: Ambiguity in MEGACO textual grammar ? > > Hello Megaco - IETF Team, > > during my study about MEGACO V2 Textual syntax (Annex B) i have probably > discover TWO (similar) ambiguties in "auditReply" productions. In fact, > > auditReply = (AuditValueToken / AuditCapToken ) ( contextTerminationAudit / > auditOther) > > and may be "rewritten" as: > > auditReply = AuditValueToken contextTerminationAudit / (1) > AuditValueToken auditOther / (2) > AuditCapToken contextTerminationAudit / (3) > AuditCapToken auditOther (4) > > Let me consider the First two productions (1) and (2) (but what i will say > is valid for the last couple too, (3) and (4)). > > auditOther = EQUAL TerminationID [LBRKT terminationAudit RBRKT] > contextTerminationAudit = EQUAL CtxToken LBRKT errorDescriptor RBRKT / ... > terminationAudit = auditReturnParameter *(COMMA auditReturnParameter) > auditReturnParameter = ... / ... / errorDescriptor > > So, production (1) may genarate a "string" (sentencial form) of this kind: > > AuditValueToken EQUAL CtxToken LBRKT errorDescriptor > RBRKT > > While production (2) may generate a "string" (sentencial form) of this kind: > > AuditValueToken EQUAL TerminationID LBRKT errorDescriptor RBRKT > > Well, if i choose a TerminationID in pathNAME form, that simulate the > CtxToken value, "c" or "context", the two production are the same and it's > not possible to distinguish between them. > Changing AuditValueToken with AuditCapToken, demostrate that production > (3) and (4) may generate the same sequence (are ambiguous, in some cases). > > I know NOBODY probably choose TerminationID value = CtxToken value, but > theorically this choice is allowed. > > Best regards > > Angelo Contardi > angelo.contardi@italtel.it > 2004-10-13 > > > > > > > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Oct 18 08:02:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09256 for ; Mon, 18 Oct 2004 08:02:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJWBY-00060E-MM; Mon, 18 Oct 2004 08:00:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJWAT-0005oj-15 for megaco@megatron.ietf.org; Mon, 18 Oct 2004 07:59:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08992 for ; Mon, 18 Oct 2004 07:59:11 -0400 (EDT) Received: from [194.90.152.129] (helo=mr.teledata-networks.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJWMP-0006k7-Bd for megaco@ietf.org; Mon, 18 Oct 2004 08:11:36 -0400 Received: from mr.teledata-networks.com (localhost.localdomain [127.0.0.1]) by localhost.teledata-networks.com (Postfix) with ESMTP id CCDC0AF0AC for ; Mon, 18 Oct 2004 13:28:42 +0200 (IST) Received: from tndcmail.Teledata.Local (ADC-FW.ser.netvision.net.il [199.203 .98.2])by mr.teledata-networks.com (Postfix) with ESMTP id B3FCCAEF7Ffor ; Mon, 18 Oct 2004 13:28:42 +0200 (IST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 18 Oct 2004 13:58:12 +0200 Message-ID: Thread-Topic: ISDN support with Megaco Thread-Index: AcS1Cby/YyAN5MqmR2GN76PknbbM7A== From: "Matia Marcu" To: X-imss-version: 2.0 X-imss-result: Passed X-imss-scores: Clean:24.67568 C:12 M:1 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Subject: [Megaco] ISDN support with Megaco X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2071127361==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============2071127361== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B509.BE32BE03" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B509.BE32BE03 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Dear Megaco-list members, Two main options have been proposed for ISDN phone /PBX support: Q,931= signaling conversion to MGCP /Megaco or Q.931 signaling transport over the= IP network to a softswitch that supports Q.931 network side (Q.931 /IUA= /SCTP). I'll describe part of the transport option as we figured it out and ask= questions where we have a dilemma: 1. Tone generation Outgoing call process: the ISDN entity sends a SETUP to the softswitch,= which responds with SETUP ACKNOWLEDGE; concerning dial tone, the= softswitch may do as follows: * instruct the VoIP gateway to apply dial tone and inform the ISDN entity= that in-band indication is expected * instruct the ISDN entity to apply dial tone towards the user side (ISDN= phones have this capability, so do PBXs) In the first case, the gateway would apply the tone as for analog= interfaces - phones and trunks. The difference appears when dial tone must= stop. For analog interfaces, the gateway performs both tone generation and= event detection, meaning that digit detection would stop dial tone. For= ISDN, the softswitch would receive the first digit signaled as Q.931= INFORMATION message and would instruct the gateway to stop the dial tone.= If this command to the gateway gets lost, the user would be stuck with= dial tone - at best for a short time, till the retransmitted command is= received, at worst for a longer time...The same applies for other= combinations of signals and events. If the ISDN entity applies the tone, the problem is that the ISDN tone= range is narrower than the tone range generated by CO (and consequently by= VoIP gateway) and this would leave ISDN users with poorer functionality. Which option is preferable? Should vendors support both options and decide= at deployment time - based on the concrete network and the actual risk of= retransmission /network failure? 2. Service state management This question is intended for the US market, where ISDN PRI standards= include a B-channel maintenance procedure. How should this procedure be= harmonized with Megaco ServiceChange (in the signaling transport option)?= Give up the B-channel maintenance altogether? Or use it - but then it= should be clear which VoIP entity is responsible to solve mismatches - and= how? Thank you, Matia Marcu Teledata Networks This mail was sent via Teledata-Networks.com=0D ***************************************************************************= ********* This footnote confirms that this email message=0D has been scanned by InterScan Messaging suite=0D for the presence of malicious code, vandals & computer viruses. ***************************************************************************= ********* ------_=_NextPart_001_01C4B509.BE32BE03 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable ISDN support with Megaco

Dear Megaco-list= members,

Two main options have been= proposed for ISDN phone /PBX support: Q,931 signaling conversion to MGCP= /Megaco or Q.931 signaling transport over the IP network to a softswitch= that supports Q.931 network side (Q.931 /IUA /SCTP).

I'll describe part of the= transport option as we figured it out and ask questions where we have a= dilemma:

1. Tone generation

Outgoing call process: the ISDN= entity sends a SETUP to the softswitch, which responds with SETUP= ACKNOWLEDGE; concerning dial tone, the softswitch may do as= follows:

  • instruct the VoIP gateway= to apply dial tone and inform the ISDN entity that in-band indication is= expected
  • instruct the ISDN entity= to apply dial tone towards the user side (ISDN phones have this= capability, so do PBXs)

In the first case, the gateway= would apply the tone as for analog interfaces - phones and trunks. The= difference appears when dial tone must stop. For analog interfaces, the= gateway performs both tone generation and event detection, meaning that= digit detection would stop dial tone. For ISDN, the softswitch would= receive the first digit signaled as Q.931 INFORMATION message and would= instruct the gateway to stop the dial tone. If this command to the gateway= gets lost, the user would be stuck with dial tone - at best for a short= time, till the retransmitted command is received, at worst for a longer= time...The same applies for other combinations of signals and= events.

If the ISDN entity applies the= tone, the problem is that the ISDN tone range is narrower than the tone= range generated by CO (and consequently by VoIP gateway) and this would= leave ISDN users with poorer functionality.

Which option is preferable?= Should vendors support both options and decide at deployment time - based= on the concrete network and the actual risk of retransmission /network= failure?

2. Service state= management

This question is intended for= the US market, where ISDN PRI standards include a B-channel maintenance= procedure. How should this procedure be harmonized with Megaco= ServiceChange (in the signaling transport option)? Give up the B-channel= maintenance altogether? Or use it - but then it should be clear which VoIP= entity is responsible to solve mismatches - and how?

Thank you,

Matia Marcu

Teledata Networks

This mail was=
 sent via Teledata-Networks.com=0D

***************************************************************************=
*********
This footnote confirms that this email message=0D
has been scanned by InterScan Messaging suite=0D
for the presence of malicious code, vandals & computer viruses.
***************************************************************************=
*********
------_=_NextPart_001_01C4B509.BE32BE03-- --===============2071127361== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============2071127361==-- From megaco-bounces@ietf.org Mon Oct 18 12:13:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28367 for ; Mon, 18 Oct 2004 12:13:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJYei-0007Eb-4p; Mon, 18 Oct 2004 10:38:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJYYj-00064E-2i for megaco@megatron.ietf.org; Mon, 18 Oct 2004 10:32:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21757 for ; Mon, 18 Oct 2004 10:32:23 -0400 (EDT) Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJYke-0001XR-6P for megaco@ietf.org; Mon, 18 Oct 2004 10:44:49 -0400 Received: from l22760A (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0I5S00DF683UAW@mta0.huawei.com> for megaco@ietf.org; Mon, 18 Oct 2004 21:28:43 +0800 (CST) Date: Mon, 18 Oct 2004 21:29:58 +0800 From: luoshaohua To: megaco@ietf.org Message-id: <00f701c4b516$907d3850$ae706e0a@l22760A> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Megaco] Hi!Everyone X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0689221414==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0689221414== Content-type: multipart/alternative; boundary="Boundary_(ID_q3qbmr/95rFazUUO03fj/w)" This is a multi-part message in MIME format. --Boundary_(ID_q3qbmr/95rFazUUO03fj/w) Content-type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7BIT Who has this ducument? Please send me a copy .Thank you! draft-ietf-megaco-naspkg-05.txt --Boundary_(ID_q3qbmr/95rFazUUO03fj/w) Content-type: text/html; charset=Windows-1252 Content-Transfer-Encoding: 7BIT
Who has this ducument? Please send me a copy .Thank you!
 
 
 
--Boundary_(ID_q3qbmr/95rFazUUO03fj/w)-- --===============0689221414== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0689221414==-- From megaco-bounces@ietf.org Tue Oct 19 02:43:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23934 for ; Tue, 19 Oct 2004 02:43:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJnOE-0003U0-3o; Tue, 19 Oct 2004 02:22:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJn5k-00049P-CQ for megaco@megatron.ietf.org; Tue, 19 Oct 2004 02:03:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08901 for ; Tue, 19 Oct 2004 02:03:22 -0400 (EDT) From: Albrecht.Schwarz@alcatel.de Received: from mailrelay1.alcatel.de ([194.113.59.55] helo=mailrelay2.alcatel.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJnHk-0004Wm-OP for megaco@ietf.org; Tue, 19 Oct 2004 02:15:56 -0400 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.12.10/8.12.10) with ESMTP id i9J62hRE006879; Tue, 19 Oct 2004 06:02:43 GMT In-Reply-To: Subject: Re: [Megaco] ISDN support with Megaco To: "Matia Marcu" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Tue, 19 Oct 2004 08:02:41 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.11 |July 24, 2002) at 10/19/2004 08:02:42 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-virus-scanned: i9J62hRE006879 at mailrelay2.alcatel.de X-Spam-Score: 0.3 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hi Matia, I'm only aware of defined technologies for the 2nd option (SIGTRAN IUA or DUA). The first case, meaning relaying CCS over GCPs (Common Channel Signalling via Gateway Control Protocol) is not supported ("because this scenario is questionable because of the "CCS protocol suite" approach, - where's typically at least layer 2 and layer 3 signalling, plus layer management" for CCS's like DSS1, PSS1, V5, GR-303, or SS7; please note that this is a significant differences of (3) CCS to (1) Analog Line Signalling and (2) CAS; guess you know that (1) & (2) are inherently supported by H.248). Conclusion: the Call/Session Control Server housing the Q.931/IUA endpoint AND the H.248 MGC endpoint is the responsible coordination instance between out-of-band signalling events (D channel) and corresponding inband signalling (B channel; terminated in H.248 MG, remotely controlled by MGC). Do I miss sth.? Regards Albrecht |---------+-----------------------------------> | | "Matia Marcu" | | | | | | Sent by: | | | megaco-bounces@ietf.org | | | | | | | | | 18.10.2004 13:58 | |---------+-----------------------------------> >-------------------------------------------------------------------------------------------------------------------------------| | | | To: | | cc: | | Subject: [Megaco] ISDN support with Megaco | >-------------------------------------------------------------------------------------------------------------------------------| Dear Megaco-list members, Two main options have been proposed for ISDN phone /PBX support: Q,931 signaling conversion to MGCP /Megaco or Q.931 signaling transport over the IP network to a softswitch that supports Q.931 network side (Q.931 /IUA /SCTP). I'll describe part of the transport option as we figured it out and ask questions where we have a dilemma: 1. Tone generation Outgoing call process: the ISDN entity sends a SETUP to the softswitch, which responds with SETUP ACKNOWLEDGE; concerning dial tone, the softswitch may do as follows: instruct the VoIP gateway to apply dial tone and inform the ISDN entity that in-band indication is expected instruct the ISDN entity to apply dial tone towards the user side (ISDN phones have this capability, so do PBXs) In the first case, the gateway would apply the tone as for analog interfaces - phones and trunks. The difference appears when dial tone must stop. For analog interfaces, the gateway performs both tone generation and event detection, meaning that digit detection would stop dial tone. For ISDN, the softswitch would receive the first digit signaled as Q.931 INFORMATION message and would instruct the gateway to stop the dial tone. If this command to the gateway gets lost, the user would be stuck with dial tone - at best for a short time, till the retransmitted command is received, at worst for a longer time...The same applies for other combinations of signals and events. If the ISDN entity applies the tone, the problem is that the ISDN tone range is narrower than the tone range generated by CO (and consequently by VoIP gateway) and this would leave ISDN users with poorer functionality. Which option is preferable? Should vendors support both options and decide at deployment time - based on the concrete network and the actual risk of retransmission /network failure? 2. Service state management This question is intended for the US market, where ISDN PRI standards include a B-channel maintenance procedure. How should this procedure be harmonized with Megaco ServiceChange (in the signaling transport option)? Give up the B-channel maintenance altogether? Or use it - but then it should be clear which VoIP entity is responsible to solve mismatches - and how? Thank you, Matia Marcu Teledata Networks This mail was sent via Teledata-Networks.com ************************************************************************** ********** This footnote confirms that this email message has been scanned by InterScan Messaging suite for the presence of malicious code, vandals & computer viruses. ************************************************************************** ********** _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Oct 25 13:16:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15143 for ; Mon, 25 Oct 2004 13:16:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM8P3-0005pn-9F; Mon, 25 Oct 2004 13:13:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM8F9-0004dt-Gm for megaco@megatron.ietf.org; Mon, 25 Oct 2004 13:02:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14233 for ; Mon, 25 Oct 2004 13:02:48 -0400 (EDT) Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM8Sb-0002wm-Lr for megaco@ietf.org; Mon, 25 Oct 2004 13:16:48 -0400 Received: from r70036l (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0I6500M18F81D6@mta0.huawei.com> for megaco@ietf.org; Tue, 26 Oct 2004 00:31:17 +0800 (CST) Date: Mon, 25 Oct 2004 17:32:06 +0100 From: Rajeev K R To: megaco@ietf.org Message-id: <003801c4bab0$2d5ee260$3b80a8c0@r70036l> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7BIT Subject: [Megaco] Actions at MG during MGC oveload X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7BIT Hi All, Issue: MGC is overloaded and has detected that a particular MG (or rather subscribers on a particular MG) is placing lot of calls and could be an apparent reason for the overload. MGC wants to restrict the call rate from the MG. MG terminations are supervised for offhook with embedded dial tone signal and digit collection on off-hook event detection. So the MGC dos not issue a MOD command to MG to play dial tone and collect digits. So obviously during the overload situtaion MGC do not want to control individual terminations to restrict the call rate as it would deteriorate its load condition. I thought of the following actions: 1. MGC modify the digitmap to allow only certain digit strings(like 911) to be reported. This can be done for all terminations using wildcard so that this action does not impose burden on MGC. This is perfectly legal in H.248 so not much to discuss about this. 2. MGC instruct the MG to delay dialtone. This should be done in the embedded signal itself. Otherwise the MGC has to remove the embedded dial tone signal globally and delay the playing of dialtone for individual termination by sending a delayed MOD(sig=dialtone) message. This would impose processing burden on the already overloaded MGC. This can be done by defining a new signal DelayedDialtone with delay parameter. This will be set globally replacing the normal cg/dt event. 3. MGC instruct the MG to delay reporting of digit collection event. (Delaying off-hook event notification is not considered as the MGC need to know this info immediately for termination state machine. A new event DelayedDigitmapCompletion with delay parameter will be defined for this. This will be set globally replacing the normal dd/ce event. 4. Instruct the MG to ignore dialling events for a percentage of terminations. A new property IgnoreDialPercentage will be defined for ROOT termination. The MG will ignore digits for a percentage of terminations. The algorithm at MG will be defined in the package so that a subscriber is not denied service for a long time. This could be coupled with playing a different tone than dialtone if the dialling is to be ignored for a termination. 5. Instruct the MG to ignore dialling events based on temination priority. A new property for physical terminations to indicate priority. This will be set by MGC based on subscriber information after MG restart or when a new subscriber is provisioned in MGC. A new property IgnoreDialPriority will be defined for ROOT termination. MG will ignore the dialled digits for terminations if the termination priority is less than this ROOT property value. This could be coupled with pecentage , i.e a certain percentage of subscribers below a certain priority would be denied service. This could also be coupled with playing a different tone than dialtone if the dialling is to be ignored for a termination. 6. Instruct the MG that MGC is overloaded and MG take the above actions by itself. based on pre-provisioned values. I would like to know whether the suggested actions contain any protocol violation. In all these actions, I am not giving the MG the freedom to decide anything here. Everything is still happening under the control of MGC. Of course, except the percentage mechanism where the MG actually decides who are the unfortunate subscribers. But still the action is initiated by MGC. I would espcially like to know whether MG actions like delaying event reporting, delaying signal and ignore events selectively based on ROOT properties are legal. This solution need to be implemented across multiple vendors, so I thought I better clarify all these before I proceed. Thanks, Rajeev _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Oct 26 01:59:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16073 for ; Tue, 26 Oct 2004 01:59:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMKKH-0002in-37; Tue, 26 Oct 2004 01:56:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMKG4-0002Dn-AN for megaco@megatron.ietf.org; Tue, 26 Oct 2004 01:52:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15810 for ; Tue, 26 Oct 2004 01:52:35 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.196]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMKTe-0002vX-Ik for megaco@ietf.org; Tue, 26 Oct 2004 02:06:39 -0400 Received: by wproxy.gmail.com with SMTP id 55so142368wri for ; Mon, 25 Oct 2004 22:52:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=bdQc4JBvG2THgs2EmNTa6q2+VRIb4aCQShCmD0C+i3tMmnLpTY5mV4ezC1M/nqSgkC/HJvVN3RNC24FQrHEaUIkGilXqef5mfsI1fg38rmILZgO4Yvuiwa6zuIeTFaLYFkkf8anlyRRNbRyNA9xGCWNI+XbiZc8WsOo2yCvNyQo= Received: by 10.38.76.16 with SMTP id y16mr175431rna; Mon, 25 Oct 2004 22:52:02 -0700 (PDT) Received: by 10.38.72.26 with HTTP; Mon, 25 Oct 2004 22:52:01 -0700 (PDT) Message-ID: <52a9bccc041025225225926cd1@mail.gmail.com> Date: Tue, 26 Oct 2004 11:22:01 +0530 From: Jagan Mohan To: MEGACO list Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Subject: [Megaco] Require clarification on Audit of Statistics X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jagan Mohan List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, I have a H.248 VoIP call b/w 2 gateways. Say, the RTP termination on one gateway goes down and it's reported to the MGC. Now, the MGC should send a SUBTRACT message to the gateway for subtracting the RTP termination. Here, a normal subtract command from MGC would mean that Audit of Statistics should be done on the gateway. But since the RTP termination has gone down, Audit of statistics would fail on the gateway. So, should the MGC send (A) SUBTRACT command MEGACO/1 [10.10.10.1]:2944 Transaction = 11025 { Context = 4 { Subtract = R10 } } OR (B) SUBTRACT command and Audit with no descriptor. MEGACO/1 [10.10.10.1]:2944 Transaction = 11025 { Context = 4 { Subtract = R10 { Audit { } } } } Regards, Jagan _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Oct 26 14:10:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00289 for ; Tue, 26 Oct 2004 14:10:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMVbu-00030J-K6; Tue, 26 Oct 2004 13:59:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMVZ5-0001ak-3Q for megaco@megatron.ietf.org; Tue, 26 Oct 2004 13:56:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29011 for ; Tue, 26 Oct 2004 13:56:57 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMVmm-0000ve-FU for megaco@ietf.org; Tue, 26 Oct 2004 14:11:08 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9QHuP919445; Tue, 26 Oct 2004 13:56:25 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Oct 2004 13:56:26 -0400 Message-ID: From: "Kevin Boyle" To: Jagan Mohan , MEGACO list Subject: RE: [Megaco] Require clarification on Audit of Statistics Date: Tue, 26 Oct 2004 13:56:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.8 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1265943116==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org 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. --===============1265943116== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4BB85.184BE846" 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_01C4BB85.184BE846 Content-Type: text/plain The spec is clear that it must include an empty audit descriptor to suppress statistics in v1 and v2. Kevin -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Jagan Mohan Sent: Tuesday, October 26, 2004 1:52 AM To: MEGACO list Subject: [Megaco] Require clarification on Audit of Statistics Hi, I have a H.248 VoIP call b/w 2 gateways. Say, the RTP termination on one gateway goes down and it's reported to the MGC. Now, the MGC should send a SUBTRACT message to the gateway for subtracting the RTP termination. Here, a normal subtract command from MGC would mean that Audit of Statistics should be done on the gateway. But since the RTP termination has gone down, Audit of statistics would fail on the gateway. So, should the MGC send (A) SUBTRACT command MEGACO/1 [10.10.10.1]:2944 Transaction = 11025 { Context = 4 { Subtract = R10 } } OR (B) SUBTRACT command and Audit with no descriptor. MEGACO/1 [10.10.10.1]:2944 Transaction = 11025 { Context = 4 { Subtract = R10 { Audit { } } } } Regards, Jagan _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C4BB85.184BE846 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Megaco] Require clarification on Audit of = Statistics

The spec is clear that it must include an empty audit = descriptor to suppress statistics in v1 and v2.

Kevin

-----Original Message-----
From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Jagan Mohan
Sent: Tuesday, October 26, 2004 1:52 AM
To: MEGACO list
Subject: [Megaco] Require clarification on Audit of = Statistics

Hi,

  I have a H.248 VoIP call b/w 2 gateways. Say, = the RTP termination on one gateway goes down and it's reported to the = MGC. Now, the MGC should send a SUBTRACT message to the gateway for = subtracting the RTP termination.

  Here, a normal subtract command from MGC would = mean that Audit of Statistics should be done on the gateway. But since = the RTP termination has gone down, Audit of statistics would fail on = the gateway.

  So, should the MGC send

(A) SUBTRACT command 

MEGACO/1 [10.10.10.1]:2944
Transaction =3D 11025 {
    Context =3D 4 {
          &nb= sp; Subtract =3D R10
    }
}


OR

(B) SUBTRACT command and Audit with no = descriptor.

MEGACO/1 [10.10.10.1]:2944
Transaction =3D 11025 {
    Context =3D 4 {
          &nb= sp; Subtract =3D R10 { Audit { } }
    }
}

Regards,
Jagan

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

------_=_NextPart_001_01C4BB85.184BE846-- --===============1265943116== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1265943116==-- From megaco-bounces@ietf.org Wed Oct 27 00:40:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02553 for ; Wed, 27 Oct 2004 00:40:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMfaP-000106-1c; Wed, 27 Oct 2004 00:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMfZA-0000i9-CA for megaco@megatron.ietf.org; Wed, 27 Oct 2004 00:37:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02327 for ; Wed, 27 Oct 2004 00:37:40 -0400 (EDT) From: ajohri@hssworld.com Received: from spark.hss.co.in ([203.200.71.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMfmv-0004IT-P1 for megaco@ietf.org; Wed, 27 Oct 2004 00:51:58 -0400 Received: from spark.hss.co.in (localhost [127.0.0.1]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id i9R4YUJT014755 for ; Wed, 27 Oct 2004 10:04:31 +0530 (IST) Received: from dlfmail1.hss.hns.com (dlfmail1 [172.16.32.24]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id i9R4YU9s014752; Wed, 27 Oct 2004 10:04:30 +0530 (IST) Subject: Re: [Megaco] Require clarification on Audit of Statistics To: Jagan Mohan Date: Wed, 27 Oct 2004 09:54:43 +0530 Message-ID: X-MIMETrack: Serialize by Router on Dlfmail1/HSS(Release 6.0|September 26, 2002) at 10/27/2004 09:54:44 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 3.4 (+++) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hello, I agree with you that since RTP termination has gone down, gateway may not have information for all the statistics when the termination gets subtracted by MGC. However, some statistics like call duration can be calculated by gateway internally by taking time stamps at the start and the end of the call.So it would still be possible for the media gateway to report these statistics. So I think sending (a) would not be a bad idea. Gateway would in this case fill a zero for all other statistics except for the ones which it has information on like "duration of the call". Regards, Abhishek Hughes Software Systems. www.hssworld.com Jagan Mohan @ietf.org on 10/26/2004 11:22:01 AM Please respond to Jagan Mohan Sent by: megaco-bounces@ietf.org To: MEGACO list cc: Subject: [Megaco] Require clarification on Audit of Statistics Hi, I have a H.248 VoIP call b/w 2 gateways. Say, the RTP termination on one gateway goes down and it's reported to the MGC. Now, the MGC should send a SUBTRACT message to the gateway for subtracting the RTP termination. Here, a normal subtract command from MGC would mean that Audit of Statistics should be done on the gateway. But since the RTP termination has gone down, Audit of statistics would fail on the gateway. So, should the MGC send (A) SUBTRACT command MEGACO/1 [10.10.10.1]:2944 Transaction = 11025 { Context = 4 { Subtract = R10 } } OR (B) SUBTRACT command and Audit with no descriptor. MEGACO/1 [10.10.10.1]:2944 Transaction = 11025 { Context = 4 { Subtract = R10 { Audit { } } } } Regards, Jagan _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ***************** HSS-Unclassified ************* "Please note:The email domain of Hughes Software Systems Ltd. has been changed to "hssworld.com" from hss.hns.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-bounces@ietf.org Wed Oct 27 15:09:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03171 for ; Wed, 27 Oct 2004 15:09:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMt7N-0005b1-FY; Wed, 27 Oct 2004 15:05:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMsrg-00070w-TO for megaco@megatron.ietf.org; Wed, 27 Oct 2004 14:49:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00975 for ; Wed, 27 Oct 2004 14:49:42 -0400 (EDT) Received: from [212.179.22.140] (helo=imss.audiocodes.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMt5Q-00043E-K7 for megaco@ietf.org; Wed, 27 Oct 2004 15:04:08 -0400 Received: from aclmsg.corp.audiocodes.com ([10.1.0.8]) by imss with InterScan Messaging Security Suite; Wed, 27 Oct 2004 21:54:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [MEGACO] Can the 'Z' digit timer have the value of 0? Date: Wed, 27 Oct 2004 20:49:49 +0200 Message-ID: X-MS-Has-Attach: yes Thread-Topic: [MEGACO] Can the 'Z' digit timer have the value of 0? Thread-Index: AcS8VbxxJpR8F9YeSeKDtxvUu0El2w== From: "Nurit Shenhar" To: X-Spam-Score: 0.4 (/) X-Scan-Signature: 6379955759c38e2371a49573a0932fc7 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0874728339==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0874728339== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C4BC55.BC0E6E26" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4BC55.BC0E6E26 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C4BC55.BC0E6E26" ------_=_NextPart_002_01C4BC55.BC0E6E26 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =0D The spec defines the following for the digit map timers: =0D digitMapValue =3D ["T" COLON Timer COMMA] ["S" COLON Timer COMMA] ["L" COLON Timer COMMA] ["Z" COLON Timer COMMA] digitMap=0D Timer =3D 1*2DIGIT ; Units are seconds for T, S, and L timers, and hundreds of=0D ; milliseconds for Z timer. Thus T, S, and L range from 1 to 99 ; seconds and Z from 100 ms to 9.9 s =0D I know that the first three can have the value of 0, which means ignore. Is there such a possibility for the 'Z' timer? If yes, what does it mean? =0D Thanks, =0D =0D =0D Nurit Shenhar H.248/MEGACO architect =0D =0D Tel +972-3-9764000 Fax. +972-3-9764223 www.audiocodes.com =0D =0D =0D ***************************************************************************= ********************************* This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity= to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination,use, distribution or copying of this communication is strictly prohibited and= may be unlawful. If you have received this email in error please notify= postmaster@audiocodes.com and permanently delete the e-mail and files. ***************************************************************************= ******************************** ------_=_NextPart_002_01C4BC55.BC0E6E26 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

The spec defines the following for the digit map= timers:

 

digitMapValue      &nbs= p; =3D ["T" COLON Timer COMMA] ["S" COLON Timer= COMMA]

         = ;            &n= bsp; ["L" COLON Timer COMMA] ["Z" COLON Timer= COMMA]

         = ;            &n= bsp; digitMap=

Timer        =         =3D 1*2DIGIT

; Units are seconds for T, S, and L timers, and hundreds of

; milliseconds for Z timer. Thus T, S, and L= range from 1 to 99

; seconds and Z from 100 ms to 9.9= s

 

I know that the first three can have the value of= 0, which means ignore. Is there such a possibility for the ‘Z’= timer? If yes, what does it mean?

 

Thanks,

 

=  

= Nurit Shenhar

H.248/MEGACO architect

 

Tel   +972-3-9764000

Fax.= +972-3-9764223

www.audiocodes.com

 

 

------_=_NextPart_002_01C4BC55.BC0E6E26-- ------_=_NextPart_001_01C4BC55.BC0E6E26 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlheQAWAPQAAAAAAP////Hz9yFGez1djEtplFl0nGeApHWMrYOXtZCivau5zbnF1tXc5i9S g52uxcfR3uPo7v///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/C01T T0ZGSUNFOS4wGAAAAAxtc09QTVNPRkZJQ0U5LjAgJPn1cgAh/wtNU09GRklDRTkuMBgAAAAMY21Q UEpDbXAwNzEyAAAAA0gAc7wALAAAAAB5ABYAAAX/oDGMwxKcJ0Ou7GigcCzPdG3feC6LIzIrreBL RywajznesCGIHYKsIXJKrdpEhabAIT0JClBS10ouHw2ORuA7UsQijvBgbK7baQbICbFixCBydCkG gndvDwcGBFwHDxGGJ2oBDywOjzAMCgoQnJyZJjMEI6CQMQJ8UA6lKUEFMgILCgmECQoMTTIqIwRI CxAMj7g2bC6SEQkDPjmdeobEUTM8I81FYAMQQJZXJMqY1DdAA245AqIrD8Nx0H8D6nNnI8fxNbrt wkjh4zioJN8BEZdQNGhBR4QCfgF18DgBQRINft2m5FN4bgedBetQAHIgYGAPFLEUqAn5CAICAwms //3jhGtBogOgpKGzYZLQA1wCZiF4Im7NA0IIJLlEGUEarxgeZ8Lg9w7Gk3HSLvHQM1UXAWsDAoRb A6bAgq4CpPmpwceBy3ZMrElTAEecLgjICM2RlkAGxnaa8mpy1yVCD03SlE0NMNVcE3NaRwRApUbX TxL67I5AJ2DEgXDo8pU9IYIngggIFqyVEU6Oi6VhOBKetrrE6QDIsm5Vx9BF7AGuHrIOoI5HyTai CABux7dBYBmATL/+Nwp1m9ZUJ7+OnTgridpz/JIgFWNwADGKAyRXoA5B3gcL3HEhoTqGu0Ao+BzV yD7sCD/mkh9VudVaE8cB3DUZDBEcUEBsflSGG6oqetylAE+R+bKAOdLgdk8A9cDH3AB1xWCOOKV9 aNJklEyzlS4KsNFeeuwRYg1bcRiQ0zTJFcCAOpuQUItwBBCACG6zEEKLXUIWaWSHsxDgEAoPFOBi AzwVkIgBTKBCgIsQLJDAAY8wYI0DCNwjwGMrHNgEaOoc0MyE7VxpADoQ8DQAlwikGYEEeOap5558 9unnn4AGKuighBZq6KGIJqrooow26uijkAoaAgA7 ------_=_NextPart_001_01C4BC55.BC0E6E26 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhegBVAPcAAAAAAP///yInMgkTIQgTIAgSIAB9xe0jJNeNju0cJO4dJeAeJeEfJtSDhucd KOUdKOYeKeEeLd4eL1M6PNweMdkfM81FUtUeNtYfNtMfOdAfPM4fPs4gPsJbbc6LlsggQ8cgQ5Es P8cfQ8A0Ur1DX8IgR8EgScIhST0lK74hTb0hTciKnMeJm7ghULchUrchUbciUoYrSD0jK8eJnMaK nrIhVLEhVLIiVTwjLMSJn8OInq4hV68iWKwhWawiWachXKgiXL+Fn6IhYHsqUaAhYaAhYqIiYaEi YqtagrVyk54iZJ0iZDkiLp0hZJshZa1ljZwyb7uHpZghaJchaZ1MgZMhbEk0Qo8hcI4hb2g1W3lN bYBZd1kcTGAqVLSFqrKLqlIMRVMNRoMsdIQtdYA6dX86dYA7dox2jDIhM6aZqC4gNSwfNmpddKKh p2hncFxbZVBQWk9PWVtbZVxcZWhocUNETkRFT09QWk9QWS4xPISRvC4xOzg7RSMnMmJmcmt+sC0x OyMoMxcdKU5spBceKhceKQkTIChbmHqv3muo2oOJjgBRkkaZ1Fuj0QB+xiuT0SyU0QCCyAB/wACL zACIxW+uywCCuC+awQCJtgCFsgCUvS+duwCKq364x1tscEqmt2NzdgCQpwCMoi+hr4C9uQChkwCU iUuspC6pmACXfwCYf3K6rU91bgCadmC2oXaNhwCdagyKYgyJYgCeagCdaQCSXQCRXJytpwCgXgCZ WAChUgB9QAeCRjOvdILFopK3ol2QciyHTnLEkoy9n0CMV4uplGyfdnmmgHmlf/aMK/WBIPy9hvR4 IfR8K/NxIfV/N6hfMPaNTfqxgvNuIfNtIfNuIvR2K/mldfJqIfNrIvJiIvFiIvJsK/JkK/FZIvFa I/FdKvBSI6dKLu+SePJqSvNzVetyVvBII+9II+9HI+p9ZOVWPuplTOeSgu89I+8+JONHNuVWRuVk U+4wI+4wJOI2LNZjXN6PityOirGOjOg2L9hxbe4kJNpVU9mOjv///yH/C01TT0ZGSUNFOS4wFwAA AAttc09QTVNPRkZJQ0U5LjBCPKT1ACH/C01TT0ZGSUNFOS4wGAAAAAxjbVBQSkNtcDA3MTIAAAAD SABzvAAh+QQBAAD/ACwAAAAAegBVAAAI/wD/CRxIsKDBgwgT/qOjsKHDhxAjSpz4kGGdfxfp8LFD saPHjyAN7hEkhyCff4YW/jspcKOAkDBjyhQgSCDHgif3CODIR5Cbf30E/nzzU6bRowl/4iFI6ObA kycHrBwoQE7Qfz7/2cmTB6nXozxNGixZMs6/kgLNdg1k52RXhoQYfp0LEWqdOm/+5Z0z9Q6fvBHd wGlpcynWq3QTI+za9d+ef4C0CgIM8k2cpU4F1lTMOfLUx1MpG33DEvRLlpwT45W7507jxGaBCsBT NDXdOJttUz27FK3ur3Dk/hYol+XF4R89I094HPXyiXt8Pzdoxw2dkgIExJ6u8GX2l9wNxv/h2Ph1 ePGQCWk9j9A5X/a7026HTzD3SsPsc9JvuJ0P6PAsCcIRePslRCB7jdEkEx2CzOcVfv8tV5QczoXk BiEFEFCAfXMh9hwcJPnHYUd0EKKhhgUUoNh7jnEX4UcMDpDiABoOUGFCdwggI4oFCDBYQ5GZ99yL E5VYgIwD7JiiQ3EcmSQBBOyIoiEHGnSdQNkVCJEgKUZJY5RHOoiTl5lBNmOKKR6H0Bt9cCSmlgQJ kOEAhiRJY5KGqIgQHmBWOVAeTp4pJEE/CQJHmXTJIVxHcqLZJY9JvokVlAWoeZCXR544qFi61TTY og8JAKWMmdZIqowHvXFkAYZIOpAdNJ7/mSZCsblBQG109fFSHKAqBGiSjq4aa5QE3GEQH6QWsKlB XyoJZXc1jfhVHHx42B2KPGKbYZeoFrTHnAT4iVCX26Io7kJFuSoTkd01eyaSwGaaIa5Y1RlrRIDE iiSlBuoWyLJxfrnqwKyiKTABhRTEZYYaikYodfGSCqV0BPU6140GyZmtk3aeCeaqiy5Mqp8E0EGH noQquW2KAKcGh3oN5ZEnlCduC+i7KdaZ8J9zbnvQAHfIgfJAbjj6sYbTxYZfQoJQiuZVfIDJI5rC wRorywa5IWPUBVRYY89oPoeHugZhCOV8+56YZwEwL9RznlIdVIDJBMxRobyjhr3cS3lY/9qQAPR+ u+3MBROk8pHWDjT3yRoVdCKxDMcN50NfD5wngY1OnVABbhTtRoXJGgL50JMn1AedyQo7kBw15yyt QMo22bjhaFLKb+kNlQv3qgQyPLXDBLVF4T8s/lN07dvSibtCE6DgvAwy4IADE9QPZAUa2KOhxvZr eHTy1OUut7RH6bhDzwEJQCBBBRlsYMFANfTwgxFKSFHFFVR4xEfBG+/820V1yAO9IgIOdJiPHwpQ H/s4MBAS3KAHQBBCE+yHheVFBDUYc8g1wmFAevAjfevLgD0G8oIb+OAHQlgCBS0IETqYJTgd6UY4 zuGOeaDPASFsYAts4AMgGEGFVcgfQf/G0Y52DMQfA/GAQGgwkCgI5Atf+Eca0iCQW9ziH78YxjB8 IRBf+IIUBdnEJQqCCEQMpIxmFEgZ1Vgxj0jDGzM8YAJwWIERCiQFL6jBCelnPycSJAIUwIBA7mGC EfyjAzv4xwqO4IR/RKGCXhgDGf6xBTYIhBXA+EcsbJELXfTiH7iARStSUQqBiIITmbDEQAzASjMi gpUGcEQi/hEJAwjEAIxQyUe4AUca2hCEFRjIPlQAAx6icIJVMAggLyAQfJwgBYfkwT9mwEhHXuEf kSzDP87Ahjb8gxWv+IcsbNGLXggDlLRwRSpM8Y9PiGITmrDELP8By1y+chKTcIQtGWH/gDI6YnVd o4g0tgHH8nkwgRKQx0BKoII87hGIBRnHMptpAhU0oAPSXEERnJCER2JTDJPkpjdZUQxN1oIguKDF P0phClKMQhQCsQQkbhnLmSLCEY+gpy3/4QhIPGKncVDORKyhjW+EIx3v8GACHiABgjC0hHusHxIK Yo5lGvEeJ1BBBzA6TUZCIQrX9IIYzCBFNijim1fcJEph8Q9UtPSlnyiIIyZhgEn845UzZaVAHFFL u/6DWnmgmEOkgQ2CHlWODlCoQOxRURfYQH5GmKAfB8KOCLTjAvv4ByFV0AISJJKaTpjCEyA5Bm3+ w6xtYIVA1DqQlP5jnaToxCkbcUZc/+r1ppN45U5rKcuQNCMb2uhlUj/4AIKAIKvFPGEKpWAQfVgW AyMkZApacIPPbnQK98OmJAXCBj8oQrUm7aRAUjpKdv4jFKik7V3/eVtY9lQgkIilQCjUk4lIwxmF hWMH0ccO4z5Vj/OboEEcEI9/XKAf/8BHCTrQghpktAhIwC4kQcpdP7wCvJsULzpHuYqBoFKV//gp T//5Sn3u9B+J0CtImuEM4Or3gAogyD0+wNBiyk+CzC2IA+ChjgtoQLMmaECDpcmCIuQACtmNJFlP 6wdQgHeca12FKk5BEExYghL/oGuKSWyAR9Sytv8syAATsgxmtNiwBuUHOQiyDxFk9f8FxqTfVHUs AQr4OMEnQEAHHPyPIusgCUkew5LP4AdPhNOka/2HKkr5j07EVBI6heVdDeDTfq7yxESLSDLMnA3D 0tCDBbEHjVXg2B5KcM4ESWw7MPBjQiKRzzMgQg7+UYUJT3KbhT4rolurUlWw052OtgSk64oIupax y4nA6aUFMgdBCCCDB1mGMjgd3KMmdc0E2QAIamzCAAchog4Yxz9YjWck3kCa1Jx1rT9q2jQU+oqa JGc50fladsqWE5e4Mj1n2ghHNOKVOTVAJAbiiDB3JBnTPrNRP20QbT81zkr4NkHK4QCB9OPHzkTA Pzw7TSP/gwph3e4/2lDogcSiFp3/1AUoZ7HSlp73w7e0J07xqlOCn/hziUOItBOOjaJy0B3Yzva2 Sf3Y+UXcIOIWiBH/gUSBKHGaTXxiFAXSBm8KJItb5KIXBQJGgVSiEmcM+13VmMa7ptE6UHkIwhPu 4jgeZAMfePMDI3h0FlbkH6dxSD6gwXdoiMPv4gi8HQsSgsLH4PBDSPwQ8kERPjj+8dBGDh949ZBC iM5OSFqS3IxWM7IdK3JRatlzhHoQOjitdhrKOVAwL6WASgR8okfOyRzSNJplKE95SogdUESnlZ0L IadT0uumkwcBGEshWjNV8gqgetgNLFsROdnK2MWe4TENbI4awJgVB6ypESAiqI/9/+RMfyIp0aht 7YlcqQYg2IOYiGGIoo8ddJQQDOHtTgTwvMF2dH6H7CFvFrMfclA8BNEkpwImSPIQcNAzoyIj2ycQ /5civ7cf4eI3zgcuj+N6DgEIONMlBlIjDzg5DoMHVxMvHhgRdoAzSTIiTaIhngcn1kIu3JInjkcR OjIjmUcIjsclAyAIx2d3BbEodNA5IdgRddA0wPIkBNAUQFgQ3vFXkfcV1tGECSFAeRCFVLgcP6Ib SYcQ0pCFDaEHCmEMCqEFCrEOCvEMYKgQg/AHCREMyJAQXHAGCbEACkENa2gQg3AIf7AIfHgIgzAQ xBAMxrALhMgLZCgQWdAFWwAGWeWgBVywBQNRD/BgDgzADuZQD11oDdEQDc7Qic6QhwPRh4tQim5I EMSwC6q4C3FIEFkQBmAAiwaxDgywAAzAAAZhDdWwi80gigOhB6VYigZRiKrICwbRiGAABlxgEOxg iwsADwYRDbtIDdHgi//Qh4fgh4dwCAQBDIa4C7wAjq4IBl1AjspIEOvwjAxQDwuAhgPxDNQAj9aA DdVojf/AhwJxiiUlELtwDALhjwUBBgMhif/QhXYoEOogENcwENMwEF9ojYGYEMSgEF2gEAeJEHho j7+oEACJEASJEAmZEAupkSSZGgEBADs= ------_=_NextPart_001_01C4BC55.BC0E6E26-- --===============0874728339== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0874728339==-- From megaco-bounces@ietf.org Wed Oct 27 16:50:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12703 for ; Wed, 27 Oct 2004 16:50:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMuaR-0005uk-9F; Wed, 27 Oct 2004 16:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMuSn-00036k-Re for megaco@megatron.ietf.org; Wed, 27 Oct 2004 16:32:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10680 for ; Wed, 27 Oct 2004 16:32:07 -0400 (EDT) Received: from [200.51.236.210] (helo=mail3.telefonica.com.ar) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMugf-0006U2-9r for megaco@ietf.org; Wed, 27 Oct 2004 16:46:34 -0400 Received: by mailhub.telefonica.com.ar with Internet Mail Service (5.5.2657.72) id ; Wed, 27 Oct 2004 17:31:39 -0300 Message-ID: <6BB2DEB822D3D111817B00805FBE5F021518274C@mstelefonica6.telefonica.com.ar> From: Pellegrino Jose Luis To: "'megaco@ietf.org'" Date: Wed, 27 Oct 2004 17:31:32 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.1 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Subject: [Megaco] NAS packages X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1779468094==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org 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. --===============1779468094== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4BC63.F1F31380" 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_01C4BC63.F1F31380 Content-Type: text/plain; charset="iso-8859-1" Hi, Some years ago IETF Published Draft-ietf-megaco-nasppkg-02.txt, wich then became obsolete. Two years late another draft appeared, Draft Megaco/H.248 NAS Packages (April 2002), wich, became obsolete too. I was wondering if are there any work in progress in order to take back the NAS packages or, in the other hand, this topic has been closed. Has been the subjet handled in the ITU-T? Regards ------_=_NextPart_001_01C4BC63.F1F31380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi, =

&nbs= p;

Some years ago IETF Published Draft-ietf-megaco-nasppkg-02.txt, wich then =A0became obsolete. Two years late another draft =A0appeared, Draft = Megaco/H.248 NAS Packages (April 2002), wich, became = obsolete too.

&nbs= p;

I was wondering if are there any work in progress in order to take back the = NAS packages or, in the other hand, this topic has been = closed.

&nbs= p;

Has been the subjet handled in the = ITU-T?

&nbs= p;

Regards

 

 

------_=_NextPart_001_01C4BC63.F1F31380-- --===============1779468094== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1779468094==-- From megaco-bounces@ietf.org Wed Oct 27 18:36:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23940 for ; Wed, 27 Oct 2004 18:36:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMwJv-0005tR-90; Wed, 27 Oct 2004 18:31:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMw8O-0002zI-Ko for megaco@megatron.ietf.org; Wed, 27 Oct 2004 18:19:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22234 for ; Wed, 27 Oct 2004 18:19:09 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMwMJ-0000lU-8P for megaco@ietf.org; Wed, 27 Oct 2004 18:33:37 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9RMIY008172; Wed, 27 Oct 2004 18:18:35 -0400 (EDT) Received: from [47.130.24.99] (acart13b.ca.nortel.com [47.130.24.99]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VN20KS0P; Wed, 27 Oct 2004 18:18:35 -0400 Message-ID: <41801EBA.7010707@nortelnetworks.com> Date: Wed, 27 Oct 2004 18:18:34 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pellegrino Jose Luis Subject: Re: [Megaco] NAS packages References: <6BB2DEB822D3D111817B00805FBE5F021518274C@mstelefonica6.telefonica.com.ar> In-Reply-To: <6BB2DEB822D3D111817B00805FBE5F021518274C@mstelefonica6.telefonica.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: "'megaco@ietf.org'" X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit The work was dropped for lack of interest. Pellegrino Jose Luis wrote: > Hi, > > > > Some years ago IETF Published Draft-ietf-megaco-nasppkg-02.txt, wich > then became obsolete. Two years late another draft appeared, Draft > Megaco/H.248 NAS Packages (April 2002), wich, became obsolete too. > > > > I was wondering if are there any work in progress in order to take back > the NAS packages or, in the other hand, this topic has been closed. > > > > Has been the subjet handled in the ITU-T? > > > > Regards > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco -- Tom Taylor Carrier VoIP Standards Development Nortel Networks Phone +1 613 763 1496 (ESN 393-1496) E-mail: taylor@nortelnetworks.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Oct 28 23:12:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01366 for ; Thu, 28 Oct 2004 23:12:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNMgF-0005nd-FO; Thu, 28 Oct 2004 22:39:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMS9C-0005OC-PL for megaco@megatron.ietf.org; Tue, 26 Oct 2004 10:18:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08523 for ; Tue, 26 Oct 2004 10:18:00 -0400 (EDT) From: ksaurabh@hssworld.com Received: from spark.hss.co.in ([203.200.71.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMSMo-0003vr-9h for megaco@ietf.org; Tue, 26 Oct 2004 10:32:10 -0400 Received: from spark.hss.co.in (localhost [127.0.0.1]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id i9QEEkJT018251 for ; Tue, 26 Oct 2004 19:44:47 +0530 (IST) Received: from sandesh.hss.hns.com (sandesh [172.16.32.19]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id i9QEEk9s018245; Tue, 26 Oct 2004 19:44:46 +0530 (IST) In-Reply-To: <52a9bccc041025225225926cd1@mail.gmail.com> MIME-Version: 1.0 To: Jagan Mohan Subject: Re: [Megaco] Require clarification on Audit of Statistics X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Tue, 26 Oct 2004 19:35:24 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 26/10/2004 07:57:55 PM, Serialize complete at 26/10/2004 07:57:55 PM X-Spam-Score: 3.9 (+++) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 X-Mailman-Approved-At: Thu, 28 Oct 2004 22:39:54 -0400 Cc: ksaurabh@hssworld.com, MEGACO list X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0320356213==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multipart message in MIME format. --===============0320356213== Content-Type: multipart/alternative; boundary="=_alternative 004EA0C665256F39_=" This is a multipart message in MIME format. --=_alternative 004EA0C665256F39_= Content-Type: text/plain; charset="US-ASCII" Hello Jagan, I agree with you that since RTP termination has gone down, gateway may not have information for all the statistics when the termination gets subtracted by MGC. However, some statistics like call duration can be calculated by gateway internally by taking time stamps at the start and the end of the call. So it would still be possible for the media gateway to report these statistics. So I think sending (A) would not be a bad idea. Gateway would in this case fill a zero for all other statistics except for the ones which it has information on like "duration of time the termination has been in the context". Regards, Saurabh Hughes Software Systems www.hssworld.com Please respond to Jagan Mohan Sent by: megaco-bounces@ietf.org To: MEGACO list cc: Subject: [Megaco] Require clarification on Audit of Statistics Hi, I have a H.248 VoIP call b/w 2 gateways. Say, the RTP termination on one gateway goes down and it's reported to the MGC. Now, the MGC should send a SUBTRACT message to the gateway for subtracting the RTP termination. Here, a normal subtract command from MGC would mean that Audit of Statistics should be done on the gateway. But since the RTP termination has gone down, Audit of statistics would fail on the gateway. So, should the MGC send (A) SUBTRACT command MEGACO/1 [10.10.10.1]:2944 Transaction = 11025 { Context = 4 { Subtract = R10 } } OR (B) SUBTRACT command and Audit with no descriptor. MEGACO/1 [10.10.10.1]:2944 Transaction = 11025 { Context = 4 { Subtract = R10 { Audit { } } } } Regards, Jagan _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ***************** HSS-Unclassified ************* "Please note:The email domain of Hughes Software Systems Ltd. has been changed to "hssworld.com" from hss.hns.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." --=_alternative 004EA0C665256F39_= Content-Type: text/html; charset="US-ASCII"
Hello Jagan,

I agree with you that since RTP termination has gone down,  gateway may not have information for all the statistics when the termination gets subtracted by MGC. However, some statistics like call duration can be calculated by gateway internally by taking time stamps at the start and the end of the call. So it would still be possible for the media gateway to report these statistics.

So I think sending (A) would not be a bad idea. Gateway would in this case fill a zero for all other statistics except for the ones which it has information on like  "duration of time the termination has been in the context".

Regards,
Saurabh
Hughes Software Systems
www.hssworld.com



Please respond to Jagan Mohan <jaganmk@gmail.com>


Sent by:        megaco-bounces@ietf.org

To:        MEGACO list <megaco@ietf.org>
cc:        

Subject:        [Megaco] Require clarification on Audit of Statistics



Hi,
I have a H.248 VoIP call b/w 2 gateways. Say, the RTP termination on
one gateway goes down and it's reported to the MGC. Now, the MGC
should send a SUBTRACT message to the gateway for subtracting the RTP
termination.
Here, a normal subtract command from MGC would mean that Audit of
Statistics should be done on the gateway. But since the RTP
termination has gone down, Audit of statistics would fail on the
gateway.
So, should the MGC send
(A) SUBTRACT command
MEGACO/1 [10.10.10.1]:2944
Transaction = 11025 {
Context = 4 {
Subtract = R10
}
}

OR
(B) SUBTRACT command and Audit with no descriptor.
MEGACO/1 [10.10.10.1]:2944
Transaction = 11025 {
Context = 4 {
Subtract = R10 { Audit { } }
}
}
Regards,
Jagan
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


*****************    HSS-Unclassified    *************

****************************************************************= ********************************************
This email and any files= transmitted with it are confidential material.
They are intended solely= for the use of the designated individual or entity to whom they are= addressed.
If the reader of this message is not the intended= recipient,
you are hereby notified that any= dissemination,use,
distribution or copying of this communication is= strictly prohibited and may be unlawful.

If you have received this= email in error please notify postmaster@audiocodes.com and permanently= delete the e-mail and= files.


********************************************************= ***************************************************
"Please note:The email domain of Hughes Software Systems Ltd. has been changed to "hssworld.com" from hss.hns.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."
--=_alternative 004EA0C665256F39_=-- --===============0320356213== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0320356213==--